Привет Хабр!

Расскажу и я свою историю.

Случилось так, что однажды я устроился на должность начальника технического отдела в одном небольшом интернет-провайдере. Компания на тот момент испытывала некоторые проблемы технического характера, технаря найти не могли. В тот момент я как раз искал нормальную работу — за год до этого ушел с великого и могучего завода АвтоВАЗ (работал в Дирекции Информационных Систем) — кризис прижал, денег не давали. После — год работы учителем в школе (параллельно регистрировался как ИП), в общем крутился как мог. И находясь осенью в другом городе, от знакомого узнаю о том, что срочно нужен технарь. Пришел на собеседование без особой надежды, да и большого желания, и как оказалось — зря. После примерно 10-минутной беседы директор попросил выйти сегодня же. И я вышел.

Как там говорится, то все присказка была?

Как часто вас посещала мысль о трудоустройстве за границей, будь то просто временная работа или переезд на постоянное место жительство? Какую страну выбрать? Возможно ли пройти собеседования за тысячи километров по телефону и получить джоб-офер? Как будет выглядеть переезд и жизнь в другой стране? В данной статье я бы хотел поделиться личным опытом и опытом многих моих друзей работающих за рубежом.

Две недели назад я начал работу в датской компании "Secunia", и хочу — как и многие хабровчане, уехавшие работать за рубеж — поделиться своим опытом. Не уверен, к какому хабу это должно относиться, но вроде бы предыдущие подобные рассказы были в «Офисах IT-компаний».

Поиск работы

Всё началось с того, что Google AdWords показал мне ссылку на вакансию "Senior Reverse Engineer and Vulnerability Researcher". Как раз в это время я искал новую работу, и гугл, видимо, тонко проанализировал мою историю поиска и содержимое последних писем; а может быть, просто подфартило. Эта вакансия до сих пор открыта; и если кто-нибудь из вас на неё устроится, упомянув меня в качестве порекомендовавшего, то мне будет положен какой-то приятный бонус. Так что не стесняйтесь.

В начале ноября я отправил на рассмотрение своё резюме, и получил по очереди два тестовых задания. Оба были похожи: дан кусок дизассемблированного кода x86 (одно задание было на Си, другое на С++). Нужно восстановить исходник и найти в нём возможные уязвимости и другие проблемы. От момента получения кода, до отправки заключения по нему — даётся час. Длина кода — около сотни команд. Фактически, у меня уходило минут двадцать на его разбор, и минут двадцать на написание соответствующего кода на Си/С++. Ничего сложного для любого, кто когда-нибудь пытался ковыряться в чужих программах.

В конце ноября у меня — удачно совпало — уже была запланирована поездка по Скандинавии; и в тот единственный день, когда я был в Копенгагене, я решил заскочить в Secunia, почти без предупреждения. Новая удача: именно в этот день им какие-то строители экскаватором перерубили интернет, и все сотрудники сидели без дела. Поэтому CTO оказался свободен, чтоб меня прособеседовать. Он произвёл на меня весьма серьёзное впечатление, но больше я его с тех пор не видел; а с моим нынешним начальником мы тогда обменялись разве что парой слов. Они сказали, что пришлют мне последнее, самое сложное и важное задание, и после этого окончательно решат по поводу моей кандидатуры.

Это последнее задание мне прислали в начале декабря. Нужно было найти конкретную версию Adobe Reader, взять готовый PDF-файл, который её валит — и написать подробный отчёт, почему это происходит. На задание давался день, с комментарием «не торопись, сделай качественно, сможешь за четыре часа — отлично, за шесть — приемлемо». У меня ушло где-то часов восемь с перерывами на кофе. Я отправил результат, и принялся ждать.

До чего же странная штука твиттер! В одном профиле нет ничего, кроме коротких сообщений, как его владелец пошел в туалет и вернулся счастливым. В другом, президент США общается с американцами.

А один простой восемнадцатилетний школьник Майк Стоун воспользовался твиттером, чтобы на выпускной бал пригласить в качестве подружки порно звезду!

Несколько недель назад W3C был представлен черновик предложения о введении системы ограничений использования видео и аудио тегов в HTML5. Авторами данного предложения являются David Dorwin из Google, Adrian Bateman из Microsoft и Mark Watson из Netflix.

