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

Дискуссии об ИИ и больших языковых моделях (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, но на сфере), где инопланетный космический кораблик летает над некоей планеткой.

Два разных проекта на движке Godot. Первым был Tesserfact — попытка перенести урезанную часть механик из настольно‑ролевой тактической игры в игру компьютерную. Но в процессе, в силу принципиальной невозможности переноса всех аспектов, подумал переориентировать его в игровой стол (Монстробой: Тактика — второй проект), где игрок управляет всем мануально и может «эмулировать» любые, незакодированные, правила. Что из этого лучше — вопрос открытый, как и то, что обязательно ли компьютерные игры должны быть именно играми общераспространённого вида, где весь интерактив целиком автоматизирован.

Прототип adventure-rpg в мире маленьких планет, где игрок управляет разумным звездолётиком, который посещает различные планетки.