Всем привет! На этой неделе с вами я @validoll. Работаю в @adyax занимаюсь разработкой бэкендов на Drupal.

Пишу на PHP, но хочу научиться еще чему-нибудь. Говорю на русском, но учу английский. Использую Ubuntu как десктоп, но... а никаких но :)

В начале своей работы с PHP я работал только с Drupal, и это было прекрасно, пока проект не развалился, и я не остался на улице

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

В это время я понял, насколько полезно ходить по собеседованиям, до сих пор иногда делаю тестовые задания just for fun, если есть время

Затем я попал в веб-студию, где запилил свою CMS на Kohana. Не спрашивайте меня "зачем?" :)

Своя CMS - отличный опыт для джуниора. Думаю, каждый должен это попробовать. Понимаешь, почему большие CMS устроены так а не иначе.

Большая беда была в том, что когда я писал CMS то не писал тесты. Было страшно и непонятно, что это и как оно мне в конечном итоге поможет

С тех пор я получил немного опыта и профита от тестов, но еще не имею привычки писать их всегда, к сожалению.

А какие отговорки используете вы, чтобы не писать тесты?

Выбрал “запускать тесты долго”. Твиттер-клиент закрашился. :D twitter.com/backendsecret/…

@backendsecret да уж, я лет 10 так на TYPO3 убил, чтобы понять, что я ничерта не знаю. Потом связался с командой Neos и это откыло мне глаза

@backendsecret "мой код идеален."

@backendsecret а где же вариант "никакие, всегда пишу тесты" чтобы посмотреть ответы? ;)

Т.е. половина разработчиков не знает как писать тесты, вторая - не понимает что пишет :)

С тестами ожидаемо (хотя 4 неожиданно :)). 1 и 4 вариант взаимосвязаны, потому как незнание кода приводит к невозможности/сложности оценки.

Единственный способ научиться писать тесты - это писать тесты.

"Слишком мало времени, чтобы писать тесты!" Перевод: "Я раньше не писал тестов, поэтому не знаю сколько времени мне нужно, но явно больше"

И да, написание тестов - это время, и не только на написание. Не забудьте так же, что тесты это тоже код, и тоже нуждается в поддержке.

Но время, которое тратится на написание тестов окупается при рефакторинге. Рефакторить код с тестами выгоднее, а уж приятнее в 1000 раз!

@backendsecret С другой стороны никто не знает сколько стоит выпустить непротестированный код хотя бы в приемлимом качестве... Баги чинить..

@backendsecret есть ещё вариант "пишу самотестируемый код")

@backendsecret а ваще, любой кто писал тесты, согласится, что: twitter.com/blia/status/79…

Чтобы не бояться писать тесты я начал с малого: брал высокоуровневые методы и писал для них "приемочные" тесты по принципу черного ящика

И тут я узнал неприятную вещь: я пишу код, который невозможно тестировать!

Но тут мне на помощь пришла теория, которую я читал, когда остался без работы (DI, IoC и пр.) Картинка мира сложилась и жить стало легче

@backendsecret вот на этом моя последняя попытка написать тесты и закончилась: я понял, что надо половину отрефакторить для этого

На сегодня все.Завтра говорим про плюсы и минусы удаленной работы, Drupal и его использование (где его можно применять) Задавайте вопросы :)

@BesseIFunction @backendsecret вот поэтому я пишу тесты к коду, который неправильно работает. Ну и чтобы изучить незнакомую систему

Доброе утро! Поговорим про Drupal как CMF.

На данный момент в приближенных ко мне проектах используется Drupal 7, который вышел в 2011 году!

