Всем привет! На этой неделе ведущим буду я, @KSDaemon, разработчик, архитектор, Oracle OCP, подкастер, активный участник разных сообществ.

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

Поскольку я живу на стыке frontend<=>backend, интересно обсудить вопросы взаимодействия, коммуникаций, технологии обмена данными и прочее.

Не стесняйтесь задавать интересующие вас вопросы! Ну что, погнали!

Для разогрева, предлагаю начать неделю с новостей. Как и откуда вы черпаете новую информацию? Если раньше её не хватало, то сейчас слишком

Для себя я остановился на твиттере, как основном источнике инф-ции. Читаю многих разработчиков и активных ИТ деятелей. На блоги нет времени.

@backendsecret фолловлю в твиттере кучу разного народа, в ленте как правило все что нужно пролетает:)

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

А как вы относитесь к восприятию аудио-информации? ;) Например, подкастам? Кстати, я (со)автор двух подкастов: SDCast & RadioJS.

@backendsecret читаю ЛОР, твиттер, хабр (и отпочковавшиеся от него ресурсы). RSS с подписками на англоязычные ресурсы не прижилась :(

.@fat0troll фрагментация хабра, имхо, не дала какого-то положительного эффекта. Да и все меньше и меньше там интересного проскакивает…

Вот сейчас появилось много разных чатиков (gitter/slack/и тд). Но мне всегда было больно от того, что нужно миллион приложений.

Всегда мечтал об одном приложении для всех чатов :) И вот услышал про sameroom.io от создателей kato im. Кто-нибудь пробовал?

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

.@mktoid Да есть такое. Поэтому вопрос: какой формат/длина подкастов вам наиболее интересны?

В продолжение темы подкастов. Судя по ответам, никто не любит выпуски >часа. Я, кстати, тоже :) но это не всегда получается.

.@raxpost @mktoid короткие выпуски могут быть только новостными. В них не поместятся дискуссии и интервью.

“@anton_davydov:что посоветуешь начинающим подкастерам?” Главное - желание,приличный звук,хороший контент! Остальное-мелочи. Могу подсказать

@backendsecret Для меня «идеальным» подкастом было «Свободное радио Компьюлента» (compulenta.podster.fm/511), 10—15 объёмистых статей за час

“@listochkin: Хороший подкаст часа на 2-2.5 - это очень ок.” Если интересная дискуссия - да. Но все же это редкость, и можно разбить на два

Завершая тему подкастов: мне кажется,это интересный инфоканал.И радует,что их стало больше,интересных и качественных.Слушайте и записывайте!

Давайте поговорим про OSS. Был вопрос про мое отношение, вклад и будущее.

Open Source — это интересная концепция, и я положительно к нему отношусь. Но не все так просто, как про это обычно говорят →

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

И если его не будет,скорее всего проект просто загнется.

Было интересное исследование на эту тему:оценка bus factor для open-source проектов lwn.net/Articles/65136… посмотрите на числа — это единицы

У меня тоже есть несколько небольших проектов на github’е. Они так или иначе касаются WAMP. Это такой протокол с Pub/Sub и RPC.

Активно участвую в разработке самого протокола. Кстати, делал про него доклад на одном из @moscowjs. Вот презенташка blog.ksdaemon.ru/2014/09/para-s…

И само собой делаю PR в проекты,которые сам использую.В этом свете вопрос: контрибьютите ли вы в используемые проекты? Bugfix, new features?

“@dcromster: я нахожу баги. Сообщение о баге считается вкладом в OS?” Если он правильно оформлен — да. Но еще лучше,сразу PR с исправлением!

“@dcromster: не всегда это возможно. Например, программа на С, а человек глубокий ПХПшник.” Да, бывает. Тогда надо сообщить о проблеме!

Кстати, если интересно, могу рассказать пару слов про WAMP.

@backendsecret одно время слушал radiojs но отписался из-за низкой концентрации информации. В слушаемых остались ctocast и radio-t

.@serebro Хммм,интересно. В RadioJS мы как раз обсуждаем новости по большей части, даже если зовем гостей. Чего не хватает? Спасиб за мнение

.@serebro и да, почему в этом списке нет SDCast’а!? :)

WAMP (WebSocket Application Messaging Protocol, wamp.ws) легкий протокол, изначально поверх websocket, но уже можно и raw →

→ в нем из коробки есть Pub/Sub и RPC. В нем несколько слоев, что позволяет использовать разный транспорт или энкодеры (JSON, msgpack) →

→ сам по себе протокол довольно прост, и уже есть реализации на многих языках, в том числе пара моих: JS клиент для браузера, LUA клиент →

→ и WAMP Router на базе Nginx и модуля LUA.

.@lisovskyvlad не, это старье судя по всему, еще v1. Актуальные реализации всегда тут: wamp.ws/implementation… и да, что-то там не видно Ruby

“@lisovskyvlad: @backendsecret * задумался об опен сорс проекте...” Да-да! Отличный повод! ;) Готов проконсультировать по WAMP’у !

Кстати, про OSS: для любого проекта, потенциально интересного сообществу очень важно иметь хорошую документацию c описанием API,интерфейсов

И вариант, что «у меня код самодокументированный» — не работает. Первое, что видишь заходя на стр проекта — это его описание, aka README →

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

Другое дело, что даже наличие хорошей документации, не означает качественную реализацию. Но тут как раз можно и в код глянуть.

Github, кстати, в плане развития OSS сделал большое дело! Все реже и реже можно встретить разработчиков, которые не знают что такое VCS.

То есть общий уровень подготовки разработчиков стал выше. И это здорово!

Кстати о LUA.Кажется тут не было любителей этого языка :) Мне оч нравится идея использования таких легких и быстрых языков на APP-серверах

