Начинаем карьеру программиста: Пишем код

Как начать карьеру программиста

Каждую неделю вижу на тостере очередной вопрос из серии: “Ребята, программить умею, вчера вот градусы в фаренгейты на C++ переводил! Как теперь работу найти?”. Самое печальное, что отвечают на эти вопросы, чаще всего, такие же новички, советуя всякую чушь, типа: “Иди для начала в opensource”, “Пойди на курсы «Супер-Стартап своими руками за 16 дней»”, “Устройся уборщицей, и дорасти до программиста”… На самом деле, начать карьеру программиста достаточно легко. Нет, конечно, если вчера ты узнал, что твой школьный товарищ Василий получает зарплату в три раза больше твоей за то, что программирует в каких-то интернетах, и тоже захотел программировать интернеты – мне тебя порадовать нечем. Я предполагаю, что читатель этих строк уже определился с будущей специализацией, прочел пару-тройку книжек и чувствует, что готов зарабатывать программированием на хлеб. Вот только не знает как.

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

(далее…)

Код, который рассказывает историю, или снова о чистоте кода

clean code

Эйнштейн однажды сказал:

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

Я совершенно уверен, что мистер Эйнштейн не написал при жизни ни строчки кода, однако, для таких людей, как я (а возможно и как вы), которые пишут и видят много кода, эти слова звучат так, как будто были написаны про разработчиков ПО.

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

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

Я знаю, что не решу проблему написанием очередной статьи, но я не могу промолчать! Я просто надеюсь, что кто-нибудь прочитает это, и исправится. Хотя бы на какое-то время. Хотя бы на день… Кто знает, возможно эта статья изменит хоть что-нибудь.

(далее…)

Fuck!!! Или автоматизируем исправление ошибок в консоли.

The fuck

Все мы постоянно опечатываемся в консоли. atp-get, git brnch, cta и.т.д. Ну может и не все, но я так точно, знаете, до компа, я печатал на печатной машинке, и поэтому, вместо мягкого нажатия, долблю пальцами по клавиатуре со всей силы, с высоты примерно в пол метра. Прикольно то, что все мы опечатываемся одинаково (кстати, в топе урлов в моем браузере наверняка есть “млюсщь” и “чмшвущыюсщь”). Даже странно, что такую нужную утилитку придумали только сейчас. Я говорю про программу с лаконичным названием “The Fuck”. Смысл в том, что после установки утилиты, по команде fuck программа сама исправит и выполнит последнюю введенную команду. Немного примеров:
(далее…)

Создаем свой Фреймворк на компонентах Symfony2

1419434926_hq-wallpapers_ru_cars_26439_1920x1200

Я совершенно не фанат Symfony2. У меня нет ни одного проекта на этом фреймворке, и вряд ли когда-нибудь хоть один появится. Это к тому, что я решил перевести цикл статей “Создаем свой Фреймворк на компонентах symfony2” совсем не из-за Symfony2. Этот цикл должен прочесть каждый. Этот цикл про программирование, про ООП, про архитектуру. Этот цикл – best practices разработки проектов на PHP. Изначально, конечно, Фабьен Потенсьер, автор оригинального текста и создатель Symfony2, задумывал эти статьи как рекламу своего фреймворка. Но что-то пошло не так…

Содержание цикла:

(далее…)

Создаем свой Фреймворк на компонентах symfony2. Часть 12

1419434926_hq-wallpapers_ru_cars_26439_1920x1200

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

Сам фронт-контроллер стал куда более лаконичным:

(далее…)

Создаем свой Фреймворк на компонентах symfony2. Часть 11

1419434926_hq-wallpapers_ru_cars_26439_1920x1200

Если бы вы использовали наш фреймворк прямо сейчас, вы бы наверняка задумались о поддержке кастомных сообщений об ошибках. Мы уже имеем обработку для ошибок 404 и 500, но способ обработки захардкоден во фреймворке. Сделать их кастомизацию – легче легкого, достаточно определить новое событие, и слушателя, который будет вызывать по этому событию определенный контроллер. Вроде все просто, но, что если, в этом контроллере выбросить исключение? Вы получите бесконечный цикл! Не самый лучший вариант правда?

