Захотелось поделиться с сообществом собственными наблюдениями на тему карьерного роста технаря.

Информация основана на опыте в больших западных конторах, которые делают реальные продукты. Всё изложенное ниже не претендует на абсолютную истину.

Начнем сначала: вы свежий выпускник тех. вуза. Вам 22-23 года, вся жизнь впереди и она прекрасна. В этом прекрасном будущем есть, скорее всего, есть жена-модель, дом – полная чаша, несколько машин, и первый миллион к 30 годам.

Карьера представляется немного смутно, но в целом, понятно: начинаем активно и качественно работать, нас, несомненно, замечают и продвигают. Множество фильмов и книг именно так нам и обещают: много и хорошо работай –> и всё будет хорошо.

Вы устраиваетесь на работу, ваше звание — инженер или разработчик. У вас появляются коллеги. Почти все они старше вас. И тут вы, возможно, заметите, что на таком же уровне, как и вы, есть очень пожилые люди. Прямо 30-40 летние мужики, может даже 50ти летние “стариканы”. И многие из них тоже закончили похожие вузы, и многие совсем не дураки, но как-то не сложилось с карьерным ростом…

Получается хороший вуз, диплом, интеллект, работоспособность, хорошее первое рабочее место – далеко не гарантия того, что вы вырастете в иерархии.

В последние несколько лет моя работа связана с использованием CMS Drupal, но на досуге я изучал и just for fun запускал проекты на питоновских фреймворках Django, Flask и Twisted. Сейчас я решил освоить основы двух-трех популярных PHP-фреймфорков и первыми я решил изучить Zend Framework 2 и Yii.