Та же связка Nginx и LUA позволяет на начальной фазе запроса сделать какие-то проверки,скорректировать роутинг и прочее, не проксируя запрос

В этом плане так же интересен Tarantool, который и БД и APP-сервер одновременно. Но данные рядом и их легко можно достать. А вы что думаете?

“@iamale_ru: Как насчёт luvit.io?” Да, интересный проект Тима Касвела. Посматриваю, но пока не дошли руки попробовать.

“@iamale_ru: Как насчёт luvit.io?” →но пока что мне достаточно LUA модуля для Nginx,даже если это не просто обработка запросов

Кстати,есть еще язык Terra, который интероперабелен с LUA, но со статической типизацией и ручным управлением памятью. terralang.org

Что-то к вечеру все стихли… Давайте завтра поговорим про процесс разработки, взаимодействие и коммуникации.

А пока вот вам список подкастов, которые я слушаю: gist.github.com/KSDaemon/1d3c4…

“@kspitfire7: TAOP и ТиП Звука же уже всё?” Нуу может быть и все. Хотя иногда еще в TAOP что-то проскакивает, поэтому я не удаляю пока :)

@backendsecret Как думаешь, дёргать публикацию в Push Stream в nginx через LUA напрямую (без http-запросов) из RabbitMQ — это хорошая мысль?

.@subzey если ты имеешь в виду, сразу пушить в стрим, а не через отправку в очередь — то конечно да! Или я что-то не так понял, скажи.

@backendsecret а примеры крутых репозиториев накидать можешь? :)

.@anton_davydov да таких полно. В python asyncio отличная докуменатция и примеры (кстати, мы обсуждали это с Андреем Светловым)

.@anton_davydov openresty/lua-nginx-module, да и свои проекты я старался оформлять как следует.

.@subzey такс сложно сказать по одному приложению. Попробуй обрисовать всю картину, тогда можно посмотреть и понять :)

@backendsecret советы по написанию документации: stevelosh.com/blog/2013/09/t…

.@subzey кажется, в твоем случае, брать сообщения из AMQP прямо в LUA/Nginx — должно быть гуд. Но все же, lua работает в контексте запроса.

В OSS кроме readme надо писать тесты! Тесты, КАРЛ! @backendsecret

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

@shuvalov_anton @backendsecret можно подумать, что не в опенсорс-проектах тесты не нужны

.@listochkin @shuvalov_anton кажется НЕ в опенсорс мире, на тесты почти никогда не остается времени…

@backendsecret @shuvalov_anton поэтому главное правило OSS: будь монополистом с офигенной документацией :D

Кстати,в контексте OSS: а вы обращаете внимание на лицензии используемых либ/фреймворков?Соблюдаете условия лицензирования? Или взяли и все?

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

@backendsecret @sudodoki GPL на сервере - не проблема в 95% случаев, +4% проблем решаются сменой текста контракта.

.@listochkin @sudodoki если у вас какой-то веб-сервис,да — ок.А если вы выпускаете какие-то железки с софтом? Все становится немного сложнее

.@listochkin @sudodoki да я ж ретвитнул вообще :)

“@paaleksey: А как разработчик бэкенда связан с железками?” я ж архитектор) И один из наших проектов — это программно-аппаратный комплекс.

Доброе утро, товарищи! Ой, или какое там у вас время суток!) Давайте сегодня поговорим о разработке, коммуникациях и взаимодействиях.

для начала только отвечу на оставшиеся вопросы.

.@serebro основная область применения WAMP’а как я вижу и знаю — это IoT.

.@serebro Тобиас @oberstet Оберштейн (автор wamp) запускает python wamp router (crossbar.io) на RaspberryPI и подключает всякое

.@serebro я в одном своем проекте так же строю на базе WAMPа коммуникации между конечными устройствами и сервером.

.@serebro и еще одно, как мне кажется, удачное применение WAMP — это оповещения о изменениях в многопользовательской среде

.@serebro пример: есть админка, пара админов зашли и хотят поменять инфу одного и того же юзверя. →

.@serebro → Админка при заходе на стр. юзверя подписывается на соотв. канал. И в случае изменений — получает уведомления. →

.@serebro → ну и сами задачи изменения данных легко можно превратить в вызов RPC и тем самым вообще абстрагироваться от бэкенда.

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

.@serebro по wamp есть новости на wamp.ws, неско заметок у меня в блоге (нет времени написать еще) и groups.google.com/forum/#!forum/…

Мне оч нравится идея использовать WAMP как основу композитных SOA-приложений. SOAP/WSDL—слишком тяжелые.Писал про это blog.ksdaemon.ru/2015/02/wamp-k…

@backendsecret как у тебя хватает сил и времени на всё? и OS и 2 подкаста, а ещё работа и личная жизнь...

.@dcromster о да! Сам удивляюсь. На все, что кроме работы и семьи, остается немного времени перед сном, когда все легли спать.

.@dcromster поэтому свои проектики я пилю по ночам, последнее время, правда, реже и меньше :( но как минимум пишу тестики, PR, доки и пр.

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

. @dcromster и, конечно же, самая большая проблема — это найти удобное время для записи всех участников. Приходится идти на компромиссы :)

@backendsecret Что делаешь когда "ничего не идёт" ака "тупняк"?

.@dcromster да,это нормально.В таких случаях я переключаюсь на какую-то механическую работу,та же документация или какие-то админские задачи

“@iamstarkov: интероперабельность это больше, чем совместимость?” Мне кажется в данном случае, это примерно одно.

.@iamstarkov тут смысл в том, что в одном скрипте можешь юзать и то и другое. +Как они пишут, можно на LUA метапрограммировать функции Terra

“@dcromster: так самому спать тоже надо!” Вот именно поэтому мало времени и я не сижу до утра %) хотя иногда бывает…

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

