Всем привет! На этой неделе с вами @retran.

lead software developer в маленькой продуктовой компании, разрабатывающей коммерческий фреймворк для erp-систем.

Уже лет пять специализируюсь на энтерпрайзном бэкенде и разного рода API и сервисах.

Так что на этой неделе будем говорить про REST, RESTful, SOAP, проблемах интеграции систем, мобильных бэкендах, etc

@backendsecret о, давай: кто возвращает 200 вместо 4xx и 5xx, тот...?

Не могу придумать цензурное слово :) Аналогично - коды ошибок вместо SOAPFault

@gvsmirnov @backendsecret jsonRpc?

ИМХО, json не лучший выбор для rpc вообще. Можем поспорить :)

@backendsecret где можно почитать про бестпрактисы по структуре REST API

Чтиво про rest - infoq.com/minibooks/emag…

"@vassilevsky: @backendsecret подскажи единственно верный способ аутентификации в JSON API" OAuth 2.0

"@atnartur: @backendsecret каким инструментом для создания документации по API пользуетесь?" visualstudiomagazine.com/articles/2014/…

@OdinYury @backendsecret shop.oreilly.com/product/mobile…

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

Когда вы делаете что-то для SPA или мобильного приложения - это не так важно.

Но когда вы делаете публично api или api для интеграции с другой компанией (да даже и другим отделом в компании)...

Лучше сделать так, чтобы само api "умело рассказать" о своем контракте и уменьшить издержки на boilerplate-код для парсинга и валидации.

.@OdinYury Всем рекомендую эту статью blog.2partsmagic.com/restful-uri-de… @backendsecret

Соответственно, если вы суровый энтерпрайз - вам нужен XML (или вообще SOAP). Если модный веб-стартап - например, protobuf.

Кстати, если у вас XML - не забудьте проверить ваш фреймворк в целом и парсер конкретно на подверженность XXE.

XXE (owasp.org/index.php/XML_…) - одна из самых популярных дырок в XML-based сервисах.

Например, дотнетовский XmlDocument в дефолтной конфигурации дыряв.

Мое больное место - непонимание кучи людей зачем в SOAP есть SOAPFault и как его использовать.

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

С другой стороны, однажды делал интеграцию с одной платежной системой. Дотнетовский парсер на их xml'е радостно падал.

Оказалось, что их бэкенд написан на некоем пхпшном фреймворке, содержащем баг.

Но так как их клиенты собирали soap-сообщения ручками и парсили тоже ручками, про этот баг никто не знал, пока не пришли мы :)

@backendsecret можешь ввертеть aws.amazon.com/ru/api-gateway… для валидирования. Сейчас таких продуктов становится всё больше.

@backendsecret capnproto.org/index.html от создателя protobufs v2

@defly_self вот, что я хотел показать api.github.com
даже в точке вхождения в API есть мануал,и это круто @flushdia @backendsecret

@Bubyakin @flushdia @backendsecret был опыт внедрения, только не публичного API, отлично себя показал. Экономит время и бэкэндам и фронтам

Расскажите про самое кривое API с которым вам приходилось интегрироваться.

Мой случай - SOAP-сервис одной милой госслужбы, в котором все идентификаторы в контракте были заданы кириллицей. КИРИЛЛИЦЕЙ, Карл!

@backendsecret круто! =) ну, я второй год работаю с шикарным немецким апи... в котором все параметры - сокращенные немецкие слова.. (

@ztaaz @backendsecret я вот сейчас читаю код на perl'e.. и на немецком (я пхпшник ваще). Да, у них это норма походу :( жизнь - боль

Приходилось ли вам когда-нибудь делать stateful api? Стыдно ли вам за это?

А еще выбора нет, когда ваше api предоставляет клиенту какой-либо пошаговый бизнес-процесс (workflow, вот это все).

Думаю с форматами и протоколами пока все. Предлагаю другую большую тему - SOA 2.0 и event driven services.

И близкую к ней - CQRS, event sourcing и даже набившие оскомину в последнее время микросервисы.

Давайте определимся с терминами. Когда вы просто напрямую синхронно дергаете за некое api и синхронно получаете ответ - это SOA 1.0

В SOA 2.0 вы кладете ваше сообщение в service bus (или даже очередь) и спокойно про него "забываете".

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

Удобно считать, что сообщение несет с собой информацию о некотором событии произошедшем в системе.

@backendsecret понятно :) В качестве резюме --- синхронные запросы для получения данных в концепции SOA 2 никто не запрещает.

