Спросили про цифры. Напомню, что в 2ГИС предлагали X. Здесь я запросил на 20-25% больше с учётом всех премий. Сумма не выглядела завышенной, потому что прошёл я на высокий грейд, и потому что чистый оклад X приводил в итоге к среднемесячному доходу ~1.17X, если разбить годовую премию по месяцам. Стал ждать преоффера, больше интервью в Т-Банк не было.

Что понравилось:
1. Классические энтерпрайзные секции, известно, как готовиться
2. Перед интервью всегда скидывали рекомендации по подготовке с книгами и видеороликами
3. После интервью была очень детальная обратная связь, тоже с рекомендациями литературы
4. Хорошо размялся на алгоритмической секции
5. На языковой секции в задаче на SQL можно было выполнять запросы и смотреть результаты, в отличие от Озона, где требовалось по памяти составить нужный запрос с первого раза

Что не понравилось:
1. Чисто менеджерская секция без вопросов по архитектуре почему-то названа архитектурной и засчитывается, как архитектурная
2. Идеальную языковую секцию засчитали на middle+ по неизвестной причине
3. Постоянные качели: то есть вакансии, то нет, то тимлид, то техлид, то не техлид
4. Даже очень хорошее прохождение секций ничего не значит, и работу можешь не получить
5. Тимлиды это менеджеры без технических задач, поэтому предлагать им могут должность мимо стека. Даже очень сильно мимо стека.

Что бы вы выбрали с учётом всех вводных? Представьте, что вам предложили в Т-Банке 1.2X-1.25X. Не хочу запускать опрос, так что ставьте реакцию ангела 😇, если бы выбрали 2ГИС, и демона 😈, если бы выбрали Т-Банк )

Финал #interview #dev

Собственно, да. Выбор не единогласный, но вполне очевидный, и вы это тоже показали голосованием. Я два дня прокручивал в голове варианты, спрашивал у друзей и родственников их мнение, и в итоге не стал дожидаться преоффера. Написал Т-Банку отказ, а 2ГИС согласие. Вот завтра уже выхожу, первый рабочий день. Так что, сколько денег бы предложили в Т-Банке, мы так и не узнаем. Спросили, могут ли вернуться через год, если что. Конечно, пообщаться я всегда за. Кстати, в 2ГИС много акцента делали на простую и понятную систему повышения дохода, и она как раз через год должна будет себя показать.

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

В чём заключалась подготовка:

1. DeepSeek. Очень круто объясняет. Ты прямо ему задаёшь вопросы, которые в книгах затронуты поверхностно. Можно задавать максимально стыдные вопросы. Например, вот один из моих вопросов:

Я:
— Что является узлами кучи, в которой хранятся ссылочные типы в C#? Куча это отсортированное дерево, но я не понимаю, что такого можно извлечь из ссылочных объектов, чтобы по этому сортировать. И зачем.

DeepSeek:
— Понимаю вас, но здесь есть путаница в именовании. Куча (Heap), как структура данных — это не то же самое, что Куча (Heap) , как область памяти в C#, Java и других языках. Они называются одинаково, но имеют разное устройство и поведение...
...

2. Книги. Целиком я ни одну не прочитал, но погрузился в:
• Крис Ричардсон, «Микросервисы». Собственно, это один из авторов идеи микросервисов, хорошо объясняет, как и зачем.
• Алекс Сюй, System Design. Это просто книга с шаблонными примерами для шаблонной же секции.
• Ганс-Юрген Шёниг, PostgreSQL. Описаны, пожалуй, все существующие функции и особенности СУБД, но без разъяснения. В целом я делал так: узнавал у Шёнига о существовании чего-то и шёл в дипсик уточнять.

3. Видео
• Мок-собеседования. Некоторые компании даже прям свои собесы выкладывают на ютуб, удобно.
• Доклады, в основном с DotNext. Кстати, я в программе на эту осень, приходите слушать :)

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

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

Вижу, что многие подписались в разгар историй о собеседованиях. Конечно же, эти истории не могли продолжаться вечно. Но, если вам нравится мой слог, предлагаю попробовать остаться и почитать два-три следующих поста. Если потом поймёте, что не заходит, и отпишетесь, я не обижусь.