Согласен с высказыванием @bobuk: индикатор наличия творчества в профессии разработчика - если ты все еще программируешь вне работы

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

.@VasyaRomashova ой, вот у меня с этим точно проблем нет, потому как: 1) Личные проекты отличаются от рабочих,2) можно применять новые тех.

.@chemikadze это не важно, важно что ты читаешь, изучаешь, думаешь, мечтаешь, и в итоге делаешь (хоть и мало в силу разных причин)

@VasyaRomashova @backendsecret Геймдев для себя — главная страсть в жизни. Другие виды отдыха уже по вкусу. А работа близкая по духу ищется.

“@VovanR: было время и на работе и дома прогал не для себя =)” Лучше наоборот %) Все время для себя!)

@backendsecret без этого никак! Нужно же поиграться с новыми технологиями, запилить небольшой проект "для души" или что-то автоматизировать)

@backendsecret, плагинчики под WordPress доставляют особое удовольствие. И денег приносят бонусом :-D

Тут спрашивают, кого из разработчиков “must follow” в тви… Попробую назвать несколько имен…

enDevs которых я читаю: @rauschma @weaverryan @creationix @agentzh @fabpot @addyosmani @AriyaHidayat @igrigorik @gvanrossum @spolsky →

enDevs которых я читаю: @wycats @__DavidFlanagan @paul_irish @WebReflection @stoyanstefanov @ppk @slicknet @Souders

ruDevs,которых я читаю: @DmitryBaranovsk @AntonShevchuk @sam_dark @listochkin @rdvornov @mista_k @lisachenko @dshevchenko_biz @sergeybelove

на самом деле этот список можно продолжать долго) вплоть до 276 пунктов))

Конечно же там есть @filipovskii и @bashmish (с кем мы делаем @RadioJSPodcast и @moscowjs) и @jekill (c кем мы делаем @SymfoniacsMsk)

Вы вот мне лучше скажите, вы участвуете в каких-то сообществах? Не в тви почитать,а реально! Встречу/конфу сделать, помочь советом и прочее.

“@anton_davydov: пока провожу неформальные встречи в рамках moscow-rb.org.
В будущем хотелось бы более техн встречи делать” Круто!

“@anton_davydov: заметил странную особенность: все хотят неформального общения, но мало кто ходит :D” Все любят языком потрепать, а не делом

.@anton_davydov главное, что все же есть активисты, которые приходят и участвуют!

“@anton_davydov: а сам не думал проводить какие-то реальные встречи?” Я чуть раньше писал, что организую @moscowjs и @SymfoniacsMsk ;)

.@anton_davydov Ну на самом деле,основной двигатель @moscowjs — это @filipovskii :) Но ты приходи в гости, пообщаемся, поделимся чего да как

.@anton_davydov а из советов: не опускать руки, найти единомышленников, собираться, делать доклады, расширять сообщество.

“@anton_davydov: @backendsecret @moscowjs @filipovskii я вот 30го числа к вам хочу зайти как раз :)” Будем рады!

Да, чего-то мы сегодня так и не добрались до процессов разработки! Завтра с утра и начнем обсуждать! :)

Такс, давайте все же поговорим про процесс разработки и сопутствующие вопросы. Каким по вашему должен быть идеальный workflow? Методологии?

Сейчас эра гибких методологий. Но многие ли из вас строго следуют какой-то одной? ;) расскажу про себя сейчас.

У нас вотерфолл в долгосрочной перспективе и что-то эджайлоподобное на ближайший месяц/два с недельными итерациями и ежедневными стендапами

После внедрения стендапов - явно ощутили плюс: народу пришлось общаться :) и многие проблемы взаимодействия обсуждались на ранней стадии

Но даже стендапы не решают на 100% проблем взаимодействия.

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

Например:есть сишный сервис.Ему потребовалась бд.Дев взял и завел себе sqlite’тик,а про осн бд системы он и не думал. Итог: задвоение данных

Или еще хороший пример: деву сервиса удобно хранить все данные в JSON в одном поле в табличке. Но с этими данными работают другие модули ->

-> и им нужна фильтрация, поиск. И тут json уже не удобен. Но дев сервиса про это не знает. Результат: переделка, доп время и ресурсы.

Вы скажете “Ты ж архитектор! Вот и решай!” Но я скажу, что не возможно спускаться на такой низкий уровень, иначе просто не хватит времени!

Еще пример: есть web-клиент,Win-клиент,пара сишных сервисов. Все работают с одними данными. Но: .NET удобно 10 курсоров из одной хранимки →

→ веб юзает какую-ньть Doctrine, и генерит запрос сам. Сишным сервисам удобно вызывать одну хранимку с одним result-set’ом. →

Вопрос: как БДшнику грамотно организовать хранение данных в БД и угодить всем? %)

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

А @PZabolotniy любит каскадную модель. Но в ней большой риск не попадания в сроки и отклонения в сторону от реальных потребностей.

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

.@gruz0 вот тут тоже есть пример хороший: у нас несколько разные девы разных сервисов выбрали свой формат конфига. →

.@gruz0 А когда это попало в руки нашего системщика, aka devops, он был в ужасе, потому что ему все эти конфиги править при развертывании

По поводу средств сопровождения разработки и инструментов, у нас все просто: задачи, баги, вики - redmine, ТЗ, код-ревью и код в gitlab.

Вообще, мы довольно не плохо выстроили процесс.Я писал серию заметок про это.Почитайте,вдруг найдете что-то полезное. blog.ksdaemon.ru/2014/02/v-pois…

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

.@dcromster я бы сказал наоборот: у нас большие ТЗ с диаграмками и схемами, которое лежит в gitlab в markdown’е

