Если вы уже зарегистрированы на melp.pro (т.е. являетесь бета-тестером), ссылку на закрытый чат найдете у себя в профиле.

Запустили отдельный канал по развитию Melp.pro:

https://t.me/melpdaily

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

Не допускайте попадания в ямы

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

К примеру, этот канал молчал почти месяц. При этом в черновиках у меня лежит порядка 30-и тем для постов. И по полчаса в день на них с недавних пор я снова могу уделять. Но психологически вернуться к каналу тяжело.

Так же и в работе. Стоит пару недель не заниматься одним из проектов — потом будет тяжело и некомфортно к нему возвращаться. Так же и в спорте. Чем дольше пропускаешь тренировки — тем сложнее их потом возобновить.

Решение? Делать понемногу каждый день

Не позволять себе «отвыкнуть» от дела, заниматься им хотя бы по 5-10 минут, но каждый день. Для этого:

1. Длительные задачи по делу разбивать на короткие;
2. Вести список задач явно, не надеяться на надежность собственной памяти;
3. Если вчера не уделили время какому-то делу — сегодня выполняете его в первую очередь.

———————————
А сталкивались ли вы с подобной проблемой? Как решаете? Поделитесь мыслями в чате.

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

Как и с обычными языками (рус англ нем яп) — с каждым новым изученным языком следующие схватываются проще.

Если опустить с десяток нишевых языков, я программирование осваивал примерно в такой последовательности: Basic, Pascal, Delphi, C++, Java, PHP, Ruby, CoffeeScript, ES6. Примерно на этапе Basic я усвоил принципы императивных языков, и все последующие воспринимал, как «то же самое, только с чуть другим синтаксисом и возможностями».

Сложны были только отличия. В C++ это было ООП с его паттернами, в JavaScript это было прокидывание функций как аргументов в другие функции. В остальном все примерно одинаково и сложностей не вызывает.

Как следствие из этого — не помню наизусть тонкости конкретного языка. Чем там отличаются protected от private в руби, как хранятся типы данных в памяти, есть ли в языке указатели. Типичное техническое собеседование я 100% завалил бы. Но в ежедневной работе помнить такие вещи не требуется. Нужно будет для выполнения задачи — пара минут в гугле и знания освежил.

На что тогда уходит время при работе?

90% времени у меня уходит на обработку напильником тех технологий, которые связаны вместе в проекте. К примеру:

1. «Пользователя разлогинивает каждый раз при закрытии браузера» — поправить время жизни куков и сессии в рельсах.
2. «Пользователя кидает с закрытой страницы на страницу входа, а хотим на страницу регистрации» — залезть в сорцы гема Devise и поменять это там, конфигом, наследованием или манкипатчем.
3. «Слайдер на сайте плохо прокручивается жестами, без инерции» — изучить доки и сорцы текущего слайдера, поправить конфигами или своим кодом, если можно; если нет — найти другой слайдер, который отвечает этому требованию и всем тем, которым отвечал текущий слайдер, и впилить в проект его.

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

​​Вышло видео доклада Кирилла Мокевнина «Ментальное программирование 2.0»

Я не устаю советовать новичкам и не только материалы Кирилла. Это один из немногих известных мне программистов-современников, кто видит суть вещей и открыто рассказывает об этом. На канале я делился его Иерархией контроллеров.

В 2013-м Кирилл уже выступал с «Ментальным программированием», теперь выпустил вторую часть. Рекомендую посмотреть обе, так как они не замещают, а дополняют друг друга.

Часть №1 (2013)
Часть №2 (2017)

P.S. Для просмотра второй нужна регистрация, не поленитесь — она бесплатна, и доклад того стоит.

P.P.S. В докладе Кирилл упоминает другие свои выступления и внешние ресурсы, вот список:

Книга Optimization Guide на русском.

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

Почему сложно программировать UI и как выглядит идеальный фреймворк — грамотно и последовательно о том, в чем проблема современных фронтенд-фреймворков, и почему Реакт не просто популярная библиотека, а концептуально правильный продукт.

​​Как вы поддерживаете высокий темп в работе?

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

В итоге я заметил, что максимальную отдачу получаю в те часы и дни, когда нахожусь в «особом состоянии». Как Бредли Купер под НЗТ, только без НЗТ. Собран, сосредоточен, с ясной картиной и планами в голове. И я подумал — чтобы показатели были высоки, необязательно вести их. Достаточно поддерживать себя в этом «особом состоянии» каждый день.

Следить за этим помогла таблица. Строка — день. В каждой строке — 24 ячейки-часа. Каждый час оценивается от 1 до 5, где:

1 — Деградирующий овощ
5 — Бредли Купер

Круто, когда в строке все пятерки. Но если ниже — думаем почему, находим причину, делаем выводы, исправляемся.

На скрине видно последние три мои недели. Каждая красно-желтая яма — своя проблема, выбивающая меня из ритма, но решаемая. Последняя неделя — тому доказательство.

Воспользуйтесь таблицей сами:

Google Таблица «Темп»

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

⚠️ Гем factory_girl переименовали в factory_bot.

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

Извиняюсь за внезапное появление коубов на канале. Промахнулся и запостил их в канал вместо диалога с самим собой.