Неплохая презентация на тему - slideshare.net/chris.e.richar…

Еще одна хорошая связанная тема - actor model. Скалисты, где вы? :)

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

@backendsecret @unel86 ну, я экторы только в скале плотно пощупал. И довольно быстро разочаровался. Когда проект разрастается, то сложно…

@backendsecret @unel86 …становится даже банально осознать флоу сообщений. А тулов для дебага нормального (по крайней мере на тот момент) нет

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

ИМХО, если сложно осознавать поток сообщений, то вы что-то не так делаете.

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

@backendsecret всякие сервисы email-рассылок местного розлива, "аналоги" MailChimp, типа pechkin-mail.ru. Стыд-то какой, господи.

@ivan0yu @backendsecret О, скотч! Хоть один человек понимают мою боль (:

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

@backendsecret официальный кончился в шесть, неофициальный не имеет границ)

@backendsecret обычно ухожу с работы часов в 19-20)

@backendsecret нет официального окончания, о чем жалею иногда

@anton_davydov 00-24 это тяжко :) @backendsecret

Интересно, а остались еще разработчики, которые сидят на работе "от звонка до звонка"?

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

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

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

У меня очень хорошо взлетел emacs org-mode как раз потому что можно писать почти в свободной форме.

@backendsecret с недавних пор producteev.com GTD реализовать можно, хотя и не удобно списки через теги, но пока лучше не нашёл

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

@backendsecret очень даже сделает. нахуй послать может несколько раз :)

На сегодня вас покину :( Завтра все-таки поговорим про actor model и подробнее про семантику и контракты сервисов.

Если есть интересные темы - предлагайте.

"@en_austin: @backendsecret PS4 vs XOne? ;-)" Оффтопик же

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

"@en_austin: @backendsecret верно, но рабочий день закончился, можно и пооффтопить:)" может сразу IOS vs android?

@backendsecret agile results очень хорошо идет 30daysofgettingresults.com

"@webholt: @backendsecret Я так работаю." Зачем?

"@webholt: @backendsecret Вариант, что кого-то это может устраивать, не рассматривается вовсе?" Рассматривается.

@backendsecret @unel86 да, именно. Но с ростом актёров (модулей), кажется, всё становится излишне сложным.

@backendsecret @unel86 то же самое можно про микросервисы сказать, лол.

"@43oN: @backendsecret @unel86 а, да. я говорю про кейс с антайпед-экторами." У антайпед-подхода есть плюсы, но.... В общем, я не поклонник.

@backendsecret Вот. У нас в городе я вообще не слышал о сколько-нибудь серьезных конторах со свободным графиком.

@backendsecret А что касается меня, то после 7 лет фриланса я целенаправленно шёл в офис на фуллтайм.

@backendsecret @unel86 ммм... Вот создатели считают наоборот. Да и тайпед-экторы были костылём. А их ещё не выпилили разве? :3

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

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

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

@strizhechenko @backendsecret «А если я просплю до обеда, успею ли я завершить таск и не выебет ли меня шеф?»

Обычно в качестве плюсов untyped-авторов приводят возможность "менять контракт" в зависимости от стейта. Но для меня это звучит странно.

Почему новый контракт не может быть типизованным?

@backendsecret нее. Untyped — это когда у эктора один метод receive, который принимает произволный мессдж, а далее паттерн-матчинг с понями

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

@backendsecret typed — когда ты пишешь обычный класс с блекджеком и методами и обращаешься как к обычному объекту. Вся магия от тебя скрыта

Опять же, как то что возвращает актор зависит от того как он парсит сообщения?

"@Fodoj: @backendsecret @en_austin микросервисы это buzz word" Согласен.

@backendsecret логично предположить, что есть. Но, честно, уже не помню/не знаю умеет ли

@backendsecret в акке был плох реализацией — не более. Статический роутинг прще дебажить.

"@Kukuruzovich: @backendsecret ровно никак" вот и я о том же

@backendsecret считается ли statefull service за API как statefull API? statefull service вполне годная вещь если применять с умом

@backendsecret кидал до этого когда вел этот твиттор ссылки на statefull сервисы, в gamedev это вообще only way по факту

@unreal_michael @backendsecret все так, даже больше - composite сервисы, они же API Gateway (edge services) это и делают по факту =)