.@dcromster у всех девов есть доступ, причем и на запись, любо может сделать PR в ТЗ. Но мало кто смотрит вокруг и на систему в целом :(

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

.@gruz0 у нас новичок сразу попадает в команду, ему дается небольшая но завершенная задача, ТЗ/вики/схемы/соседи в помощь.

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

.@dcromster @gruz0 Невозможно ДО написания кода полностью разработать и утвердить структуру БД, ибо БД — это часть процесса, как и код!

.@gruz0 да, у нас тоже системы безопасности, программно-аппаратные комплексы, и это совсем не инет-магазины на CMS’ках %)

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

Моя позиция: нельзя сразу стать кем-то крутым, архитектором, тимлидом, СЕО или еще кем. Надо знать, уметь и прочувствовать каждую ступень

А чтобы добиться чего-то большего,просто сидеть и качественно делать свое дело недостаточно. Это только наоборот большая радость начальнику)

Поэтому надо проявлять инициативу всегда, везде и во всем! И не бояться принимать решения и нести за них ответственность.

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

Именно поэтому важно начинать с азов: писать код, писать и знать его хорошо, смотреть по сторонам, залезать в смежные области. →

→ Это дает хорошую базу и экспертизу для принятия решений. А принятие решений и инициатива выталкивают вас на новый уровень

Именно так я шел:админство *nix,баз данных, программирование backend, frontend.Это все расширяет кругозор. Для архитектора это крайне важно.

@backendsecret, а как определяется проект, куда можно и куда нельзя воткнуть разработчика? По скиллам или "этот горит, надо срочно делать"?

.@gruz0 нет, конечно по скиллам. Просто если видно, что он не сможет там где нужно, можно перекинуть/переиграть расстановку сил.

@backendsecret а ты видел серьёзные команды, которые используют YouTrack? Кругом одни упоминания Redmine и Jira... Но мы мигрировали RM ->YT

.@PetrMyazin нет, я пока не встречал, не слышал. Тут скорее фактор того, что: ну вот мы настроили RM и все ок, нет смысла искать новое…

@backendsecret, у нас для задач/багов/вики — Bitrix24, код в Gitlab, код-ревью через RSS на Vienna :-D

@backendsecret, разработчики поголовно хотели Redmine, но было принято волевое решение оставить всех на Битрикс24. Прижилось вполне.

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

@anton_davydov @backendsecret много-много-много читать. Фаулера, Мартина и прочих взрослых дядек. Практика-практика-практика :-)

.@dcromster в ТЗ невозможно описать все-все-все, иначе оно будет 10000 стр. и его никто никогда не будет читать даже.

.@dcromster в любом случае,какие-то мелкие детали ложатся на плечи разработчиков.Инач,можно набрать индусов,которые будут циклы и ифы писать

.@dcromster именно это отличает хороших разработчиков от кодеров (кодировщиков блок-схем) %)

“@dcromster: чем точнее тз тем меньше проблем. Разве не так?” Все так!Но сложно охватить сразу все.ТЗ живет и развивается вместе с проектом

“@dcromster: не все начальники это понимают :(” Плохие начальники — это печаль. Но я правда, тьфу-тьфу-тьфу, таких не встречал :)

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

. @gruz0 это очень хорошее замечания! Оно было завуалировано в принятии решений, которые раньше принимал начальник :)

@backendsecret @dcromster я считаю, что ТЗ может и должно меняться из формального документа в Wiki по проекту.

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

@dcromster @backendsecret я раз в месяц подхожу к своему VP и говорю: "выгрузи из головы идеи на бумагу, давай их мне". Садимся и обсуждаем.

@dcromster @backendsecret в общем, в этом я вижу роль тимлида и управления разработкой — грамотно распределить зоны ответственности.

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

.@PetrMyazin расскажи, чем YouTrack интереснее RedMine или каких других продуктов?

Важно понимать,что у тимлида свои обязанности,он не просто дев с большим грузом ответственности. У него свои функции [помимо/взамен старых]

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

.@anton_davydov хороший вопрос! Я почти не пишу код. Пара небольших модулей+эпизодически код ревью, осн время: ТЗ, управление,распределение

.@anton_davydov именно поэтому я отрываюсь в личных проектах: пишу на чем хочу, юзая свежии версии инструментов! %)

@anton_davydov @backendsecret очень редко, практически не прикасаюсь к коду, но часто приходится во время код-ревью его читать и…

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

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

Есть такое понятие как «Предел некомпетентности» aka принцип Питера, выдвинутое Лоуренсом Питером (ru.wikipedia.org/wiki/Принцип_Питера)

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

@anton_davydov @backendsecret на практике код пишут дома(: очень маленьких процент людей реально желающих стать тимлидами

@backendsecret, стоит отдельно обсудить такую тему, как уход/увольнение текущего тимлида из команды и назначение этой роли другому человеку.

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

Как верно было замечено, не много желающих/могущих быть тимлидами. Да и 2 тимлида в одной группе — не вариант. Так что тут дилемма: →

Или назначать кого-то старшим в группе «сверху»,что не ok,или делать рокировку и брать «сбоку».Найти на рынке и сразу в тимлида — не вариант

Оффтоп: на днях утекли исходники fl.ru. Для поднятия настроения посмотрите в перерыве) github.com/veryEvilMan/fl…

.@rastopyr_ua там мегахрень, а не мегамонстр!))

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

.@gruz0 именно по этой причине у любой задачи всегда ОДИН ответственный, но может быть много соисполнителей.

В свете обсуждения вопроса повышения проф навыков: как вы относитесь к курсам?Часто на интервью слышу от новичков вопрос по этому поводу

Даже перефразирую: как вы относитесь к курсам повышения квалификации и подобным и сертификации? Оно кому-то нужно? Или нет смысла?

@backendsecret, курсы бывают разные. Я мало прошёл в своей жизни, в основном по книгам всё. Но вот Swift на udemy.com изучал.

