Представляем вам перевод статьи Sm0ke, опубликованной на сайте dev.to. Автор рассказывает о своем опыте генерации веб-приложений и способе автоматизации процесса их создания.

Привет, кодеры!

Я — разработчик-фрилансер, и я сгенерировал более 100 приложений на различных языках и платформах, используя инструменты автоматизации, парсинг HTML и бойлерплейт-код.

Все мои приложения, как платные, так и бесплатные, находятся в открытом хранилище GitHub. О некоторых из них я расскажу в этой статье.

#1  Сгенерированные JAMstack-приложения

Всего я создал более 40 таких приложений. Дизайн для них разрабатывали известные веб-агентства.

Часто в процессе реализации проектов команды сталкиваются с вопросом: чему следует уделять больше внимания – выпуску новых фич или повышению качества кода? Обычно менеджеры делают выбор в пользу фич. Зачастую разработчики таким положением дел недовольны, считая, что им выделяется недостаточно времени для работы над архитектурой и качеством кода.

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

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

На этой неделе я начал работать над новой темой: генерацией подземелий и пещер. Я использовал разбиение пространства для генерации комнат, алгоритмы генерации лабиринтов для генерации коридоров и клеточные автоматы для придания пещерам более естествненного внешнего вида.

Разбиение пространства

Существует множество способов генерации комнат для подземелья (случайное размещение, генерация на основе агентов, с использованием separation steering behavior или физического движка, и т.д.). Но мой любимый метод — это разбиение пространства, потому что оно легко контролируется и расширяется.

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

Единственная сложность этого алгоритма — выбор позиции разделения. Если мы не наложим ограничение на позицию разделения, то будем получать странные разбиения пространства:


Такого поведения можно избежать несколькими способами. Один из них — ограничить позицию разделения двумя соотношениями длин сторон, например, в интервале от 30% до 70% или от 40% до 60%. Другой способ — использовать вместо равномерного распределения нормальное или биномиальное, благодаря этому повысится вероятность разделения по центру стороны, а не по краям. Эти способы устраняют проблему, но сложно понять, как конкретно параметры влияют на окончательный результат.

Публикую на Хабр оригинал статьи, перевод которой размещен в блоге Codingsight.
Вторая часть доступна здесь

Необходимость делать что-то асинхронно, не дожидаясь результат здесь и сейчас, или разделять большую работу между несколькими выполняющими ее единицами была и до появления компьютеров. С их появлением такая необходимость стала очень ощутимой. Сейчас, в 2019, набирая эту статью на ноутбуке с 8 ядерным процессором Intel Core, на котором параллельно этому работает не одна сотня процессов, а потоков и того больше. Рядом, лежит уже немного потрепанный, купленный пару лет назад телефон, у него на борту 8 ядерный процессор. На тематических ресурсах полно статей и видео, где их авторы восхищаются флагманскими смартфонами этого года куда ставят 16ти-ядерные процессоры. MS Azure предоставляет менее чем за 20$/час виртуальную машину со 128 ядерным процессором и 2 TB RAM. К сожалению невозможно извлечь максимум и обуздать эту мощь не умея управлять взаимодействием потоков.

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

Как законодатели мод по теме Unity на российском рынке предлагаем вам почитать интересное исследование о практическом использовании алгоритма WFC (Wave Function Collapse), построенного по образу и подобию известного принципа квантовой механики и очень удобного при процедурной генерации уровней в играх. Ранее на Хабре уже публиковался подробный рассказ об этом алгоритме. Автор сегодняшней статьи Мариан Кляйнеберг рассматривает алгоритм в контексте трехмерной графики и генерации бесконечного города. Приятного чтения!

Основатель digital-агентства Роман Квартальнов делится простым решением, которое помогло сделать производственные процессы прозрачными, дало возможность в любой момент времени оценить себестоимость проекта и компании целиком, а также экономить около 1 000 000 рублей на сборе отчетов с сотрудников.

Знаете ли вы себестоимость работы вашей компании? Можете за 3 минуты получить доступ к информации о выполненной работе за вчера? А за неделю?