В процессе ознакомления с Zend Framework 2 я изучил туториал с официального сайта (http://framework.zend.com/manual/2.2/en/user-guide/overview.html), просмотрел документацию фреймворка (http://framework.zend.com/manual/2.2/en/index.html), прочитал книгу Michael Romer “Web development with Zend Framework 2” и собрал собственное тестовое приложение.

Переварив всю эту информацию, я пришел к мысли, что официальный туториал к фреймворку суховат:

• в нем не рассказывается о работе с пользователями, сессиями и правами доступа,
• лишь вскользь рассматривается такая основополагающая часть фреймворка как ServiceManager,
• в качестве интерфейса с базой данных безальтернативно используется паттерн Table Gateway (и соответствующая его реализация в фреймворке),
• используется встроенный в фреймворк шаблонизатор, который после питоновского Jinja 2 кажется совершенно неудобным и примитивным,
• и т.д.

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

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

• в качестве шаблонизатора будет использоваться Twig,
• для работы с БД — Doctrine ORM,
• для авторизации/аутентификации и распределения прав доступа я буду использовать существующие модули ZfcUser и BjyAuthorize,
• также я рассмотрю вопросы разработки собственных валидаторов форм, View плагинов и другие.

Ну про Zend сертификацию PHP 5.3 никто еще не писал, попробую написать я, надеюсь, будет интересно.

План будет таков: сначала я расскажу зачем, потом о подготовке и о сдаче экзамена.

Приступим!

В этом топике я хотел бы рассказать о том, как устроена кассандра (cassandra) — децентрализованная, отказоустойчивая и надёжная база данных “ключ-значение”. Хранилище само позаботится о проблемах наличия единой точки отказа (single point of failure), отказа серверов и о распределении данных между узлами кластера (cluster node). При чем, как в случае размещения серверов в одном центре обработки данных (data center), так и в конфигурации со многими центрами обработки данных, разделенных расстояниями и, соответственно, сетевыми задержками. Под надёжностью понимается итоговая согласованность (eventual consistency) данных с возможностью установки уровня согласования данных (tune consistency) каждого запроса.

NoSQL базы данных требуют в целом большего понимания их внутреннего устройства чем SQL. Эта статья будет описывать базовое строение, а в следующих статьях можно будет рассмотреть: CQL и интерфейс программирования; техники проектирования и оптимизации; особенности кластеров размещённых в многих центрах обработки данных.

Эта статья рассказывает о времени выполнения и о расходе памяти большинства алгоритмов используемых в информатике. В прошлом, когда я готовился к прохождению собеседования я потратил много времени исследуя интернет для поиска информации о лучшем, среднем и худшем случае работы алгоритмов поиска и сортировки, чтобы заданный вопрос на собеседовании не поставил меня в тупик. За последние несколько лет я проходил интервью в нескольких стартапах из Силиконовой долины, а также в некоторых крупных компаниях таких как Yahoo, eBay, LinkedIn и Google и каждый раз, когда я готовился к интервью, я подумал: «Почему никто не создал хорошую шпаргалку по асимптотической сложности алгоритмов? ». Чтобы сохранить ваше время я создал такую шпаргалку. Наслаждайтесь!

В заметке собраны сайты с обучающими материалами для веб-дизайнеров и веб-разработчиков. Старался не повторяться с постом 27+ ресурсов для онлайн-обучения хабраюзера nicolausYes.

Academic Earth

Множество бесплатных лекций, в том числе от известных университетов (Гарвард, MIT, Стенфорд и др.).

В подборке инструменты, плагины и другие полезности, облегчающие работу с Twitter Bootstrap. Предыдущая подборка.

Инструменты

Bootstraptor — подборка большого количества бесплатных и премиум тем, в том числе Starter Kit, на основе Bootstrap.

Как получить работу инженера?

Давай на чистоту. Ты хороший кандидат на должность инженера? Как ты сам себя оцениваешь? Много ли компаний, в которых ты бывал на собеседованиях? Каково у тебя отношение пройденных интервью к полученным предложениям о работе? Попробуй воспользоваться следующей формулой (это мое сферическое измерение в вакууме, которое не означает ровным счетом ничего):

# x = количество компаний, в которых ты проходил собеседования

# y = количество предложений о работе, которые ты получил

рейтинг = 100 * log(x) * y / x


Если твой рейтинг < 90, обязательно прочти это. Если > 120, возможно, тебе это не нужно, но, все равно прочти.

Так уж повелось, что программисты закрепляют удачные решения в виде шаблонов проектирования. По шаблонам существует множество литературы. Классикой безусловно считается книга Банды четырех «Design Patterns» by Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides" и еще, пожалуй, «Patterns of Enterprise Application Architecture» by Martin Fowler. Лучшее из того, что я читал с примерами на PHP – это «PHP Objects, Patterns and Practice» by Matt Zandstra. Так уж получилось, что вся эта литература достаточно сложна для людей, которые только начали осваивать ООП. Поэтому у меня появилась идея изложить некоторые паттерны, которые я считаю наиболее полезными, в сильно упрощенном виде. Другими словами, эта статья – моя первая попытка интерпретировать шаблоны проектирования в KISS стиле.
Сегодня речь пойдет о том, какие проблемы могут возникнуть с инициализацией объектов в ООП приложении и о том, как можно использовать некоторые популярные шаблоны проектирования для решения этих проблем.

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

Любой программист создающий нагруженные проекты с тысячами пользователей, когда-либо задавался вопросом, как он может улучшить SQL запросы и экономить многие сотни долларов. Процесс анализа обычно начинается с профилирования и отладки кода приложения. Далее происходит процесс оптимизации SQL запросов, для этого можно воспользоваться встроенными иструментами MySQL сервера. Например логирование MySQL в файл. Но рано или поздно начинаешь понимать, что это не удобно.

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

Насколько просто сейчас сделать такой сервис, как хостинг изображений? В принципе, его и раньше было несложно сделать. Но прогресс не стоит на месте, и за то же самое время теперь можно учесть больше нюансов. Я уже рассказывал о проекте Uploadcare. Это сервис, позволяющий облегчить работу с файлами: загрузку, хранение, обработку и раздачу конечному пользователю. Его и будем использовать в качестве основного блока.

Пример будет написан на Питоне. Во-первых, потому что Питон я знаю лучше всего, во-вторых библиотека pyuploadcare обновляется в первую очередь. На самом деле, для Uploadcare есть библиотеки под разные языки, и все они в open source. Если в нужном вам модуле отсутствует какая-то функциональность, можно дождаться, когда она появится, или дописать самому.

Node.js — вещь, вокруг которой сейчас много шума, восторженных отзывов и гневливых выкриков. При этом, по моим наблюдениям, в умах людей закрепилось следующее представление о том что же такое Node.js: «это штука, позволяющая писать на JavaScript на серверной стороне и использующая JavaScript-движок от Google Chrome». Поклонники языка восторженно вздохнули: «Ах! Сбылось!», противники же процедили сквозь зубы: «Ну вот только еще этой ерунды с прототипами и динамической типизацией нам на серверах не хватало!». И дружно побежали ломать копья в блоги и форумы.

При этом многие представители обоих лагерей придерживаются мнения, что Node.js — это эзотерическая игрушка, веселая задумка для переноса языка браузерных сценариев на «новые колеса». Дабы быть до конца честным, признаюсь, что я так же придерживался подобной точки зрения. В один прекрасный момент, я набрался духу и решил «копнуть поглубже». Выяснилось, что создатель Node.js Райан Дал далеко не фанатик, а человек, пытающийся решить реальную проблему. А его творение — не игрушка, а применимое на практике решение.

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

tl;dr Eсть новое API для асинхронного try\catch. Из статьи можно скопипастить пример и поиграться.

Бывает что есть сайт, но пользоваться им с мобильного телефона не очень удобно и было бы замечательно иметь отдельное приложение для него. Любители веб разработки легко смогут это сделать использую phoneGap. Под катом речь пойдет про сервис отслеживания почтовых отправлений, которым я часто пользуюсь и написанный для него демонстрационный клиент с базовым функционалом: авторизация, получение списка треков и описания к ним и возможность добавить новый трек. Я не связывался с разработчиком по этому поводу и очень надеюсь что он на меня не обидится за наглость, за копание в JavaScript коде и за то что в приложении не будет показана реклама. Так же прошу простить за костыльность и велосипедность кода, воспринимайте его как пример.

tmux — это менеджер терминалов, к которому удобно подключаться и отключаться, не теряя при этом процессы и историю. Как screen, только лучше (в первую очередь потому, что использует модель клиент—сервер).



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

Хай, Хабр!
Сегодня я хочу представить, дорогому хабрасообществу свой первый хабраперевод. Программировать на языке Python — подобно песне. Но еще лучше, когда Ваш код читаем и понятен, а значит чуть более поэтичен, чем обычно бывает производстве. У каждого свои правила и свои стереотипы относительно написания и оформления исходного кода, на каком бы языке он ни был написан. Множество копий сломано о щиты на форумах, но, как ни крути, нельзя не считаться с мнением авторитетных товарищей. Так что сейчас будет представлен перевод первой части стайл-гайда для языка Python от Google. Коснется он именно постулатов написания кода (вторая часть тоже скоро появится, а посвящена она будет форматированию исходного кода). Сразу предупреждаю: тут много (если не большая часть) прописных истин, которые все знают уже давно. Но я искренне надеюсь, что Вы сможете найти тут что-то новое или хотя бы вспомнить старое. Приступим под катом. И pdf тут как тут.

Оригинал статьи: smyck.net/2012/04/22/why-erlang

Шансы, что вы читаете эту статью на устройстве с многоядерным процесcором, растут каждый день, вот почему все постоянно говорят про параллелизм (concurrency). Параллелизм для наших web приложений и API бэкендов, это когда вывод htop выглядит примерно как на картинке:



Я недавно был на великолепной Ruby конференции и три или четыре доклада были про параллелизм. Сообщество Ruby достаточно открыто и обсуждалось достаточно много возможностей: использовать потоки, использовать различные среды выполнения Ruby, чтобы обойти GIL, использовать больше процессоров, использовать модель акторов через библиотеки как Celluloid или даже использовать Akka через JRuby.

В то время как модель акторов, кажется, хорошо подходит для создания сетевых параллельных приложений, которые часто страдает от проблем, если среда выполнения, на которой реализовано приложение не имеет нативной поддержки. Существуют реализации для Ruby, Python и Java, но все они должны подстраиваться, чтобы достичь нормальной работы и не обязательно результат даёт наилучшую производительность. Это одна из многих причин, почему Erlang был бы намного лучшим выбором, но сначала, давайте немного уделим время модели акторов, чтобы понять, почему это так хорошо работает.

Позавчера (27 апреля) из праведных недр интеловского Центра технологий с открытым исходным кодом (а это тот самый Центр, который hshhhhh обозревал неделю назад во блогозаписи «Печеньки для пингвина») вышла в свет новая версия движка node-webkit — могучего объединения Node и WebKit (точнее даже не просто WebKit, а Chromium — и в дальнейшем, вероятно, Blink), обеспечивающего быстрое и бесхитростное создание GUI-приложений методами веборазработки (код на JavaScript с употреблением API от Node.js, а интерфейс на HTML да на CSS) под операционные системы Windows, Mac OS X и Linux.

Новая версия имеет номер 0.5.1; на её основе нетрудно составить и запустить, например, вот такое окно:



Одну из предыдущих версий node-webkit (0.4.1) мне довелось обозреть в начале февраля, а теперь на дворе конец апреля. Настала пора рассказать обо всех тех изменениях, которыми сопровождался выход версии 0.4.2, за нею 0.5.0, и затем 0.5.1 наконец. Рассказываю:

Недавно мне довелось разобраться и устранить несколько утечек памяти в популярном фреймворке Торнадо. Не беда, если вы никогда его не использовали, потому что описанное будет мало связано с ним. Рассказать я хочу о методах, которые я использовал для поиска и устранения утечек.

Все сказанное будет по большей части справедливо только для самой популярной реализации Питона — CPython. Как известно, в нем есть два механизма освобождения памяти. Первый из них — подсчет ссылок. Каждый раз, когда вы явно или не явно создаете новый объект, его счетчик ссылок равен единице. Если вы присваиваете этот объект новой переменной или передаете в качестве аргумента, его счетчик ссылок увеличивается. При выходе из функции количество ссылок на объекты, которые были в локальных переменных и аргументах, уменьшается. Если для какого-то объекта количество ссылок становится равным нулю, он немедленно уничтожается.

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

Формально, циклические ссылки нельзя назвать утечками: сборка мусора рано или поздно уничтожит такие объекты. Беда только в том, что Питон не может сам определить, когда еще рано, а когда уже поздно. В моем случае система просто прибивала процесс с Питоном, если сборка мусора не начиналась вовремя.