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

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

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

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

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

И не нужно упускать из виду работу с заказчиком. Если бы у нас была система, которая может написать программу по формализованному, чётко сформулированному по определённым правилам техническому заданию, то написание такого задания, учитывая, что требования исходят от людей, по сложности было сродни написанию самой программы. Современная же разработка вообще обходится без технических заданий (кто составлял, тот знает, насколько это тяжкий труд), а задачи ставит от спринта к спринту, ориентируясь на дорожную карту.

В конце предлагаю к прочтению занятный материал по теме: https://habr.com/ru/post/507420/.

Скорость набора текста (особенно англоязычного, если говорить про жителей СНГ) является косвенным показателем профессионализма в IT.

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

В целом, работа за компьютером связана с набором большого количества символов. Что важно, большая часть набранной информации не получит отражения в конечном результате. То есть, на 1000 строк в репозитории может приходиться 2000 фактически набранных, а затем удалённых строк.

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

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

Отмечу, что речь идёт не о скорости программирования в частности, а о скорости набора текста вообще, о способности печатать «вслепую».

Тем, кто входит в IT или уже вошёл, можно посоветовать прокачать скорость набора. Так будет проще учиться, проще получить хороший оффер и проще будет работать.

Самые запоминающиеся факапы у меня связаны с удалением того, что удалять не следовало.

Году в 2007 друг попросил меня переустановить Windows на компьютере его мамы. Я как-то невнимательно отнёсся к тому, из каких папок нужно сохранить информацию и забыл перенести, в частности, незаконченную научную работу.

Позже, в 2010 году, когда я осваивал Linux, допустил классическую опечатку, набрал под рутом rm -Rf . / вместо rm -Rf ./ и удивлённо наблюдал, как с экрана исчезают значки, виджеты, система начинает сбоить. Когда понял в чём же дело, было уже поздно: директория /home оказалась удалённой вместе с архивами моих старых pet-проектов, которые я поленился забэкапить, документами, фотками... И, главное, текущей работой по проекту: это был какой-то сайт на Drupal для заказчика, а мои оправдания по поводу того, что я случайно всё удалил, наверняка показались заказчику выдуманными.

Следующим на память приходит эпизод, когда я грохнул корпоративный сайт oncloud.ru. Мне нужно было на уже существующую тестовую виртуалку вместо старого проекта залить новый, чем я и занимался в окне терминала через ssh. Меня отвлекли каким-то срочным хотфиксом на корпоративном сайте, я его сделал и задеплоил (тоже через ssh, но в другом окне терминала), после чего вернулся к текущей задаче. Выполнив удаление с диска старого проекта, я понял, что сделал это не в том окне терминала, в котором нужно. Всё бы ничего, код сайта хранился в репозитории, а базу я не трогал, но удалился весь загруженный на сайт контент. На этот раз спасли бэкапы: виртуалка бэкапилась через veeam, так что сайт находился в неприглядном виде всего час, что, впрочем, для облачного провайдера немало.

Ну и из прошлогоднего. Решил на выходных сделать простое в использовании dev-окружение для системы, которую мы пилили. Там порядка 30 docker-контейнеров. Код микросервисов и фронтендов из репозиториев я решил скачивать в директории backend и frontend соответственно (и добавил их в .gitignore: backend и frontend без слеша вначале). А Docker-файлы я хранил в директориях docker/backend и docker/frontend. Разумеется, команда git add -A их не добавляла в коммиты (и в глаза не бросилось то, что не все файлы добавлены), о чём я узнал не сразу, а только когда грохнул директорию проекта и попытался проинициализировать его заново, чтобы убедиться что всё скачивается и работает как надо. Я тогда даже безуспешно пытался восстановить удалённые файлы, настолько мне не хотелось заново писать 30 docker-файлов и проверять нормально ли работает каждый контейнер. Часов 6 работы было тогда потеряно.

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

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

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

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

За годы я выработал идеальный для себя способ обращения с паролями: это программа KeePass (раньше использовал KeePassX из-за более приятного интерфейса, но программа не обновляется с 2016 года), которая хранит пароли в файле *.kdbx, зашифрованном мастер-паролем. Мастер-пароль я храню, разумеется, только в голове. При этом сам файл *.kdbx уже можно хранить где угодно, без мастер-пароля он бесполезен. Я храню его вместе с остальным барахлом локально в директории, которая синхронизируется на Яндекс-Диск, благо Яндекс не ленится обновлять клиент для Linux. Таким образом, в облаке у меня всегда актуальная версия файла с паролями. Если мне нужно, например, на смартфоне получить какой-либо пароль, я просто скачиваю файл из облака и открываю его в Keepass2Android.