Зачем вообще постил? Это лайфхак — так можно легко выдрать видео с коуба, чтобы использовать в своих целях. Конкретно те коубы ушли в обновленные страницы ошибок в Мелпе: 422 и 500.

Вообще с видео последовательность такая:

1. Добываем видос;
2. Конвертируем в .webm и .mp4 (с кодеком H.264/MPEG4-AVC — это важно);
3. Вставляем в верстку:

<video
  width='100%'
  height='auto'
  autoplay='autoplay'
  loop='loop'
  preload='auto'
>
  <source
    src='/500.mp4'
  />
  <source
    src='/500.webm'
    type='video/webm'
  />
</video>

И всё, видосы крутятся, лавэха мутится.

И еще немного про сами страницы ошибок

На сервере я использую связку Nginx + Puma:

Nginx — прокси-сервер, быстро отдает статику (стили, скрипты, картинки, шрифты), ssl-сертификаты, отрабатывает редиректы.
Puma — сервер Ruby on Rails, отрабатывает все запросы к БД, API, рендерит страницы.

Логика по ошибкам такая:

1. Если упадет Nginx — сайт не будет доступен совсем.

2. Если упадет только Puma — Nginx сможет показать простенькие страницы ошибок. В Мелпе это 404, 422 и 500. Минимум верстки, статичные ссылки и почта для связи

3. Если ошибка случится где-то внутри Rails — тогда и страницу с ошибкой мы сможем показать, используя все возможности рельс. Взгляните на рельсовую 404. Похожа на статичную 404, но с полноценной шапкой, подвалом и ссылками. Учитывает, залогинен пользователь, или нет.

Отличный видос на вечер для бэкендеров — Антон Давыдов рассказывает о грамотной архитектуре в веб-приложениях, функциональных объектах, Dry, Hanami, касается DI и DDD.

https://www.youtube.com/watch?v=pzrZru-oZeY

Я уже посмотрел, буду и дальше внедрять абстракции в свои рельсовые проекты, изолируя части приложений друг от друга. А там глядишь — и можно будет плавно отпочковывать части проектов в микросервисы и масштабировать их. Для Мелпа и будущих проектов — не помешает.

И по поводу «видосов на вечер» — откладывайте к просмотру обучающие видео, скринкасты, лекции. В ютюбе это «Добавить в список — Посмотреть позже».

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

Тоша Исаев толково об этом донес:

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

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

Теперь вы умеете предугадывать судьбу человека лишь по экрану его мобильного телефона.

Новый набор — Женя обновил курс и лендинг (который ему оперативно подогнал его же ученик), гляньте:

http://erodionov.ru/frontend/

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

А нас теперь — 200 🌋🔥 И это круто, ребят. Я рад, что нам удалось собраться здесь, и вместе впитывать важное о вебе и разработке.

Как думаете, когда отметим третий юбилей?

​​А вы пользуетесь gui git-клиентами?

Гит в терминале или в gui-клиенте — тема холиварная. Мне удобнее gui, и вот почему:

1. Удобно коммитить изменения порционно

Была у вас ситуация — нужно закоммитить файл, а в нем есть как целевые для коммита изменения, так и нецелевые? Последние было бы здорово закоммитить потом, в следующем коммите. Но как это сделать в терминале?

Уверен, что можно, но в gui это явно быстрее. Смотрите скрин ниже. Выбираем файл, видим изменения, выделяем нужные просто как текст, жмем S (Stage changes). Всё. Нужные строчки закоммитятся, другие останутся нетронутыми.

2. Нет семантических разрывов

Смотрели ведь уже «Ментальное программирование»? В первой части Кирилл даже приводит Git в пример. Куча команд в гите семантически не связана с действиями, которые мы хотим совершить.

Например. Хотим внедрить в проект новую фичу («new feature») или написать багфикс («new bugfix»). А пишем что? git branch feature_name. branch? wtf?

Ладно, окей, в гите есть «ветки» и мы их используем. Хотим перейти с одной ветки на другую («change branch»). Что пишем? git checkout branch_name. checkout? WTF?

Ладно, ясно, чекаут меняет ветку в гите, запомнили. Хотим откатить файл к версии в гите («reset file», «restore file»). Что пишем? git checkout file_name. checkout??? Какого хрена, он же меняет ветку!

И так далее. Какие-то разрывы фиксятся использованием утилит вида git flow. Какие-то — использованием графического интерфейса, наглядно показывающего, в каком состоянии находится код и какие возможности с ним можно производить.

————————
А вы пользуетесь gui-клиентами? И если да — какими? Пишите в чате. Мой текущий клиент — git-cola, в прошлом использовал лагающий из-за Java SmartGit, сейчас посматриваю на Github-овский клиент.

@gambala кстати, для порционального добавления есть флаг -p, таботает как с git add, так и с git commit

И да, ребят-дизлайкеры, у нас в проекте действительно всего два гендера, не обижайтесь ¯\_(ツ)_/¯

Прерву молчание на канале репостом на отвлеченную тему.

Обожаю терменвокс, на котором, несмотря на ограниченную область применения, можно выдавать крутые синтетические мелодии. Например, https://www.youtube.com/watch?v=_3EPtUPcs8s

А в репосте — гайд. Что за инструмент, как действует, как на нем играть.

Краткий гайд по терменвоксу
https://youtu.be/MJACNHHuGp0