Я вот, кстати, по личной инициативе сдал много разных экзаменов по Oracle DB. И не ради кого-то или потому что надо, а для себя.

Но и руководством это не осталось незамеченным. И это дополнительный плюс.

@backendsecret, для сетевых инженеров/DBA и прочих — однозначно надо, всякие там Cisco/Microsoft. А разработчикам на их усмотрение.

Я вот тоже считаю, что по програмированию курсы имеют смысл только для новичков. Для мидл/сеньёр — книги, практика, дискуссии

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

.@gruz0 поскольку мы партнеры Oracle, 2 экз в год — бесплатно :) Курсы для сертификации — контора оплачивала, самому — дорого.

Сейчас, кстати, подписался на бетаэкзамен по Оракловым кластерам по 12с версии. Осталось 2 недели, еще нифига не готовился %)

@backendsecret, экзамен ≠ курс же :-) Можно дома изучить и поехать сдавать, оплачивая только сам экзамен.

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

@backendsecret, мне в Роснефти с пяток лет назад приходилось иметь дело с Oracle в .Net. Впечатления положительные, но рад, что соскочил.

.@gruz0 если говорить про БД: я имел дело с PostgreSQL (еще 7.x), MySQL, MSSQL, Oracle. Мой личный выбор — однозначно оракл. Он крут!

@backendsecret, вообще, я сторонник той позиции, что если есть возможность — лучше нанять отдельно разработчика БД. Это выгоднее в разы.

.@gruz0 поддерживаю. Именно по этому у нас есть отдельные БДшники и я ярый сторонник процедур и пакетов, а не SQL в коде приложений и ORM.

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

@backendsecret, простой вопрос: уместно ли хранить расчёты/агрегацию и прочу числовую муть в SP? Как у вас реализовано? :-)

.@gruz0 мы всю агрегацию делаем на уровне БД. Она же для этого и нужна! В клиент уходит конечный рекорд-сет.

.@gruz0 у нас был 1 тяжелый случай,когда было много новых данных,а агрегированный пересчет затрагивал всё!—пришлось обсчет делать на сервисе

@backendsecret, чёрт побери! Я нашёл себе собеседника для души, комрад! :-D Спасибо тому, кто дал тебе доступ к этому аккаунту! :-D

@backendsecret, видел много ада раньше, когда чуваки выбирали тысячами данные из БД и потом в AR рассчитывали это, вместо того, чтобы…

.@gruz0 это просто ужасно!Слепость разработчиков и привязанность к своему ORM. Бить по рукам! Собственно, это одна из задач архитектора!

“@gruz0: гоняете юнцов на вопросах о left/right inner/outer join? :-D” С join все более-менее ок, а вот group by/having — уже многие плавают

Коли уж мы затронули БД и код. Холиварный вопрос: как вы относитесь к ORM? Мое мнение и @gruz0 вы уже знаете. А как у вас?

@backendsecret @gruz0 ORM - зло!

@backendsecret @gruz0 хм, а как вы деплоите процедуры? И что вообще в бд считаете? У меня нету вообще такого опыта.

.@lisovskyvlad например,в хранимках у нас проверяются права юзверя на данные. Или подсчет какой-то базовой статистики по джобам или сработке

“@rainrb: имхо дело не в орм, а в недостатке опыта” ORM — норм, если оч хорошо знать как она работает.Иначе можно крайне неэффективно делать

.@rainrb Знаю много примеров, когда юзали Doctrine, и писали через сущности и было много лишних запросов. →

.@rainrb а ведь можно было написать один метод в репозитории, который за раз собирал все и отдавал. Так что знание и опыт решают!

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

.@rainrb ой, мне сложно сказать. Но по опыту Oracle моя мысль такая: надо хорошо понимать как работает БД →

.@rainrb какие процессы в БД за что отвечают,как устроено хранение, что и как хранится в памяти, как работают логи и журналы, курсоры и кэши

.@rainrb и в итоге самым лучшим источником знаний является официальная документация! Кстати, насколько знаю, в pg она довольно хороша!

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

В Oracle с 11-й, кажется, версии, есть понятие версии схемы. Смысл в том, что у вас могут одновременно жить несколько версий структуры →

Вы заводите новую версию, выкатываете новую структуру/приложение. Старые сессии/клиенты дорабатывают по-старому, а новые уже видят новое.

Давно хочу попробовать это дело, но все времени нет.

“@gruz0: в моей текущей деятельности пытаемся обеспечить простой при деплойменте приложения меньше секунды :-D” Круто!

“@de_gis: а как это ТЗ в гитлабе?” ТЗ пишется в MD, и версионируется как проект в gitlab → все (dev, qa) имеют доступ к актуальной версии!:)

@gruz0 @backendsecret @dcromster замечу,что часто ещё ТЗ фиксируется в контракте на весь объём работ

.@de_gis @gruz0 @dcromster в контактах обычно общие слова и функции. А у нас уже подробное функционально-техническое.

@backendsecret, кстати, да — отдельно стоит обсудить постановку и приёмку задач, управление сроками. Это тоже очень интересная тема.

У нас процесс работы с задачами следующий: крупными мазками с руководством планируем задачи. Дальше они детализируются, декомпозируются →

→ после чего компонуются в порядке приоритета. Затем обсуждаются в кругу разработчиков: кто что и, главное, за какое время сделает →

→ а дальше, у каждого разработчика есть свой коэффициент :) считающийся по формуле: затраченное время/озвученное время. →

→ в идеале, этот коэф. должен быть равен 1. Но это крайне редко. В некоторых случаях он доходит до 4х а то и больше.

Именно поэтому ходит поговорка: возьми время, озвученное разработчиком, умножь на 2|4|8 и получишь реальный срок :)

