Post Category → О работе

Developer Survey Results за 2019 год

На SO появился самый интересный Developer Survey Results за 2019 год. Самые на мой взгляд главные моменты в этом опросе:

  • Python растет невероятно быстрыми темпами для такого не молодого языка, нашел свою нишу. Тут, безуспловно, изрядную роль в столь стремительном росте оказали ML с одной стороны и рост популярности автоматизации всего и вся с другой стороны. А так как Python великолепно себя зарекомендовал в обоих областях, то ожидать чего-то иного было бы сложно. Если вы думаете о том, какой бы язык изучить – не думайте, возьмите область в которой популярен Python разберитесь, окупится.
  • Rust самый желанный и быстро растущий язык на протяжении последних 4-х лет. Лично для меня это невероятно удивительный факт с учетом сложности этого языка. Думаю что изрядная составляющего этого роста – шумиха вокруг языка от людей, которые на нем ничего сложнее “Привет Мир” не писали, но факт остается фактом и шумиха не может не сказаться на количестве вакансий на этом языке. Опытным разработчикам, особенно с опытом в C/C++ есть на что обратить внимание.
  • Моя персональная слабость – Vim, по прежнему входит 5-ку самых популярных сред для разработки! Ура и вечной жизни этому восхитительному редактору.
  • Kotlin стал 4-м по желанности языком! Восхитительная новость, а JetBrains молодцы!
  • В общем случае лучше всего платят за Site Reliability Engineering (что за зверь такой?) и DevOps. Если же говорить про разработчиков, то в лидерах Clojure, Go, F# и Scala. Если с Clojure мне совершенно не понятно кто и за что так хорошо платит, то F# и Scala – это явно финансы, а Go – это разнообразные бэкенды и облака. Выбор куда идти за хорошей ЗП довольно простой, правда?
  • Наиболее оптимистично смотрящие в будущее разработчики живут в Китае, наименее оптимистичные в Западной Европе. Ну что, тоже более чем ожидаемо, но то, что даже программисты начали что-то подозревать кажется занятным.
  • Для большинства разработчиков программирование – это еще и хобби. Я, видимо, в какой-то другой вселенной живу, но где эти 80% у которых программирование – хобби?!
  • В Индии почти все разработчики постоянно ищут работу. Во всех остальных странах для которых приведены данные тренд противоположный.

Rust и социальные факторы

Так сложилось, что вчера, с одной стороны, Евгений провел довольно интересную аналогию между моделью памяти Rust и книгой и это была, наверное, самая наглядная иллюстрация различий в отличиях управления памятью между Rust и C++. А с другой стороны я прочитал  “Memory Management Patterns in Business-Level Programs” из 148 выпуска Overload в которой вскользь затронут этот же вопрос. В обоих случаях отношение к изменениям принесенным Rust на мой взгляд очень разумное: изменения на выдающиеся не тянут и решают уже решенную со времен C++14 (хотел бы написать со времен C++11, но make_unique появился только в C++14, а без него модель была не полной) проблему сильно более сложным способом, заставляя думать не только о корректности логики как таковой, но и о доказуемой корректности кода с точки зрения конкретной версии компилятора.

При этом, все мы живем в обществе, работаем в командах и не можем игнорировать вау эффекты и стадные инстинкты. По не очень понятным мне причинам я со всех сторон наблюдаю щенячий восторг по поводу Rust от людей которых я бы ну никак не заподозрил в таком. Например сегодня был диалог с очень продвинутым Python-разработчиком и не менее продвинутым C# разработчиком о том, что Rust – это круто, Rust – это нам надо и мы уже начали затягивать его в нашу кодовую базу. При этом какие-либо аргументы в пользу того, что то же самое можно сделать в меньшее количество легче воспринимающихся строк кода на C++14 (так как код не будет изобиловать модификаторами времени жизни) отбрасываются сразу с аргументами “я 15 лет назад на C++ писал – жуткое убожество”.

Наблюдая за скоростью продвижения Rust исключительно (как мне кажется) за счет этого загадочного вау-эффекта начинаешь задумываться, а может всё же стоит вложиться в него временем более серьезно? Не по тому, что такое большое количество народу не может ошибаться, а потому, что когда говоришь с фанатиками и понимаешь предмет их фанатизма, легче “продать” что-то кажущееся правильным и нужным лично тебе. И пусть логически проект проще и быстрее выполнить на C++, желание сделать на чем-то ином очень важный стимул который довольно часто положительно сказывается на качестве готового решения. Единственная и самая главная неизвестная для меня в этом вопросе, а на как долго хватит этого Растоманского запала? Что же будет после него? Понятно, что C++ был, есть и будет, но вот Rust…

ML не взлетает…

В начале этого года меня довольно сильно проперло с  машинного обучения. Настолько сильно что я прошел Deep Learning Specialization и стал размышлять на тему того, что дальше делать и как это монетизировать.