@ivanenok @backendsecret так это было самое первое собеседование. Оно очень спонтанное было. Сидел в переговорке, ждал генерального, тыкал в

@ivanenok @backendsecret планшетик. И думаю "Дай отзывы посмотрю". Посмотрел. Охуел. Начал спрашивать "Так?" говорят - "Да". Ну я и ушел :)

"@Woundless: @backendsecret а ты сам по графику работаешь?" В офисе, но фактически свободный

@strizhechenko @webholt @backendsecret та же проблема... Еще и режим сбился после новогодних. Есть идеи как выбираться из этой ситуации?

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

"@Woundless: @backendsecret т.е. в теории можешь прийти и уйти когда хочешь, но это не желательно?" Не нежелательно, а "надо предупредить".

Доброе утро, твиттер!

@backendsecret Пора делать великие дела и релизить новые фичи!

"/api/entities, но /api/entity/1" или "/api/entities и /api/entities/1"?

@backendsecret Когда начинают менять URL то начинается путаница и главное что постоянно нужно держать в голове сей факт. Короч я за 2 :)

@backendsecret 2й лучше - уменьшается когнитивная нагрузка на пользователя твоего API (прогеру клиента проще без заморочек с формами слов)

Опросом я проиллюстрировал, имхо, довольно важную тему.

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

Поклонники второго варианта обычно говорят, что так с АПИ проще работать (и они правы, имхо).

Иногда, еще говорят, что семантика такого варианта расшифровывается как "есть массив entities, мы получаем элемент массива entities[1]"

Что важнее? 1. Семантика бизнеса 2. Техническое удобство 3. Нужно искать компромисс, и это как раз этот случай.

@backendsecret вот бизнесовое удобство у твиттора например :) каша, мёд, гавно и пчёлы :) dev.twitter.com/rest/public

@backendsecret покажите мне тех людей, кто проголосовал за #1! Я хочу на них посмотреть

@Bubyakin пусть лучше сами признаются :) @backendsecret

@Bubyakin @backendsecret это тролли :)

История № 2, большая, поэтому гистом - goo.gl/9eACAz

@backendsecret проблема генерации урлов надумана, я за 1 вариант голосовал

@backendsecret если тру REST, то без разницы, хоть10 раз в день можно менять

Разберем. 5 вариант не подходит, так как запрос валиден и ситуация с пустым списком кастомеров тоже. Так что мы должны вернуть ответ.

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

Да и расширять становится проще.

И самое интересное: что возвращать если нет элементов - null или пустую коллекцию?

@backendsecret Мне кажется вариант API императивных истеричек, не хватает еще варианта с исключением :)

Семантика null - это отсутствие значения. То есть нет его, вообще.

А в нашем случае, коллекция существует (хоть и пустая), а значит правильно вернуть именно коллекцию.

Заодно мы избавим клиента от лишних nullrefexception.

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

Тогда null - вполне валидное значение для ситуации "не заполнено".

Кстати, мои личные варианты, на первый опрос - 2, так как нужен компромисс, второй опрос - 4.

@backendsecret И присылать 412 Precondition Failed, если хедера нет!

@en_austin @backendsecret, а последняя версия как sensible default как же?

@_kix @backendsecret explicit is better than implicit?

@en_austin @backendsecret Вопрос философии и специфики конкретного АПИ, и наверное сферы, из которой это АПИ происходит.

История №3, без опроса. Как бы вы в restful api выразили операцию "Approve Document"?

@backendsecret, «вот этот конкретный запрос локализуемый, а вот тут у нас вообще только циферки в ответе, нечего переводить, хватит квери»

@backendsecret PUT /approvements/{documentId}, обратно DELETE. POST/PATCH отсутствует. Внутри у документа связь 1-to-1 с approvement.

@backendsecret в общепринятом да, но есть ещё академический первоисточник ics.uci.edu/~fielding/pubs… считаю его очень актуальным

@backendsecret попиарь плиз twitter.com/provorov/statu…

