Выпуск выходит при поддержке курсов Ruby on Rails “Паровоз Феликс Дзержинский”. “Курсы ФД — стань локомотивом на рельсы зарабатывания бабла!” Итак, в студию пишет Артём: Периодически вы упоминаете, что используете в работе Rails и считаете его отличным фреймворком для веб-разработки. С вашей точки зрения, оправданно ли сейчас начинать изучение Ruby/Rails или же это просто хорошая платформа для состоявшихся профессионалов, которым не составляет большого труда сменить стек технологий в угоду конкретному клиенту/проекту?

Суд. 2019 начался довольно позитивно — подошла к логическому завершению одна из пренеприятнейших историй моей жизни — неудачная покупка квартиры. Long story short, в 2013 году я купил квартиру, в конце 2013 я узнал что купил я её у мошенников и объявился законный владелец, с 2014 по 2018 шли многочисленные судебные тяжбы, которые закончились моим полным поражением, в феврале 2019 мы забрали из этой квартиры абсолютно всё, что можно было забрать (двери, розетки, радиаторы), съехали, и наконец-то закрыли мерзкую страницу.

Начало Вот уже второй месяц для ежедневной работы я использую Linux. Как человек, который до последнего жрал кактус тима кука, но сумевший соскочить, я делюсь с опытом переезда и ободряю сделать вас то же. С 2007 по 2015 я работал на винде. На работе у меня вначале был десктоп с Windows NT 2003(?) Кажется, точно не помню, потом переехал на ноутбук Thinkpad. NT 2003 обновили до Win 7. Работал я в то время с Java поэтому особых проблем не испытывал.

В любом деле которое требует постоянства для меня самое сложное — это начать. Но как только удалось превозмочь лень и раскрутить маховик, то дальнейшее поддержание нужной скорости вращения тратится уже не так много сил — помогает инерция. Но как только даешь слабину и пропускаешь несколько дней, не поддерживая нужное количество оборотов, то назад вернуться уже очень трудно. Месяц назад ездил к родственникам в другой город. Поездка заняла 4 дня и эти 4 дня я не играл на гитаре, не писал в бложик и не занимался спортом.

В середине октября я начал трекать всё рабочее время по каждому из проектов. Во-первых, мне самому вдруг стала интересна доходность по каждому из, во-вторых, хотелось понять сколько я работаю. Стандартные репорты из resque time просто говорят что “вот столько-то времени ты просидел в intellij, а вот столько – играл в контрстрайк”. Вроде и полезно, да не очень. Ну и третья, главная причина: с конца лета я взялся за несколько проектов, где платят за жопочасы, а не за результат, и нужен был удобный инструмент затрекать время, собрать потом все в кучу и отправить инвойс (с разбивкой по задачам).

Пару недель назад встречался с человеком — основателем конторы AnimalID. Они делают чипы для чипирования животных и держат соответствующую базу данных, работают в США и Украине. Во Львове они порешали проблемы с бездомными животными на корню, а в Киеве не порешают (потому что тут бюджеты на это огого какие пилятся, хватит стрерилизовать всех собак в Украине, не то что в Шевченковском районе). Но это лирика. У нас разговор был по поводу интеграции в проект который сейчас бодро пилится силами двух волонтеров.

Скорость сборки, как и интерактивность — еще одна, к моему прискорбию, недооцененная характеристика платформ, сред, языков. Мозги так устроены, что дай им малейший шанс отлынивать от работы — моментально этим воспользуются. Все знают анекдот про “у меня код компилируется”? Вот то-то же. Сборка, компиляция, редеплой, называйте как хотите — всё это убивает эффективность разработчика, снижает каденс (загуглите что это такое), притупляет мысль. На простейшие вещи уходит куча времени. В частности именно поэтому я не люблю мобильную разработку — пока дождешься сборки, пока она доедет на девайс, пока перезапустится приложение — пройдет вечность, а мозг в это время уже переключился на просмотр котиков и SJW-срачей в твиторе, все, фокус потерян, поток теперь не мощная горная река сметающая когнитивной силой всё на своём пути, а жалкий ручеёк, медленно пересыхающий с каждым просмотренным постом в соцмедиа.

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

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

В среде разработчиков часто принято критиковать PHP. Недавно, на конференции Devoxx, один из топовых спикеров вставил в свой доклад неуклюжие стереотипные шутки про PHP. Мне эти шутки не понравились, и я даже задумался о том, что такого рода поведение, это что-то вроде явного ущемления групп других людей и за такое надо выдавать волчий билет, но пока что не пришел к решению где должна проходить граница между шуткой и оскорблением. Однако пост не об этом.

Всем известен аргумент в спорах “сперва добейся”. Звучит это так “вот ты сперва (сделай что-нибудь) … а потом критикуй”. В контр-аргументы чаще всего приводят сравнение о том что необязательно быть профессионалом чтобы оценить конкретный продукт. Например, не нужно быть шеф-поваром, чтобы оценить вкус блюда. Или, не нужно быть гонщиком, чтобы оценить комфортность автомобиля. Не нужно быть музыкантом, чтобы оценить музыку. И так далее, ряд можете продолжить сами. Спорящие, однако очень часто подменяют понятия.

В продолжение темы об интересной и неинтересной работе. Я люблю выдавать результат. Длинные задачи, бесконечные проекты и доработки меня напрягают. Мне нравится сделать что-то, довести его до минимально рабочего состояния, запустить и пойти дальше. Если быстро не получается выдать что-то или выполнить минимальные требования к качеству, то интерес к задаче быстро пропадает и заниматься ею нет никакого желания. Что это могут быть за задачи такие нехорошие? Для меня самое первое – обработка данных.

Для тех, кто не знает, “вендор-лок” — это такая тема, когда вы подвязываетесь (в чем угодно) закрытую технологию какого-нибудь производителя, делаете на его платформе какое-то решение, а дальше не можете с него слезть. Самый распространённый пример — использование, например, базы данных Oracle или облака AWS. Вначале может быть все хорошо и радужно, но чем дальше в лес тем толще партизаны, и вот уже весь ваш бизнес завязан на кучу технологических решений, которые в любой момент по желанию вендора могут изменить свое поведение или ценовую политику.

На всех проектах, в которых я участвую, или которые я делаю сам, я всегда вижу кучу проблем. Более того, я даже знаю как их все можно исправить! Вот один пример: Один из проектов, который живет в активном продакшене уже более двух лет, в основе своей имеет некое API, которое принимает на вход данные от партнёров. Дальше мы эти данные вращаем и асинхронно отдаем результат. И вот, есть проблема, что иногда сервера могут быть недоступными.

Любимая тема при старте проекта — “какой системой будем пользоваться для управления?”. Кажется что вот сейчас выберем правильную и хорошую систему и проект сделается сам по себе. На моей первой работе (в 2007) была самописная штука сделанная на базе платформы, которую компания и разрабатывала/продавала (сама платформа — это ERP конструктор для телекомов, тоже очень навороченная). Для заказчиков продавались модуля для работы с сетями, инвентарём и труднопереводимым словом resource/service provisioning, а для внутренних нужд пилились свои модули.

В любой работе есть 20% интересной и сложной части и 80% рутины и полировки. Вначале ты довольно долго подступаешься к задаче, превозмогаешь, а дальше раз—основная проблема решается и остается только “задеплоить код”. Вторая фаза естественно будет занимать гораздо больше времени нежели первая. Basecamp визуализируют это в виде так называемых Hill Charts. Вначале ты долго ползешь на гору, не знаешь, что будет дальше, кое-как добираешься до вершины, понимаешь, что дальше лезть уже некуда и надо спускаться.