Эту неделю с вами буду я, Андрей Валяев. @Dronmdf.
Я работаю в компании Код Безопасности @Security_Code, в группе разработки Континент.

Эту неделю мы будем говорить про Agile. Поскольку эта тема мне наиболее интересна.

Что касается языковых предпочтений - основной мой язык C++, от веб разработки я далек. И собственно разработка у нас хардкорная, серверная.

В моем представлении слово backend почему-то ассоциируется с web разработкой. Не знаю откуда у меня возник такой стереотип.

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

SCRUM мы практикуем давно. Помоему больше 10 лет. где-то в 2005 году @scrumtrack проводил у нас один из своих первых тренингов.

Долгое время казалось, что лыжи не едут. Но со временем становится понятно, что наше кунфу не такое уж плохое. И наш SCRUM достаточно крут.

Кстати про #agile. Через неделю в Москве проходит #agiledays agiledays.ru. Я там буду.

@backendsecret веб обычно просто обертка вокруг хардкора и серверов

Какие методологии вы используете?

Наша служба и опасна и трудна...
И end-юзерам обычно не видна...
:)

@backendsecret точно точно. особенно с трафиком.

@yevvers очень распространенное явление. безопасник который защитил правильно себя - явно без работы сидит :) @backendsecret @Security_Code

Почему-то существует стереотип, что SCRUM нужно делать точно по рецепту, иначе это не SCRUM. Скрам, но...

... Джефф Сазерленд так не считает. mann-ivanov-ferber.ru/books/scrum-a/… @mifbooks. SCRUM это такой же адаптивный процесс, как и другие agile методологии

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

Сколько в ваших проектах зарегистрированных багов?

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

А вот у кого больше чем сотни багов. Тысячи? Проект большой?

На мой взгляд - 80% багов - это просто потенциальные доработки в беклог. Они не мешают жить. Торопиться с их исправлением - вредно.

Идет обсуждение нового стандарта c++, многое из того, что все хотят не входит.
usingstdcpp.org/2016/03/05/tri… модули, корутины, рейнджи, концепции

На мой #agile взгляд, это тоже нормально. :) Что-то новое они определенно включат в c++, и язык становится лучше. Будет хуже, если испортят.

Всем привет! Меня зовут Пётр и на этой неделе я расскажу все секреты разработчика бэкенда, которые знаю!

Секрет1: меньше кода = лучше! Но это не про заковыристые однострочники или фанатичное DRY...

Меньше кода=лучше-это про выбор простых решений,простых абстракций,простых реализаций, достаточных для 90% пользоват habrahabr.ru/post/153225

@backendsecret Не всегда, если абстракция сложная, лучше написать чуть больше простого кода, чем перемудрить sandimetz.com/blog/2016/1/20…

Секрет2: выбор подходящей технологии. Зачастую говорят: "каждой задаче - свой инструмент для решения" - не совсем так...

Для вашей задачи может подходить десяток разных со своими плюсами/минусами. Знать все подводные камни невозможно, пока не попробуешь

Выбрать _наиболее_ подходящий язык/СУБД/Фреймворк из десятка вполне подходящих поможет опыт и интуиция - это работа для CTO/Тимлида

Секрет3: хороший инструмент - обычно, это популярный инструмент. Следствие хороший тулинг, много документации/статей, жить становится проще!

Есть нишевые исключения, но для типового программного продукта выгодно выбирать популярные технологии (выгода в сроках/качестве/стоимости)

Например, для web лучше выбрать PHP/Node/RoR, легче поддерживать, будет меньше ошибок, чем, допустим, при использовании Yesod (Haskell)

Знаете сколько в Yesod ошибок/недоделок/шероховатостей? Мало кто знает, потому что мало кто использует, а на что-то вы натолкнётесь впервые

С Yesod на одной чаше весов у вас будет пуленепробиваемая система типов Haskell, а на другой ОГРОМНЫЙ НАПИЛЬНИК,придётся всё доводить до ума

Это не был наезд на Haskell, лишь пример "популярная технология vs не очень". Безусловно, у Haskell есть свои узкие ниши.

Продолжая про выгоду выбора популярных технологий. Хотел я однажды сделать реактивное full stack приложение. Взял Clojure+ClojureScript...

Сам язык Clojure классный (судя по книге), функциональный, имутабельный, JVM экосистема на серевере=много готовых Java библиотек если что...

На деле куча подводных камней и вопросов, которые НЕ гуглятся и даже не стековерфлокаются (какое слово придумал!)

На Meteor (full stack nodejs) всё заработало практически без вопросов из коробки. Хуже масштабируется,чем Clojure, но в целом выгодный выбор

На Meteor (fullstack nodejs) всё заработало почти без вопросов из коробки.Хуже масштабируется, чем Clojure, но выгоднее(сроки/качество/цена)

Продолжая историю Clojure->Meteor, если отказаться от требования реактивности, тот проект ещё проще и быстрее было бы сделать на PHP!

В итоге, делаю так: свои web проекты на интересных технологиях (например Clojure, Elm), серьёзный бизнес на популярных (PHP, Node)

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