@backendsecret @en_austin Для мажорных версий — УРЛ. Для минорных — хедер

@backendsecret пустую коллекцию конечно, чтоб можно было единообразно обрабатывать ответы, типа response.map(...)

@backendsecret вот кстати, если кто докер юзает или хочет, но боится, полезное github.com/TomasTomecek/s…

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

Всё что стоит знать о сегодняшних дебатах в @backendsecret за API cyclowiki.org/wiki/%D0%92%D1…

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

@43oN @backendsecret @unel86 Тут youtu.be/p5NOI52MExU?t=… говорят, что когда-нибудь тайпед-экторы будут в акке экторами по умолчанию.

@strobegen @backendsecret @unel86 пойду попробую :3 А поход-то тот же остался? Ну в смысле, что ты снаружи обращаешься к методам

@43oN @backendsecret @unel86
не совсем как раньше, см. scastie.org/14672

Утро доброе, твиттер!

Сегодня соберем немного статистики. Начнем с простого.

@backendsecret сегодня магнитные бури и вспышке на солнце? все с самого утра срутся на тему статической и динамической типизации!

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

Немножко поинтереснее:

@redenergy0 @backendsecret т.е. большие системы на языке с динамической типизацией не написать либо сильно сложнее? По-моему уже срались.

Множественное наследование?

@backendsecret И даже Pure Vanilla C нет. Так себе опрос.

@backendsecret twitter.com/lexaguskov/sta…

Есть ли место JavaScript на бэкенде?

@backendsecret ИЗВЕРГ

@POS_troi JS не бэке не обязательно Node. Я компилил шаблоны с помощью V8. Чем не применение JS на бэке? ;) @backendsecret

@dcromster Не я всё-же понимаю JS в бэке это работа в бэке, а твой вариант больше просто вспомогательная замутя для деплоя :) @backendsecret

@dcromster @POS_troi @backendsecret фантом еще есть, но все же, когда говорят про js на бэке, речь про ноду

@backendsecret серверный javascript - это как ЛГБТ, в принципе существует, но вообще не нужен

@POS_troi нифига не для деплоя. После V8 оно шло на фронт. @backendsecret

@en_austin @backendsecret Смотрите, НОДОФОБ!

@backendsecret ну, пока там есть всякие python, php, ruby - вполне себе есть место и для js)

@POS_troi @dcromster @backendsecret ты так говоришь, будто упрекаешь меня за ответ номер 1. Но я тоже ткнул во второй=)

@backendsecret nooooooooooooooo.com

Кричащие о том, как ужасен и не нужен Node.js, — латентные нодосексуалисты.

@backendsecret lua под nginx/openresty хорош. Сделал WAMP-роутер на его базе (bit.ly/1PUtdcm) и еще так: bit.ly/1PUtagQ

@backendsecret, как шаблонизатор/изоморфный рендер — почему нет.

@backendsecret pic.twitter.com/GV1WA7MsPF

Ок, поехали дальше. Есть ли в вашей компании Code of Conduct?

@webholt @backendsecret вы так говорите, как будто нодофобия это что-то плохое

@backendsecret «Не доеби ближнего своего»

@backendsecret Я, наверное, уже привык в JS, но мне кажется, что там типы сломаны не больше, чем в Пайтоне или Луа

@dcromster @backendsecret ну, это же нормальный вопрос, а не "сексистские шуточки"

Ок, тогда дальше. Как вы устроились на текущую работу?

@backendsecret для тех кто выбирает последний пункт pic.twitter.com/nmkA5Tb2RR

@devmru @backendsecret Выбирающие последний пункт просто кодили, не вылезая из кровати. Вот их и позвали.

А в каком сегменте вы работаете?

Под продуктами я понимаю коробочные решения, а под сервисами - SaaS.

...никто не палится, что он из диджитала... :)))

Как часто вы, хм, рефакторите?

И в догонку:

Прогоняете ли вы тесты перед мержом фичебранча в транк?

У вас нет тестов и...

@backendsecret Тесты? Какие тесты?

@backendsecret Что естественно, то не безобразно!

@backendsecret … денег

@backendsecret Очень хочется узнать, если можно :3

Вечер близко, сменим направление опросов.

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