Четыре года назад я открыл свою компанию. На старте у нас была небольшая команда. Очевидно, что чем меньше людей, тем лучше у них получается работать слаженно, быть единым организмом. К концу первого года мы начали активно масштабироваться и столкнулись с проблемами роста. В определенный момент мы просто потеряли контроль над процессами внутри компании и начали принимать решения хаотично. Есть такой термин – «хаотичное управление», его можно трактовать так: руководитель не имеет возможности прогнозировать риски, постоянно тушит пожары и не разбирается почему они происходят. У такого подхода есть 2 пути развития:

1. Признать, что такова жизнь и основателю бизнеса отведена роль пожарного. В этом случае ваш потолок – крутой пожарный, пожарный-супермен.

2. Осознать, что пожаротушение развивается спиралевидно, т.е. время идет, задачи растут, ресурсы уменьшаются. В этом случае ваша цель — поднапрячься и выйти за рамки, встать над проблемами и постараться найти системные решения.

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



Под катом вы найдете процесс создания proof-of-concept бота для игры Clash Royale, в котором я использовал Scala, Python и CV-библиотеки. Используя компьютерное зрение и машинное обучение я попытался создать бота для игры, который взаимодействует как живой игрок.

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

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

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

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

Прим. перев.: На днях в блоге для инженеров любимого нами проекта GitLab появилась небольшая, но весьма полезная заметка с инструкциями, которые помогают сохранить время и нервы в случае различных проблем, случающихся по мере работы с Git. Вряд ли они будут новы для опытных пользователей, но обязательно найдутся и те, кому они пригодятся. А в конец этого материала мы добавили небольшой бонус от себя. Хорошей всем пятницы!

Все мы делаем ошибки, особенно при работе с такими сложными системами, как Git. Но помните: Git happens!

В течение нескольких месяцев мы собирали памятки по искусственному интеллекту, которыми периодически делились с друзьями и коллегами. В последнее время сложилась целая коллекция, и мы добавили к памяткам описания и/или цитаты, чтобы было интереснее читать. А в конце вас ждёт подборка по сложности «О большое» (Big-O). Наслаждайтесь.

UPD. Многие картинки будут читабельнее, если открыть их в отдельных вкладках или сохранить на диск.

Год назад у нас в компании был один проект — мобильный шутер War Robots с относительно медленными, но красочными и напряженными боями. Игра продолжает развиваться, у нее десятки миллионов установок и игроков по всему миру, постоянно выходят апдейты. В какой-то момент мы захотели сделать динамичный шутер на Unity со скоростями, сравнимыми с Overwatch, CS:GO или Quake. Но реализовать задуманное для мобильных платформ (в первую очередь iOS и Android) на основе War Robots при текущих архитектуре и подходах было практически нереально.

Мы понимали, как это сделать в теории — есть много статей, презентаций на YouTube, детально рассказывающих о том, как написать шутер, как работать с сетью, какие возникают проблемы и как их решать. Здесь нет Rocket Science, все эти подходы придумали еще 30 лет назад и за это время они особо не поменялись. НО: у нас не было практики.

Забегая вперед, скажу — нам удалось реализовать задуманное. Мы создали для мобильных платформ динамичный быстрый шутер, который сейчас находится в бета-тестировании и активно дорабатывается. И мне очень хотелось бы всем этим поделиться. Это первая, обзорная статья с перечислением и кратким описанием практически всего того, что мы используем (прошу не путать с другим нашим проектом в разработке, технологии и подходы в котором похожие, но отличаются в деталях).

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

В этой статье мы рассматриваем ПО, которое способно справиться с этими задачами.

Работа 24 на 7

«Всем привет, меня зовут Антон, и я — трудоголик. Я часто работаю по 12 часов в день. Моя семья очень страдает от этого. Я очень хочу начать жить, как все нормальные люди, но каждый раз срываюсь и засиживаясь заполночь...» — наверное так бы я начал свою речь, если бы состоял в клубе анонимных трудоголиков.

Описать понятие прокрастинации можно этим максимально простым изображением. У вас есть ряд определенных задач и есть выделенное время на их выполнение. Прокрастинаторы решают свалить все задачи в кучу и оставить на самый последний момент.

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



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

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

Под катом рассказ Петра Людвига на конференции Aletheia Business 2017 о том, как положить конец прокрастинации используя три простых инструмента. Как только вы внедрите их в свою жизнь, вы сразу заметите разницу. Вы будете более продуктивны, почувствуете себя счастливее и у вас появится больше энергии.

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



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