С другой стороны, у go слабоват пока инструментарий: IDE, дебаггер, пакетный менеджер - на фоне PHP/Node всё плохо, трудно быть продуктивным

@backendsecret Что скажешь насчёт применения популярного ЯП (Ruby/PHP), но непопулярного фреймворка? Та же история? Мне кажется, чуть лучше

Отличный вопрос от @AlexWayfer про выбор web фреймворка: практичнее выбрать что-то популярное: Symfony/Laravel/Yii, RoR/Sinatra,Django/Flask

Но это не столь критичный вопрос,в отличие от выбора языка/платформы. Крутые эффективные проекты на самописном фреймворке+пакеты не редкость

Выбор фреймворка, в том числе, зависит и от размера команды/амбициозности проекта. У крутых вообще всё своё (типа Badoo).

По фреймворкам для большинства web проектов я бы выбирал Laravel: простота+батарейки+очень позитивная атмосфера вокруг, хорошо развивается

Шли годы, а ASP.NET так и выстрелил. Нам обещали золотые горы ASP.NET vNext, теперь обещают 1M RPS .NET Core

Есть, конечно, ниши ASP.NET - корп. приложения полностью завязанные на стеке MS + одна история успеха от StackOverflow

ASP.NET напоминает WindowsPhone,который с каждым релизом обещает всех порвать, но популярны почему-то Android/iOS (PHP/Node)

Хотя сам язык C# - шикарен, спору нет. Хороший дизайн, хороший баланс всего и MS начали вкладывать в его кроссплатформенность - радует глаз

Спрашивали про Spring(Java). Spring Boot позволяет очень быстро запустить проект/сервис на любой вкус-удобно, но как там дальше? Поделитесь!

Всегда любил Yii, но как-то он сдал :( Зайдите на сайт, документация по виджетами Yii 2.0 почти вся TBD, даже по гридам! Сравните с Laravel

Признаюсь в странном: пару лет назад продал свой MacBook Pro и купил Sony Vaio Pro 11" - не пожалел! А с Windows 10 совсем удобно стало.

Всем привет! На этой неделе тема - браузеры и всё, что с ними связано. Буду отвечать сам, если не смогу - уточню у девелоперов Vivaldi :-)

Интересное наблюдение: самые жаркие споры среди девелоперов возникают по поводу какой-нибудь мелочи, которую изменить - пара минут :-)

Баян, но прикольный: потратив годы и миллионы баксов, учёные научились копировать двух пьяных мужиков, несущих диван pic.twitter.com/VcLPZB0gx9

Интересное наблюдение: Аутсорсинг - очень удобный стиль работы, вот только за недельную поездку в офис успеваешь сделать гораздо больше...

Надо тортик сходить купить - у Твиттера, оказывается, юбилей сегодня, 10 лет...

По просьбе @anton_davydov попробую рассказать вкратце про процесс разработки и тестирования Vivaldi.

Тесты, естественно, есть, как самописные, так и сторонние. Многие тесты работают в автоматическом режиме.

Особая проблема - тестирование после выхода каждой новой версии движка. Без этого тестирования всё отвалится при первом же обновлении.

Код в Chromium меняется оперативно, и, порой, значительно. В итоге, например, несмотря на все усилия, при переходе с 48 на 49 - куча багов.

К счастью, между 49 и 50 не так много изменений, обновление проходит легче. Но всё равно - гемор. Впрочем, как у всех Chromium based.

Вообще, в компании есть пара человек, которые занимаются исключительно тестами - отладкой, тестированием, созданием тестов и т.д.

Патчи - принимаем, когда по делу и грамотно. Но это - редкость. Лично помню патч от пользователя для исправления установки в Mandriva.

На самом деле - 98% это код Chromium, так что патчи шлют в основном туда. Но - общие, не для Vivaldi конкретно.

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

Ветки ведём две. Одна - тестовая (еженедельки), другая - "стабильная" (беты). В стабильных отключаем неготовое - например, почтовик M3.

В общем, вкратце - как-то так.

Из языков - в основном HTML/CSS/JS, но есть и девелоперы на C++ - они колдуют с кодом Chromium и с функциями, которые мы берём из него

Как зарабатываем :-) Довольно популярный вопрос. Как все: контракты с поисковиками, с онлайновыми сервисами и магазинами.

В России партнёры - Яндекс, OZON.ru, AliExpress, несколько игровых сайтов. Также работаем с eBay, Booking.com, и т.д.

Оказывается, Хакер теперь платный. Статья доступна полностью только подписчикам. В общем, живу и работаю из России, т.к. здесь лучше :-)

Работаю не только по России, но и по миру. На мне локализация вся, более 50 языков, 216 переводчиков. Тестирование, репорты, и т.д.

OK, появилась полная версия статьи: issuu.com/farsenvo/docs/…

Всех девушек спешу поздравить с 8 марта! Процент девушек среди читателей наверное невелик, но вы есть!

Думаю о чем повести сегодняшний разговор?

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

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

Есть два основных направления в сериализации - поменьше объем, или поменьше напряга. На чъей стороне ты?