В данном предложение идет речь о создании некоего медия расширения в рамках HTML5, которое позволит приложению контролировать контент. Контроль будет осуществляться так называемым «сервером лицензий» на основе ключей полученных от самого приложения. Цель такого контроля конечно же понятна — защита копирайта, которую так желают многие компании. Хотя в самом документе говорится о том что этот функционал не является попыткой введения DRM в HTML5, все говорит о том, что как раз DRM это и есть.

Однако судя по всему не все в W3C согласны с разумностью таких нововведений. Скорее всего пройдет еще много времени прежде чем будет принято окончательное решение. Нам же только остается ждать и надеяться на благоразумность W3C, ведь мы все прекрасно знаем как хорошо работает DRM в игровой индустрии на сегодняшний день. Не так ли, Ubisoft?

Ссылка на черновик предложения на сайте W3C
По материалам Engadget

Судя по отзывам на мою предыдущую статью о процессе прохождения интервью, многие хаброколлеги интересуются, как лучше подготовиться к поиску работы на западе. Хочу поделиться моим опытом и дать ссылки, которые будут полезны тем, кто думает о переезде или просто хочет узнать, как это работает в другом мире. Статья ориентирована на среднестатистического разработчика ПО, так что если у вас блестящие навыки разговорного языка и превосходные знания нужных технологий и языков программирования, то многие советы можно пропустить.

Итак, вы задумались о поиске новой работы.

Здравствуйте, Хабраюзеры.

Этим постом я хотел бы начать цикл (если позволит время и будет интересно аудитории) про профессиональную эмиграцию, особенно без привязки к работодателю.

История

Внедрение Linux в ПриватБанке началось в 2007 году. За это время был пройден большой путь и хотелось бы поделиться с сообществом своим опытом внедрения. На данный момент мы достигли следующих показателей: более 36500 рабочих мест с ОС Linux в 4000 отделений, расположенных в 5 странах.
В 2007 году за основу был взят ASPLinux 11.2. Со временем для альтернативы были выбраны другие дистрибутивы — Fedora, openSUSE, Ubuntu. Позже стала очевидной необходимость создания собственного дистрибутива и системы управления рабочими станциями. Разработка началась в январе 2012 года. Для основы был выбран Ubuntu 12.04 LTS с рабочим окружением Gnome Classic (no effect). Основные аргументы: Ubuntu — самый распространённый десктопный дистрибутив последних лет; обширное комьюнити, где проще найти решение возникающих проблем; именно его в качестве основы внедрения выбрал Google, много примеров внедрения в государственных и муниципальных учреждениях Германии, Франции. Выбор системы управления остановился на Puppet.
В июне 2012 года стартовал переход и к январю 2013 на корпоративную ОС были переведены уже около 95% ПК. Такая скорость перехода обусловлена тем, что сотрудники уже имели опыт работы в Linux.

Основные задачи, которые удалось решить благодаря текущему внедрению:

• cущественная экономия ресурсов при поддержке ОС на рабочих местах сотрудников;
• поддержание программного обеспечения в актуальном состоянии;
• возможность оперативного применения критических обновлений (до 1 часа на всех ПК);
• cбор и анализ статистической информации о парке ПК и периферии;
• создание системы проактивной реакции на сбои (Event Manager).

Дальше более детальное описание компонентов нашей реализации.

Привет Хабр! Примерно год назад я представил вашему вниманию первую версию open-source библиотеки FileAPI, предназначенную для работы с файлами на клиенте и последующей загрузки на сервер.

За это время был пройден долгий путь. Библиотека заработала 670+ звезд и 90+ форков. С помощью github-сообщества удалось исправить множество «детских» проблем и внести ряд улучшений. Было закрыто более 100 тасков, и благодаря Илье Лебедеву сделана загрузка файлов по частям. Сегодня я с гордостью хочу представить вам FileAPI 2.0.

I-Tier: Расщепление монолита

Недавно мы завершили годовой проект миграции веб-трафика компании Групон в США от монолитного Ruby on Rails приложения к новому стеку Node.js и получили существенные результаты.

С самого начала весь веб-фронтенд американского Групона был единым исходным кодом Ruby. Код фронтенда быстро развивался, что затрудняло его поддержку и усложняло процесс добавления новых фич. В качестве решения проблемы с этом гигантским монолитом мы решили реструктурировать фронтенд посредством его разделения на меньшие, независимые и более простые в управлении части. Основой этого проекта стало разделение монолитного вебсайта на несколько независимых Node.js приложений. Мы также переделали инфраструктуру, чтобы обеспечить совместную работу всех приложений. Результатом стал Interaction Tier (I-Tier).

