Ровно 15 лет назад, в этот самый день, своими дрожащими коленками я переступил порог офиса небольшого провинциального интернет-провайдера. Моя первая настоящая работа в качестве программиста. Знаний почти нет. Тонкий испуганный голосок откуда-то из желудка советует развернуться и убежать подальше, пока окончательно не опозорился. Глубокий вдох-выдох, и вот генеральный директор уже ведет меня в небольшую комнатку-подвальчик, показывает на полуразобранный компьютер, видавший лучшие времена: «Это твое рабочее место. Устраивайся». Так началась моя карьера.

Но перенесемся в настоящее. Сейчас я пишу эти строки, сидя в удобном офисе престижного БЦ в центре Москвы. За плечами работа с крупными международными брендами и разработка сложных fintech приложений. Сотни книг прочитано и десятки статей написано. Мания величия давно вылечена. Менеджерские позиции опробованы и отвергнуты. Душевное равновесие найдено. Любовь к профессии сохранена. Однако это не статья из серии “Какой я молодец. Делай, как я и тоже будешь молодцом”. Эта статья о том, какие ошибки я совершал и что можно было сделать лучше. Эта статья — ретроспектива моей карьеры.

Ведущие разработчики, они же Senior developers. Это те самые люди, которые на своем веку перевыполняли уже все возможные задачи. Это люди, которые входят в переговорку, открывая дверь с ноги. Они — решение всех проблем компании и гарантия светлого будущего. Они не изучают технологии, а изобретают. Они знают бизнес-требования до того, как те были сформулированы. И самое главное: они четко и отчетливо представляют себя через пять, а иногда и через десять лет.

Серьезно, мне кажется, что от сеньоров сейчас слишком много ожиданий. Судя по вакансиям, это такой аналог советских космонавтов. Если внезапно в вашем офисе перестанет работать stackoverflow, вся документация, да и вообще интернет, версия компилятора/интерпретатора доунгрейднится на 5 лет назад, а вам срочно нужно будет написать аналог Редиса, не используя сторонних фреймворков и библиотек — вы обязаны это сделать. Причем за пару часов и излучая стрессоустойчивость.

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

Качество кода не только в том, как он работает, но и в том как выглядит. То, что единый в рамках кампании code style — это очень важная вещь — в наши дни убеждать уже никого не нужно. Код должен быть не только написан, но и оформлен. В плане оформления PHP кода, утилита php-cs-fixer давно уже стала стандартом. Использовать ее довольно просто, есть куча правил и можно удобно забиндить ее запуск на какую-нибудь комбинацию клавиш в шторме или на pre-commit hook в гите. Все это легко гуглится и подробно разбирается в сотнях статей. А мы сегодня поговорим о другом. Хотя в php-cs-fixer есть большое количество разных фиксеров, но что, если нам понадобится такой, которого там нет? Как написать собственный фиксер?

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

Компьютер всегда прав

Самая раздражающая ситуация в программировании — когда код верный, но не работает. “Да тут три строчки, блин, просто негде ошибиться! Наверное баг! Пойду потрачу три дня на изучение баг-репортов компилятора/интерпретатора/фреймворка...”. Возникает чувство, будто компьютер над вами издевается!

Тут главное помнить, что в этих трех строчках есть ошибка. Если код работает не верно — значит код написан не верно. Точка. Виноваты только вы. Универсальный совет — идите спать! Ну или хотя бы отвлекитесь на чашку чая. Когда, через некоторое время, вы вернетесь к коду, наверняка станет ясно, что тут лишний оператор отрицания, или перепутаны две переменные с похожими именами, или еще какая-нибудь мелочь, в которой мы никогда никому не признаемся.

[Дабы не возникло недопонимания, стоит пояснить, что автор оригинального текста — Fabien Potencier, создатель популярного PHP фреймворка Symfony — прим. пер.]

Совсем недавно, Nils Adermann, прислал мне милую открытку, в напоминание о нашей встречи три года назад на “SymfonyLive hackday” в Сан-Франциско. Nils присутствовал на конференции, т.к. за год до этого, он анонсировал, что phpBB в версии 4 перейдет на Symfony.