Обычно на этом канале я рассказываю о гиковых хобби: фантастика, 3D-печать, DIY, настольные игры. Иногда высказываю своё восприятие айти-новостей и технологий. Вот для примера мой типичный обзор на фантастическую книгу, а вот электронное устройство.

И ещё я очень люблю организацию пространства, много этим занимаюсь, поэтому друзья в шутку прозвали такие посты «ОКР-контент», так что я добавил специальный тег #окр. Типичные примеры вот и вот. Stay tuned )

Раз всем так зашло, опубликовался на Хабре. Там, конечно, своя атмосфера, но по крайней мере делиться такой ссылкой проще, чем серией постов в Телеграме.

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

https://habr.com/ru/articles/926214/

История одного прикольного проекта.

Многие знают, что я постоянно вписываюсь во всякие конкурсы, соревнования, хакатоны и прочий движ. Так вот где-то с полгода назад было объявление от фонда поддержки инновационных проектов при участии Ростеха: присылайте, дескать, нам идеи для улучшения оборудования, а мы вам денег дадим. Список оборудования прилагался, и там было всякое: например, огнетушитель, насосная станция, рециркулятор и так далее.

Вот как можно улучшить огнетушитель? Особенно, если вы не профессиональный специалист по борьбе с огнём. Скорее всего, с точки зрения его способности тушить пожар вы ничего крутого не придумаете. Я бы не придумал. Но улучшить огнетушитель, тем не менее можно: достаточно решить какую-то из проблем, которые возникают при работе с ним. На поверхности проблема UX: если у вас нет практического опыта, то с первого раза вы можете запутаться и не суметь его правильно открыть. Так что я предложил на каждый огнетушитель клеить QR, который запускает на телефоне вебсайт с трёхмерной интерактивной моделью, на которой можно прямо пальцами по экрану вытянуть чеку выдавить стекло и нажать на рукоятку. Конечно, когда уже горит, то возиться в приложении как-то странно, но вот во всяких очередях и залах ожидания люди вполне могли бы сканировать от скуки огнетушители и играться с их запуском, попутно обучаясь.

Увы, эту идею совсем не оценили. А жаль, мне и сейчас она кажется неплохой.

Ещё в списке были газоанализаторы от одного российского предприятия. «Ага!» — подумал я, и описал в заявке историю, как мы с другом проходили практику на заводе высоковольтных выключателей Siemens. Выключатели наполнены элегазом, в котором размыкается дуга. Он бесцветный и без запаха, но человек в присутствии этого газа быстро теряет сознание. И я подумал: что если газоанализатор помимо уведомления непосредственного владельца будет ещё и передавать телеметрию на какой-то центральный сервер?

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

Дальше несколько месяцев я в перерывах между основной работой кодил на C# + Vue (TypeScript) фулстек-приложение. В качестве БД по условиям нужно было что-то локальное и с шифрованием, так что я взял SQLCipher. Библиотеки для UI, графиков. Отдельный модуль для чтения данных через ModbusRTU. Конфигурации для регистров, отдельная программа для создания сборок разным заказчикам. Завёл в программу систему триггеров, чтобы при разных условиях можно было дёргать вебхуки и/или менять статусы устройств. Ну, например, если концентрация с датчика N уже пять минут превышает некоторый порог, то сигналим тревогу. Или если устройство M не в сети полчаса. И так далее. Поначалу сделал очень гиково: интерпретатор выражений с переменными. Можно было ввести в параметры триггера что-то типа {КАНАЛ1.КОНЦЕНТРАЦИЯ} + 5 > {КАНАЛ1.ПОРОГ1}.

Приехал показывать. Думал: ну всё, сейчас расскажу им про все функции, задам вопросы для доработок. Собрали внезапно целый конференц-зал в присутствии большого начальника. Но оказалось, что 80% присутствующих абсолютно ничего не знали об этом проекте (завод очень большой, в нём много отделений, я взаимодействовал с небольшой группой интересантов). Через пятнадцать минут как раз на рассказе про язык выражений большое начальство прервало меня с вопросом о том, что это вообще такое, и что конкретно я пытаюсь продемонстрировать. Я безуспешно пытался что-то промямлить о ТЗ и о том, что это вообще-то их заказ, и вроде как им должно быть интересно, что я в итоге сделал, как оно работает, и вообще выполняет ли поставленную задачу.

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

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

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

