servzin

11 апреля 2016, Worldwide

# Понедельник 29 твитов

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

9:42

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

9:47

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

9:48

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

10:10

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

10:11

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

10:14

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

10:17

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

10:18

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

10:20

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

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

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

10:41
@backendsecret Её просто сложно внятно оценить. Много кода. Но некоторые используют это как аргумент к продвижению.
11:18
@backendsecret Говорят - я блин столько труда в это вложил, я потеряю время на разбивку. Давай замечания потом устраню. Это рабочее...
11:18

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

11:29

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

11:31

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

13:07

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

15:21

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

15:21

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

15:21

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

15:22

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

18:43

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

18:45

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

18:46

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

18:48

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

18:49

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

18:51

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

18:52

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

18:53

# Вторник 24 твита

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

7:53

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

7:57

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

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

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

10:07

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

10:09

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

11:49

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

11:50

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

11:50

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

11:50

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

11:50

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

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

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

12:14

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

12:17

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

12:21

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

12:46

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

12:47

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

12:52

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

12:57

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

12:59

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

13:29

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

13:34
Sidekiq.js is happening here, this will be the next 6mo of my life and I'm super excited to learn a whole new lang!! github.com/mperham/sideki…

.@mperham анонсировал разработку Sidekiq для Node.js. Он планирует за 6 мес выучить JS и написать на нём Sidekiq.rb. twitter.com/mperham/status…

18:28

# Среда 26 твитов

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

7:40

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

7:43

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

7:45

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

7:49

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

7:50

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

7:52

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

8:05

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

8:07

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

8:09

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

8:12

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

12:06

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

12:12

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

12:13

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

12:14

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

12:16

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

12:18

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

12:20

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

12:21

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

12:23

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

12:24

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

12:25

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

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

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

13:14

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

13:39
If you're upgrading to Rails 5, upgrade to Ruby 2.3 too. Rails 5 uses Module.prepend, which leaks memory in Ruby 2.0-2.2.

О, свежачок-с от Rails dev команды. Ну, раз уж всё равно начали говорить за память… twitter.com/nateberkopec/s…

14:35

# Четверг 18 твитов

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

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

8:08

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

11:06

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

13:50

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

13:50

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

13:50

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

13:51

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

13:51

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

13:52
@backendsecret но триггер просуществует ровно до успешного окончания миграции
13:53
@backendsecret а в случае PostgreSQL просто не паришься и добавляешь ;)
13:53

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

14:10

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

15:31

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

15:44
@backendsecret А что думаешь насчёт github.com/martanne/vis?

Выглядит круто, я бы даже пощупал в свободное время, несмотря на то что сам работаю в Emacs. twitter.com/iamale_ru/stat…

15:49
@backendsecret А spacemacs пробовал?

Пробовал, но мне больше всё же нравится ванильный. Хотя, это тоже условно — starter-kit местами остался в конфиге. twitter.com/PaGrom/status/…

16:11

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

18:05

# Пятница 18 твитов

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

9:41

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

10:40

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

14:41

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

14:41

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

14:41

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

14:42

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

14:42

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

14:42

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

14:42

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

14:42

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

14:43

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

14:43

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

14:43

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

14:46

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

14:47

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

15:54

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

15:54

# Суббота 1 твит

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

# Воскресенье 20 твитов

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

7:25

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

7:27

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

7:29

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

7:32

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

7:34

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

7:39

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

7:40

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

7:42

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

7:45

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

7:46

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

7:47

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

7:48

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

7:49

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

7:51

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

8:38

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

8:47

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

9:07

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

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

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

18:33

github.com

goo.gl

other