У бинарного протокола есть схема. Для текстовых протоколов тоже можно сделать схемы, но обычно это лишние телодвижения. (схемы снаружи)

Схемы помоему полезны, спасают от глупых ошибок.

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

Это риск проекта. Что решение окажется не таким удачным, и не взлетит. Микросервисы борятся с этим путем локализации взаимодействия.

Если мы говорим про более-менее монолитный проект, то #agile помогает. #agile заранее настраивает нас на неокончательность решения.

Неокончательность решения заставляет нас реализовывать гибкую архитектуру. В отличии от неитеративных разработок, где все делается "навсегда

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

Есть две стороны медали - использовать библиотеку для сериализации объектов, или просто набивать json/xml и тд.

Билиотека для сериализации объектов - это жестко. :) Хотя в плане командного взаимодействия и фиксированного API - это правильно.

В гибкой разработке удобнее менять API по мере необходимости. Жесткие контракты тормозят разработку.

Кстати вот #protobuf... Его тоже приходится руками набивать, я не вижу большой разницы по сравнению с ручной набивкой json.

@backendsecret тот кто хоть раз делал оптимизации для сильносвязного графа, понимают какой в этом профит и риски.

@notxcain @backendsecret вопрос не в поддержке, а в простоте наверное. Json проще - protobuf сложнее:)

Вопрос к тем, у кого итеративный подход к разработке. #agile
Какова у вас длина спринта?

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

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

Фокусировка на демо вообще очень помогает еще при планировании. @henrikkniberg советует на обороте карточек заранее писать план демо.

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

Размер задач - стандартная отмазка. У нас же эпическая фича, мы работаем над этим, на демо нечего показывать. Это может долго продолжаться..

На демо можно показывать технические вещи. Если заказчик видит пользу, то проблем нет. Покажите ему пользу. #agile

@backendsecret постоянно работаем в пределах 1 недели/спринт и редко остается 1 задача не завершенная. ПМ мастер декомпозиции!

@backendsecret в конце спринта всегда чек лист - как задачи помогут пользователю/бизнесу

Мне кажется, что канбан может быть от лени. Нам надоело тратить столько времени на планирование - долой спринты. У нас теперь канбан. :)

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

Тут переписали с go на rust, из-за "низкой эффективности использования памяти при больших нагрузках" @backendsecret twitter.com/opennetru/stat…

Секрет4: масштабирование. Каждый интернет-магазин мечтает стать Алибабой или Амазоном, а каждая CRM хочет продаваться как Salesforce...

Но есть реальность, бизнес план и бюджет на старт. Мастабирование по вертикали дешевле, проще, и имеет большой запас при современном железе

Чтобы писать супер-распределённую отказоустойчивую систему с самого начала, нужно точно понимать зачем вам это нужно

Выбираем СУБД: пяток MongoDB/RethinkDB (легко масштабировать в горизонт) или пару(mst+slv) надёжных и быстрых PostgreSQL (вертикально)?

Кстати, про PostgreSQL рекомендую ​SDCast #33, конкретно на тему масштабирования начиная с 33 минуты ​sdcast.ksdaemon.ru/2015/12/sdcast…

Опрос для статистики типовых проектов: для старта вашего недавнего/текущего/ближайшего проекта что бы вы выбрали?

@backendsecret CQRS + EventSourcing + Cassandra, будет и надежно и масштабируемо

Секрет5: микросервисы! Они помогают не только масштабировать, но и оптимизировать, выбирая различные инструменты под разные части продукта

Например, рендеринг web на PHP/Node/RoR, сложная бизнес-логика на JVM, а картинки жмём на чистом Си

Отличная статья про микросервисы от Фаулера: martinfowler.com/articles/micro… (перевод на хабре: habrahabr.ru/post/249183/ )

Но с микросервисами добавляется сложность на интеграцию и особенно на интеграционное тестирование

Впрочем, использовать несколько ЯП можно и в монолитe, как делают ребята в Рамблере с Clojure + jRuby в единой JVM youtu.be/yA8gJ_1ukY0

Учитывая, что сейчас каждый второй ЯП транслируется в JS, интересно было бы увидеть пример Node приложения собранного из нескольких языков!

Порекомендую выпуск Software Engineering Daily про историю перехода от монолита к микросервисам в SoundCloud softwareengineeringdaily.com/2016/02/04/mov…

Между тем, не так давно пробегала новость, что SoundCloud под угрозой закрытия, убытки-с consequenceofsound.net/2016/02/soundc…

К слову softwareengineeringdaily.com ежедневный (!) подкаст без бла-бла, от архитектуры и методологий до языков и фреймворков - выбирай по вкусу

Если же хотите отвлечься на холиварную тему, послушайте нашумевший выпуск Разбора Полётов про ООП головного мозга razbor-poletov.com/2016/03/episod…

@backendsecret я бы выбрал какой-нибудь slim + php-di, а потом можно легко переехать на любой фреймворк, если нужно. php-di.org/news/18-slim-b…

@backendsecret Я знаю, что это ересь... :)

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

