Как вы наверное догадались, хочу рассказать о Yii2 и о том, что ждет новичков в стартапе, который выбрал данный фреймворк. Ни для кого не секрет, что многие фреймворки используют компоненты symfony, дабы не изобретать новый велосипед. Многие, но не Yii, но при этом Yii многое позаимствовал от symfony и впитал в себя лучшее от Ruby on Rails. На github в issues часто можно увидеть предложение по расширению функционала, перенятого у этих фреймворков. В данной статье хотелось бы описать именно те моменты, в которых разработчики Yii не сходятся во мнении с разработчиками других фреймворков.

Факт 1

Под капотом самых критичных программ, которые вы используете на ежедневной основе (Mac OS X или Facebook) содержится ужасное количество хаков и костылей, которые с трудом уживаются друг с другом. Это как если бы вы разобрали боинг 747 и увидели, что топливопровод держится вешалкой для одежды, а шасси смотаны изолентой.

Бен Черри

Наименование: Functional Decomposition (функциональная декомпозиция)
Другие наименования: No Object-Oriented AntiPattern «No OO»
Масштаб: приложение
Рефакторинг: объектно-ориентированный реинжиниринг

Функциональная декомпозиция — хорошая практика процедурного программирования, так как она позволяет разделить приложение на отдельные функциональные модули.

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

Этот пост посвящён оптимизации PHP с помощью профайлера Blackfire в PHP-скрипте. Нижеприведённый текст является подробным техническим объяснением статьи в блоге Blackfire.

Обычно применяется метод strlen:

if (strlen($name) > 49) {
...
}

Однако такой вариант примерно на 20% медленнее этого:

if (isset($name[49])) {
...
}

Выглядит неплохо. Наверняка вы уже собрались открыть ваши исходники и заменить все вызовы strlen() на isset(). Но если внимательно прочитать оригинальную статью, то можно заметить, что причина 20-процентной разницы в производительности — многократные вызовы strlen(), порядка 60-80 тысяч итераций.

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

Наименование: Dead End (тупик)
Другое наименование: Kevorkian Component (мертвый компонент)

Суть проблемы

Антипаттерн «тупик» получается в результате модификации повторно используемых компонентов, если компонент больше не поддерживается и не сопровождается его поставщиком. После внесения изменений в компонент, бремя его сопровождения перекладывается на разработчиков прикладной системы. Улучшения в повторно используемом компоненте не могут быть легко интегрированы а сделанные изменения могут стать причиной проблем при его поддержке.

«Я точно не знаю, что делает этот класс, но я уверен, что это важно!»

У паттернов проектирования — типовых решений, есть антиподы — типовые ошибки в проектировании. О паттернах проектирования написано достаточно книг, о антипаттернах — единицы. Вашему вниманию представлен вольный перевод статьи с сайта SourceMaking, описывающий один из таких антипаттернов (всего на сайте в разделе Software Development Antipatterns их представлено 14).

Наименование: Poltergeists (полтергейсты)
Другие наименования: Gypsy (цыган), Proliferation of Classes (рост количества классов), Big DoIt Controller Class
Масштаб: приложение
Рефакторинг: Ghostbusting (охота за привидениями)
Причина появления: непонимание концепций ООП, лень продумать архитектуру классов

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

Дисклеймер: этот текст меня заставило написать практически полное отсутствие вменяемых материалов по данной теме на русском языке. Этому плохо учат в вузах, об этом молчат самоучители PHP и официальный мануал, хотя это самый важный момент при разработке программы — создание архитектуры. Плохая архитектура может убить ваш проект, так что он никогда не увидит свет. Хорошая архитектура даже при плохом коде, а кто из новичков пишет хороший код, способна творить чудеса.

Разработка архитектуры должна начинаться в тот момент, когда вам в голову пришла идея «хочу сайт такой-то» или кто-то вложил идею «нужен сайт такой-то». К сожалению, большинство разработчиков сразу приступают к написанию кода, причём даже не того, какого нужно.

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