Вот некоторые из важных моментов этой глобальной архитектурной миграции:

• Страницы на сайте загружаются значительно быстрее

• Наши команды девелоперов могут разрабатывать и добавлять новые фичи быстрее и с меньшей зависимостью от других команд

• Мы можем избежать повторной разработки одних и тех же фич в разных странах, где доступен Групон.

Этот пост является первым из серии постов о том, как мы реструктурировали сайт и какие огромные преимущества мы видим в дальнейшем, которые будут лежать в основе продвижения компании Групон.

Этом цикле статей «Идеальный www кластер», я хочу передать базовые основы построения высокодоступного и высокопроизводительного www решения для нагруженных web проектов для неподготовленного администратора.
Статья будет содержать пошаговую инструкцию и подойдет любому человеку кто освоил силу copy-paste
Ошибки найденые вами, помогут в работе и мне и тем кто будет читать эту статью позже! Так что любые улучшение и правки приветствуются!

Хочу отметить, что эта инструкция родилась в процессе миграции web-систем компании Acronis в высокодоступный кластер. Надеюсь мои заметки будут полезны и для Вас!.

В процессе экспертизы и проведенных мною исследований, она доказала свое право на жизнь и благополучно служит нам верой и правдой день ото дня.

На frontend мы будем использоваться связку из двух службы:

keepalived — реализации протокола VRRP (Virtual Router Redundancy Protocol) для Linux. Демон keepalived следит за работоспособностью машин и в случае обнаружения сбоя — исключает сбойный сервер из списка активных серверов, делегируя его адреса другому серверу.

Другими словами, у нас 2 сервера на которых прописано по одному публичному адресу. Если любой из этих серверов падает, то адрес упавшего подхватывается вторым.
Демоны keepalived общаются по протоколу VRRP, посылая друг другу сообщения на адрес 224.0.0.18.
Если сосед не прислал свое сообщение, то по истечению периода он считается умершим и оба адреса обслуживает оставшаяся нода. Как только упавший сервер начинает слать свои сообщения в сеть, все возвращается на свои места

nginx [engine x] — это HTTP-сервер и обратный прокси-сервер, а также почтовый прокси-сервер, написанный Игорем Сысоевым. Уже длительное время он обслуживает серверы многих высоконагруженных российских сайтов, таких как Яндекс, Mail.Ru, ВКонтакте и Рамблер. Согласно статистике Netcraft nginx обслуживал или проксировал 15.08% самых нагруженных сайтов в октябре 2013 года.

Основная функциональность HTTP-сервера

• Обслуживание статических запросов, индексных файлов, автоматическое создание списка файлов, кэш дескрипторов открытых файлов;
• Акселерированное обратное проксирование с кэшированием, простое распределение нагрузки и отказоустойчивость;
• Акселерированная поддержка FastCGI, uwsgi, SCGI и memcached серверов с кэшированием, простое распределение нагрузки и отказоустойчивость;
• Модульность, фильтры, в том числе сжатие (gzip), byte-ranges (докачка), chunked ответы, XSLT-фильтр, SSI-фильтр, преобразование изображений; несколько подзапросов на одной странице, обрабатываемые в SSI-фильтре через прокси или FastCGI, выполняются параллельно;
• Поддержка SSL и расширения TLS SNI.

Другие возможности HTTP-сервера

• Виртуальные серверы, определяемые по IP-адресу и имени;
• Поддержка keep-alive и pipelined соединений;
• Гибкость конфигурации;
• Изменение настроек и обновление исполняемого файла без перерыва в обслуживании клиентов;
• Настройка форматов логов, буферизованная запись в лог, быстрая ротация логов;
• Специальные страницы для ошибок 3xx-5xx;
• rewrite-модуль: изменение URI с помощью регулярных выражений;
• Выполнение разных функций в зависимости от адреса клиента;
• Ограничение доступа в зависимости от адреса клиента, по паролю (HTTP Basic аутентификация) и по результату подзапроса;
• Проверка HTTP referer;
• Методы PUT, DELETE, MKCOL, COPY и MOVE;
• FLV и MP4 стриминг;
• Ограничение скорости отдачи ответов;
• Ограничение числа одновременных соединений и запросов с одного адреса;
• Встроенный Perl.

Картинка для придания нужного настроения