У нас SCRUM of SCRUM проходит в переговорке. Полчаса минимум. :(

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

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

В этом году Антон Зотин так же будет на #agiledays agiledays.ru/members/profil…. Пойду.

Рефакторинг - он всегда двигает проект в какую-то сторону. Давайте попробуем угадать, что захочет заказчик завтра. :)

Я не очень-то верю в глобальный рефакторинг. И в переписывание с нуля не верю. Лучше обычно не становится. В постоянное улучшение верю.

И когда ты настроен на постоянное улучшение, ты как-то более негативно относишься к быстрым и топорным решениям... Можно сделать лучше!

@backendsecret Но наверное я не буду так категорично это утверждать... бывают очень старые приложения которые нужно переписывать. :)

Вопрос вот в чем. При переписывании понимают ли разработчики реальные проблемы имеющегося решения, или просто не хотят разбираться?

Типичное проявление симптомов болезни NoSQL и BigData. arbinada.com/main/ru/node/1… pic.twitter.com/E9SmEyWxou

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

Кто как проводит CodeReview?

@backendsecret я про те проекты на которые с самого начала всем пофиг. если есть неравнодушные, то код и вряд ли будет настолько плохим

@backendsecret непристало принцам, конюшни чистить, ибо лучше пойти на Go и NodeJS, микросервисов под Docker нахерачить, это круче :)

@backendsecret обычно со стаканом водки

gerrit замечательная вещ. У нас раньше был perforce. Садиться рядом и смотреть кто что хочет закоммитить - это вообще не вариант!

@backendsecret О Данила-стайл! Надо переписать! :)

@backendsecret В gerrit это временные ветки.

Мы все коммиты сохраняем. И то, что уже внесено в основную базу - не ребейсится и не сквошится. Нам ветки и merge commits не мешают.

@backendsecret Хотя несомненно возможны и другие подходы.

Секрет6: статическая типизация против динамической и строгая против слабой. Что эффективнее и что выгоднее в долгосрочной перспективе?

Начнём с первого: static vs dynamic. Плюсы и минусы в общих чертах всем известны, но всё же обсудим...

При статической типизации нам сильно помогает компилятор, проще делать статический анализ -> лучше подсказки в IDE, рефакторинг

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

Минусы статической типизации: слишком многословный синтаксис во многих языках, требуется больше усилий на старте pic.twitter.com/e826oZRU5i

Впрочем, не везде есть проблема синтаксиса, например, в ML языках (типа Haskell или OCaml) всё выглядит очень аккуратно благодаря...

...благодаря алгоритму вывода типов Хиндли-Милнера (объяснение алгоритма на пальцах: habrahabr.ru/post/125250/ )

На Haskell ты сначала вдумчиво проектируешь типы, а потом типы проектируют^w ведут тебя, type driven develoment, но это не для простых умов

Диаметрально противоположный пример статической типизации: язык Go - максимально лёгкая система типов, на деле выходит очень практично

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

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

Мы сначала экономили умственные усилия и нажатия кнопок на более лёгком синтаксисе, а потом пишем доп. тесты

В защиту: чувак исследовал 1,7 млн репо. - только 2,7% ошибок на Python было связано с типами, не так много, правда? vimeo.com/74354480

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

Вспоминаем TypeScript. А теперь и в официальных кругах ECMAScript поговаривают о возможном тайп-хинтинге в будущем

Ещё больше порадовал Flow, очень круто выводит типы в JS! Учитывает даже ветвления типа if (typeof x === 'string') flowtype.org

В Ruby 3.0, возможно, появится статическая типизация news.ycombinator.com/item?id=8620129

Для динамически-типизированного Clojure есть проект Typed Clojure, но с ним проблемы blog.circleci.com/why-were-no-lo…

Facebook выпустил Hack с опциональной статической типизацией, позже подтянулся и PHP 7 php.net/manual/en/func…

Всем порекомендую этот доклад: The Unreasonable Effectiveness of Dynamic Typing for Practical Programs vimeo.com/74354480

@backendsecret а кто кроме груви? Тайпскрипт там не честная типизация

Вечерняя рекомендация подкаста: changelog.com/podcast/ - хорошая редакторская работа и крутые гости в эфире, авторы языков, фреймворков...

В подкасте The Changelog побывали авторы Go, Rust, .NET Core, Vagrant, RoR (DHH), Laravel, WP и много других интересных персонажей

@backendsecret Когда понимают - точно успех. "Вот здесь плохо, здесь могут быть ошибки, а здесь - не гибко". Тогда и новый код лучше)

@AlexWayfer бизнес идет на компромис: не 20, а 50% времени на рефакторинг, но не 1-3 месяца на 100%
И это правильно, считаю @backendsecret

@backendsecret Чем абстрактная расширяемость в вакууме...

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

@SiliconBangalor @Bubyakin @backendsecret Смотри твит про разницу содержимого методов и обёртки.Плюс да,часто бизнес придумывает всё и сразу

@SiliconBangalor @AlexWayfer @Bubyakin @backendsecret странно, что мало кто относится к коду как к временному неидеальному куску дерьма :)

