Написал на Хабр статью про то, как я пытался стать «яндексоидом», но вовремя одумался: https://habr.com/ru/post/530228/

В 2010 году, когда я попробовал тёмную тему в PhpStorm, долго восхищался тому, насколько же это красиво. С тех пор я старался использовать тёмную тему везде, где это было возможно: в операционной системе, в текстовых и графических редакторах, на сайтах и в приложениях, в терминале и на смартфоне. Кроме визуальной эстетики, я был уверен в том, что это ещё и менее вредно для глаз, чем светлая тема.

В августе я приобрёл новый ноутбук с экраном ярче и сочнее, чем у прежнего ноутбука. На новом экране темные темы стали выглядеть ещё красивее. Примерно с октября я стал замечать, что у меня начали болеть глаза. Иногда привычные для меня 12 часов перед экраном приводили к рези и покраснению, которые не проходили несколько дней. Это стало напрягать. И вот неделю назад, в вечернее время я вновь почувствовал усталость глаз, я переключил тему в Visual Studio Code на светлую и мне сразу же стало легче смотреть на экран. Попереключав темы туда-сюда, я понял, что светлая тема ощутимо комфортнее, хотя эстетически менее приятна.

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

До сих пор не уверен в том, есть ли вообще разница для здоровья глаз. Чтобы дать себе ответ на этот вопрос, хорошо бы подковаться в офтальмологии. Но поскольку, всё знать невозможно, приходится принимать во внимание мнение других, например такое: https://habr.com/ru/company/funcorp/blog/506770/.

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

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

Я люблю Си, это был один из языков, на которых я учился программировать, и мой восторг от написания первых программ во-многом связан с Си. Когда я обратил внимание на Rust, меня затянуто так, что пришлось на неделю оставить работу, я испытал те же эмоции, что и от изучения Си в юности.

В Rust реализован интересный подход к управлению памятью: её не нужно выделять и освобождать самому, однако и сборщика мусора там тоже нет. Это делает написанные на Rust программы такими же производительными, как и на Си, а их разработку сравнимой по простоте с разработкой на Go. О том за, счёт чего это достигается, понятно и ярко рассказали авторы книги «Язык программирования Rust». Книга настолько хорошо написана, что подойдёт даже новичкам в программировании.

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

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

Дал комментарий «Комсомольской Правде» по поводу профессии веб-разработчика. Однако, моё мнение в статью включать не стали, хотя зря, потому что я дал важный ответ на вопрос «Как стать веб-разработчиком?»:

Нужно заинтересоваться вебом, разработкой и, в целом, IT. В мире информационных технологий изначально всё шло от интереса. До того, как IT-профессии стали популярными, всё делалось крайне увлечёнными людьми. Программисты становились программистами не из-за денег, а потому, что не могли жить без программирования.

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

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

Хочу дополнить свой комментарий и сделаю это в следующем посте позднее 👇

В продолжение предыдущего поста ☝️

Ни для кого не секрет, что в веб-разработку и другие IT-профессии манит немало людей, которых компьютеры волнуют просто как средство заработка. А IT-индустрия — это как завод (или офис), но где вместо условных гаечного ключа и гаек (или документов и принтера) есть клавиатура и средства разработки.

И правда, современный IT — это как завод, на котором сейчас очень, как говорится, «не хватает рук». Чтобы насытить рынок нужными специалистами, технологии стремятся к тому, чтобы создавать приложения можно было бы так же, как собирать корпусную мебель. И я говорю не про сложность труда, потому что трудиться всегда сложно, а про сам процесс: можно не заморачиваться, собирать мебель из готовых мебельных щитов чётко по инструкции.

В процессе сборки мебели в фоновом режиме можно думать о чём-нибудь отвлечённом. То есть, рутина не так сильно донимает. В процессе разработки обычного фронтенд-приложения на React, не смотря на то, что субъективно 90% задач — самая что ни на есть рутина, думать о чём-то постороннем «в фоне» не получится: пока ещё разработка требует мыслительной деятельности, а думать о двух вещах одновременно мы не умеем. Соответственно, в рабочее время нужно посвящать всю мозговую активность задаче. Часто даже музыка на фоне отвлекает.