Идем дальше: приемка. Тут неско важных моментов: код-ревью кем-то из коллег, сливание PR в осн ветку, закрытие задачи и выставление статуса

.@marinintim а задача стрелочки всего лишь сообщить, что в продолжение мысли в следующем твите :) А при чтении их надо игнорить просто :)

.@gruz0 да, самое время расслабиться после рабочего дня!

А я пока расширил и дополнил ссылками список слушаемых мной подкастов.Удалил заглохшие больше года. gist.github.com/KSDaemon/1d3c4… Там много нового

Вчера обстоятельно поговорили про процесс разработки (и то не все обсудили). Но давайте сменим тему :)

Давайте поговорим об архитектуре в общем смысле. Монолит, SOA, микросервисы? Что думаете? У каждого подхода есть свои + и -. Какие у вас?

Многие сильно хают монолиты, что прям вот микросервисы и никак иначе! Я в корне не согласен.

Монолит — это быстрый старт, удобство обслуживания, возможность проверки решения и жизнеспособности проекта, выработка подхода и функций

Микросервисы с нуля — возможны при ооочень подробном и детальном ТЗ, когда сразу можно увидеть функциональные блоки →

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

Именно по этой причине мне всегда смешно,когда в новом проекте сразу выбирается какая-ньть монга/кассандра как БД, вместо традиционной RDBMS

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

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

@backendsecret монга разве не проще для JSON APIs? Как минимум на серелизации экономишь

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

.@gruz0 да, это большая проблема. И тут надо только показывать и доказывать руководству как действовать дальше.

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

@filipovskii @backendsecret а если взять couchdb, то можно совсем без бекенда

.@somerandstring @filipovskii что подразумевать под прототипом? Если просто интерфейс—может и ок. Но работающий прототип—это и бэк и сервисы

Есть интересный доклад про модуляризацию систем: Nano, Micro, Mini, oh my: Modularization for sustainable systems youtube.com/watch?v=HYiLzj…

А еще есть такая методология 12-ци факторов для создания SaaS-приложений. 12factor.net/ru/ Там много правильных слов.

По архитектуре самих приложений есть оч интересный ресурс:The Architecture of Open Source Applications aosabook.org/en/index.html Крайне советую

Наподобие 12Factor, еще есть метод «aim42». aim42.github.io Там тоже про эволюцию, поддержку, улучшение и миграции систем.

.@raxpost если этот выбор осознанный — я только «ЗА»! Но если просто потому что «ну все же юзают монгу!» — то уж извините.

@backendsecret для некоторых стеков Mongo - база по умолчанию. На Node 90% фреймворков, BaaS, шаблонов проекта как раз рассчитаны на нее.

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

.@listochkin я про то, что выбор БД для фреймворка обусловлен только личным предпочтение создателя, а не реальными потребностями

Хотите посмеяться? Веселый баг в MySQL: есть SQL запрос вида CREATE USER ххх ident by yyy require SSL. Так вот в старых версиях MySQL →

он работает очень круто: создает пользователя без пароля и говорит, что все ок!!! То есть проблем нет, но и пароль с SSL я включать не буду!

Сегодня, кстати, у нас мероприятие @moscowjs. Вот вы, бэкендеры, скажите, вы смотрите на мир фронтенда, чего там нового? Интересно?

@backendsecret @moscowjs бэкендер смотрит в мир фронтенда через REST

.@RusAlexander а как насчет веб-сокетов или еще каких протоколов? REST — это хорошо, но есть и другие способы взаимодействия! ;)

Еще интересный вопрос: есть ли кто-то, кто ушёл в бэкенд с клиентской стороны (не важно какой)? Вот наоборот знаю много случаев.

@backendsecret я перешел когда-то с front на back end, но стараюсь не отставать по обеих направлениях

@backendsecret @moscowjs Я таки full-stack, но graphql и falcor всё изменят и на фронтенде и на бакенде.

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

Graphql - это новый способ общения клиента и сервера, точнее язык запросов. Когда клиент говорит чего хочет, а бэк все разруливает и дает.

Мне всегда нравился SOAP/WSDL за готовое описание интерфейсов. Но он оооочень тяжёёёёёлый!

@backendsecret я как комар между двух фонарей. И там интересно, и без бэка никуда. @moscowjs

@backendsecret @moscowjs это смешно, но работу найти труднее. Узкая специализация сейчас всё ещё "рулит" :(

.@dcromster мне кажется, сейчас в проектах нужны все категории спецов: и узкого и широких профилей. У меня в веб-команде есть и те и другие

.@dcromster это дает гибкость в распределении и решении задач. Всегда можно усилить ту или другую сторону.

Хелло world! :) Продолжим? :) Вчера было еще несколько вопросов, сейчас на них отвечу.

Да, мы обсуждали тему: «смотрят ли бэкендеры по сторонам?» :)

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

.@RusAlexander → и у нас сложная и гибкая система прав на данные, поэтому проще решать эти вопросы внутри хранимок . →

.@RusAlexander → пользователь БД, из-под которого работает ПО, имеет доступ только к выполнению определенных хранимок.

.@RusAlexander → это проще, чем настраивать доступ для БД-юзеров на уровне строк кучи таблиц и поддерживать это в актуальности.

.@backendsecret Redmine vs YT: в YT отличный "аяксовый" keyboard centric интерфейс, экономит время на типовых задачах habrahabr.ru/post/245065/#c…

“@KELiON: считаю что полезно не только во фронтэнд смотреть, но и в ux/аналитику (в первую очередь) и ui (во вторую)” Поддерживаю!

Как я говорил, вчера был отличный @moscowjs и душевные посиделки после. Радует, что участвующих становится все больше и есть новые лица!

Так вот, рассказывал про @backendsecret. Обсудили много разных тем: DB, ORM, ACL, PgSQL, Oracle, Ruby, Django, Doctrine и еще много всего!