@AlexWayfer @Bubyakin @backendsecret или НЕТ, потому что в следующий раз будет все по-новому и с совсем другими требованиями!

@rusgautama @backendsecret Почему засоряется? Каждый мерж - фича. История получается история добавленных фич.

Мне, как разработчику, хотелось бы, чтобы моими программами пользовались после меня. Это приятно. А не переписывали при первой возможности.

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

@backendsecret И если код не достаточно гибок, не достаточно понятен - я не смогу сделать это быстро. Какой же я тогда профессионал? :)

@backendsecret Заставлять его пушить раньше, чем он что-то запилил? Это какая-то искуственная мера для обеспечения прозрачности получается.

Тема про чистоту кода оказалась достаточно холиварная... :) Переключимся на что нибудь еще?

@backendsecret Производительность можно. Например, когда (что) стоит писать не на медленном языке (Ruby/Python), а на быстром (C++/Java).

Скорость разработки помоему слабо кореллирует со скоростью выполнения программы на конкретном языке.

У интерпретируемых языков есть большой плюс, что их не надо компилировать! Ваш КО. :) И можно быстро подгонять и фиксить...

Я вот хотел обратиться к web программистам. Сейчас помоему модно распаралеливание. Важна ли для вас производительность отдельных приложений?

@backendsecret Конечно это наверное вопрос цены. Но ведет ли кто нибудь, кроме google, борьбу за такты?

Бывает так, что было все быстро, а потом допилили пару фич и стало медленно... Как люди с этим борятся? тесты на скорость?

@indieloki @backendsecret Так скоро и программисты не нужны станут.

@backendsecret Это конечно шутка. Мозг надо экономить... Чтобы думать о важном.

@backendsecret @webholt у меня был случай: китайцу написал скрипт на ноде и он так и не смог поставить ноду :) пришлось на го переделать.

@backendsecret Тут даже не столь важно - отдельный ли это сервис, отдельный модуль или отдельный класс... Важна область ответственности. SRP

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

Кстати хорошая тема - SOLID. Кто применяет? Знаю, что некоторые даже не слышали такой аббревиатуры. Это не про чистоту, про ясность кода.

Почему эти ваши модные NoSQL решения не так уж хороши eax.me/avoid-nosql/ с помощью @afiskon

@backendsecret Мне кажется, суровость серверного ПО не имеет большого значения, если грамотно выбрать место связи и саму связь. Дробится всё

У нас бывает, при проработке решения - никто про скорость не вспоминал. А потом - у-у-у, тормозит, давайте перепиливать... :(

@backendsecret Иногда правда бывает, что действительно тормозит... Надо бы думать заранее, могло бы помочь...

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

@backendsecret компилируемые языки с хорошей системой типов позволяют писать гораздо меньше тестов в сравнении с интерпретируемыми языками

Что вот неудобно, в C++ с моками достаточно непросто... завидуешь java с ее рефлексией...

@anton_davydov @backendsecret не нужно писать тесты для проверки инвариантов которые могут быть проверены компилятором

@anton_davydov @backendsecret Это не только правильность API, но и бизнес-логики тоже. Например не перепутать id заказа и id пользователя.

Открыли новую парадигму - костыльное программирование. Основные понятия: костылирование, поликостылизм и инкостыляция. (Juu|away)

Сегодня на работе заговорили про websockets, вспомнился WAMP wamp-proto.org Кто нибудь пробовал юзать? Идея нравится, вдохновляюсь.

@backendsecret Мы смотрели на него еще года два назад, с тех пор он обзавелся RFC и множеством имплементаций.

@backendsecret отличная штука! Сам юзаю и всем советую! И да, участвую в разработке самой спеки и автор нескольких реализаций

А кто нибудь юзает парное программирование? Есть тут XPшники? :) Думаю, что эта практика - большая редкость...

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

youtube.com/watch?v=dYBjVT…

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

На мой взгляд - тестировщики это зло (особенно отдельные). Разработчики расслабляются и не за что не отвечают... Мы сделали, че...

Вот еще один доклад, очень вдохновляющий. Антон Волков из АльтернативаПлатформ 2013 год. plus.google.com/+%D0%90%D0%BD%…

Антон Волков на AgileDays'13, Это нужно видеть. plus.google.com/+%D0%90%D0%BD%…

@backendsecret Правда я не знаю, как у них в АльтернативаПлатформ сейчас...

@backendsecret Хуже, когда отдел тестирования отделяют... Я не знаю как они хотят после этого добиться повышения качества.