Но что если разработка или сборка чего-либо перестали быть интересными? Чему психика будет сопротивляться сильнее?

а) Неинтересное занятие, во время которого можно подумать о чём-то более приятном и интересном;
б) Неинтересное занятие, во время которого можно думать только об этом неинтересном занятии.

Даже если work-life баланс прекрасно выстроен, долгие вечера проходят с семьёй и/или за любимым хобби, а в выходные у вас сплошные сноуборды и купание в море, вариант «а» всегда будет более комфортным для психики, чем вариант «б». Если вы не любите IT, вы всегда будете тяготеть к какому-то другому занятию, в котором будет больше времени для приятных мыслей. Отсутствие интереса к IT так же замедляет обучение и профессиональный рост, таким сотрудникам не достаётся интересных задач, где есть место исследованию и постижению чего-то нового, потому что они достаются тем, кто хочет погружаться в IT всё больше и больше. В поиске интересных задач может начаться частая смена работодателей/проектов. Но интересных задач всё меньше и меньше. И очень не хочется, чтобы заканчивались выходные и начинался понедельник. Потому что в понедельник придётся либо 8 часов заставлять себя думать о неинтересных вещах, либо прокрастинировать, уделяя работе пару часов в день, а потом ловить на себе не самые приятные взгляды коллег. Да, в IT рады и таким работникам, поскольку «не хватает рук». Но сами работники оказываются заложниками высокого спроса и, соответственно, высоких зарплат.

Это не столько выгорание, сколько ненавистная работа, которая может привести к выгоранию. Я знаю, что в IT много людей без интереса, но это плохо не для индустрии, а для них. Возможно самый простой выход — полюбить компьютеры, потому что это удивительный огромный мир, который одному человеку постигнуть уже не под силу.

Когда я только начал работать в Linux, в настройках переключения раскладки клавиатуры я увидел опцию «Переключать по Caps Lock». Для меня, как для пользователя Windows, это показалось необычным, и раз уж я решил перейти на Linux, то начал пробовать всё необычное. С той поры 10 лет я переключал раскладку нажатием Caps Lock, что гораздо проще, чем нажатие любого сочетания клавиш. Когда мне приходилось работать не за своим компьютером, где был настроен другой способ переключения раскладки, мне было ощутимо неудобно.

10 лет у меня оставалась ещё одна проблема: я часто начинал набирать текст не на том языке, на котором хотел. Для того, чтобы «предсказать» на каком языке сейчас будет набран текст, необходимо было смотреть на индикатор Caps Lock на клавиатуре (да, в Линуксе можно настроить, чтобы он светился, например, тогда, когда включена русская раскладка) или на соответствующий значок в интерфейсе окружения рабочего стола. Это делать лень и это отнимает время.

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

— Caps Lock — для переключения на английскую раскладку;
— Shift + Caps Lock — для переключения на русскую (в моём случае) раскладку.

Принцип в том, что больше не нужно смотреть на то, какая раскладка сейчас активна: если вам нужно печатать на русском, вы нажимаете Shift + Caps Lock, если нужно на английском — просто Caps Lock.

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

UPD1: в случае, если раксладок больше двух, это методика бесполезна.
UPD2: конечно, какое-то время уйдёт на привыкание, у меня оно заняло чуть больше месяца, но я не пожалел.

Чем мне нравятся новогодние выходные, так это отсутствием тонны всевозможной рабочей переписки. Даже когда я работал на фрилансе, где выходные и праздники не повод не писать по рабочим вопросам, в новогодние выходные меня никто не тревожил. Такой «новогодний» уровень свободы от кучи рабочих чатов и email'ов труднодостижим даже в период отпуска.