Мы знаем, что EVM работает на основе консенсуса, и нам не нужно думать об этом механизме до тех пор, пока он работает. Не думаем мы и о майнерах, ведь в конце концов, нет никакой необходимости понимать принцип работы полупроводников или особенности проектирования микросхем современных компьютеров. Но, увы, это удобное и предсказуемое разделение между уровнями — не более чем иллюзия. Иллюзия уровня консенсуса, которая помогает нам забыть, что майнеры нам не друзья.

На практике переход от контрактов к консенсусу — явление гораздо менее плавное, и не такое однозначное, как принято считать. Создание блоков влияет на состояние EVM, что в свою очередь сказывается на вызовах умных контрактов и в результате влияет на работу децентрализованных приложений и их пользователей. Чем медленнее блоки, тем медленнее децентрализованные приложения. Чем блоки быстрее, тем приложения быстрее. Пустые блоки приводят к остановке работы приложений.

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

Говоря об эффективной разработке систем машинного обучения, всегда поднимается вопрос контроля скорости обучения, анализа процесса обучения, сбора различных метрик обучения и тд. Особая сложность заключается в том, что мы (люди) привыкли оперировать 2х и 3х мерными пространствами, описывая различные процессы вокруг нас. Процессы внутри нейронных сетей происходят в многомерных пространствах, что серьезно усложняет их понимание. Осознавая это, инженеры по всему миру стараются разработать различные подходы к визуализации или трансформации многомерных данных в более простые и понятные формы.

Существуют целые сообщества, решающие такого рода задачи, например Distill, Welch Labs, 3Blue1Brown.

Это руководство написано для новичков, но я постараюсь поделиться всеми советами и трюками, которые я узнал за последние 5 лет полетов и фотомоделирования.

Вступление

Меня зовут Matthew Brennam, я аспирант факультета информатики в Индианском университете. У меня есть опыт в архитектуром дизайне, но я работал археологом и дизайнером мультимедиа.

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

Недавняя потребительская доступность современных беспилотных летательных аппаратов (UAV / UAS) в сочетании с легкими камерами с высоким разрешением и повышенной вычислительной мощностью для фотомоделирования означает, что в настоящее время на долю времени и денег, которые она когда-то занимала, мы способны создавать высокоточные модели больших структур и ландшафтов, которые могут использоваться для приложений AR и VR, а также отображаться в реальном времени в Интернете.

Взявшись за написание небольшого, но реального и растущего проекта, мы «на собственной шкуре» убедились, насколько важно то, чтобы программа не только хорошо работала, но и была хорошо организована. Не верьте, что продуманная архитектура нужна только большим проектам (просто для больших проектов «смертельность» отсутствия архитектуры очевидна). Сложность, как правило, растет гораздо быстрее размеров программы. И если не позаботиться об этом заранее, то довольно быстро наступает момент, когда ты перестаешь ее контролировать. Правильная архитектура экономит очень много сил, времени и денег. А нередко вообще определяет то, выживет ваш проект или нет. И даже если речь идет всего лишь о «построении табуретки» все равно вначале очень полезно ее спроектировать.

К моему удивлению оказалось, что на вроде бы актуальный вопрос: «Как построить хорошую/красивую архитектуру ПО?» — не так легко найти ответ. Не смотря на то, что есть много книг и статей, посвященных и шаблонам проектирования и принципам проектирования, например, принципам SOLID (кратко описаны тут, подробно и с примерами можно посмотреть тут, тут и тут) и тому, как правильно оформлять код, все равно оставалось чувство, что чего-то важного не хватает. Это было похоже на то, как если бы вам дали множество замечательных и полезных инструментов, но забыли главное — объяснить, а как же «проектировать табуретку».

Хотелось разобраться, что вообще в себя включает процесс создания архитектуры программы, какие задачи при этом решаются, какие критерии используются (чтобы правила и принципы перестали быть всего лишь догмами, а стали бы понятны их логика и назначение). Тогда будет понятнее и какие инструменты лучше использовать в том или ином случае.

Данная статья является попыткой ответить на эти вопросы хотя бы в первом приближении.