@backendsecret Это я о наболевшем. :(

В ленту @backendsecret и @jsunderhood - рекомендую twitter.com/borisvolfson/s…

@backendsecret пушо иначе это превращается в "тяни-толкай тикет", а тестировщик отвыкает кодить

@backendsecret на 100% согласен, олсо считаю, что тестировщик должен править баги, если может.

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

@backendsecret Чтобы все думали о повышении качества!

@backendsecret И часто усилия отдельных личностей не согласуются с интересами пользователей. И пользователи страдают. Штрафовать?

@backendsecret И эти личности искренне верят, что они тут в поте лица работают... одни...

@backendsecret @ruxeg ну например тот же bit.ly/1U5psBM умеет работать в кластере. Да и Wiola можно поднять на нескольких нодах.

Секрет7: расширяйте кругозор, изучайте смежные технологии, хотя бы обзорно по видео-докладам или по подкастам в фоне(не займут доп. времени)

Посмотрите на конференцию Strange Loop о языках, библиотеках, инструментах и технологиях на переднем крае индустрии
youtube.com/channel/UC_QIf…

Иногда возникает вопрос, как не гнаться за технологиями и начать жить? Отвечает @listochkin youtu.be/xPFRUM_oDKA

В догонку: фокусируйтесь на том, что выделаете и зачем youtube.com/watch?v=Mx22Na… Гонка технологий - это фон. twitter.com/backendsecret/…

Про PHP, который последние 4 года сильно развивается, новые фичи и синтаксис в ежегодных релизах 5.4: 2012, 5.5: 2013, 5.6: 2014, 7.0: 2015

Темпы только растут! Увеличивается и скорость исполнения с каждым релизом, особенно в PHP 7 habrahabr.ru/company/badoo/… pic.twitter.com/H9ijLYPxmY

В PHP 7 также исправлено много старых недочётов, с разумной потерей совместимости php.net/manual/en/migr…

Помимо официального мануала порекомендую вот это репозиторий с подробным описанием изменений и примерами кода github.com/tpunt/PHP7-Ref…

В PHP 7 много сил ушло на внутренний рефакторинг и оптимизацию. Релизы PHP 7.1+ будут более насыщенными по фичам wiki.php.net/rfc

Можно провести параллели в развитии PHP и JavaScript ES2015: генераторы, spread operator (...), Destructuring syntax (list в 7.1)

@backendsecret я в принципе удивляюсь, как этот весь код за 14 лет с php 3 на 5.6 переполз.

Exponential operator (ES7/2016), Arrow functions (в PHP пока планируется). Кто-то даже пишет transpiler для PHP github.com/jaytaph/Transp…

Ещё одна, уже классическая, статья на тему трансляции PHP 5.4 в более старые версии igor.io/2013/07/26/evo…

На практике, в мире PHP более актуальна другая задача: автоматизированная конвертация из старых версий в новые (в отличие от JS!)

В этом помогут упомянутый ранее github.com/sstalle/php7cc и инспекции в PhpStorm, прогоните по всему проекту: jetbrains.com/help/phpstorm/…

Рекомендую также ознакомиться с The PHP Quality Assurance Toolchain от @s_bergmann (автор PHPUnit) phpqatools.org

Чтобы держать код в аккуратном виде можно попробовать github.com/FriendsOfPHP/P… (но я отказался в пользу встроенных возможностей PhpStorm)

Не забудем про пару крутых (и платных) сервиса проверки PHP кода: scrutinizer-ci.com и blackfire.io

Чтобы держать руку на пульсе рекомендую подписаться на знаменитый PHP-Дайджест на Хабре в блоге компании Zfort habrahabr.ru/company/zfort/…

Аналогичный англоязычный ресурс с ежедневной подборкой статей о PHP: phpdeveloper.org/archive

Подкасты о PHP, которые я слушаю: soundofsymfony.com - редкий, но меткий, оценка 5/5

Voices of the Elephpant - интервью с видными участниками комьюнити, больше про конференции и соц. активность, 4/5 voicesoftheelephpant.com

PHP Town Hall - бывает бла-бла-бла, бывает и по делу, 3/4 phptownhall.com

PHP Roundtable - хорошие технические темы, но иногда страдает сфокусированность участников и качество звука 3,5/5 phproundtable.com

Lately in PHP podcast - когда совсем нечего слушать, ужасный акцент ведущего, 2/5 itunes.apple.com/ru/podcast/lat…

uWebDesign (на рус) - не совсем о PHP, больше про дизайн и WordPress, зато ребята весёлые с шутками-прибаутками, 4/5 uwebdesign.ru/category/podca…

Ищем Go-феров на очень интересный длительный проект. @backendsecret поделитесь pls. #Kubernetes, #CoreOS #AWS #microservices #golang

@backendsecret Я стараюсь следовать TDD. Некоторые пишут тесты раньше или позже. Уже хорошо.

В 99, когда проект стартовал - про тесты вообще никто не знал... потом, где-то 7-8 начались робкие попытки писать тесты... тормозилось... :)

Сейчас у нас есть юниттесты, интеграционные тесты, это все прогоняется на каждом коммите. Есть еще автотесты на ESX, правда они тяжелые...

@backendsecret Надо отметить, что продукт в сборе - это целый инсталлируемый дистрибутив.

@backendsecret У нас их несколько сотен... :)

Иногда бывает что один тестировщик пишет башу, исправляем. А потом другой тестировщик пишет - багу - верните обратно. Не хватает согласия.

@backendsecret Мы используем требования, у нас довольно тяжеловесный процесс. Но в требованиях тоже всегда чего-то не хватает. там тоже баги

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