Единственное исключение — рекрутеры, занимающиеся хантингом через LinkedIn, они никогда не дремлют. Про LinkedIn ходит шутка, что это соцсеть, где девушки первыми пишут парням, а те их игнорят. У меня там в статусе стоит «НЕ ищу работу», но даже это не всех останавливает, прямо так и начинают сообщение: «видела, что вы не в поиске, но...». Ответив сегодня отказом на очередное предложение рассмотреть вакансию (да, стараюсь не игнорить), задумался: а зачем мне вообще нужен там аккаунт?

Лет 10 назад в русскоговорящем интернете среди людей, чья работа связана с IT и интернетом, стало модным быть зарегистрированным в этой соцсети. Потому что это была серьёзная площадка для «профессионалов». Но из-за слабой ориентированности на русскоговорящего пользователя там совершенно нечем было заняться, кроме как, добавлять друг друга в друзья. Непосредственно профессиональное общение шло в других местах. В этом плане преуспел Фейсбук, где стало уместно и нужно говорить о работе.

После того как Роскомнадзор «заблокировал» LinkedIn на территории РФ, пользоваться соцсетью стало ещё бессмысленнее: часть пользователей ушла и не вернулась. Смотрю сейчас ленту в LinkedIn и понимаю, что её невозможно читать: унылые мемы вперемешку с объявлениями о вакансиях и неинтересной корпоративной повесткой. В этом плане мне нравится Telegram: много качественных каналов с интересной, иногда просто уникальной информацией, читаешь только то, что хочешь, в нужном объёме и в хронологическом порядке.

Начал думать о том, чтобы закрыть аккаунт в LinkedIn и задаюсь вопросом: вдруг он мне ещё понадобится? Трудно представить для чего, если честно. Даже прямое своё назначение он не выполняет: все свои работы и занятости я находил где угодно, кроме LinkedIn. Всё что мне даёт эта соцсеть — это поток предложений о работе, которые мне не нужны. А когда они мне нужны, я просто переключаю видимость резюме на hh.ru.

В 2008 году, когда я перешёл из десктоп-разработки в веб-разработку, вопросом выбора языка для бэкэнда задаваться не пришлось: судя по вакансиям и проектам на фрилансе, абсолютным лидером был PHP.

В 2018 году я перестал использовать PHP, когда увидел, что Node.js и TypeScript стали достаточно хороши для того, чтобы в моём инструментарии заменить PHP, потому что писать и бэкэнд и фронтенд на одном языке очень удобно, а я за удобство и скорость разработки.

С теплотой вспоминаю время, когда я прогал на пыхе. У этого языка хватает недостатков, но у него есть немало достоинств, и главное из них в том, что он вдохновляет создавать свои проекты, фреймворки, CMS. Почему-то на этом языке очень интересно делать что-то своё и для себя. Кроме того, что я периодически пилил на PHP стартапы, последние два года разработки на этом языке я увлекался разработкой собственного фреймворка.

Почти всё своё свободное время я проводил за допиливанием и перепиливанием этого фреймворка, я сделал свою реализацию Dependency injection, ORM, контроллеров, в общем, делал полноценный свой велосипед. Но самое важное заключается в том, что мотивировала меня не какая-то материальная потребность, не жажда признания, мотивировал меня исключительно исследовательский интерес. И это прекрасно!

Я уверен, что схожие чувства испытывали создатели многочисленных крутых фреймворков и CMS. Благодаря этим инструментам и самому PHP стала возможна разработка огромного числа сайтов и сервисов, которые мы знаем, которые не появились, если бы их разработка оказалась сложнее и дороже.

В прошлом посте ☝️ я упомянул момент, когда перестал использовать на бэке PHP и перешёл на Node.js. Переключаться с одной технологии на другую — обычная практика, не вызывающая сложностей у разработчиков. Однако в карьерном плане такой переход может быть болезненным, поскольку работодатель настороженно относится к недостатку опыта работы с конкретной технологией, отказывая в высокой зарплате даже опытным программистам. Например, если у вас опыт разработки на Ruby 10 лет и вы привыкли получать N рублей, то при переходе на Go, в котором у вас опыта без году неделя, вы сможете рассчитывать в лучшем случае на мидловую зарплату N/2.

