Прототипирование *

Одно время  на прогулках по блошиным рынкам я увлеченно высматривал винтажные музыкальные инструменты, особенно синтезаторы 70x-80x годов. Я нахожу их звуки очень красочными и разнообразными, а так же эти устройства интересны с точки зрения схемотехники.

И вот однажды по счастливой случайности и благодаря алгоритму поиска на основе AI на одном из самых популярных интернет-сервисов для купли-продажи подержанных вещей, который предложил мне объявление по моим интересам.

И это оказалась не «пиликалка» с пластиковым звуком и не кондовый электроорган, - а очень даже продвинутый для середины 80ых и актуальный по сей день аналоговый полифонический синтезатор с цифровым управлением, выпущенный компанией Roland.

После приобретения музыкальный инструмент не подавал ни каких признаков жизни кроме подсветки дисплея. Вскрытие и сверка со схемой из документации показали то, что хоть разработчики и использовали Poka Yoke для предотвращения неправильного подключения межплатных кабелей, но или не досмотрели или ассортимента не хватило и установили на главной плате два разъёма с одинаковым количеством контактов и невнимательный настройщик который обслуживал синтезатор перепутал местами те единственные два кабеля в которых можно было ошибиться. В таком вот состоянии инструмент мне и достался. Уcтранив ошибку сначала я очень обрадовался, - основные функции заработали, но к сожалению вышли из строя два входа микросхемы IC7 “Gate Array“, которая выполняет роль IO интерфейса для CPU, в частности для функций клавиатуры. Из Рис. 1 и Рис. 3-4 видно как происходит обработка нажатия клавиш.

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

Ванночку (грань, где плёнка натягивается на основание) нужно выполировывать и удалять слой краски, но самой важной частью будет выставление зазора между плёнкой и экраном. Оно должно быть 0.2-0.3 мм. Дело в том, что отрицательное давление при подъёме платформы (особенно на первых слоях) создаётся в промежутке между ними. И при малейшей течи в плёнке туда будет засасывать смолу (у меня подозрение что даже в виде аэрозоля), на фото видны микро следы от затянутого в щели полимера по краю защитной плёнки. Экран был в идеале, несколько капель на периферии ванны (там где натягивается плёнка) не могли такого сделать. Поэтому любители печатать максимально близко к экрану (без защитной плёнки) сильно рискуют, без каких-либо выгод. У меня платформа надавив на такие артефакты выбила несколько линий в экране.

Дискуссии об ИИ и больших языковых моделях (LLM) в разработке часто скатываются в бинарные споры: «замена», «выживание», «деградация». LLM — не против нас, а с нами. Не угроза, а помощь в рутине. Не замена, а инструмент. При умелом использовании ИИ освобождает от рутины и ускоряет реализацию, но не отменяет глубокое понимание предметной области. Без навыка писать код и ясности, что и зачем ты делаешь — ИИ бесполезен. Важнее понять, как LLM усиливают нас, трансформируют работу и рождают новые практики.

В мобильную разработку приходят различными путями. Некоторые рождаются с девайсом в руках, других ведет извилистая дорога вдоль серверов, майнфреймов, дестопных приложений. Но каждый кто в нее попадает ощущает свою незащищенность с тыла, если нет надежного партнера в лице бэкенд ‑разработчика. И, буквально, каждый мобильщик ожидает, что необходимый API будет готов хотя бы за один спринт, до того, как в нем возникнет необходимость. Конечно же, мир IT разработки редко допускает такую роскошь — за нее требуется бороться с ПМ и бизнес‑аналитиком. К тому же не редки ситуации, когда то, что должно быть сделано «на вчера», будет готово «на послезавтра». Те кто имеют достаточно опыта как в наземном, так и подземном мире — берут инициативу с свои руки, и сами предлагают клиент‑серверный интерфейс.

Для мобильного мира C# и Java — падения из рая в ад — это довольно естественный процесс, поскольку присущие им платформы изначально целились на поддержку темных сил бэкенда. То ли дело Swift — познавшему небо — не легко дается жизнь на льдине, вместе с ластоногими.

Получить лучшее из обоих миров, и не потерять темп позволяют некоторые экзотические решения, наподобие Perfect и Vapor. Однако, они в большей степени отвечают на вопрос «Как?» вместо того, чтоб предложить какое‑нибудь удовлетворительное минимальное решение. С другой стороны, как правило, исходные требования мобильной команды довольно умерены и стереотипны от одного приложения к другому. Обычно требуется поддержка и управления такими сущностями как аккаунт пользователя, профиль, продукт и изображения.

Хобби - это всегда сложно. Я постараюсь немного помочь, рассказав о том, с чем, и что у меня получилось и как можно немного облегчить и удешевить печать подняв её качество и удобство, снизить риски там где можно и цену там где нельзя) В общем поделюсь опытом и надеюсь с временем один из 3D принтеров совершив круг сделает мягкую посадку и займёт место в вашем доме и душе)

Важной частью работы дизайнеров является передача интерфейсов в руки фронтенд-разработчиков (mobile и web). Но, между творческим замыслом дизайнера и его воплощением в коде может возникнуть немало трудностей. 

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

Привет, Хабр!

const fn в Rust давно перестал быть просто инструментом для сложения чисел на этапе компиляции. Сегодня это мощный инструмент, который умеет циклы, условия, матчинг, парсинг и даже кусочки бизнес-логики — и всё это ещё до запуска программы.

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

Сделаем систему измерения среза помещения из независимой точки!