#dev #gadgets

Тут незаметно подъехала свежая статистика по разработчикам от Stackoverflow. Каждый год я думаю о том, что надо бы принять участие в опросе, и каждый год пропускаю его. Судя по всему, его не рекламируют по почте, не присылают никаких уведомлений, не продвигают. В итоге мы получаем абсурдную картину, когда в статистике по странам разработчики из России представлены на одном уровне с Нигерией. Хотя понятно, что айти сектор в России очень развит и влияет на глобальные процессы (взять тот же Kotlin).

Так что, на эту статистику стоит смотреть, как на данные по США и чуть-чуть Германии. Ещё довольно высоко стоит Индия, но мы-то знаем :)

Ладно. Принципиально нового по сравнению с предыдущими годами почти нет. Три года назад я делал анализ графиков, чтобы дать ответ на вопрос: «Какой язык программирования учить?». С тех пор общие тренды остались плюс-минус такими же: вся [американская] разработка до сих пор сидит на Винде и пишет на JavaScript, потому что нет выхода, много использует проприетарщины и коммерческих облаков от монополистов.

В статистике Web-фреймворков React вдвое популярнее у разработчиков, чем jQuery, хотя, вроде как, 73% сайтов до сих пор на jQuery. Вывод понятен: значительная часть этих сайтов в сети не поддерживается, никакой активной разработки по ним нет. Это, кстати, важная причина, по которой не стоит использовать аргументы вроде: «На PHP до сих пор весь интернет, поэтому язык востребован».

Стоит отметить, что среди профессионалов наконец C# стал самым популярным языком с нормальной системой типов, если не считать TypeScript. Позиции Java уверенно падают который год. А ASPNET Core самый популярный Web-фреймворк с нормальной системой типов (но так было и раньше, даже три года назад).

Остальное ожидаемо: PostgreSQL, Docker, VS Code в топах по использованию.

Ну, и большая секция про ИИ. Почти все используют LLM, но почти все просто общаются в чатах, а не применяют какой-нибудь агентный режим. 66% опрошенных сказали, что в ИИ их фрустрирует приближенность ответа к правильному, но всё-таки не до конца («AI solutions that are almost right, but not quite»). И почти половина отмечает, что дебаг нейросетевого кода отнимает больше времени. Хотя тут, мне кажется, эффект в том, что дольше дебажить код, который писал не ты, и не важно, ИИ там или другой разработчик.

Я кстати и сам после первых восторгов от Cursor немного поубавил свой пыл: реально большой проект на C# он не умеет правильно читать и понимает происходящее там довольно посредственно. DeepSeek, ChatGPT, Claude Sonnet — за всеми нужно внимательно следить и править их ошибки, ловить галлюцинации, не позволять творить дичь. Я бы сказал, что в моей рабочей практике ИИ это просто очень быстрый поиск и агрегация материала по тому, как что-то сделать. Но делать нужно самому.

#dev

Программисты пока могут не бояться ИИ.

В Росатоме работать с ИИ-агентами было нельзя, а вот тут в 2ГИС это даже поощряется, и компания сама оплачивает нужные доступы и лицензии. Практически любые модели на выбор, чаты, Copilot и так далее. Поэтому я попробовал выполнять прям настоящую энтерпрайзную работу при поддержке ИИ, и вот что скажу.

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

И тут начинаются проблемы.

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

Во-вторых, и это более важно, мы используем свои человеческие навыки и опыт жизни в окружающем мире, чтобы правильно понимать предметную область. Нужно именно что пожить в мире, чтобы понимать, как пить из пресловутого перевёрнутого стакана. И пока моделькам не получается передать всё многообразие человеческого опыта, люди в относительной безопасности. Ну, кроме тех, чья работа это просто кодить без обдумывания.

#dev

Тут неистово завирусился мой твит с жалобой на современные ущербные UX-практики на примере Яндекса, и в процессе срача в комментах я, наконец, смог сформулировать своё главное требование к "нормальным" интерфейсам: интерфейс никогда не должен брать инициативу на себя. Абсолютно никогда. Не существует вообще таких случаев, когда это было бы допустимо.

