Всем привет! С вами @servzin, и я буду развлекать вас эту неделю. Поговорим об open source, Ruby, читаемости, тестировании и многом другом.

И начнём, пожалуй, с новостей-нововведений Github — зелёная кнопка мёрджа приобрела новую функциональность github.com/blog/2141-squa…

А как вы мёрджите свои pull-request'ы?

С пулл-реквестами часто появляется дилемма: с одной стороны, коммиты должны быть атомарными. Один коммит — один маленький неделимый кусочек.

С другой стороны, добавление новой фичи порой очень сложно уместить в эти рамки. Порой получаются монстры с diff'ом на +10k -12k (например).

На моём текущем проекте принят формат "1 feature — 1 PR". Получаем колбасу из rebase-force push-merge. На вид коммит чище, но сам он большой

Но это всё лирическое вступление. Все знают, что хранить пароли в репозиториях плохо, но многие при этом всё равно продолжают их коммитить.

Можно и так: «Давайте создадим другой репозиторий, в котором у нас будут жить рецепты, которые будут прописывать пароли на основе шаблонов!»

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

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

Just as I expected, reactions to GitHub comments mostly annoy the maintainers by adding uncalled for peer pressure.

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

@backendsecret Её просто сложно внятно оценить. Много кода. Но некоторые используют это как аргумент к продвижению.

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

@backendsecret пока что в опросе уверенно лидирует «зелёная кнопка». А вас никогда не напрягали сообщения "Merge PR12 from weird_branch"? :)

На правах рекламы: #ВАКАНСИЯ DataArt нужен Python-разработчик для работы над сервисом будущего. goo.gl/BSpt4B /cc @DataArt_Dev

Не, зелёная кнопка — это удобно, не спорю :) Но если не иметь возможности изменить commit message, это ж ад, не? :) pic.twitter.com/JsnpnJuUcF

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

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

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

Как бы поступили вы?

У нас есть RoR-приложение, которое в большей степени выполняет различные background задачи в большом количестве, некоторые из них долгие.

Проблемной оказалась задача, которая выбирает порядка >100K из >3M записей из базы, и из полученных данных генерирует много background job.

Проблема заключалась в том, что она работала суммарно около 2,5 часов и в конце-концов убивалась monit'ом за превышением памяти.

Первым нашим шагом было уменьшить количество запросов к базе. Получился пока ещё красивый код на ActiveRecord, работающий чуть шустрее.

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

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

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

Итог — 7 минут вместо 2,5 часов, отсутствие падения, но к сожалению не самый легко воспринимаемый код. Но оно стоило того в этом случае.

Всем доброе утро или добрый день! Сегодня я хотел немного поговорить о тестировании веб-приложений: подходах, особенностях и необходимости.

Для начала короткий утренний блиц-опрос: тестируете ли вы, и если да, то что?

Кстати, всем хорошего дня и успешных взлётов! 12 апреля на дворе.

"Javascript dev is overwhelming and confusing because everyone is over-engineering their apps by default", planningforaliens.com/blog/2016/04/1…

А какую конечную цель вы преследуете при написании тестов? Стабильность приложения, документация, чтобы CI не фейлился или что-нибудь ещё?

По моим личным наблюдениям, некоторые были бы не против заюзать что-то типа такого :) github.com/auchenberg/vol…

В RoR-приложении, над которым сейчас работаем, мы делаем моки с помощью vcr github.com/vcr/vcr Он сохраняет ответ в исходном виде.

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

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

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

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

Как много времени вы тратите на написание тестов?

@backendsecret выбираю 4й пункт "какие тесты? O.O"

Как-то мой коллега-тестировщик написал тест, закоммитил. Через пару часов его тест удалил разработчик, т.к. не умел запускать #gorydetails

Как правило, подобные вещи всегда случаются в пятницу. Либо при минорном апдейте версии какой-нибудь зависимости. pic.twitter.com/Pf2v01jNiE

Минутка рекламы: #ВАКАНСИЯ Python-разработчик для создания сервисов популярной компьютерной игры goo.gl/x6Qrbt /cc @DataArt_Dev

Либо 66% опрошенных пишут на языках со статической типизацией, либо они колдуны :) А как у вас с документацией проекта?

.@dcromster учту, спасибо. Я в плане общения с твиттером застрял где-то в 2012 году, некоторые вещи для меня стали в диковину.

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

.@chikiro_twi на самом деле не всё так страшно :) Устное техническое не больше часа, обычно, задачка — как у всех, думаю.

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