Я присматривался к облачным сервисам для хранения паролей, пожалуй, самый известный — это 1password.com. Кроме необходимости ежемесячно платить по 5 баксов, это облачный сервис, к которому можно потерять доступ во время очередной борьбы РКН с ветряными мельницами.

Просто факт: в моём менеджере паролей сейчас насчитывается 224 записи.

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

В 2000-х популярность программирования набирала обороты, а самым популярным направлением изначально была десктоп-разработка. Самыми ходовыми решениями для десктоп-разработки были Java, Delphi, C++ Builder, .NET Framework. Все они подразумевали разработку в парадигме объектно-ориентированного программирования, поэтому в моде тогда было знать паттерны (шаблоны) ООП, чтобы писать красивые решения, не изобретать велосипеды и не городить костыли. Я старался применять популярные паттерны в уместных местах, не потому, что это правильно (что, в зависимости от задачи, бывает спорным), а потому, что это экономило время.

А ещё в то время было модным обсуждать и пробовать «экстремальное программирование». Кроме автотестов, парного программирования и прочего, оно подразумевает непрерывный процесс улучшения качества кода (рефакторинг). То есть, если сейчас код написан плохо, например, имеется дублирование, но задача решена, в этом нет ничего плохого, но этот код обязательно должен быть улучшен в ближайшее время. Таким образом, не так важно какая архитектура у только что написанного кода, важно чтобы этот код стал лучше через месяц и ещё лучше через два. Я с удовольствием взял тогда на вооружение этот принцип и применяю его в своей работе. Это позволяет, не выделяя отдельных дней на рефакторинг, поддерживать код в хорошем состоянии: видишь код, который можно улучшить, улучшаешь его прямо сейчас, не откладывая «на потом». У такого подхода есть и ещё один плюс: ты не забываешь кодовую базу и хорошо в ней ориентируешься, как паук в своей паутине.

Несмотря на то, что принципы SOLID были описаны в начале 2000-х, широкую практику применения они стали получать в конце нулевых - начале десятых во многом благодаря спросу на разработку и поддержку огромного количества веб-сервисов. Из-за отсутствия релизов, которые были заменены непрерывной доставкой, необходимо было покрытие кода автотестами, чтобы очередной деплой ничего не сломал. Микросервисная архитектура требовала от кода модульности, возможности беспроблемного заимствования отдельных частей. Эти и другие факторы, а также высокие требования к масштабируемости процесса создания продукта, когда команда программистов могла увеличиться за год в разы, сделали SOLID мастхевом в промышленной веб-разработке.

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

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

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

Задать вопрос, предложить тему для заметки, а так же проголосовать за понравившиеся темы вы можете на странице qst.it-monk.ru.

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

Фронтенд — JavaScript;
Бэкэнд — JavaScript;
Мобильные приложения — JavaScript;
Игры — JavaScript;
Искуственный интеллект — JavaScript.

Как это ни странно, ноги сегодняшней кроссплатформенной популярности JavaScript растут из его, некогда, тормознутости: когда Google решил создать самый быстрый браузер, им пришлось столкнуться с необходимостью разработки быстрого движка для выполнения JavaScript. В нулевых шло активное состязание между браузерами за скорость выполнения JavaScript кода. Поскольку веб-приложения стали использовать JS очень широко, а jQuery встраивался чуть ли не в каждый сайт, то самый быстрый браузер должен был быть, в первую очередь, самым быстрым в части выполнения кода, а не загрузки HTML, стилей и картинок.

Поэтому в 2008 году вместе с первой версией Chrome вышла и первая версия используемого в нём JS-движка V8. V8 был и остаётся самым быстрым, с тех пор в нём появилось ещё больше оптимизаций. Скорость и асинхронная природа JS подтолкнули программиста Райана Даля к идее использования JavaScript на бэкэнде для разработки высоконагруженных приложений, и в 2009 году он выпустил среду Node.js, которая использовала V8 и позволяла выполнять JavaScript вне браузера. В 2010 году появился менеджер пакетов NPM, тогда началось победоносное шествие JavaScript по всем направлениям.

Node.js и NPM позволили появиться таким технологиям как Babel и Webpack, TypeScript, Angular, React и всему тому, без чего современная фронтенд-разработка не может обойтись. Node.js широко используется в бэкэнд-разработке в качестве основной и вспомогательной среды. Когда сообщество увидело в языке большой потенциал, стандарт языка стал активно развиваться, приобретая мощные синтаксические инструменты.