Как познакомить пользователя с новыми фичами в приложении или на сайте? Нет, не модалками при запуске, как это делают, например, Яндекс и Discord, потому что модалки вылезают по инициативе самого приложения мешают, блин, им пользоваться, требуя прервать поток мыслей и подумать отдельно, как бы это убрать побыстрее, чтобы вернуться к тому, что ты хотел сделать. И даже не тултипы или поповеры, как любит делать гугл, потому что они тоже вылезают по инициативе самого приложения, и тоже часто закрывают нужные тебе элементы.

Самый оптимальный способ — интегрировать информирование об обновлениях в UX самого приложения. Например, собственно, телеграм так делает — после обновления клиента тебе приходит системное сообщение с описанием новых фич. И сторисы ещё. В соцсети это может быть плашка в ленте (прокручиваемая вместе с лентой) или уведомление (но ни в коем случае не пуш). ВК при Дурове знакомил пользователей с новыми фичами через маленькие плашки под левым меню со ссылками на страницы с подробным описанием изменений, тоже очень хорошо. Я такое даже в Smithereen сделал вот недавно.

Адекватный способ, если интегрировать в UX невозможно или сложно — показывать красную точку на иконке настроек, а в настройках сделать отдельный пункт "новые возможности" или "история обновлений", на котором показывать что-нибудь привлекающее внимание после обновлений. Внутри, соответственно, либо список фич по времени добавления, либо просто чейнджлоги, те же, что во всяких там гугл плеях.

Пора бы мне, всё-таки, добавить себе в резюме, что я не только программист, а ещё и специалист по user experience :)

Друг делал уборку у себя и обнаружил мою книжку. Двадцать лет у него хранилась. Именно с неё де-факто началось моё изучение программирования. Первые две части про то, как во флэше рисовать, а вот третья — о программировании на ActionScript 2 (тогда ещё), причем очень подробно, с самых основ.

До сих пор считаю убийство Флэша одним из наиболее деструктивных и вредных для человечества действий компании Apple.

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

Еще в комплекте с Флэшем был набор демок, и, запуская каждую из них, я думал "Хочу уметь так делать!". Одна из мечт, которые сбылись полностью.

#dev

Ровно три года назад в этот день я сделал тотально неверное предсказание относительно развития рынка гаджетов. Я тогда написал, что складные экраны — это Next Big Thing — и мы все будем ходить с ними уже совсем скоро. Потом я купил складной Huawei Mate Xs2, и проходив с ним чуть больше года, вернулся на обычный форм-фактор.

Вот мы в 2025, складные смартфоны всё ещё нишевые игрушки, а предсказание не просто не сбылось, но даже динамики в эту сторону не видно. Моя мысль была такая: на смартфонах неудобно выполнять ряд повседневных задач (например, набирать длинные тексты), неудобно делать рабочие манипуляции с документами, писать код, монтировать видео, верстать, моделировать в 3D и так далее. И для всего этого не хватает только удобного ввода/вывода, потому что и мощности железа и потенциальных возможностей софта давно уже достаточно. Складные экраны должны были стать первым шагом к появлению более удобного вывода (а про ввод было непонятно).

Но вместо улучшения UX для работы рынок продолжил уверенное движение в сторону entertainment-возможностей. Нужно отредактировать таблицу? Пошёл нахер, открывай ноутбук. Монтаж видео на смартфоне? Ты, должно быть, долбанулся. Писать код? Ха-ха-ха. Даже проблему с написанием текстов решили элегантно: подсадили народ на вертикальные видео и сторисы. В этом отношении очень забавно видеть тех, кто скринит в сторисы свои заметки, чтобы типа таким образом вести текстовый блог. Вот только при чтении нужно или держать экран пальцем (чтобы сторис не перелистнулась), или пропускать половину. Рынок и массовый потребитель недвусмысленно даёт понять, что акцент совсем на другие форматы.

В итоге даже чтобы вырезать из картинки кусочек и состыковать два оставшихся, мне нужен компьютер с клавиатурой и мышью. И, по-видимому, этот тренд с нами надолго. Да, мы уже видели случаи, когда из-за инерции какой-то подход становится мейнстримом, хотя он в основе своей неверный (например, превращение HTML+JS в средство написания полноценных программ), и за этим следуют десятилетия костылей, компромиссов и Стокгольмского синдрома.

