Влетайте в майнинг! Это безумно прибыльно! А еще безопасно: если крипта упадет то у вас хотя бы останется оборудование, вещали из Ютюб каналов.

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

Последние годы часто хвалят язык программирования Rust. Однако, без изучения синтаксиса и особенностей языка в нём сложно разобраться. Честно говоря, при первом просмотре дальше простых примеров я продвинуться не смог. Вроде догадываешься, что тут указываем тип переменных, амперсанд – это вроде “я только посмотреть”, но всё равно код складывался в некую мешанину иероглифов с кучей скобок и, на первый взгляд, случайно проставленных точек с запятыми. То ли дело Python, минимализм синтаксиса которого так привлекателен для неокрепших душ. Однако, так ли сложен Rust на самом деле или это миф? 

Я предположил, что те базовые знания по программированию, которые предлагают распространенные курсы можно дать и с помощью Rust.

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

Для упрощения я буду горутины в Go и асинхронные задачи в Rust называть корутинами. Для проверки различные тесты запускались на количестве корутин 10¹, 10², ..., 10⁶. Смысл тестирования заключается в том, чтобы определить, какой из языков решит задачу наиболее быстро. По затраченному времени на выполнение задачи можно судить не только о скорости работы языка, но и том, насколько он страдает от большого количества конкуретных задач. Также в каждом тесте записывалась потребляемая память.

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

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

Рассчитываю на новичков, но если у вас есть интересный опыт в этих вопросах - добро пожаловать в комментарии.

• Что будет, если создать круговую цепочку прототипов? И прочие сведения случайного характера.
• Как мигрировать с webpack 3 на webpack 5? И прочие частности.
• В чем разница между числом и массивом? И прочие вопросы, затуманенные расплывчатыми формулировками.
• Как быстрее всего перевести строку в число? И прочие вопросы, не дающие достаточно информации о поведении.
• Как сделать этот фрагмент кода лучше? И прочие вопросы, предлагаемые вне контекста.

Технология 3D-печати зародилась еще в 80-х годах 20-го века, а вот строительная 3D-печать появилась гораздо позже.  Первые строительные проекты с использованием этой технологии появились только в 2014 году. Речь идет, прежде всего, о так называемых малых архитектурных формах (скамейки, клумбы, заборы). О постройке домов еще и не мечтали. Но уже в 2015 году российский стартап Apis Cor произвел фурор - напечатал целый дом в Подмосковье. С тех пор периодически появляются новости о новых 3D-печатных домах. Однако несмотря на то, что технология показала себя очень перспективной с точки зрения скорости возведения жилья и снижения стоимости строительства, никакого массового внедрения не последовало.

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

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

В 2006 году Яндекс и Google приехали в Петербург в Borland, который сокращал команду. Обе компании одновременно открывали в Петербурге свои офисы на его базе. Тогда к нам пришли замечательные ребята. Мы много общались, но больше всего запомнились слова Толи Орлова. Он сказал, что рост Яндекса на тот момент ограничивает только количество лидов, которые бы могли развивать продукты. Что роли техлида и тимлида очень существенны, и часто рост компании зависит только от наличия сильных лидеров. Тогда мне и захотелось узнать, как им стать.

Меня зовут Владимир Горовой. Я был тимлидом, потом перешёл в менеджмент, руководил созданием разных сервисов, в том числе, Яндекс.Путешествий. Сейчас работаю в Яндекс.Вертикалях. У меня есть разный опыт: менеджерский, разработческий и тимлидский. Всем этим и хочу с вами поделиться.

В статье Наблюдение за выполнением конкурирующих задач в Go и Rust коллега cpmonster привёл весьма интересные результаты:

Программа на Rust показала намного большую производительность при вычислении членов возвратной последовательности, чем программа на Go: 367 млн. итераций в секунду против 44 млн.

Ну, в 1.5 раза… Ну, в 2 раза… Но семь гвардейцев за два дня? — это слишком, тем более что тут "гвардейцев" больше восьми!

Или нет, не слишком? В общем, потенциал любопытства пересилил другие потенциалы и я провёл своё исследование.

Под катом вас ждёт чертёж установки, блок-схемы агента, работающего методом проб и ошибок, а также визуализации, видеоролики и, конечно, код. Материалом делимся к старту нашего флагманского курса по Data Science.

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

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

Я берусь доказать, что основной тезис ошибочен. В РФ нет дефицита кадров. 

В мире, казалось бы, победившего переменного тока назревает — нет, не революция, но органичная эволюция: постоянный ток не просто возвращается, а претендует на лавры победителя. Инвестиции в возобновляемые источники энергии и трансграничная передача электричества сделали высоковольтные сети постоянного тока как никогда актуальными. В этом посте мы рассказываем, почему постоянный ток уступил току переменному и как спустя век после «Войны токов» постоянный ток взял реванш.

Давным-давно, в одном далеком-далеком 2015 году…, в индустрии ноутбуков доминировала львиная доля решений на базе чипов Intel, тогда как мобильные устройства с процессорами AMD занимали всего 16% рынка. Прошло пять лет…, и ситуация в корне изменилась. Теперь мы можем уверенно говорить о том, что «красные» не просто догнали «синих» по количеству продаж, но и составили им серьезную конкуренцию с перспективой на полноценный переворот.

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

Джорджо де Кирико. Великий метафизик (The Grand Metaphysician), 1917.

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

1) CS — создание подходов, имеющих научную новизну. Разработка новых алгоритмов. Основная цель: научная новизна, развитие CS, решение проблем CS.

2) Инженерно-конструкторская деятельность – комбинирование уже известных подходов (алгоритмов, ЯП, библиотек, технологий, исходных кодов), их адаптация под конкретную задачу. Основная цель: создание продукта для решения конкретной практической задачи.

3) Техническое обеспечение — решение типовых (зачастую тривиальных) проблем в ходе эксплуатации “железа” и софта. Обеспечение бесперебойной работы ПО и оборудования с учетом возникающих требований.

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

Как видим цели противоположные: для научной новизны бывают нужны новые рискованные решения, а для обеспечения – наоборот. Для успешной разработки продукта, желательно применять уже опробованные зарекомендовавшие себя решения, хотя при их отсутствии может понадобится и эксперимент, как в CS.

Кому и насколько в IT нужна математика? — Попробуем ответить на этот вопрос (хотя бы частично).

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

Planetoid (2015-2016 годы)

Пока все кому не лень пишут статьи о том, как войти в айти, некоторые из нас нет-нет, да задумываются, а не выйти ли оттуда. Ночные релизы, бесконечные переработки, легаси код, невнятные баги, грубые разговоры в курилках и в коридорах, постоянные требования от менее технически подкованных коллег, иногда целые блоки кода, а то и сборки, отправленные в корзину… Выгорание? Жажда новой жизни? А вдруг там, за дверью серверной или опенспейса R&D, всё по-другому? 

Начну с анекдота: «Июнь. Рассвет. По набережной идут два отметивших защиту диплома студента политеха. Весёлые, пьяные. Один из них радостно кричит:
— Ура, мы дипломированные инженеры!
Вдруг его друг садится на корточки и начинает плакать. 
— Ты чего?
— Я подумал, что сегодня выпустились два таких же дипломированных врача».

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

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