Спойлер: C++ не быстрее и не медленнее и вообще смысл не в этом. Эта статья является продолжением славных традиций развенчания мифов крупных российских компаний о языке Rust. Предыдущая была "Go быстрее Rust, Mail.Ru Group сделала замеры".

Недавно я пытался заманить коллегу, сишника из соседнего отдела, на Тёмную сторону Rust. Но мой разговор с коллегой не задался. Потому что, цитата:

В 2019 году я был на конференции C++ CoreHard, слушал доклад Антона antoshkka Полухина о незаменимом C++. По словам Антона, Rust еще молодой, не очень быстрый и вообще не такой безопасный.

Антон Полухин является представителем России в ISO на международных заседаниях рабочей группы по стандартизации C++, автором нескольких принятых предложений к стандарту языка C++. Антон действительно крутой и авторитетный человек в вопросах по C++. Но доклад содержит несколько серьёзных фактических ошибок в отношении Rust. Давайте их разберём.

*FAANG — акроним 5 крупнейших tech компаний (Facebook, Apple, Amazon, Netflix and Google), предоставляющих одни из самых хороших возможностей для разработчиков, которые мечтают/планируют/хотят приобщиться к волне IT-эмиграции.

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

К сожалению, на практике подобный процесс поиска работы часто заканчивается неудачами. Сайты со списком вакансий — один из самых низкоэффективных способов, по крайней мере в США.

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

Некоторые относятся к спору о выборе первого языка программирования примерно так:



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

Виталий Брагилевский решил поставить точку и на Saint AppsConf представил окончательное решение. После прочтения статьи (или просмотра доклада) вы будете знать, как правильно отвечать родственникам или знакомым, которые узнали, сколько зарабатывают в IT и что удалёнка тут не помеха, и теперь интересуются, с чего же начать.

Об исследовании

Введение

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


Возможно, по причине относительной малочисленности этой группы специалистов, ни специфика их опыта переобучения, ни особенности трудоустройства и найма, до сих пор не являлись предметом содержательного обсуждения или исследования. Однако, отсутствие явного интереса к про-джуниорам трудней объяснить, как только мы переходим от относительных величин к абсолютным: даже 0.2% от 24 млн — это почти половина от общего количества разработчиков в Чехии, а 2% или 480 тысяч девелоперов — это уже значительно больше количества разработчиков в России.

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

Дисклеймер:

Я не программирую с трёх лет, не знаю наизусть Кнута, не являюсь призёром олимпиад по информатике и чемпионатов по спортивному программированию, не училась в MIT. У меня за плечами образование по информатике и 6 лет опыта в коммерческой разработке. И до недавнего времени я не могла пройти дальше первого технического скрининга в IT-гиганты из FAANG (Facebook, Amazon, Apple, Netflix, Google и подобные), хотя предпринимала несколько попыток. 

Но теперь всё изменилось, я получила несколько офферов и хочу поделиться опытом, как можно к этому прийти. Речь пойдёт о позиции Software Engineer в европейских офисах перечисленных компаний.

После моей первой публикации прошло два месяца. После него я немного сменил приоритет на одну задачу. А именно — реализацию дебаггера, хотя бы для Mono .NET.

Решил разобраться с новой возможностью С++20 — концептами.

Концепты (или концепции, как пишет русскоязычная Вики) — очень интересная и полезная фича, которой давно не хватало.

По сути это типизация для аргументов шаблонов.

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

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

Скажу честно, я немножко в шоке:) С++ и без того сложный язык, но тут хотя бы есть оправдание: так получилось. Метапрограммирование на шаблонах именно открыли, а не заложили при проектировании языка. А дальше, при разработке следующих версий языка, были вынуждены подстраиваться под это «открытие», так как в мире было написано очень много кода. Концепты же — принципиально новая возможность. И, как мне кажется, в их реализации уже присутствует некоторая непрозрачность. Возможно, это следствие необходимости учесть огромный объем унаследованных возможностей? Попробуем разобраться…

В прошлый раз мы оставили сцену Xbox 360 на моменте, когда разработчикам стало очевидно, что защита DVD-ROM легко обходится, и с этим точно нужно что-то делать. Попытки исправить ситуацию обновлением ПО самой приставки не увенчались успехом, и на поле битвы вступила компания Philips & Lite-On, DVD-приводы которой с каждой новой моделью становились всё более продвинутыми в плане защиты. Но и методы взлома с каждым разом становились всё более и более изощрёнными. В этой части я расскажу, как в Microsoft пытались исправить ситуацию с нелицензионными дисками, и до каких методов прошивки DVD-привода можно докатиться, когда закрыто буквально всё.