На основе Chromium был создан Electron, позволяющий разрабатывать десктоп-решения, на основе которого созданы Visual Studio Code, Skype, Discord, Slack, Streamlabs OBS, WhatsApp Desktop и другие. Но для десктопа используется не только Electron: например, клиент Spotify использует Chromium Embedded Framework для отображения интерфейса.

React Native, появившись в 2015-м году, быстро занял прочные позиции в качестве инструмента для мобильной разработки, став основой для таких приложений, как Facebook, Instagram, Skype, Tesla, Airbnb, Discord, Pinterest и многих других.

Нашлось место JavaScript и в разработке AAA-игр. Благодаря технологии Coherent Gameface, разработчики таких игр как Battlefield 1, Godfall, Control, PUBG, BlackDesert Online используют JavaScript для разработки игровых интерфейсов.

Разумеется, у JavaScript есть недостатки, но, как однажды сказал Страуструп, «есть всего два типа языков программирования: те, на которые люди всё время ругаются, и те, которые никто не использует».

На этой неделе принял решение уйти из Mail.Ru Group, в котором я занимал позицию разработчика DonationAlerts Studio. Если раньше причины моих уходов из проектов лежали в плоскости неудовлетворённости проектом, организацией процессов или просто усталостью, то теперь я дорос до более простой причины — неудовлетворённостью доходом. Настало время поговорить о волнующей всех теме, о зарплатах программистов.

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

Всё объясняется простыми рыночными отношениями: зачем компании платить кому-то 300к, если есть очередь из желающих работать за меньшую сумму? Тем более, если это компания крупная, с тысячами разработчиков в штате, экономия на зарплате которым способна принести существенную прибыль в абсолютном выражении. Можно было бы возразить, что программист за 300к будет делать больше программиста за 200к, но нередко оказывается, что это не только не так, но и наоборот. Не слишком уверенный в себе программист способен создавать ценность не хуже «рок-звезды», но получать в три-четыре раза меньше денег, просто потому, что не знает, что можно по-другому. А по-другому можно и я считаю своим долгом об этом говорить.

После полутора лет работы, первый год из которых был особенно «жарким», мне предложили увеличение зарплаты на ~5.5%, что меньше даже официальной инфляции. При этом всё это время я отказывался от предложений выше по зарплате в полтора-два раза. Где-то предлагали не очень интересный проект, где-то не очень сильную команду, но чаще всего я оправдывал себя примерно такими словами: «ну как же я могу променять проект, о котором знают все, на работу в компании, название которой я первый раз вижу, над проектом какой-то далёкой от меня криптобиржи».

Через неделю после того, как я получил долгожданное «повышение», ко мне начало приходить озарение такой силы, что мне пришлось срочно взять отпуск и провести полторы недели в размышлениях о том, почему я оцениваю свой труд так низко и что пора бы перестать вестись на крутые HR-бренды, а уделять внимание компаниям, которым ты нужнее (раз они готовы платить больше).

И вот мы подходим к ответу на вопрос о максимальных зарплатах в айти. Например, сегодня я получил предложение пройти собеседование на вакансию с вилкой з.п. 420-600к, с комментарием, что можно и больше, всё зависит от скиллов. Вилки зарплат 400-500к — это вообще обычное дело. Но вы, как программист, никогда не увидите таких предложений от рекрутёров из Тинькофф, Яндекса, Авито, Мейла и прочих известных компаний. Айти-гиганты доминируют на рынке труда, предлагая вместо высоких зарплат нематериальную компенсацию в виде массажа, фреш-баров и, главное, сопричастности к «великому». Остальным компаниям приходится просто больше платить.

За довольно долгий перерыв в ведении канала (в процессе смены работы решил устроить себе отпуск) было время подумать над вопросом отчего сейчас в основном зависит моя зарплата. Тем более что сам процесс поиска новой работы заставил задуматься о своём ценообразовании.

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

В процессе перехода по условным шагам «junior-middle-senior» работодатель начинает уделять софт-скиллам всё больше внимания. Для middle-разработчика важными становятся умение работать в команде, память и внимание.

У senior список навыков пополняется гибкостью (пригождается в процессе выбора подходящей для решения задачи технологии), навыками тайм-менеджмента, коммуникации, умением доводить начатое до конца. А требования к умению работы в команде увеличиваются.

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

Зависимость размера зарплаты от hard-soft навыков я бы субъективно описал так:

- У junior 90% суммы зависит от hard-скиллов, а 10% от soft-скиллов;
- У middle это 80%-20%;
- У senior — 60%-40%;
- У team lead — 40%-60%.