Это я про к тому, что даже вот на такие, вроде бы, чисто фронденд-встречи, ходят и бэкендеры и тоже участвуют в обсуждениях! И это здорово!

.@RusAlexander мы юзаем хранимки и в MySQL. У нас порядка 8 программных модулей (PHP/C#/C/C++), у всех свои гранты на определенные хранимки

“@listochkin: про что говорили?” Ох, много про что: подкасты, debug, рендеринг, оптимизация, фреймворки, конференции, сорта пива :) и т.д.

“@RusAlexander: но на самом деле столкнулся с ограничениями хранимок в MySQL.” Расскажи поподробнее!

Товарищи! А расскажите мне, какая у вас структура команды: сколько бэк/фронт-девов, есть ли UI/UX-дизайнеры, тестеры, архитекторы?

Видать пятница всех расслабила… Тишина :) все ушли в соц сети, арканоиды и солитеры?)

.@RusAlexander мы спокойно возвращаем один и даже неско рекордсетов из хранимок. Или я не правильно понял мысль.

@backendsecret , Ваше отношение к исключениям (exception) в программировании?

.@PZabolotniy если коротко: эксепшны нужны. Сервисы и приложения должны работать корректно по отношению к миру даже в случаях ошибок.

.@PZabolotniy ошибки разрабов надо ловить и собирать, но для пользователя должно быть понятное уведомление и инфа о том как быть.

.@PZabolotniy то же касается и АПИ. Очень раздражает, когда получаешь стэктрейс внутренней кухни, вместо какой-то вменяемой ошибки/кода

@backendsecret SELECT * FROM ProcName(param1, param2); Хочется такого.

.@RusAlexander а чем плох вариант exec ProcName(param1, param2); которая возвращает нужный рекордсет?

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

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

@backendsecret а что ты понимаешь под админом в душе? :)

“@anton_davydov: а что ты понимаешь под админом в душе? :)” Я скорее про то, что надо уметь и любить ковыряться в настройках, конфигах и пр.

@backendsecret именно. Когда я моюсь в душе и моя борода превращается в мокрую и лохматую, то на вид - админ админом!

.@listochkin ну ты-то точно админ в душе, я уверен! А после душа — так вообще без варинатов, судя по всему!)

@backendsecret , разработку надо вести в той среде, в которой удобно, или в той, в которой ПО будет эксплуатироваться?

.@PZabolotniy Я бы сказал, одновременно и там и там :) Сейчас полно инструментов для этого: docker, vagrant и прочие.

.@PZabolotniy это позволяет: а) унифицировать окружение у всех девов, б) иметь одно dev/test/prod окружение, в) дать легкий старт новичку

.@PZabolotniy Опять же благодаря этому, можно иметь любимое и удобное окружение для работы, Mac/Linux/Win, любой редактор и прочее.

@PZabolotniy @backendsecret если тестирование на той же машине, что и конечная эксплуатация, то скорее да.

.@Kern_0 @PZabolotniy о нет! Это очень плохая идея!А что,если что-то пойдет не так?Прод просто ляжет из-за глупой ошибки. Нельзя так делать!

.@Kern_0 @PZabolotniy да,я тоже ЗА то,чтобы если прод на линуксе—то и разработку желательно вести на линуксе. Но контейнеры это абстрагируют

“@RusAlexander: К нему join нельзя будет сделать.” А зачем к нему делать join потом, если его можно сделать сразу в SP?

.@RusAlexander Или вы динамически строите запрос с джоином с участием каких-то статических кусков запросов?

.@iamstarkov да, сорри, если забыл пару раз ретвитнуть перед ответом!

@backendsecret @Kern_0 @PZabolotniy а мы не придерживаемся такого правила. У нас все пишут на Mac OS, а продакшн-серверы на CentOS 6.

@backendsecret @Kern_0 @PZabolotniy но у нас для каждого приложения есть staging- и production-серверы, которые идентичны в настройках.

@backendsecret да, есть часть запроса которая идет по проекту. Видимо идет к тому, что запросы будут строиться динамически.

.@RusAlexander ну если кейсов не много, можно их же забить в SP и +1 параметр на вход.

.@RusAlexander если кейсов много, то да, if-else не вариант, но и dSQL можно в хранимке писать, все равно будет в одном месте.

@backendsecret Во имя Сети и Сервера и Резервных Копий. Админь!

“@anton_davydov: вот ты много говорил про администрирование. поэтому, можешь посоветовать 1 самый маст рид?” Сложный вопрос

.@anton_davydov Я начинал с FreeBSD handbook то ли по 4.4, то ли по 5.0 версии :) ну и дальше понеслась.Но вот одной какой-то книжки не знаю

“@truecrux: каждый из нас админ локалхоста ;)” :) Хех! Жаль, но даже это не всегда так.

@backendsecret да, dSQL, но не очень уж они удобные у MySQL, хотя может мне не хватает в этом опыта.

.@RusAlexander больше практики и изучения best practice! А так же спрашивать у старших товарищей совета и рекомендаций! ;)

Товарищ @23slider вот какой ресурс посоветовал: Server Admin for Programmers serversforhackers.com

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

P.S. Хабр/SO/Google не предлагать! :)

Или может, какой доклад интересный посмотрели, что наступило прозрение, или наоборот, башню снесло! %)

“@afiskon: мы все цепляющие статьи в #devzen обсуждаем, там куча ссылок :)” О, привет! И ты тут! :) Но все же что-то зацепило особенно! ;)

Вот товарищ @vyazovoi проникается emacs и org-mode: planet.emacsen.org и doc.norang.ca/org-mode.html

Очень интересный доклад автора Clojure, Rich Hickey «Are We There Yet?» infoq.com/presentations/… Доклад 2009 года, но актуальности не потерял!