В плане того, что делать дальше курсы в рамках  Deep Learning Specialization довольно наглядно показали что тема откровенно бездонная, и если хочется не просто как-то решать задачи при помощи TensorFlow и иже с ними, но и понимать то что делаешь, то нужно копать отсюда и ужина, который ожидается в лучшем случае через несколько лет. Я было даже взялся за Mathematics for Machine Learning, чтобы освежить школьную математику, которая была само собой благополучно забыта за 20 лет после окончания школы. Но что-то мне начало казаться, что так слона не съесть, так как он слишком велик. У меня вообще сложилось ощущение что люди в ML делятся на две категории: одни понимают как оно работает, а вторые просто используют инструменты без понимания что внутри. И само собой, этих самых вторых около 98%, что выглядит очень страшно…

С монетизацией тоже не всё понятно. Несмотря на шумиху вокруг ML, тема довольно нишевая и если приглядется к вакансиям в мире ML, то нормальный уровень (текущий, грубо говоря) дохода гарантирует только звездный уровень с PhD в данной области в придачу. Возникает довольно твердое убеждение что успешно продать ML в дополнение к моей основной специализации скорей всего не выйдет. А если что-то нельзя продать, то зачем оно нужно?

Плюс мир ML чем-то напоминает мир JavaScript с новыми прорывными решениями по нескольку раз в год, что сильно контрастирует с моей текущей специализацией. Те же сети и системная разработка позволяет довольно прохладно относиться к гонке за новинками, так как нового тут не так уж и много. К примеру те же несчастные корутины, которые “вот наконец решат все проблемы разработки сетевых приложений на C++”, обсасывают со всех сторон уже третий год, и реализации в 3-х основных компиляторах как разом как небыло, так и нет. Хорошо если через год-другой выкатят…

Но так как учить что-то надо всегда и во всех ситуациях, я на некотором распутье, то-ли продолжить копать ML, но не очень понятно как и в каком направлении, то-ли… ну, к примеру, посмотреть на blockchain, с куда более близкими криптографией, сетями и т.п.

Зачем и кому нужен Go?

Так вышло, что последнии 2 года я довольно плотно работаю не только с давно привычными мне C++ и Python, но и Go. Как мне кажется, 2 года довольно приличный срок для того чтобы сформировать свое мнение о каком-либо инструменте, так что, пора им поделиться. Так же, по моим ощущениям, про Go обычно пишут люди из небольших компаний и стартапов, я же буду писать с точки зрения разработчика из матерой корпорации специализирующейся на разработке ПО.

Когда Go не нужен и не полезен

Начнем с самого важного: при каких условиях этот язык скорее вреден.
Continue reading →

Rust и Я

У меня, как наверное и у многих других C++ разработчиков какие-то сложные отношения с Rust. Этот язык вроде как и очень сильно нравится и в то же время всё сложно. На сей раз моя попытка заняться Rust в серьез зашла куда дальше чем обычно (обычно я после нескольких небольших тестиков удовлетворенно забрасывал изучение) – я нашел компанию которой нужны Rust разработчики, связался с ними и взял тестовое задание. Тестовое задание просто восхитительное, не сложное, но помогает понять главное – хочешь ли ты связываться с языком или нет?

На тестовое задание я честно потратил часов 8 и за это время успел заглянуть в tokio, которая, как я понимаю, является образцово-показательной библиотекой для написания асинхронных сетевых приложений. Честно говоря, я до сих пор в состоянии смятении, но точно знаю одно – видеть такое и не дай бог поддерживать на постоянной основе я точно не хочу. К примеру, вот кусок кода, который читает данные из канала и шлет их по TCP:

Box::new(tcp.map(move |stream| {
    let (sink, stream) = stream.framed(Bytes).split();
    pool.execute(stdin.forward(sink).then(|result| {
        if let Err(e) = result {
            panic!("failed to write to socket: {}", e)
        }
        Ok(())
    })).unwrap();
    stream
}).flatten_stream())

Несколькими месяцами раньше я баловался с биндингами к libClang, где было всё читабельно и очевидно, что наводит на мысли, что написать на Rust можно писать как в адекватном и легко поддерживаемом стиле, так и городить write-only код в духе приведенного выше. И надо отметить что в примере выше чувствуется и стиль и задумка. Если в него какое-то время повтыкать (желательно в IDE с навигацией, очень рекомендую IntelliJ Rust), то становится понятно что хотел сказать автор и почему. Только вот “НУ ЗАЧЕМ?!?!” не покидает.

В итоге мне в очередной раз стало казаться, что за пределами небольших сообществ гиков Rust взлететь не может, так как поддерживать столь неочевидные решения должно быть даже дороже чем решения на C++ с ручным управлением памятью (в конце концов, санитайзерами можно отловить практически всё). Не знаю чем это вызвано, скорей всего тем, что Rust развивает комьюнити гиков, а C++ комитет старперов. В результате в Rust тянут все, что круто выглядит, а в C++ только то, что “мегамозги” одобрили. Побочным эффектом этого выступает то, что в Rust многие удобные вещи доступны сразу или почти сразу, а в C++ это “наверное будет реализовано после C++20” (да-да, это я про Meta).