При этом он вышел, как говорили, "мертворожденным", т.к. на тот момент не использовал всех плюшек ООП, которые PHP 5.3 могло дать, и хуки :(

Но не смотря на это, 7-я ветка еще жива, и активно используется.

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

Порог вхождения в Drupal всегда было достаточно высок по сравнению с другими CMS.

@backendsecret у нас под капотом свой фреймворк Flow. Писали когда Symfony еще и в помине не было. Сейчас берем некоторые компоненты от туда

По большей части раньше это обуславливалось отсутствием внятной документации. Ситуация изменилась. Документации много, и не только по ядру.

Популярность Drupal - это его проклятие. Я множество раз видел проекты, где он используется, но где его использовать не следовало.

@Sigiller @backendsecret Я сел сразу за 7 друпал. И было это году в 2011. Пока осилишь 7 друпал по мануалам к 6, всё станет понятно :D

@backendsecret вот я как-то все это попытался на русском однажды написать: dimaip.github.io/2015/06/15/abo…

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

Согласно Эрику Эвансу в DDD, на это обречена любая универсальная система.

Интересно, так ли это на практике? Есть у кого-нибудь примеры универсальных систем без боли?

Для Drupal 8 порог вхождения выше за счет использования Symfony 2. Это хорошая чистка сообщества, слабые - уйдут, сильные останутся.

Ну и конечно для Drupal-разработчиков будет плюсом то, что кроме Drupal придется учить и Symfony (на самом деле нет)

Или другой вариант - старые говнокодеры останутся, но к ним присоединятся ковнокодеры из Symphony.

@backendsecret я постоянно хожу на омское кафе vk.com/drupalomsk

.@backendsecret It's another option. Drupal 7 was a proven, successful product. #BackdropCMS improves on it, a little at a time. @EAytpaev

А русскоязычные разработчики всегда готовы поблагодарить @xandeadx, @Spleshka, @kalabro, @NiklanRUS , @graker_ru и др. за блоги и дайджесты

Доброго дня всем. Давайте поговорим о рабочем месте. Для меня это лично всегда было больной темой.

Какой способ работы для вас наиболее приемлем?

Большинству нравится приходить в офис когда вздумается. Иллюзия свободы :)

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

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

Доброе утро! Начнем веселье. Вчера работа забрала меня, сегодня будет веселее :)

Раз уж я тут представляю Drupal-сообщество, давайте еще немного о нем поговорим.

Сейчас наступило смутное время, когда D7 еще поддерживается, а D8 вовсю наступает, и возникает вопрос, что же выбрать для знакомства/работы?

Рассмотрим подробнее, что нового нам дает Drupal 8, и какие задачи в нем решены лучше, и какие проблемы Drupal 7 он решает.

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

Views - давно, и не без оснований, мощнейший инструмент работы с выводом контента, наконец-то в ядре D8.Теперь используется и админки.

В D8 конфиги наконец-то в коде. D7 хранит почти все в БД, а для кода есть модуль Features, с которым тоже бывают проблемы.

В D8 появилось адекватное превью перед сохранением. В D7 лично я решал это кастомными модулями, потому как штатное превью ни к черту.

Встроенный шаблонизатор Twig (ибо Symfony). Прощай логика в темплейтах.

D8 заточен под мобильную разработку. Почти все темы адаптивные. Имеется REST API.

В D7 прорывом было создание Entity API. Это довольно специфичная вещь, но решала многие проблемы с управлением объектами (не ООП)

D8 имеет еще более навороченную Entity API, теперь можно УДОБНО создавать кастомные типы сущностей через Drupal Console,

А, ну да, и Drupal Console - навороченный инструмент работы с Drupal из командной строки. Управление, генерация кода, установка и пр.

В общем, и Drupal-разработчики будут теперь жить как люди :)

Кто-то спросит "Зачем все это?Почему не использовать чистую Symfony?" Drupal - это CMF, где главное в данном вопросе - Content Managengement

Воспользуюсь возможностью, и спрошу про оценку и планирование времени.

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

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

Как в вашем проекте производится оценка?

А те, кто выбрал методологию, поделятся с нами в чем ее суть?

@backendsecret Я оцениваю сам, я тимлид. Методологии не сработали. :(

@backendsecret Не выбирал пункт методология, но я, когда оцениваю, стараюсь разделить задачу на подзадачи достаточно мелкие, чтоб их можно=>

@backendsecret давно хочу везде ввести правило - кто говорит что можно быстрее - садится и помогает.

А как у вас обстоят дела с балансом семья/работа?

У меня есть правило: в выходные не приближаться к компьютеру.

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

Пришло время прощаться. Это была отличная неделя. Спасибо вам!

Меняйте мир к лучшему, начинайте с себя.

С вами эту неделю был @validoll. Пока!