Очень часто при цифровой обработке сигналов необходимо вычислить длину вектора, обычно это делается по формуле A=SQRТ(X^2+Y^2). Здесь возвести в квадрат значение не сложно, но операция вычисления квадратного корня не является простой операцией, особенно для микроконтроллеров. Кроме того, алгоритмы вычисления корня выполняются не стабильное время, и для алгоритмов, в которых таких вычислений много, становится сложно прогнозировать время, необходимое для вычислений.

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

В продолжение темы разберемся в протокольных типах и обобщенном (generic) коде.

По ходу будут рассмотрены следующие вопросы:

• реализация полиморфизма без наследования и ссылочных типов
• как объекты протокольных типов хранятся и используются
• как с ними работает отправка метода

Завкафедрой системного программирования Матмеха СПбГУ, профессор, доктор физмат наук, президент компании «Ланит-Терком» Андрей Николаевич Терехов — о том, как делал первый в СССР транслятор языков Алгол 68 и Ада, о силе обкома КПСС и рождении «Самсона», который никогда не ломался.

Вторая часть интервью с завкафедрой системного программирования Матмеха СПбГУ, доктором физмат наук, профессором, президентом компании «Ланит-Терком». Андрей Николаевич Терехов рассказал о создании кафедры матобеспечения ЭВМ и своих многочисленных учениках, языке PADLA, работе ассенизатора и технике бега в мешках.

Доктор технических наук, профессор Юрий Рябцев — выпускник МФТИ, многолетний сотрудник ИТМиВТ и ИНЭУМ. В 1976 году он стал лауреатом государственной премии за разработку вычислительного комплекса для С-300, в 1986-м — лауреатом Ленинской премии за разработку «Эльбруса-2». В интервью из нашей исторической серии Юрий Степанович рассказывает, как готовили инженеров для передовых оборонных программ, объясняет, как в СССР взаимодействовали институты и целые отрасли, делится мнением о крупных советских проектах в области ИТ.

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

Сейчас Юрию Васильевичу 94 года, но он прекрасно помнит, как в начале 1950-х создавалась М-1 — первая в мире цифровая вычислительная машина, в которой логические схемы строились на полупроводниковых элементах. В интервью музейному проекту DataArt Рогачев рассказал о разработке ее элементной базы и арифметического узла. Но началась эта история раньше, когда Юрий Васильевич служил в армии.

Профессор Николай Прохоров больше 20 лет возглавлял Институт электронных управляющих машин, с 1984 года был генеральным конструктором СМ ЭВМ. В первой части интервью музейному проекту DataArt Николай Леонидович вспоминает учебу в МЭИ, работу в ИПУ РАН и ИНЭУМ, машины, способные управлять АЭС или универмагом, встречи с Норбертом Винером, Исааком Бруком, Баширом Рамеевым.

Начало

— Я родился в 1936 году, учился в железнодорожной школе под Москвой, занимался в кружке при детской железной дороге, был стрелочником, начальником смены и машинистом. У меня есть права машиниста паровоза на узкоколейных дорогах. В 1953-м поступил в Московский энергетический институт, тогда — имени Молотова. Считаю, что мне очень повезло — по составу преподавателей вуз был выдающимся. Кроме того, в МЭИ кипела спортивная и общественная жизнь.


Детская железная дорога в Подмосковье была заложена в 1936 году. Еще раньше похожие проекты запустили в Тифлисе, Днепропетровске и Гомеле

Получив специальность инженера-электрика, я распределился в Институт автоматики и телемеханики Академии наук — теперь он называется Институтом проблем управления РАН.

Во второй части интервью с авторами бестселлера «Энциклопедия профессора Фортрана» музейному проекту DataArt — о тех, кто помогал, о встрече с писателем Успенским, сотрудничестве с издательством «Просвещение» и особенностях бизнеса в 1990-х.

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

Именно такие претензии я услышал от наших девелоперов. Самое интересное, что это оказалось правдой, дав начало длительному расследованию. Речь пойдет про SQL servers, которые крутятся у нас на VMware.

Автор: Вячеслав Михайлов

Монолитные приложения и их проблемы

Все прекрасно знают, что такое монолитное приложение: все мы делали такие двух- или трехслойные приложения с классической архитектурой:

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

Так или иначе, по мере роста и развития приложения, вы сталкиваетесь с проблемами монолитных архитектур:

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

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