Расскажу о своём опыте, позволившем избежать просадки по зарплате. Моё предыдущее место работы было в компании, предоставляющей облачные услуги корпоративным клиентам. Им нужна была панель управления, позволяющая отображать услуги (виртуальные машины, хранилки, сети и т.п.), считать сколько услуг каким клиентом было потреблено, генерировать отчёты, в том числе сводные, и счета. Стороннее коробочное решение не подходило из-за тонкостей расчётов для разных клиентов. Когда я был на собеседовании, я понял, что в организации я буду первым и пока единственным программистом. Это несколько расходилось с моими ожиданиями: я хотел работать в компании, которая привыкла работать с разработчиками (фреш-бары, печеньки, плейстейшины и вот это вот всё), и хотел вариться среди других программистов, чтобы перенимать опыт. Но на другой чаше весов была амбициозная задача, решение которой, включая архитектурные вопросы, полностью доверялось мне. И вторая чаша весов перевесила просто потому, что сулила мне много опыта.

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

Я решил начать с бэкэнда-монолита, который был написан на PHP. Ознакомившись с обновлёнными стандартами JavaScript, новой версией Node.js, npm-библиотеками, я понял, что на этом стеке можно будет реализовать бэкэнд архитектурно схожий с имеющейся реализацией на PHP. Поскольку переписать весь монолит разом задача трудоёмкая и в процессе её решения нужно будет делать двойную работу: все фиксы и фичи нужно будет писать и на PHP и на JS, я решил применить другой подход. Я сделал список всех роутов, которые обрабатывал бэкэнд, и в рамках выплаты техдолга, но по большей части в своё свободное время брал наиболее интересный мне роут и переписывал его на Node.js. Я больше не вносил изменения в PHP-код, если правки нужно было делать для роута, который ещё не был реализован на Node.js, я его реализовывал вместе с правками. На проде nginx был настроен таким образом, чтобы старые роуты обрабатывалась PHP, а новые Node.js. Процесс такого переписывания бэка занял меньше месяца.

Немного позднее я переписал фронт с jQuery на Vue.js, а спустя полтора года, в рамках крупного обновления UI, мы уже использовали React. До этого я не имел значимого опыта разработки с использованием реактивных фреймворков и библиотек для фронта.

Таким образом, я безболезненно, с пользой для себя и для работодателя получил коммерческий опыт разработки на новом стэке, включая Vue.js и React, что позволило мне на следующем месте работы не потерять в зарплате, а существенно её увеличить.

Написал статью для блога Гикбрейнс, в которой постарался максимально доступным языком описать принцип работы блокчейна: https://geekbrains.ru/posts/kak-rabotaet-tekhnologiya-blokchejn-prostymi-slovami

«Сначала художник рисует просто и плохо. Потом сложно и плохо. Потом сложно и хорошо. И только потом просто и хорошо», — недавно в процессе беседы про профессиональный рост услышал от коллеги эти слова русского живописца и профессора Ильи Репина.

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

В таком виде фраза гармонично ложится на общепринятое деление специалистов в IT по уровню развития джун-мидл-сеньор.

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

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

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

Читайте продолжение на Хабре: https://habr.com/ru/post/537048/#habracut

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

Сам я ветеран удалёнки, проработал в таком формате примерно 7 лет и, вероятно, поэтому не люблю её. Одной из причин, по которой я 5 лет назад переехал в Москву, было как раз желание работать в офисе. Я воспринимаю работу как самую важную часть своей жизни, поэтому стремлюсь совмещать полезное с приятным. Приятным в данном случае является живое общение с коллегами, эмоции, шутки, истории, совместный отдых, вот это всё. Если я не буду иметь возможности ходить в офис, я буду месяцами безвылазно сидеть дома, отчего у меня начинаются проблемы с социализацией и я буквально засыпаю и просыпаюсь с компьютером в обнимку.

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

