Форумы умерли, да здравствует Slack

Когда я только добрался до интернета, а сделал я это довольно поздно, судя по дате регистрации на РСДН-е я активен в сети с года так 2006, то был восхищён профессиональными форумами. Это было место с реальной движухой, там были умные люди, они обсуждали интересные вопросы и вообще жизнь кипела ключом. Время шло, форумы стали отмирать. Какие-то стали местом обсуждения политики, какие-то годятся только на то, что бы замерять у кого длиннее, где-то принято плакаться на тяжелую жизнь и мечтать свалить, а какие-то годятся только для мастурбации на карму. Когда-то активные завсегдатаи говорят что куда интереснее обсудить политику или похвастаться большой ЗП, нежели поговорить про дело… а для дела есть StackOverflow, где уже на все вопросы давно ответили. Я никогда не понимал как можно сравнить форум и SO, ведь SO – это про вопрос/ответ и все дискуссии строго пресекаются, а форум был в первую очередь про дискуссию. Можно еще вспомнить про Reddit, но по мне так это скорее коллекция ссылок, нашел что-то интересное, запостил даже не потрудившись пары предложений со своими мыслями добавить, а тебе почесали ЧСВ поставив плюсики.

При этом я всегда думал, что должны быть еще люди, которым интересно профессиональное общение в первую очередь, а потом уже карма, политика и прочие не имеющие к профессиональной деятельности вещи. И да, догадка была верна, я наткнулся на Slack! На сегодня хотелось бы отметить следующие сообщества: Continue reading

C++ интервью && многопоточность

В рамках поддержки формы и необходимости размяться перед серьезным поиском работы я походил по разным собеседованиям и надо сказать, вопросы по многопоточности в связке с С++ на них стали появляться. Очень редко по сравнению с количеством вопросов по сортировке гномиков и прочей ересью, но тем не менее за этот год я столкнулся аж с 2 вопросами из этой области в компаниях, которые активно используют C++11 и выше. Что удивительно, некоторые до сих пор сидят на С++98, а то и на вообще Си-с-классами.
Continue reading

Haskell – это прекрасно, но…

Правда, я не понимаю как я мог заниматься разработкой в течении 18 лет и не удосужиться прочитать хотя бы одной книги по Haskell и даже не написать простенького “Hello world!” на этом изумительном языке. Наверное, меня всё время так или иначе отпугивали разные слухи и истории на тему того, какой это дико сложный и непойми-нахрена-нужный язык. Не иначе!

К счастью у меня, с одной стороны, нашлось довольно большое количество свободного времени для изучения чего-то совершенно не нужного в повседневной работе, а с другой стороны, мне посоветовали несколько книг по Haskell в рамках внезапно разросшейся дискуссии об этом языке на Facebook и пусть ни одна из них мне не подошла, но начало было положено. Проблема с книгами собственно в том, что имея за плечами изрядный опыт программирования, большинство из них выглядят невероятно скучными. Ну зачем долго и в мельчайших деталях обсуждать что такое let или сопоставление с образцом? Ясно же, что Haskell не будет для кого-то первым языком и у читателя уже есть что-то за плечами для того, что бы провести аналогии и понять о чем идет речь с полуслова. К моей радости я наткнулся на What I wish I Knew, которая отвечает на изрядное количество прикладных вопросов относительно языка и наиболее распространенных паттернов использования и мне где-то я разыскал рекомендацию Get Programming with Haskell в которой кратко и по делу рассматривают основные концепции языка. Сначала мне эта книга сильно не понравилась, но оказалось что нужно просто пропустить/пролистать первые две главы и всё будет просто великолепно. Continue reading

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…

Зачем и кому нужен 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.