Некоторые из вас, возможно, слышали, что в первую неделю декабря по всей России прошла образовательная акция “Час кода": для школьников 5-11 классов проводили открытые уроки, на которых показывали, что программировать это просто и увлекательно и каждый может этому научиться.



Мы в Acronis решили поделиться собственным опытом: как мы пробуем обучать программированию наших сотрудников, не отрывая их от работы.

В этой статье я хочу сделать две вещи: рассказать, почему макросы — зло и как с этим бороться, а так же продемонстрировать пару используемых мной макросов C++, которые упрощают работу с кодом и улучшают его читаемость. Трюки, на самом деле, не такие уж и грязные:

• Безопасный вызов метода
• Неиспользуемые переменные
• Превращение в строку
• Запятая в аргументе макроса
• Бесконечный цикл

Заранее предупреждаю: если Вы думаете увидеть под катом что-то крутое, головоломное и сногсшибательное, то ничего такого в статье нет. Статья про светлую сторону макросов.

К добавлению внешнего сервера рано или поздно приходит любой сложный проект. Причины, при этом, бывают совершенно различные. Одни, загружают дополнительные сведения из сети, другие, синхронизируют данные между клиентскими устройствами, третьи- переносят логику выполнения приложения на сторону сервера. Как правило, к последним относятся большинство «деловых» приложений. По мере отхода от парадигмы «песочницы», в которой все действия выполняются только в рамках исходной системы, логика выполнения процессов переплетается, сплетается, завязывается узлами настолько, что становится трудно понять, что является исходной точкой входа в процесс приложения. В этом момент, на первое место выходит уже не функциональные свойства самого приложения, а его архитектура, и, как следствие, возможности к масштабированию.
Заложенный фундамент позволяет либо создать величественный архитектурный ансамбль, либо «накурнож» — избушку на куриных ножках, которая рассыпается от одного толчка «доброго молодца» коих, за время своего существования повидала видимо — невидимо, потому что, глядя на множественные строительные дефекты заказчик склонен менять не исходный проект, а команду строителей.
Планирование — ключ к успеху проекта, но, именно на него выделяется заказчиком минимальный объем времени. Строительные паттерны — туз в рукаве разработчика, который покрывает неблагоприятные комбинации где время — оказывается решающим фактором. Взятые за основу работающие решения позволяют сделать быстрый старт, чтоб перейти к задачам, кажущиеся заказчику наиболее актуальными (как-то покраска дымоходной трубы, на еще не возведенной крыше).
В этой статье я постараюсь изложить принцип построение масштабируемой системы для мобильных устройств, покрывающей 90-95% клиент-серверных приложений, и обеспечивающей максимальное отдаление от сакраментального «накурножа».

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

Дефекты программного кода

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

Белорусские Python’нщики верны своим традициям. Python Meetup состоялся 26 сентября, в последнюю пятницу месяца.
На встрече мы обсуждали извечную головную боль всех программистов – как писать красивый и понятный код без багов. Докладчики подошли к этой проблеме с разных сторон: Павел Кохан рассказал о пяти принципах S.O.L.I.D., которые помогают писать качественный код на любом объектно-ориентированном языке, а Олег Шидловский говорил о том, как ускорить работу хорошего кода.

Недавно в нашем проекте потребовалось настроить мониторинг качества кода. Качество кода — понятие субъективное, однако давным-давно придумали множество метрик, позволяющих провести мало-мальски количественный анализ. К примеру, цикломатическая сложность или индекс поддерживаемости (maintainability index). Измерение подобного рода показателей — обычное дело для языков вроде Java или C++, однако (складывается впечатление) в питоньем сообществе редко когда кто-то об этом задумывается. К счастью, существует замечательный radon с xenon-ом, который быстро и качественно вычисляет упомянутые выше метрики и даже некоторые другие. Конечно, для профессиональных enterprise инструментов маловато, но все необходимое присутствует.

Кроме вычисления метрик, бывает также полезно провести анализ зависимостей. Если в проекте задекларирована архитектура, то между отдельными частями должны существовать определенные связи. Самый частый пример: приложение построено вокруг библиотеки, предоставляющей API, и весьма нежелательно выполнять действия в обход этого API. Другими словами, нехорошо ioctl-ить в ядро когда libc есть. Для питона есть несколько пакетов, строящих граф зависимостей между модулями, и snakefood показался мне самым удачным.

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