@backendsecret Используете ли вы соглашение о стиле кода?

И раз уж такое дело:

А эстеты с Wii U есть?

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

Продолжим.

И например так

Стратегии 1

Стратегии 2

Тактика

@backendsecret ничего не попишешь.... но не мне жаловаться)

@unel86 @backendsecret js можно использовать на бэк и на фронт. Но типичныe js-программисты, как правило, нe умeют в бэк. Это проблeма

@VovanR @backendsecret то есть "объект плюс список равно инт" вас не смущает?

@en_austin @backendsecret уже сто раз проходили. Вот у @bolknote популярно расписано: bolknote.ru/2015/06/16/~43…

@VovanR @en_austin @backendsecret спасибо, добавил в избранное, чтобы объяснять людям, почему я никогда не стану JS-разработчиком!

@hatarist @VovanR @backendsecret а вот пример каста выражения "+[]" в тип "number" подтверждает то, почему JS можно приравнять к мазохизму!

@VovanR @backendsecret спасибо, хорошее разъяснение, но это не отменяет того, что язык ужасно спроектирован!

@backendsecret народ дeлаeт фрeймворк бeз дeлeния на бэк и фронт speakerdeck.com/bbatsov/volt-r…

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

@en_austin @backendsecret а зачем ее отсутствие?

На сегодня все, доброго вечера всем. Завтра поговорим о всем, что связано с базами данных.

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

"@anton_sunrise: @backendsecret lol, неужто я один играю EU4 и CK2?" Я играю, но статистика такая статистика.

@anton_sunrise @backendsecret ты не один )

@backendsecret twitter.com/devmru/status/…

@backendsecret вот простая шпаргалка twitter.com/nixcraft/statu…

Все-таки последний опрос (честно!) чтобы закончить тему.

Замечали ли вы, что хорошие разработчики чаще интересуются видеоиграми/настолками/фантастикой/etc?

@backendsecret Command & Conquer - one love!

@backendsecret нет времени играть, слишком много книг

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

twitter.com/strizhechenko/…

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

@backendsecret у меня, например, все метрики в графит попадают, а логи - в эластик. И есть алерты, визуальные и СМС (и почта, наверное).

@ponitozhekoni для эластика нужно делать нормальную аггрегацию данных, это не движок для логов, это search engine @backendsecret

@backendsecret пытаюсь на @InfluxDB посмотреть, но всё никак времени не хватает

@ponitozhekoni эластик на хайлоаде взорвется. точнее, ты из него не вытащишь данных @backendsecret

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

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

@ponitozhekoni рекламная сеть, показы за день, эластик не вытащил по памяти. (я их предупреждал) @backendsecret

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

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

@ponitozhekoni ну может быть. все, конечно от срезов данных нужных и объема зависит, наверное. но я бы не делал так. @backendsecret

@strangeqargo @backendsecret так поделись - как правильно?

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

@ponitozhekoni сырые gz-логи за нужный тебе период, подходящая бд-агреггация, сверху эластик. имхо. @backendsecret

@ponitozhekoni ну т.е. если тебя взломали или клиент ломится с воплем "этого не было" ты идешь в gz, стату и красоту по ELK @backendsecret

@ponitozhekoni сырые логи в хайлоаде в эластике имхо неправильно. @backendsecret

@ponitozhekoni @backendsecret statsd -> graphite -> grafana для метрик

@strangeqargo @backendsecret я понял. У нас цели немного разнятся. Я с помощью ELK сеть мониторю. И мне алерты сыпятся, если что-то не так

@ponitozhekoni ну т.е. появятся запросы с группировками или условиями, по которым он не влезет, он не silverbullet @backendsecret

@Nikitoz @backendsecret расскажи, плиз, зачем statsd в этой цепочке?

@ponitozhekoni тогда да, спасибо за идею кстати @backendsecret

@ponitozhekoni у нас на это заббиксы, но я в них не очень ) @backendsecret

@strangeqargo @backendsecret не, заббиксы не нужны

@strangeqargo @backendsecret сильвербуллета вообще в природе не существует. Потому я и задал свой вопрос

@backendsecret порнухой они интересуются в основном

@ponitozhekoni @strangeqargo @backendsecret это да, туда можно весь шлак сливать, но есть нюанс, оно с дикой силой заваливается иногда :)