От руководителя одной известной ed-tech компании я услышал интересное сравнение. Онлайн-работа — это как онлайн-жена, с которой можно общаться, ругаться, смотреть вместе фильмы, делить бюджет и даже заниматься сексом (но виртуальным). Я склонен согласиться с этим, потому что офисная работа в эмоциональном плане качественно отличается от удалённой работы. На удалёнке даже заговорить трудно с кем-то, потому что перед любым созвоном принято спрашивать «я позвоню?», в то время как в офисе всегда кто-то с кем-то общается, часто непринуждённо, и не обязательно по рабочим вопросам.

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

Из трёх популярных реактивных решений для разработки фронтенда, Angular, Vue.js и React, последний мне нравится больше всего, этой мой любимый инструмент. Формально, в отличие от ангуляра и вью, реакт является библиотекой, а не фреймворком, потому что его базовая поставка не содержит решения для роутинга и управления состоянием, а также не предлагает разработчику какую-то определённую структуру проекта. Из-за этого при сравнении реакта с конкурентами приходится для их общего обозначения придумывать замысловатые словосочетания, как в начале этого абзаца, вместо того, чтобы просто говорить «по сравнению с другими фреймворками...»

Так вот, «по сравнению с другими фреймворками», React является самым популярным (посмотрите после этого поста статистику Google Trends за последние три года 👇). Полагаю популярность его изначально обоснована простотой и предсказуемостью поведения.

Для справки: первая версия AngularJS была выпущена в 2010 году, в 2013 году появился React, а в 2014 Vue.js.

Если говорить только про простоту разработки и порог входа, то Vue.js в этом плане лидирует. Помню как за один рабочий день, не имея опыта разработки на реактивных фреймворках, выбрав вью по отзывам за его низкий порог входа, запилил фронтенд для простой админки. Позже, когда я знакомился с React, мне понадобилось больше времени для того, чтобы «влиться». Но если говорить про предсказуемость поведения, то Vue.js показывает не лучшую игру. Из-за того, что он предоставляет разработчику много удобных инструментов (например, v-model, watchers и т.п.) с ростом проекта растёт вероятность «выстрелить себе в ногу» и потратить часы, если не целый день, наткнувшись на очередное цикличное обновление состояния или наоборот отсутствие обновления там, где оно ожидалось. Признаюсь, после полутора лет разработки на вью, я так и не научился чувствовать полную уверенность в том, что я знаю, как на самом деле работает моё приложение. Потому я и перешёл на React.

При этом я с интересом отношусь ко второй версии Angular. По предсказуемости поведения ангуляр однозначный лидер. Код, написанный для него, выглядит фундаментально и архитектурно красиво, а я ценитель хорошей архитектуры. Тем не менее по сложности разработки Angular перегибает палку, и то, что на вью можно сделать за полчаса, на реакте за час, на ангуляре потребует два часа. Я за скорость разработки, поэтому не выбираю ангуляр. Но всегда говорю спасибо Angular за популяризацию TypeScript.

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

Но настоящая киллер-фича React'а, которой он обзавёлся не так давно, это хуки. Когда я, приверженец ООП, узнал, что разработчики реакта в новых проектах предлагают использовать функциональные компоненты, а компоненты, основанные на классах, больше не будут развиваться, я расстроился. Понимая, что специалист, из какой бы профессии он ни был, не может позволить себе закрывать глаза на новые веяния (иначе он рискует потерять ликвидность на рынке труда и получить репутацию чувака, который когда-то был крут), я решил переписать один из своих pet-проектов на хуки и обнаружил, что кодовая база сократилась в полтора раза при сохранении функционала. «Круто», — подумал я и стал писать на hooks на работе. А вторым открытием стало то, что разработка стала быстрее.

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