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

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

Сегодня мне попалась на глаза замечательная заметка о том, что мессенджер, с более чем 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

Собеседование как…

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

При этом всё может проходить совершенно иначе, о чем недавно поведал на широко известном программистском форуме не менее широко известный в узких кругах мыщъх. Если вкратце, то идея безумно проста и, в то же время, великолепна: собеседование в виде презентации. Continue reading

Как выбрать язык программирования для нового проекта

На данный момент я кажется окончательно вывел для себя правила по выбору языка для той или иной задачи. До этого многие годы писал на C++, C, Python, Java и Objective-C. Перепробовал кучу экзотических языков, таких как OCaml, Erlang, Scala, Lisp, Clojure. Так как я не занимаюсь разработкой UI, Web-сайтов или мобильных приложений, все мои соображения актуальны исключительно для разработки системных приложений, сетевых приложений и бизнес логики. Кроме того, все что я пишу в этой заметке относится к командной разработке приложений в рамках относительно крупной компании, и будет не актуально для команд из 1-2 разработчиков или “домашних” проектов. Continue reading

Вакансии в Mac команде ЛК

У нас, в Mac команде ЛК появилась одна вакансия (работа в офисе в Мск, есть программа релокации). Условия, как всегда, отменные, коллектив прекрасный, офис замечательный и даже бассейн есть (2 минуты пешком)

То что описания вакансии две, не суть важно, т.к. нас устроит человек как с опытом из первой, так и второй вакансии.

Что самое важное, на вакансию “C++ разработчик (логика)” мы готовы рассматривать не только C++ разработчиков с опытом программирования под OSX, но и просто сильных *NIX разработчиков (BSD – предпочтительно, Linux – тоже не плохо), которых однозначно хотят перейти на OSX и готовы инвестировать в это некоторые усилия.

Со второй вакансий все проще – разыскиваются Objective-C разработчики имеющие некоторое представление о C/C++ (нулевое знание плюсов не пойдет однозначно).

C++ разработчик (логика)

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

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

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

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

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

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

  • Отличное знание 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.

C++ разработчик (UI)

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

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

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

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

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

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

  • Отличное знание Objective-C, опыт разработки на C/C++;
  • Опыт создания GUI с использованием Cocoa, знание STL и BOOST;
  • Знание платформы Mac OS X;
  • Знание инструментальных средств разработки под Mac OS X;
  • Опыт работы с логами и крэш-дампами.

Желательно:

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

Писать можно мне на e-mail. Если не интересно самим, поделитесь с теми, кому может быть интересно. Заранее спасибо!