Отвечаю на вопрос, отчего сейчас зависит моя зарплата: я устраиваюсь на позицию team lead и думаю, что в моём случае половину зарплаты мне будут платить за hard-скиллы, а половину за soft-скиллы.

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

Как и у большинства людей примерно моего возраста (мне 33), история работы с компьютером началась с системника, монитора, клавиатуры, мыши и, конечно, колонок. Системник постоянно апгрейдился, несколько раз менялся полностью. Один ЭЛТ-монитор сменился другим, потом появился LCD-монитор на 19 дюймов, позднее на 24 дюйма.

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

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

Когда я созрел для покупки ноутбука, то подошёл к выбору, как крепкий хозяственник: это был самый дешёвый из 19-дюймовых ноутбуков с топовым железом. Я купил ноутбук DNS, отличительными его чертами были дешёвый пластик и отвратительная сборка. До сих пор не знаю, что меня в нём раздражало больше всего: сильный шум, обжигающий руки нагрев или вес в 5 килограммов вместе с зарядкой. Полагаю, всё сразу.

Через пару лет я решил положить конец своим мучениям и купил другой ноутбук. Предыдущие ошибки были учтены, но не все. Это был уже 15-дюймовый ASUS, с топовым железом и в алюминиевом корпусе. Но всё такой же тяжёлый. С тем ноутбуком я ездил на работу по проектам и в Минск и в Москву. Он был даже в Дубае. Однажды он пережил полёт в багажном отделении самолёта Победы, на память об этом на нём осталась небольшая вмятина. Это не убиваемый аппарат с до сих пор актуальным железом, он и сейчас используется в качестве основного компьютера моей женой. Несмотря на то, что я не привязываюсь к вещам, этот ноутбук я, вероятно, не буду продавать, потому что с ним связано много воспоминаний.

После переезда в Москву я начал ездить в офис на метро и понял, что носить такую тяжесть на спине по три часа в день — это слишком. У меня был скромный бюджет, поэтому я купил 13-дюймовый HP ProBook 430 G5 на Core i5 с очень плохим экраном: проблемы с цветопередачей и разрешение 1366x768. Однако и этому я был рад — он был лёгкий, хорошо держал заряд и позволял программировать в метро (я даже успел написать один pet-проект, 90% которого было написано в метро).

На тот момент меня ещё не отпускала старая концепция рабочего стола: я пользовался монитором, отдельной клавиатурой и мышью. Что дома, что на работе. Я приходил домой, подключал периферию к ноутбуку и закрывал крышку. Разумеется, всегда стоял вопрос выбора хорошей клавиатуры и мыши, желательно чтобы они были беспроводными. Эта тема для отдельной заметки, но в один момент я понял, что рынок даже за большие деньги предлагает не то, что мне нужно. Я решил, что клавиатура ноутбука меня вполне устраивает, а пользоваться тачпадом вместо мыши я уже привык, тем более что я настраиваю KDE в Линуксе так, что большинство действий выполняется с помощью клавиатуры. На моём столе остался только ноутбук и дополнительный монитор.

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

После отказа от монитора встала необходимость приобрести ноутбук с хорошим экраном. На этот раз финансы позволяли купить ультрабук. Выбор пал на Dell XPS 13, я давно хотел попробовать эту модель. Я пользуюсь им уже год и дома и в офисе, моё рабочее место — это просто пустой стол, на который я ставлю маленький ноутбук и делаю на этом ноутбуке всю работу, от программирования до вёрстки.

Друзья, мне в команду на проект https://infourok.ru/ нужны фронтенд-разработчики уровня senior c большим опытом разработки на React.

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

Чем предстоит заниматься: нужно будет разрабатывать новый функционал на React и иногда поддерживать старый на старом-добром jQuery.

Самое приятное, кроме вилки з.п. 300-500к, это наш небольшой и очень дружный коллектив 🙂

Резюме можно прислать нашему HR Геннадию @GennIURU

От людей, далёких и не очень от IT не раз слышал фразу в духе «программистом быть так круто, ты можешь сам сделать любой стартап, который придёт в голову». Утверждение, в общем, верное. Например, веб-разработчик действительно может разработать и proof-of-concept (подтверждение концепции) и MVP (минимально жизнеспособный продукт) почти любого веб-сервиса.