@strangeqargo @backendsecret @ponitozhekoni эластик вообще говно, начнём с этого

@ivanenok @strangeqargo @backendsecret именно так я и делаю. А в шлаке порой бывает полезно покопаться

@ivanenok @strangeqargo @backendsecret а вот насчет "заваливается" - видимо я пока не дорос до таких масштабов. Нужны цифры? Озвучу

@SiliconBangalor @strangeqargo @backendsecret на этом и закончим. Предлагай своё решение

@SiliconBangalor @strangeqargo @backendsecret чуть выше написано "Поделитесь секретами". Видишь?

@SiliconBangalor @strangeqargo @backendsecret Что, кстати, предложишь вместо эластика?

@ponitozhekoni @strangeqargo @backendsecret у меня инхаус решение для этого, с разными хранилищами для оперативного мониторинга и анализа

@ponitozhekoni @strangeqargo @backendsecret но это серьезная инвестиция и не подходит всем

@backendsecret интересно, кто-нибудь на harbour.github.io работает?

@SiliconBangalor @strangeqargo @backendsecret у меня тоже есть инхаус-проект. Но что с ни будет, если я вдруг умру? Под машинупопаду, e.g.

@ponitozhekoni @strangeqargo @backendsecret вместо ничего не предложу, все говно, но вот это всё ещё актуально aphyr.com/posts/323-call…

@SiliconBangalor @strangeqargo @backendsecret у кого какие мысли? Давайте это обсудим

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

@ponitozhekoni @strangeqargo @backendsecret тут не актуально — тут ещё тысяча бойцов, которые винтовку подхватят.

@SiliconBangalor @ponitozhekoni @backendsecret бгг да, инхаус не в смысле домашний

@strangeqargo @SiliconBangalor @backendsecret а в каком смысле?

@ponitozhekoni @backendsecret чтобы снизить нагрузку на graphite

@Nikitoz @backendsecret а каким образом лишний демон снижает нагрузку на графит? пжлст

@ponitozhekoni @backendsecret кроме того легко будет заменить graphite на influx например(при необходимости). Без изменения кода приложения

@ponitozhekoni (если ты серьезно) in-house project - внутренняя корпоративная разработка @SiliconBangalor @backendsecret

@strangeqargo @SiliconBangalor @backendsecret ну да, именно так, внутренняя корпоративная

@Nikitoz @backendsecret расскажи, пожалуйста, про инфлюкс. подводные камни? что-то ещё? у меня руки до него не дошли

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

@SiliconBangalor @strangeqargo @backendsecret не, не подхватят, если доков нет

@ponitozhekoni (беззлобно) И НЕ В ТАКОМ ГОВНЕ РАЗБИРАЛИСЬ @SiliconBangalor @backendsecret

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

@strangeqargo @SiliconBangalor @backendsecret обнимемся

@ponitozhekoni @backendsecret аггрегирует метрики перед отправкой в graphite. Отсылает периодически, например раз в секунду(конфигурируемо)

@strangeqargo @SiliconBangalor @backendsecret нет, не на брэйнфаке. Почему ты спрашиваешь?

@Nikitoz @backendsecret спасибо. А можно числа какие-нибудь увидеть? Или графики

@ponitozhekoni после ебли с issue tracking и кодом обычно можно любой код понять. без IT плохо @SiliconBangalor @backendsecret

@Nikitoz @backendsecret Я считаю, что графит - это очень дорого по железу. Ищу варианты. Буду благодарен

@backendsecret WZ2100

@backendsecret хочется верить в это (ответил любитель фантастики)

В ленту @backendsecret habr.ru/p/276539/

@backendsecret спасибо!
Ждём дискуссию о СУБД!
Мы PostgreSQL используем =)

Вот вам два полярных тезиса.

РСУБД - bloatware, слишком медленное, тяжелое, плохомасштабируемое и избыточное для большинства задач.

РСУБД - более-менее стандартизированное, проверенное на всех задачах и универсальное решение, знакомое многим разработчикам "из коробки".

Давайте представим, что мы выбираем хранилище для НОВОГО проекта и подискутируем.

@backendsecret слишком мало вводных о проекте, чтобы можно было делать выводы. Где-то и MongoDB будет хороша, а где-то Oracle не хватит)