Бэкенд и бизнес-логика пока что преобладают. Либо это специфика подписчиков «Разработчика бэкенда», либо… :) pic.twitter.com/H6W5r9yQsK

Недавно попадалась на глаза старая статья, в которой говорилось, что Amazon деплоился каждые 11.6 минут в 2011 году youtu.be/dxk8b9rSKOo?t=…

.@dsemenov @servzin сроки сжаты, всё надо сделать к вчера :) но возможны дополнительные инвестиции на улучшение кода на, скажем, 1 неделю.

Всем доброе утро! Сегодня среда, и по расписанию у нас разговоры о затратах памяти в #Ruby приложениях, в частности, в #Rails.

И традиционный утренний блиц: а кто из фолловеров хотя бы слегка знаком с Ruby?

.@freiksenet_ru завтра планировал поговорить о бесперебойной работе нагруженных систем. Может быть, у вас есть ещё какие-то пожелания?

.@freiksenet_ru можно будет поменять приоритеты, впереди ещё 3 дня, не считая сегодняшнего :)

.@freiksenet_ru Спасибо за фидбэк! Я в любом случае постараюсь как можно больше разнообразить :)

.@dronovmm многие вообще ставят тождество между Ruby и Rails, либо для веба игнорируют такие фреймворки как Sinatra, Lotus/Hanami и прочее.

.@lisovskyvlad Я сам занимаюсь full-stack разработкой. Первая половина недели получилась с уклоном в Ruby, дальше будем говорить о другом.

.@dronovmm Последнее время Rails сам по себе почти не использую. В качестве примеров — тот же Homebrew для OS X.

.@dronovmm Кстати, какими-то гемами пользуются наши iOS'ники при создании билдов, надо будет у них уточнить.

Не могу удержаться. Админы делятся на тех, кто ещё не делает бэкапы, и тех, кто уже делает serverfault.com/questions/7693… #EpicFail

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

"less Gemfile | grep -vx ^$ | wc -l" у меня выдаёт всего 80, например. Но это только те явные зависимости, которые мы сами подключили.

Большинство gem'ов чаще всего имеют свои зависимости. "less Gemfile.lock | grep -vx ^$ | wc -l" возвращает уже 529 строк.

Ещё у многих свежа в пямяти история с npm и left-pad, не так ли? theregister.co.uk/2016/03/23/npm… 8-строчный код было подключался как зависимость.

Так, @ShapovalovTS. Получается такая каша из зависимостей, которые всё равно в конце-концов обращаются к стандартным рубишным либам.

А теперь главная проблема: при запуске скрипта/приложения в память подгружаются все зависимости, даже если в этом скрипте их не используют.

То есть если у вас есть Sidekiq процесс и он ничего не делает, он всё равно сжирает кучу памяти ни на что, и это не утечка в самом Sidekiq.

Совет разработчикам гемов: если работаете с, e.g., HTTP протоколом, используйте стандартный 'net/http', вы облегчите жизнь всему коммьюнити.

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

ember-rails, backbone-rails, … Много их! Можно просто подключить эти библиотеки как js.min, и они не будут больше аффектить бэкенд-процессы.

.@cluevick ну мозги никто не отменял, никто не спорит :) Зачем это делалось из-под рута — большой вопрос, тем более на всём подряд.

@backendsecret Или посидите годик-другой в конторе, занимающейся embedded.

Кстати о бэкапах. А кто где бэкапится? У меня для этого TimeMachine на рабочей машине + Dropbox/Google Drive + раньше был Backblaze.

#ВАКАНСИЯ Специалист по Python для работы с сервисами онлайн-супермаркета. goo.gl/qujk14 /cc @DataArt_Dev

Сюжеты из жизни IT в классической живописи. classicprogrammerpaintings.tumblr.com В ленту @backendsecret @jsunderhood @rubyunderhood Спасибо @abeshkov

Доброе утро! А какие СУБД вы используете в разработке бэкенда (если используете)?

Ага, почти все используют. А используете ли вы части бизнес-логики на уровне БД, хранимые процедуры, триггеры?

Предположим, что вы пару лет назад спроектировали БД, и вас всё устраивало. База разрослась, и в один момент пришлось добавить ещё столбец.

А если у вас ещё и MySQL, то вам не повезёт даже с введением индексов, так как эта операция вешает lock на всю индексируемую таблицу.

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

В случае упомянутого #mysql'а можно посмотреть на Percona Toolkit, позволяющий проводить online миграции percona.com/doc/percona-to…