Посмотрим на класс HttpKernel, который является универсальной, расширенной и гибкой имплементацией интерфейса HttpKernelInterface. Этот класс очень похож на класс фреймворка, который мы пишем. Он управляет событиями в некоторых важных участках кода в процессе обработки запроса. Он использует Controller resolver, для сопоставления контроллера запросу. И в качестве бонуса, он предоставляет отличную обратную связь, при возникновении проблем.

(далее…)

Создаем свой Фреймворк на компонентах symfony2. Часть 10

1419434926_hq-wallpapers_ru_cars_26439_1920x1200

В десятой части этого цикла, мы поговорим об одном из преимуществ использования компонентов Symfony2 – совместимости между всеми фреймворками и приложениями, которые их используют. Давайте сделаем большой шаг навстречу этому качеству: пусть наш фреймворк реализует интерфейс HttpKernelInterface.

HttpKernelInterface, наверное, самая важная часть кода в компоненте HttpKernel. Фреймворки и приложения реализующие этот интерфейс полностью совместимы. Более того, эта возможность может принести вам много отличного функционала.

Усовершенствуем фреймворк, для реализации данного интерфейса:

(далее…)

Создаем свой Фреймворк на компонентах symfony2. Часть 9

1419434926_hq-wallpapers_ru_cars_26439_1920x1200

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

О каком внедрении функционала я говорю? Например аутентификация, или кэширование инстансов. Причем внедрение функционала должно быть plug-and-play. По такому принципу работают например Drupal и WordPress. Часто эта возможность даже предусмотрена на уровне языка программирования, например WSGY в Python или Rack в Ruby.

Так как в PHP ничего подобного на уровне языка не предусмотрено, мы будем использовать хорошо известный шаблон Наблюдатель (Observer). В Symfony2 компонент EventDispatcher реализует упрощенную версию этого шаблона.

(далее…)

Создаем свой Фреймворк на компонентах symfony2. Часть 8

1419434926_hq-wallpapers_ru_cars_26439_1920x1200

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

Сегодняшняя задача – написать юнит-тесты для нашего фреймворка, с помощью PHPUnit.

Создадим файл конфигурации для PHPUnit phpunit.xml.dist:

(далее…)

Обзор книги “Искусство тестирования программ”

Искусство тестирования программ

Сейчас вот сижу, и не могу понять, а зачем я вообще приобрел эту книгу? Стоит она не дешево – 1300 рублей за 260 страниц устаревших методик. Купился на явно липовые отзывы на озоне? Ладно, не могу сказать что книга прямо бесполезна, нового я ничего не узнал (какой сюрприз, я не узнал ничего нового из книги написанной в 1979 году), но кое-что любопытное прочел.

В России книга переиздана (в третий раз) в 2015 году, однако по сути, это все та же книга из 79того. Просто невозможно без умиления читать главу про методы тестирования Инспеции, сквозные просмотры и обзоры программ, подразумевающие собрание из пяти человек и групповое обсуждение за столом(без компьютеров) участка кода, со скоростью 150 строк в час. Я прямо представляю, как я собираю у себя в компании программистов: “Ну ребят, ну отвлекитесь, я там новые 150 строк напечатал, нужно обсудить, ну!!!”.

“Порадовала” глава Высокоуровневое тестирование, которую по хорошему нужно было назвать “Как не закончить проект никогда”. Глава рассказывает о том, как навести в проекте отличную бюрократию в стиле романов Кафки, и явно предугадывая реакцию какого-то “очень умного” программиста из далекого 2015 года, автор рассказал в этой главе про критерии завершения тестов… Ну ни один из этих критериев я бы использовать не стал, тем более, что среди них есть совсем уж бредовые.

(далее…)