В то время, я серьезно интересовался темой менеджеров пакетов, ибо искал удобный способ управлять бандлами в Symfony2. Для плагинов в Symfony1 я использовал PEAR, но код был очень запутанным, ведь PEAR изначально создавался немного не для этого. Философия Бандлера из Ruby сообщества выглядела очень привлекательно, так что я начал поиски подобного пакетного менеджера. После долгих бессонных ночей, я наткнулся на libzypp, и моментально понял, что это оно! К сожалению libzypp — сложная библиотека, написанная на C, и в таком виде, совсем не подходила для Symfony.

Я смекнул, что хорошим менеджером пакетов, позволяющим пользователям легко устанавливать плагины/бандлы/моды наверняка интересуется и Nils, для phpBB, так что я завел об этом разговор на hackday в Сан-Франциско. Оказалось, что в то время, Нилс уже начал работу над Composer.

Любите программировать? Тогда и не мечтайте о должности CEO, если только не начнете свой бизнес, и даже в этом случае, менеджмент, скорее всего, вытеснит кодинг из вашей жизни.

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

Если же вы решите переметнуться в менеджеры, то все дороги для вас открыты. Бывший CEO компании в которой я работаю, начинал как программист 25 лет назад, через 10 лет переключился в менеджмент, и прошел весь путь, до CEO четырех-миллиардной компании. Не так давно, он ушел на пенсию, имея особняк, машины и не имея никаких беспокойств. Тем временем, я работаю с людьми, которые начинали с ним, и которые до сих пор просто ведущие инженеры по разработке программного обеспечения.

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

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

В последнее время, набирает популярность мысль, что комментарии в коде — дело не обязательное, и даже вредное. Буквально вчера вечером, общаясь со знакомым молодым программистом, попросившим посмотреть его код, я обнаружил, что комменты отсутствовали вовсе, даже привычные описания методов. На мой удивленный смайлик, был ответ: “Комментарии — первый признак плохого кода”. И черт бы с ним, с начинающим программистом, но я периодически читаю что-то похожее в блогах, и слышу от коллег. Может программирование в очередной раз сделало шаг вперед, а я, среди отстающих? Под катом, немного размышлений, о том, когда и почему стоит или не стоит комментировать свой код.

Chris Pattle, web-разработчик из Великобритании, сделал потрясающую вещь — нарисовал персонажей всеми любимого мультсериала «Симпсоны» на чистом CSS. Код можно посмотреть в его аккаунте на github, или тут, под катом.

За то время, что я занимаюсь программированием, я видел не мало проектов, загнувшихся, благодаря фанатичному следованию различным модным правилам и практикам. Это может быть что-то увлекшее всю команду, например OOP или TDD, или что-то, на чем настоял отдельный разработчик, например: табы против пробелов, или определенный стиль фигурных скобок. Даже программист работающий в одиночестве, может саботировать проект, выбрав фетиш в ущерб продуктивности.
Вот немного вещей, отнимающих часы, а то и дни программистского времени:

Списки книг

• 25 бесплатных книг по информатике
• Шпаргалки
• CodePlex: Список бесплатных книг
• Бесплатные технические книги
• Galileo Computing (Немецкий)
• How to Design Programs: An Introduction to Computing and Programming
• Microsoft Press: Бесплатные книги
• MindView Inc
• Проект O'Reilly's Open Books
• TechBooksForFree.com
• Theassayer.org
• Wikibooks: Программирование
• Неплохая подборка, редактируемая сообществом (JIghtuse)
• Книги на Русском (telteron)

Программирование графики

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

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

Звонков было много, за следующую неделю я посетил 17 собеседований, по 3-4 в день, в четверг я уже перестал соглашаться на собеседования, а звонки все шли и шли.

Это не статья из серии, «смотрите как меня все хотят, я офигенен», я просто хочу сказать, что сейчас в России существует дефицит IT специалистов, и когда подходящий человек приходит к вам в компанию, важно не только то, насколько он понравится вам, но и то, насколько вы понравитесь ему, ибо мне кажется, что сейчас конкуренция существует скорее на вашей стороне, на стороне работодателей, чем на стороне программистов. Оговорюсь сразу, речь не пойдет о всяких Яндексах, ВКонтактах и Мэилру, там все ясно, речь идет о компаниях второго эшелона, предыдущей ступени.