@backendsecret У меня в команде по разработке перевес. Очень хорошая для разработчиков возможность заняться улучшениями.

plus.google.com/+YauheniAkhotn…

@backendsecret на мой взгляд в юниттестировании недостаточно просто тестировать на результат. Как этот результат влияет на продукт в целом?

@backendsecret Стоит почитать Эванса, но пока руки не дошли.

Тесты - это докумментация. Как-то глупо писать докумментацию, если она не кореллирует с основным поведением продукта.

Я всех на работе достаю с формулировками. Чтобы в багах писали проблему. А то любят требования писать. Добавьте кнопку. Нафига?

@backendsecret Иногда правда проскакивают дурацкие баги, которые и исправить тольком нельзя. Ну пусть пылятся в беклоге. :) беклог большой.

Меня не напрягает большой беклог. Наоборот, он дает мне, как продуктовнеру в какой-то мере, возможность выбора самого важного. :)

У нас роли выделены не четко. Руководитель проекта считает, что менеджер продукта есть PO. Но тот не хочет заниматься беклогом. Что за PO?

@backendsecret Поскольку план спринта у моей команды свой, и беклог свой, и порядок там интересует только меня, я и PO и SM одновременно. :)

@backendsecret Если вдруг существует какой-то код, старательно протестированный, но не используемый в продукте - это зря потраченное время.

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

При тестировании существующего кода - интересно исследовать. Я думаю (ну по логике) что код должен вести себя так-то. Тест. Нифигажсебе...

Most JS/Python/Ruby apps... pic.twitter.com/hkDkjdxpFH

Must have плагин для PhpStorm: Php Inspections (EA Extended) - много дополнительных инспекций, очень помогает plugins.jetbrains.com/plugin/7622

А в чём вы разрабатываете на PHP?

Говорят, к предыдущему опросу не хватает варианта ответа "Не разрабатываю на PHP" - давайте сделаем перекличку!

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

Если на собеседовании кандидат увидит, что в вашей команде он сможет развиваться, узнать что-то новое и актуальное - это большой плюс

А какие у вас бывали классные вопросы на собеседовании, которые понравились и особо привлекли ваше внимание к вакансии? Поделитесь!

@backendsecret «Привет. Вопросы есть какие-нибудь? Нет, ну ок, в понедельник выходи тогда»

Возвращаясь к теме подкастов, я тоже веду один: "Пятиминутка PHP" 5minphp.ru - зимой был перерыв, сейчас возобновляю выпуски!

Эксперимент: переходящий подкаст! Формат 5-10мин, расскажи о своём опыте, интересных случаях, новостях. С меня монтаж, расшифровка, хостинг

Отвлечёмся от PHP и сравним С++, Rust, D и Go: авторы языков о прошлом, настоящем и будущем youtu.be/BBbv1ej0fFo

А один чувак на столько отвлёкся от PHP, что для своих веб проектов перешел на Rust medium.com/@eugeniyoz/res…

Голосуем, какой язык лучше всего подходит для обучения?

Не думаю что go хорош для обучения. Заточен на конкурентность, а это даже для профессионалов та еще тема. Корутины в c++ - мозг уже сломал.

@backendsecret Обычно люди приходят к функциональщине. И то не все. Мне нравится иммутабельность, но я так и не освоил никакой функц. язык.

@Dronmdf отсутствие автоматического тестирования -- это trade-off, надо просто понимать, ради чего делается, или почему его делать нельзя.

Я не знаю... помоему с питона на плюсы проще, чем с си на плюсы. Сишников надо учить ООП. twitter.com/bleazerr/statu…

Для детей есть scratch.mit.edu , но думаю что с него переучиваться на нормальные язык тоже весьма проблематично.

Где-то был прикольчик, что C++ выглядит как питон, за счет форматирования. Не могу найти...

@backendsecret в MIT на Computer Science сначала учат пайтон судя по видеокурсам

@backendsecret Сейчас я не считаю себя сишником. Не хочу писать на си. :) Cи не предлагать. :) Хотя могу конечно. И ассемблем могу, и что?

@backendsecret И ruby опережает js.

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

И функциональную... С чего лучше начинать программировать?

@backendsecret По моим наблюдениям, многие просто не могут побороть в себе си.

@backendsecret Хотя про ML что-то слышал... смутно...

@backendsecret у мeня был опыт одноврeмeнного прeподавания Си и Руби. С повышeниeм сложности у Си кода было в нeсколько раз большe.

@backendsecret Функциональный стиль очень положительно кстати сказывается на стабильности кода.

@backendsecret Это я к тому, что наверное лучше сконцентрироваться на том, чем потом будешь заниматься профессионально. Знать бы заранее...

@gorancheg @backendsecret ага, года 4 назад, притащили мне проект на оценку, как одному из тех кто помнит что такое делфяк...

@ivanenok @PaGrom @backendsecret боюсь спросить, а как тогда называют тех, кто всю жизнь с легаси сношается?:)

@gorancheg @backendsecret нужно было переписать работающую хрень - одна из базовых софтин Почты России :) думаю так еще дохера где :)