“@dcromster: всё тот же - 36.” О, да! Если вы еще не видели доклад Вадима Макишвили «36». Обязательно посмотрите! events.yandex.ru/lib/talks/2235/

@backendsecret все 5 человек full stack, отдельного архитектора нет, коллективный разум: small dream team!

.@zhulikgleb советует: golangweekly.com dbweekly.com postgresweekly.com rubyweekly.com Но я перестал их читать

@backendsecret хорошие статьи встречаются на pragmaticperl.com, например об асинхронном программировании (pragmaticperl.com/issues/21/prag…).

@backendsecret 2 бэкенда, 2 фронта, 1 фуллстэк. Но стараемся все в фуллстэк уйти

@backendsecret практичный вопрос: как правильно спроектировать API?

.@dcromster непростой вопрос, и конечно все зависит от задачи и специфики. Но попробую сформулировать общие рекомендации.

.@dcromster надо выделить сущности, определить возможные действия над ними, разложить все по неймспейсам, определить формат запросов/ответов

.@dcromster под форматом я имею в виду не тип (json|xml) а именно подход:как понимать что запрос успешен,определить диапазоны кодов и прочее

“@dcromster: Есть какие-нибудь подводные камни?” Подводные камни есть всегда! Например, когда придется расширить АПИ как-то нестандартно

.@dcromster или когда потребуется добавить какие-нибудь распределенные транзакции. В общем может быть много вопросов.

.@dcromster Но если в начале была придумана и описана четкая структура, всегда будет проще её расширять и дополнять.

Товарищи! Мы обсудили много разных тем, но вдруг у вас есть вопросы — спрашивайте, не стесняйтесь! ;)

@backendsecret ваше мнение, что важней - процесс или результат? И что же делать когда хотят результат - но на нормальный процесс нет времени

.@kryapolov смотря для кого. Для начальства всегда важнее результат, для прогеров оч часто сам процесс.

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

@backendsecret как подготовить проект к переходу на новую мажорную версию фреймворка?

.@m1kenobe ох.Непростой это вопрос.Если фреймворк серьезный,обычно известен роадмап,появляется новый АПИ, а старый помечается как deprecated

.@m1kenobe поэтому нужно не ждать релиза, а начинать переписывать deprecated кусочки, не все сразу, а по чуть-чуть.

.@m1kenobe тогда к моменту нового релиза уже не будет неработающего кода и не придется тестировать вообще все.

@backendsecret @kryapolov я, как апологет Скрама, считаю, что команда на ретроспективе должна решать, как улучшить процесс.

@backendsecret "звеньями".1звено=2бэк+1ui+1qa+1аналитик.Иногда: 1 аналитик на 2 звена и 3qa на 2звена.

“@de_gis: архитектор(тимлид) и DBA над звеньями и шарятся по проектам” вот у нас точно так же! Еще QA правда тоже shared :)

“@dcromster: @backendsecret расскажи о себе как о человеке ;)” оу.. Ну это ж будет крайне субъективно. Спросите лучше тех,кто меня знает :)

“@dcromster: расскажи о себе как о человеке ;)” ну или что-то поконкретнее спроси(те) :)

Товарищи, а какие у вас увлечения помимо программирования, ну или не по профилю?) Я вот интересуюсь IoT,пытаюсь ковырять ESP8266 и все такое

“@filipovskii: кем хотел стать в детстве? :)” В совсем глубоком - не помню, но со школы уже смотрел в электронику, =>

.@filipovskii @dcromster а в 12 лет, когда мне родители подарили 80386 (который работает до сих пор, кстати) выбор был сделан окончательно!)

.@dcromster хотя, чтобы было интереснее: вот вам несколько фактов обо мне ;)

Факт 1: мое первое место работы - Большой Театр. Попробуйте угадать кем? ;)

Факт 2: я окончил муз школу по классу аккордеона. А сейчас после каждого @moscowjs мы с @aleksisha немного дудим на гармонике :)

Факт 3: я был байкером, у меня был 1100 кубовый крузер Honda Shadow, косуха, кож штаны и все дела :)

Факт 4: я искал работу только в самый первый раз. Во всех след случаях, все получалось как-то само.

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

Факт 6: я пил пиво с Томом Кайтом и Майклом Видениусом :)

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

.@listochkin кажется это был сарказм :) но на всякий случай: Tom Kyte - самый известный чувак в мире Oracle DB, “Ask Tom” - это как раз он.

.@listochkin ну а уж Монти, создателя MySQL, кажется и так все знают :)

“@listochkin: крамольное мнение: я считаю, что MySQL - очень ОК. Для меня - база по-умолчанию.” По большому счету, я с тобой согласен!

“@a_lithium: @listochkin уже спрашивали почему не postgresql?” Я бы сказал, так сложилось исторически. Это был стандартный инстр-нт в стэке

.@filipovskii касательно дядек и игр: это была игра-симулятор развития нефтяной компании :) и играли в нее как начальники НПЗ :))

“@filipovskii: уоуоуоу ты просто обязан как-нибудь со всем этим появиться на MoscowJS!” Тогда уж ВО всем этом! ;) я подумаю ;)

“@verylazydreamer: @listochkin твиттер использует mysql, даже своя модификация есть” Многие используют и все ок, это скорее искусств негатив

“@de_gis: виноградорство” о, круто! Результат бывает полусладким, сухим и пр?)

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

Ну что, товарищи… Подходит к концу мое дежурство на посту @backendsecret. Надеюсь вам было интересно и вы узнали что-нибудь нового.

Меж тем, если что, вся инфа и статистика есть на backendsecret.ru

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

С вами был Константин @KSDaemon Буркалев. Спасибо еще раз и до новых встреч! ;)