Буду надеяться, что AR-очки, эмулирующие монитор, станут следующей попыткой достичь перемен. Сейчас вроде как эта область активно развивается, и следующее поколение таких устройств уже можно будет покупать и использовать.

#gadgets

Мне нравится, как эволюционирует мульти-материальная 3D-печать.

Самый обычный 3D принтер подаёт через разогретое сопло пруток с пластиком и с помощью перемещения сопла наносит этот пластик слой за слоем на стол, чтобы получилась деталь. В какой-то момент стало интересно попробовать печатать более чем одним материалом в рамках одной детали. Например, чтобы моделька получилась разноцветная, но не только. Можно печатать пластиками с разными физическими свойствами: поддержки, которые растворяются в воде, вставки из более мягкого или более твёрдого пластика и так далее.

И рынок стал пробовать кучу принципиально разных подходов. Что, если сделать два сопла на одной печатной голове? Попробовали, но неактивное сопло задевало за деталь, да и больше двух уже проблематично. Помните, может, авторучку с несколькими цветами? У меня была даже в детстве ручка с десятью (!) цветами, крутейшая вещь для школьника того времени, правда неудобная жутко.

Окей, а если две печатающие головы на одной рельсе? Появилась система IDEX (independent dual extrusion), и неплохо себя показала: например, печатать два зеркальных объекта можно с той же скоростью, что и один. Но, опять же, больше двух уже не сделаешь, а рельса становится слишком тяжёлой.

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

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

И вот мы пришли к сменным печатным головам целиком. Всё по заветам ТРИЗ: один принтер печатает одним цветом, а что печатает двумя цветами? Два принтера. Давайте думать, как сделать два принтера в одном. Да, вообще ЧПУ-станки со сменными инструментами уже не новость, но, насколько я помню, в основном там меняется фреза. Часто ли встречаются станки, меняющие, скажем, весь шпиндель целиком?

В общем, тут у Цифровой Фабрики вышла первая серия обзоров на модификацию Voron с таким принципом. Я уже глянул, стоит в сборке 400к, что вполне ожидаемо (и даже я бы сказал дешевле ожиданий) для такого аппарата. Посмотрим, куда эта тема отправится в будущем. #gadgets

https://vkvideo.ru/video-226299087_456239121

Вот такой ляп в четвёртой серии «Чужой: Земля». Персонаж, который должен быть супер гением, цитирует третий закон Артура Кларка, но почему-то приписывает его Азимову. Вроде бы никакие сюжетные особенности не должны в этом месте допускать именно ошибку персонажа. Я даже переключился на оригинал, чтобы убедиться, что это не косяк переводчика.

Тогда что это? Ошибка сценариста, которую прозевал режиссёр, монтажёр, звукач и сам актёр? Причём, это же не какое-то нишевое знание. Законы Кларка вообще попса в кинофантастике, особенно третий, его очень любят в Голливуде, даже в каких-то Трансформерах был. #fiction

Trigger warning: скрепы.

TL;DR: Я сделал механическую игрушку на российский конкурс, и это была очень сложная инженерная задача.

Несколько месяцев назад Российское Общество «Знание» объявило конкурс «Родная Игрушка»: нужно было отправить идею какой-нибудь куклы, модельки, конструктора, настолки итд, которая впоследствии может производиться в России и обладать соответствующим культурным или научным колоритом. Было подано что-то около 22 тысяч идей, я отправил две. В следующий тур вышло несколько сотен, в том числе внезапно одна из моих — заводная подводная лодка, которая плывет не вперед, как существующие заводные игрушки для ванны, а прям погружается и всплывает. Связал я это не с военными подлодками, а с научными глубоководными аппаратами, по которым у России несколько мировых рекордов. Вы знали, например, что Кэмерон брал наши глубоководные «Мир-1/2» для съемок Титаника? А еще они первыми достигли дна Северного Ледовитого Океана.

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

Моделирование отсекло ещё значимый процент участников, где-то 70-80 человек в пяти категориях вышли на этап создания прототипа. И вот тут я скажу вам, сложно передать, сколько хитрых инженерных задач пришлось решить по пути. Проект оказался одним из самых сложных (и одним из самых интересных) в моей практике. Вообще, айтишнику полезно поработать с материальным миром, изобилующим погрешностями и допущениями.

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

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

#gadgets #diy #hobby