Доброго времени суток!

В интернете вообще и на Хабре в частности немало публикаций о ремонте битых блоков. Например, здесь о выдергивании неповрежденных данных, а тут история победы над битым LOB сегментом.

Приводить легионы ссылок на инет с подобными статьями не буду. Но есть в большинстве этих статей общая черта. Когда данные спасены (или уничтожены, как получится), предлагается победить поврежденный free block захватом всего свободного места в tablespace. И почему то это предложение описательно.

Так добавим конкретики!

Предлагаем вашему вниманию очередную подборку с ссылками на новости и материалы.

Кстати, вчера исполнился ровно год с момента публикации первого PHP-дайджеста на Хабре. Огромное спасибо всем, кто так или иначе помогал создавать дайджесты, спасибо разработчикам за замечательные инструменты, авторам за их полезные статьи, а главное спасибо вам за то, что до сих пор читаете!

Давным давно, на Хабре была опубликована статья, рассказывающая о том, как использовать популярную библиотеку, для работы с SNMP из Java-приложения. Поддерживая, в целом, начинание автора, я хочу остановиться на тех сложностях, которые могут возникнуть в реальном проекте, использующем SNMP.

Предлагаем вашему вниманию очередную подборку со ссылками на новости и материалы.

Приятного чтения!

Здравствуй, <%= habrauser %>!

Я очень люблю фреймворк Ruby On Rails, он правда очень и очень крут. Он позволяет в кратчайшие сроки реализовать твои замыслы. Раньше я много писал на нем, но сегодня я front-end разработчик. Когда я узнал о методологии БЭМ, я был в полном восторге, потому что так или иначе ты сам приходишь к чему-то подобному. Хорошо, когда дзен-процесс сокращается в разы. О том, что такое БЭМ можно прочитать тут и тут. Недавно прошедший BEMup окончательно расставил все на свои места. Мне были просто необходимы инструменты для работы с БЭМ в рамках проектов на Ruby on Rails. Конкретных решений не существовало, а bem-tools не подходит по вполне понятным причинам, описанным ниже. Я решил написать bem-tools на Ruby.

Добрый день уважаемые слушатели. Представляем новый выпуск подкаста RWpod. В этом выпуске:

Сегодня нам, компании Maxifier Development, исполняется 6 лет… Ну ладно, соврал, не сегодня. На самом деле случилось это недели две назад, но только сейчас, когда я возвращаюсь из нашего нью-йоркского офиса обратно в родную Самару, наконец-то дошли руки что-то написать по этому поводу.

За шесть лет мы прошли путь от идеи на бумажке до международной компании стоимостью в десятки миллионов долларов. Создали сложный программный продукт в области оптимизации Интернет-рекламы, которым ежедневно пользуются крупные медиа-компании в Европе и Америке и уже подтягивается Россия. Открыли офисы в США, Японии и Англии.

И совершили 1001 ошибку на этом пути, делая многие вещи медленнее и хуже, чем могли и должны были делать. Но только сейчас у нас накопилось достаточно мужества и сил, чтобы признать это публично, поделиться нашими успехами и неудачами, научить на своем опыте других и, получив отзывы, лучше научиться самим.

Я надеюсь, что теперь мы будем регулярно публиковать статьи, связанные как с нашей предметной областью, так и просто посвященные вопросам разработки, менеджмента, взаимодействия с клиентами и прочим «интересностям» в ИТ. Но в этой, начальной статье хочется просто оглянуться назад, на основные вехи развития нашей компании.

Все дела сделаны и теперь есть время черкануть пару строк об автоматизации тестирования…

Уважаемые разработчики и тестировщики программного обеспечения! Предлагаем вашему вниманию цикл статей на тему организации тестирования и разработки приложений в облачном окружении. В этот цикл входят следующие статьи:

1. Бесплатные мощности Windows Azure для подписчиков MSDN: как активировать и начать использовать?
2. Разработка и тестирование приложений в облачном окружении Windows Azure
3. Популярные сценарии разработки и тестирования в облаке
4. Разработка и тестирование на открытых технологиях в облаке на примере Node.js, Riak, Ruby on Rails и десятков других

В этой статье мы рассмотрим возможности по разработке и тестированию приложений построенных на открытых технологиях и операционной системе Linux в облаке Windows Azure. В частности, рассмотрим работу с тестовым окружением технологий Riak и Erlang, Node.js, Ruby on Rails.