@backendsecret 1. стоимость самого хранилища

@backendsecret На файлах всё. Чо бы нет?

@backendsecret => проверенные временем opensource проекты. Остается большой вопрос к скорости работы ...

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

"@iloldhardly: @backendsecret Далее пишем 2-3 коннектора сразу к опенсорсным и популярным БД." Оверархитект же для типовой задачи.

Хотя мы в своем продукте умеем несколько субд и написали свой query-язык транслируемый в конкретный диалект SQL.

В чяте @backendsecret все вечно такие пиздатые архитекторы/проектировщики. А потом:
— Нахуя вы так делаете?
­— Нуу… Так вышло.

Мы проектировали в лучших традициях, как в чяте @backendsecret учили. А потом :: habrahabr.ru/post/276539/

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

@backendsecret ну и все вытекающие из хранения, считай, JSON документа как объекта

@backendsecret правда, иногда бывают страдания из-за отсутствия встроенных джойнов, но это решается через DBRef

Отлично, правильное ключевое слово - schemaless. Какие плюсы и минусы вы считаете важными?

Для меня самый важный плюс schemaless - простота расширения и обновления существующей базы.

И одновременно - это большой минус.

«Я ничего не делал, не устанавливал никакую монгу, оно само! Это не моё, мне подбросили!» :: @backendsecret

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

"@de_gis: @PZabolotniy @backendsecret мультимастер репликацию решали? Решили? Как?" Неа, не сталкивался :(

@backendsecret Берем Postgresql и когда нужно используем jsonb.

Не зря сейчас популярен code-first подход.

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

Ок, вот вам немного "классики" - нужны или нет хранимые процедуры?

@backendsecret нужны. Чтобы жизнь медом не казалась:)

@en_austin @backendsecret бля, бинго! в третью нормальную форму базу запихать и ебануть её в монгу ещё и профиль на write чисто запилить!

Подпишусь-ка я на @retran нынешнего @backendsecret.
Нравится мне его тонкость :D pic.twitter.com/0GIsqUIA9k

ИМХО, хранимые процедуры имеют право на существование, НО как механизм оптимизации отдельных боттлнеков.

Итак, я знаю три варианта хранения схемы данных.

Первый - database first, схема уже в БД или в каких-то, часто вручную собираемых и обновляемых, DDL-скриптах.

Второй - schema-first, когда схема исходно формируется, например, в виде xml-ки (DTD, XSD, etc) и из нее уже генерируется код и скрипты.

Третий - code-first (model-first), когда схема задана классами с метаданными в коде и уже из них, часто рефлекшном в райнтайме...

...генерируется/обновляется база.

В случае со schema-less базами мы спокойно формируем схему в коде и не особо паримся обновлениями базы.

А вот в случае SQL-баз возникает вопрос - как правильно синхронизировать схему между кодом и непосредственно БД?

@backendsecret в девелопменте со схемалесс, конечно, проще

@ivanenok @backendsecret @en_austin погоди, так монгу же придумали троешники, неспособные в 3НФ базу свести, чтобы без всего этого :)

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

@backendsecret это должна делать процедура выкладки нового релиза!

@backendsecret при сложном шардировании слой доступа к данным можно на хранимках построить - pl/proxy например. Конечно bad practices это.

@backendsecret особенно они ценны своей переносимостью!

Мы например в инсталлере продукта сравниваем базу со схемой новой версии и на лету генерим апдейт-скрипт.

Сервисам проще - они могут например генерить скрипты в девелопмент-тайм, хранить их под версионником и накатывать при деплое.

Пацаны, добавьте знаний, а?

github.com/mr-mig/going-t…

@backendsecret
@jsunderhood

В ленту @jsunderhood и @backendsecret ;) twitter.com/kalduzov/statu…

Добрый день, твиттер!

@prosto_go @backendsecret мы сравнивали не схему базы, а версию (хранили в таблице), и вели апгрейд-скрипты по версиям.

@backendsecret начнёт-ли дымиться php-разработчик, если его перекрестить?

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

Всем спасибо за приятную неделю!

Подписывайтесь на @retran, facebook.com/andrewvasilyev и ru.linkedin.com/in/andrew-vasi…