Наверное, меня всё равно не отпустит и баловаться с Rust я не перестану. Но вот подаваться на позицию “Rust разработчик” я довольно долгое время точно не буду, сообщество должно наиграться в “zero cost abstractions” для начала

Правильно выбранный инструмент творит чудеса

Сегодня мне попалась на глаза замечательная заметка о том, что мессенджер, с более чем 900 миллионами пользователей, пишет команда из, внимание, 50 человек! Да, именно 50, а не 500 и не 1500, как можно было бы ожидать. При этом, пишется сие чудо (серверная сторона, само собой) на Erlang. Не то что бы я огромный поклонник этого языка, но сама ситуация наводит на мысли о том, что правильный выбор инструмента может сильно сократить необходимое количество разработчиков. Continue reading →

Как уехать в…

В последнее время довольно популярной темой на РСДН-е стал вопрос “как уехать в …”, хотя в большинстве случаев он больше похож на “как уехать из РФ”. Как мне кажется, у меня действительно есть что сказать по этому вопросу, все же переездов у было мягко говоря не мало. Если коротко, то вырос я в Бишкеке, после этого работал в Алмате откуда переехал в Москву. Из Москвы я отправился в Сувон, Ю.Корею, откуда вернулся в Москву. Сейчас я пишу эту заметку из Сингапура и, с довольно большой вероятностью, этот город может оказаться не последним в списке переездов. Что довольно важно, только первый “понаезд в Москву” был сделан за мой собственный счет, все остальные переезды полностью оплачивались работодателем.

Continue reading →

TeamLead С++ OSX wanted!

Не думал что когда-то напишу такое, но… я ищу себе замену! По деньгам не обидят, официально вилка звучит как 140-180. Функцоинал двоякий, есть интересное, есть болото, но это как и в любой другой работе. Писать можно мне на e-mail. Если не интересно самим, поделитесь с теми, кому может быть интересно. Заранее спасибо!

C++ TeamLead, описание вакансии

Основные функции и задачи:

  • Создание программных решений в составе команды разработчиков;
  • Анализ требований и постановка задач членам команды;
  • Разработка оптимальных решений, оценка трудоемкости задач;
  • Участие в подготовке проектной и технической документацию по порученным задачам.

Позиция предполагает работы по:

  • портированию существующих Windows-компонент на Mac (включая и последующую отладку портированного кода);
  • реализации Mac-специфических компонент и сервисов (включая драйвера);
  • интеграции компонент в общий продукт.

Требования к кандидату:

Обязательно:

  • Инициативность и умение внятно, корректно обосновать логичность и правильность выбранного решения;
  • Опыт в управлении командами до 10 человек;
  • Опыт в создании WBS, распределении задач по членам команды и контроле за их выполнением;
  • Отличное знание C и C++;
  • Отличное знание библиотек STL и BOOST;
  • Знание платформы Mac OS X ИЛИ обширный опыт разработки под *NIX системы (FreeBSD, Linux, etc.) и желание перейти в разработку под Mac OS X;
  • Знание инструментальных средств разработки под *NIX, таких как GDB, Make, CMake;
  • Знание Sh, стандартных консольных *NIX приложений и какого-либо скриптового языка (предпочтительно Python);
  • Опыт работы с логами и крэш-дампами;
  • Опыт разработки мультиплатформенных систем (Windows, UNIX).

Желательно:

  • Понимание принципов и опыт разработки многоуровневых клиент-серверных приложений;
  • Знание и опыт использования межпроцессных взаимодействий;
  • Понимание принципов основных сетевых протоколов (как минимум TCP/IP);
  • Опыт портирования приложений с Win32 и UNIX.

Крик души о Python собеседованиях

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

  1. Расскажите про особенности многопоточности в Python. Зачем нужен GIL, его плюсы и минусы. (0 ответов)
  2. Как работает конструкция with open(…). Зачем она вообще нужна? (0 ответов)
  3. Что нужно добавить в класс, что бы при передаче объекта соответствующего типа в качестве аргумента функции print была выведена не информация о типе и адресе, а некая пользовательская строка. (1 ответ)
  4. Как в Python описываются абстрактные базовые классы? Зачем они нужны? (0 ответов)
  5. В чем основные особенности написания асинхронных приложений? (0 ответов)

Вот я думаю, может я что-то не то спрашивал? Просто мне не приходят в голову еще более простые вопросы.

Два вида мотивации сотрудников

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

Лично я с этим мнением категорически не согласен и считаю что сотрудник, в первую очередь, должен хотеть работать за деньги и за другие материальные ништяки. Такая позиция часто удивляет или настораживает HR, и когда на собеседовании говоришь в лоб о том, что работаешь “исключительно за деньги” они как-то странно на тебя смотрят. А зря и вот почему.
Continue reading →