@gorancheg @backendsecret так вот по их утверждению там нужен был ПРОСТО РЕФАКТОРИНГ :) теперь вы знаете всё про Почту России :)

@backendsecret ну дык брать пару языков и качать их. с конца 90 пилил на джаве и делфяке. делфяк борланд бездарно просрал, увы :(

@ivanenok @backendsecret Некоторые вещи хоть годами читай, всё равно не поймёшь, пока не набьёшь руку на использовании их.

@backendsecret Люди всегда стараются продумать вопросы со всех сторон. Никто ничего не делает во вред.Даже если кажется что это идеотизм. :)

@backendsecret Иногда в тестах удобнее писать struct, чтобы было меньше буков. Кого в тестах интересует ограничение видимости?

herbsutter.com/2016/03/11/tri… Что происходит в процессе стандартизации C++

@ivanenok @SiliconBangalor @webholt @backendsecret глянул, но не разбирался. Выгляит так, что в Яве это имеет рантайм-оверхед!

@backendsecret Пишут: Generate bridge methods to preserve polymorphism in extended generic types. docs.oracle.com/javase/tutoria… - не бесплатно.

@backendsecret Это я конечно утрирую. Менеджеры должны понимать, что в вопросах качества торг не уместен. :)

@backendsecret Это вопрос взаимопонимания.

У кого в офисе есть бесплатные печеньки?

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

@backendsecret Почему же тогда все покупают стандартные?

@backendsecret @Chudesnov @Dronmdf в бизнесе есть только 2 варианта: диктат и колхоз.Работают оба,в разных ситуациях.

@backendsecret в одной вакансии даже видел "кресла за 200$". И кресла там и в самом деле хороши :)

@backendsecret надо понимать, что в долгосрочной перспективе с тестами и дешевле и быстрее.

pic.twitter.com/wRAiALp0iK

@backendsecret сколько работаю — везде неудобные говнокресла. На одной из работ коллега за свои деньги купил нормальное

Хочется поговорить про самосовершенствование, но не знаю с чего начать... Со спорта?

Про работу в выходные как-то не хочется. :)

@backendsecret спорт помогает не только нагрузиться физически, но и разгрузиться психологически.

@backendsecret да не, норм, если работа для тебя ещё и образ жизни)

Понял наконец чем меня бесит ведение @backendsecret и @abroadunderhood без использования тредов - на интересную тему не дать ссылку друзьям.

@Onotoly @backendsecret а много ли разработок имеют "долгосрочную перспективу"? Чаще MVP сделали и в корзину

Щас будет воскресный тред, по просьбе @strizhechenko. Есть вещи, которые нельзя вставить в план. Ими нужно заниматься постоянно.

Нельзя завести себе хорошую фигуру. Вот начать первого января, завести и забыть об этом навсегда. Привет @cartmendum.

Так же нельзя взять, в первом спринте сделать архитектуру. И дальше спокойно колбасить код.

@backendsecret Или тесты написать сразу. Или рефакторинг сделать...

@backendsecret Это те вещи, которым нужно постоянно уделять внимание. Не надо планировать рефакторинг. делайте его.

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

@backendsecret Вообще +- 20% времени - это в пределах погрешности предварительной оценки. Помоему об этом даже говорит не надо, надо делать.

@backendsecret Это все должно быть в крови команды. Тесты пишутся. Если нужно сделать рефакторинг - делается без вопросов. Так правильнее.

@strizhechenko @backendsecret необходимость укладываться в собственные сроки зачастую связана с договоренностями,которые не хочется нарушать

Кто нибудь читал "Как тестируют в Google"? Они говорят - если ты выполнил 100% - ты лентяй! Прилагай усилия и стремись к 100%. 70% хорошо.

@backendsecret Это правда касается личных целей. С заказчиком так можно, если у вас хорошие отношения.

@backendsecret читали-с, занятная книженция, особенно в концепции именования тестов - большие, средние и малые.

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

pic.twitter.com/pVHYEwlqfW

Этот неловкий момент, когда тебе подарили огромный блокнот с ручкой, а ты и писать-то уже разучился #highload2015

pic.twitter.com/ERLMIUMuvL

Это была интересная неделя, спасибо. Завтра начинается #agiledays, меня можно будет там поймать.

О книгах: Кодеры за работой - серия интервью с известными программистами, интересные истории, воспоминания bookmate.com/books/SIA9aWti

Как пасти котов. Наставление для программистов, руководящих другими программистами habrahabr.ru/company/piter/…

Structure and Interpretation of Computer Programs (SICP) - классический труд об основных концепциях программирования ru.wikipedia.org/wiki/Структура…

Оригинальный SICP основан на языке Scheme, но есть адаптации на Python www-inst.eecs.berkeley.edu/~cs61a/fa11/61… и на Clojure sicpdistilled.com

@backendsecret много воды, мало толку - это не только мое мнение (отзывы на Озоне почитайте). Лучше youtube.com/watch?v=d4hUeX… посмотреть

@backendsecret о книгах - github.com/vhf/free-progr…