Когда я агитирую коллег-программистов создавать больше различных автотестов на их код, они часто жалуются, что это сложная и унылая работа. И в чём-то они правы. При использовании классических юнит-тестов, действительно, нередко приходится писать уйму кода, чтобы проверить каждый отдельный случай поведения. Да и к качеству тестирования порой возникают вопросы, особенно в сложных системах, когда тривиальные сценарии использования проходят на ура, но на каких-то более сложных сценариях, на которые никто не подумал писать тесты, возникают неприятные проблемы.

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

В чём заключается QuickCheck-подход

Описать суть подхода можно довольно просто: мы не создаём тесты-примеры, а вместо этого задаём правила, которые определяют поведение системы на произвольных входных данных. Библиотека сама генерирует большое количество случайных входных данных и проверяет, соответствует ли поведение кода установленным правилам. Если это не так, то она показывает нам, на каком примере происходит падение теста.

Звучит многообещающе? Вполне.

Опоздал с деплоем на 15 минут

Кто не знает, хакатон – это офигенный способ поработать ещё и на выходных. Только один 48-часовой день, только работа, один проект и один результат, море нового опыта и куча новых связей, плюс знания-знания-знания.

Завтра вечером стартуют 45 одинаковых хакатонов за экологию по всему миру. Мы проводим свой российский #hack4good в коворкинге #tceh, потому что круто, праздник и вообще замечательная компания.

Зачем хакатоны – Кирилл Чуваков (наш резидент, участвовал и организовал в over9000 хакатонов)

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

Сейчас любое крупное приложение состоит из множества сторонних библиотек. Хочется поднять такую тему, как доверие к этим библиотекам. В книгах и статьях можно встретить очень много рассуждений о качестве кода, методах тестирования, методологиях разработки и так далее. Но я не помню, чтобы кто-то рассуждал о качестве кирпичей, из которых строятся приложения. Давайте немного поговорим об этом. Например, есть Medicine Insight Segmentation and Registration Toolkit (ITK). Мне кажется, он написан весьма качественно. По крайней мере, я заметил в коде весьма мало ошибок. Но я не могу сказать, что код используемых библиотек столь же качественен. Тогда вопрос. Насколько мы можем доверять таким системам? Есть повод для размышлений.

На данную статью меня сподвиг следующий пост «Как улучшить свой стиль программирования?» плюс недавний спор среди коллег.

Представьте себе такой диалог:

Админ: Господа, разработчики, ваш код на сервере стал поедать много оперативки. Сервер уже свопиться начинает. Сами понимаете, все может встать колом!
Представитель разработчиков (например, тимлид): Блин, беда. Сейчас займемся проблемой.
Эй, команда, нас тут админы стыдят за неоптимальный код. Нужно срочно все бросить и оптимизировать старый код.
Менеджер проекта: Эй, вы куда? Какая оптимизация? Пусть админы докупят памяти в сервера и проблемы нет. А у вас вон кучу нового функционала нужно разработать. Никакой оптимизации! Сосредоточьтесь на новом функционале. Нам нужно опередить конкурентов с новыми фичами. Потом как-нибудь оптимизируете свой код.

И кто по вашему прав? Что нужно сделать? Сделать апгрейд железа или заняться оптимизацией?
В конце статьи будет голосование.

Исповедь 1

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

Весь мой опыт программирования складывается из университетских работ и пары лет пребывания в различных компаниях. Критикующие меня люди неоднократно говорили мне, что в целом я разбираюсь в теме, так что я далеко не клинический случай, как можно было подумать. Однако, очевидно, я выработал совсем не те программистские привычки (как минимум, на взгляд работодателя) и мне нужно срочно изменить их. Везде, где бы я ни работал, мои решения, использующие иерархии мелких классов с делегированием поведения, признавались плохими. Говорят, будто так и надо писать, но это не так. Потому что всё это «как надо» может стоить мне работы.