Мысль об этой статье началась давно с простой, на первый взгляд, фразы. Я услышал её на одной из конференций несколько лет назад от разработчика мобильных игр — человека, который явно знал своё дело. Он говорил о процессе создания новых проектов, когда уже на секции Q&A кто-то из зала спросил:

— «Как придумать идею для мобильной игры?»

Ответ прозвучал так просто, что я даже не сразу понял его глубину:

— «Возьми AAA-проект, уберите всё лишнее и оставьте только самое сладкое — то, что заставляет людей играть снова и снова.»

Эти слова тогда застряли у меня в голове. Они казались одновременно гениальными и пугающими. Гениальными потому, что в них была логика, которую невозможно отрицать: Успешные мобильные игры действительно часто строятся вокруг упрощённых версий механик из крупных проектов, так работает добрая половина мобильного рынка. Пугающими же потому, что они открывали мне некую тёмную сторону индустрии — ту, где творчество не имеет такого сильного значения и вовсе растворяется в процессе деконструкции. Где вместо создания чего‑то нового, уникального, мы занимаемся своего рода «каннибализмом», вырывая самые аппетитные кусочки из уже существующих игр и подавая их под соусом мобильной «доступности».

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

Привет, Хабр. Я Илья Сластен, продуктовый дизайнер интерактивной карты ПГК Диджитал. В своей предыдущей статье я рассмотрел ключевые аспекты работы с локальными переменными в Figma и подход Atomic Design. Сегодня предлагаю поговорить о минимализме в дизайне.

В мире, где цифровая реальность меняется стремительно, а каждый клик важен, создание успешных веб-сайтов и приложений становится задачей, от решения которой зависит многое. Говоря о самых успешных подходах, минимализм в дизайне выходит на передний план. Это не просто эстетический выбор, это философия, которая стремится к ясности, эффективности и функциональности. Как же принцип «меньше — значит больше» помогает нам создавать более удобные и интуитивно понятные интерфейсы? Давайте разберемся.

Удобный чайник можно определить через такие параметры:

1. Насколько он напрягает руку – какой крутящий момент (нагрузку) создаёт чайник, когда мы его держим на весу ровно и какую, когда наливаем (считаем "ход" такого движения 90 градусов, чтобы вылить полностью воду). У чайников с верхней ручкой (1 и 2) максимально расслаблена рука в первом положении, т.к. центр масс находится прямо под точкой хвата, и максимально напряжена во втором, при наклоне, т.к. центр масс чайника уходит из-под руки. Тем более, кисть должна вывернуться в несвойственное ей положение на запредельные углы под самой большой нагрузкой. У чайников с боковой ручкой (3 и 4) всё наоборот – максимум нагрузки в положении вертикальном и почти полное расслабление при наклоне. При этом рука движется в анатомически привычных углах. Высокая верхняя ручка (2) ещё больше увеличивает нагрузку при наклоне, т.к. эта высота переходит в рычаг нагрузки при наклоне чайника. И у чайников с высокой ручкой самые большие проблемы с углом поворота кисти при наливании. Оптимальной видится ручка, расположенная в середине пути, т.е. точка хвата расположена примерно на 45 градусах к центру масс чайника относительно горизонта.

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

Многие люди, кто не работает в сфере разработки электроники, представляют себе процесс разработки достаточно просто: разрабатываем схему, трассируем плату, пишем прошивку. А что еще надо?

В статье я опишу, как устроен типовой процесс разработки электроники на самом деле – на примере и с картинками (это может быть маленькая или большая компания, процесс плюс-минус схож). За пример мы возьмем некую материнскую плату компьютера (процессор в данном случае не принципиален) и разберем типовой процесс разработки такой материнской платы.

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

Код решения доступен:

* На Гитхабе

* На (временном) запасном аэродроме

* В виде картинки в самой статье.

О чем это, вкратце?

Мне давно хотелось написать систему, которая усиливала бы не споры, а их сходимость к ответу. В которой могли бы участвовать аргументы всех: человека, его гнуснейшего политического оппонента, и искусственного интеллекта со дна датацентра. В которой информация бы не цензурировалась прежде полного её провала улучшить хоть какое‑то предсказание. Систему, где решения вычисляет не имеющий личных интересов НИКТО. Которая могла бы распространяться просто в процессе работы, без опоры на какой‑либо центр.

Три года назад я очертил проблему и мысли по её решению в статье «цифровой вытрезвитель» на Хабре. Сегодня я выкладываю здесь прототип одного из возможных решений под Телеграм.

Прототип походовой радиусной тактики на движке Godot 3x, продвинувшийся от концепта до улучшающейся демоверсии. Передвижение персонажей, как и применение способностей, происходит не по клеткам, а в пределах определённого радиуса. Герои могут менять профессии - на данный момент это Странник, Волшебник, Сказочник или Рыцарь.

Несколько game-ready low-poly моделей, которые делал вручную с применением разделённой покраски: цвет и монохром отдельно. Используется Blender, без каких-то дополнительных штук.

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

Хотя я немного разочаровался в web-движке PlayCanvas, после того как его апгрейды поломали мне первый диаблоид - для каких-то очень маленьких легковесных игр он остаётся достаточно хорош. Поэтому для разнообразия реанимировал аккаунт и немного погрузился в программирование на js, написав аркаду (с механикой что-то вроде специфического урезанного BattleCity, но на сфере), где инопланетный космический кораблик летает над некоей планеткой.