Почему же 99.99% разработчиков не являются успешными стартаперами? На первый взгляд, может показаться, что проблема в генерации идей... Но нет. Интересные задумки генерировать может каждый, у кого достаточно развита фантазия для этого. Когда я работал на фрилансе, у меня отбоя не было от ребят, которые предлагали участие в стартапах. Долю предлагали обычно далеко не 50% на 50%: почему-то автор проекта претендует минимум на 70% и, чем более сумасшедшая, в плохом смысле, идея, тем большую долю он желает получить. От меня же требовалось всего ничего: просто поверить «гению» и реализовать его мечту с нуля. Мне всегда хватало ума отказываться от подобных предложений.

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

Почему я не автор стартапов? У стартапера должна присутствовать важная характеристика — он должен верить в свою идею до конца. Такие, как мы, кто привык зарабатывать деньги своим профессиональным трудом, кто за время работы лично наблюдал как 90% стартапов умирают, мы всегда сомневаемся и в себе, и в своих, и в чужих задумках. Пропуская через призму, прежде всего, опыта, а потом уже рефлексии и анализа, мы заранее губим проекты, которые, возможно, могли бы стать успешными. Это связано с эффектом Даннинга-Крюгера. Но правда в том, что даже самая безумная идея хоть и с малой вероятностью, но может «выстрелить». В качестве примера приведу тот же chatroulette.com.

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

Сегодня в IT Монахе видео-выпуск🙂

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

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

👇👇👇

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

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

Раньше, когда ты заходил в салон сотовой связи, у тебя разбегались глаза от разнообразия. Каждый производитель старался сделать устройство заметным и функциональным. Вендоры экспериментировали с клавиатурой, расположением камеры, складывающимися, выдвижными, поворотными механизмами экрана, вторыми экранами. Даже физическая клавиатура из 12 клавиш, благодаря предиктивной системе набора текста T9 (Text on 9 keys) позволяла набирать текст быстрее (да ещё и слепым методом!), чем это происходит на современных устройствах. При этом любое из устройств держало заряд минимум три дня, а некоторые модели могли похвастаться недельным запасом заряда аккумулятора.

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

В этой истории интересно то, что производители больше не пытаются создавать визуально уникальные устройства, наоборот, они делают смартфоны с оглядкой друг на друга. Вся эта мода на вырезы в экранах, отсутствие разъёма mini-jack и прочее настолько быстро захлёстывает рынок, что ты приходишь в очередной раз в магазин и понимаешь, что без выреза в экране смартфон ты больше не купишь, их просто нет, а для того, чтобы слушать музыку через проводные наушники теперь придётся купить и носить с собой переходник USB Type-C -> mini-jack.

С этим всем можно смириться, но больше всего меня печалит то, что хардварные клавиатуры умерли. Кто-то пытается делать смартфоны с клавиатурами, например, Cosmo Communicator или Pro1 X, но это какие-то единичные истории и они часто заканчиваются снятием с производства в виду низкого спроса.

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

Есть такая библиотека для стилизации HTML Tailwind CSS, если коротко, это как Bootstrap, только с совершенно другим подходом. На этой неделе автор библиотеки отчитался в Твиттере, что его либа достигла показателя в миллион скачиваний в неделю.

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

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

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

Пока все до сих пор обсуждают сбой Facebook, WhatsApp и Instagram, хочу высказаться по поводу технической составляющей продуктов фейсбука.

Как бы кто ни относился к социальной сети facebook.com, с точки зрения инженерии, это крутой продукт, выдерживающий огромную нагрузку. Команда фейсбука создала такие крутые технологии как HHVM (HipHop for PHP, транспайлер PHP-кода в код на C++, после выхода PHP 7 потерявший актуальность), React, React Native и другие.

При этом есть мессенджер «привет из нулевых» WhatsApp, в котором отсутствуют обычные для современных мессенджеров возможности, и какая-то проблема с desktop-клиентами (под Линукс, например, вообще нет), будто это не самый популярный мессенджер в мире, а какой-то неудачный стартап, недополучивший инвестиции.

А ещё есть глючный Instagram. Перед написанием этой заметки товарищ с работы поделился наблюдением по поводу весьма своеобразного подхода к заполнению аттрибута class с использованием множества пробелов в веб-версии Instagram: это похоже на ошибку, которую как минимум полгода не могут или не хотят исправить. См. скриншот под постом 👇

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

В общем, у меня неоднозначное отношение к Фейсбуку. С одной стороны, я благодарен им за React, потому что это сбалансированный инструмент, по праву являющийся самым популярным среди решений для разработки SPA, да и не только. С другой, мне не нравятся ни идеи их продуктов, ни качество исполнения. А ещё эта история, когда айти-гигант, который может позволить нанять лучших девопсов в мире, допускает полный простой всех своих сервисов в течение 5 часов... Фантастика.