Принцип работы вкратце: создаётся копия мигрируемой таблицы, на ней проводится миграция, потом происходит переименование временной таблицы.

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

@backendsecret но триггер просуществует ровно до успешного окончания миграции

@backendsecret а в случае PostgreSQL просто не паришься и добавляешь ;)

И ещё минутка рекламы. #ВАКАНСИЯ DataArt нужен Python-разработчик для работы над сервисом будущего. goo.gl/BSpt4B /сс @DataArt_Dev

Hitler uses Docker (на основе Downfall'а, разумеется) youtube.com/watch?v=PivpCK…

Кстати, тут Vim 8 подвезли github.com/vim/vim/blob/m… #vim

.@theaspect It depends. Процент не знаю, но это не настолько редкая задача в Enterprise разработке. В моём проекте как раз такая ситуация.

Всем привет! Сегодня мы будем говорить об измерении производительности сервисов. Вы как-нибудь это измеряете?

@backendsecret @strizhechenko twitter.com/binitamshah/st…

А пока идёт опрос, #ВАКАНСИЯ Python-разработчик для создания сервисов популярной компьютерной игры goo.gl/x6Qrbt /cc @DataArt_Dev

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

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

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

В своём посте @squadette предлагает выбирать значение, имеющее номер, составляющий 99% от общего числа запросов (на т.н. 99-квантили).

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

Его дальнейшие размышления на эту тему можно найти по этой ссылке, дабы не пытаться вместить простыню в 160 символов goo.gl/yuIWnG

С другой стороны, если при замере времени/памяти/cpu/чего-либо ещё 99% значений они скачут туда-сюда, вероятно you are screwed :)

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

Как выбрать критерии оценки? Сначала подумайте о вашем сервисе с точки зрения пользователя: какой user experience вы ожидаете от системы?

Затем подумайте о том, насколько ваш сервис этому удовлетворяет и в чём он отстаёт от ожиданий как пользователя, так и ваших затрат.

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

.@operatino @jsunderhood здесь всё достаточно субъективно. У кого-то здесь, например, частично переносится нелюбовь к js в принципе.

.@operatino @jsunderhood кому-то не нравится node'овская экосистема, кто-то просто не рассматривает всерьёз ноду как серьёзный инструмент.

Кстати, #Воронеж, приходите завтра на конференцию #ITNonStop, выступают очень крутые докладчики.
goo.gl/Z9jfHY

НеВоронеж, завтрашнюю конференцию будут транслировать, смотрите в прямом эфире: youtube.com/watch?v=woallv… :)

@backendsecret В этой лекции youtube.com/watch?v=lJ8ydI… хорошо объясняют почему плохо брать 99%

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

Чтобы не сойти с ума от большого количества задач и проектов и не ощущать себя потерянным в них, я использую #GTD gettingthingsdone.com

Для работы с быстрыми текстовыми заметками я предпочитаю nvALT. У него есть кроссплатформенный аналог nvatom atom.io/packages/nvatom

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

На текущее место работы в @DataArt_Dev я устроился через Twitter. Стоял в наряде на сборах, увидел вакансию, попросил их подождать 2 недели.

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

Старайтесь читать документацию на английском языке (чаще всего — язык оригинала). Локализация очень часто отстаёт.

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

Кстати, #VisualStudio выпустили свой кроссплатформенный ответ ST и Atom'у code.visualstudio.com. Анонс в блоге goo.gl/Crqv9b

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

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

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

. @PaGrom Вот у меня сложилось то же впечатление, при этом, не нашёл в посте ни одного упоминания Atom.

Тем временем, #ВАКАНСИЯ Специалист по Python для работы с сервисами онлайн-супермаркета. goo.gl/qujk14 /cc @DataArt_Dev

. @Arhelmus бывают и не такие ;) github.com/majioa/rdoba, например.

git log — это не changelog. Changelog должен быть ориентирован на людей keepachangelog.com

. @sorrowunderhood я, наверное, соглашусь с автором предыдущей ссылки о том, что git log отвечает на вопрос «как», а changelog — «что».

. @sorrowunderhood но всё должно быть для людей, да.

@backendsecret "Людям" нужна кнопочка "Далее->Далее.....", им ChangeLog не нужен :)

Что ж, на этом, пожалуй, всё. Буду рад комментариям/замечаниям/ответам в личку. Have fun! С вами был @servzin. Удачи и до новых встреч!