Сидя в старбаксе, в ожидании своего американо, я наблюдал за двумя парнями, взявшими газету, и затеявшими обсуждение вердикта по делу Apple — Samsung.
— Постой, то есть получается, что Samsung — то же самое что и Apple?
— Представляешь да!? Это заставляет задуматься о том, сколько я отдал за свой Mac Book!
— Да уж…

Не прошло и десяти минут, как я слышу диалог мужа и жены, по тому же поводу:

Очередной крупный взлом. Как сообщает администрация androidforums.com, форум был взломан, и злоумышленники получили доступ к персональным данным более 1,2 млн учетных записей. Радует факт, что пароли, таки, были захэшированы.
Так что, если вы были зарегистрированы на androidforums.com, не забудьте сменить пароль.

Напомню, что это не первый крупный взлом на этой неделе. Совсем недавно были взломаны: Yahoo Voices, Formspring, Last.fm, eHarmony и LinkedIn.

Хакерская команда D33Ds Company выложила в сети более 453 тысяч паролей пользователей сервисов Yahoo.
Известно, что взлом произвели через union-based sql injection.
А самое интересное, что пароли хранились в незашифрованном виде.
Под катом, линк на файл с паролями.

В очередной раз, согласившись на фрилансерский заказ (а ведь обещал себе покончить с фрилансом раз и навсегда), я тяжело вздохнул, и при первой же возможности, сел изливать свои мысли на бумагу. Когда мы начинаем новый проект, часто у нас не хватает опыта сделать это правильно, иногда нам просто лень изучать новые технологии, но чаще всего, мы уверенны что и так все прекрасно спрограммируем, без всяких VCS, фрэймворков и миграций. Для тех, кто может найти в себе силы на что то большее, чем связка Denwer -> ftp client -> hosting, я набросал несколько рекомендаций, как можно сделать процесс разработки web-приложения немного более удобным.

За те 9 лет, что я занимаюсь программированием, в мою асю пришло несколько сотен просьб о помощи, от менее опытных, начинающих программистов. И вот, когда сегодня, в очередной раз, незнакомый человек попросил помочь ему написать плагин для вордпресс (код которого, честно говоря, я в глаза ни разу не видел), я решил написать небольшой гайд, который бы помог начинающим программистам правильно обращаться за советом к более опытным.

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

Основные функции

• Вывод ссылки «Купить»
• Вывод списка товаров в корзине с названием, ценой, кол-вом, суммой (кол-во * цена), ссылкой на удаление товара из корзины, общей суммой всех товаров в корзине, и общим кол-вом товаров в корзине.
• Вывод формы редактирования корзины, т.е. изменение кол-ва товара в корзине (input), удаление товара из корзины (checkbox) плюс все функции предыдущего пункта

Это только beta версия, так что обо всех багах сообщайте в комментах, тут или на моем сайте. Так же, если что-то непонятно по использованию — пишите, все объясню.

Документация и сам модуль

Я много писАл о том, как же прекрасна эта игра, под названием программирование! Мне, и я уверен, что многим из вас, программирование заменяет все существующие логические игры, дает постоянный разогрев мозгам, не давая им засохнуть, и приносит дикое моральное удовлетворение, отличающееся от оргазма только отсутствием физических ощущений.
Так уж получилось, что много лет назад, я забросил c++ и Delphi, и чувствуя потребности IT рынка, начал осваивать php. Так что все, о чем я буду писать, касается конкретно web-программирования, и косвенно любой другой области программирования.
Признаюсь честно, хотя работы хватает, мои мозги, все равно, начинают сохнуть. Я уже писал раньше, что момент, когда программист становится профессионалом, обусловлен, прежде всего, выдвижением на первый план качества и сроков реализации проекта. А значит приходиться использовать готовые продукты (я имею ввиду различные cms), которые обеспечивают должное качество, отсутствие уязвимостей и багов, гибкость, и короткие сроки реализации.