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

---

Кандидат: Что конкретно Вы имеете в виду, говоря «скопировать»?
Интервьюер: Ну… создать новый файл, содержимое которого является копией содержимого исходного файла.

Эванс написал хорошую книжку с хорошими идеями. Но этим идеям не хватает методологической основы. Опытным разработчикам и архитекторам на интуитивном уровне понятно, что надо быть как можно ближе к предметной области заказчика, что с заказчиком надо разговаривать. Но не понятно как оценить проект на соответствие Ubiquitous Language и реального языка заказчика? Как понять, что домен разделен на Bounded Context правильно? Как вообще определить используется DDD в проекте или нет?

Последний пункт особенно актуален. На одном из своих выступлений Грег Янг попросил поднять руки тех, кто практиукует DDD. А потом попросил опустить тех, кто создает классы с набором публичных геттеров и сеттеров, располагает логику в «сервисах» и «хелперах» и называет это DDD. По залу прошел смешок:)

Как же правильно структурировать бизнес-логику в DDD-стиле? Где хранить «поведение»: в сервисах, сущностях, extension-методах или везде по чуть-чуть? В статье я расскажу о том, как проектирую предметную область и какими правилами пользуюсь.

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

А еще там разбирается характер персонажей на примере сторонников теории плоской Земли.


Сценарий фильма «Апокалипсис сегодня» (1979) по мотивам книги Джозефа Конрада «Сердце тьмы» (1899)

Алгоритм Wave Function Collapse генерирует битовые изображения, локально подобные входному битовому изображению.

Локальное подобие означает, что

• (C1) Каждый паттерн NxN пикселей в выходных данных должен хотя бы раз встречаться во входных данных.
• (Слабое условие C2) Распределение паттернов NxN во входных данных должно быть подобным распределению паттернов NxN в значительно большом количестве наборов выходных данных. Другими словами, вероятность встречи определённого паттерна в выходных данных должна быть близка к плотности таких паттернов во входных данных.

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

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

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

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

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

1. Структура и схема.
2. Представление и доступность.
3. Выбор используемых графиков.
4. Усовершенствование контекста.

Часть 1. Структура и схема

Давайте для начала остановимся и зададим себе два вопроса: кто наша целевая аудитория и каковы её цели?

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

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

Эта памятка писалась для внутренних нужд (открыть глаза менее опытным в вебе коллегам). Но, т.к. я насмотрелся велосипедов от довольно уважаемых, казалось бы, контор, — выкладываю на хабр. Мне кажется, многим будет полезно.

Зачем

Надеюсь, читающий уже понимает, зачем ему вообще нужен именно REST api, а не какой-нибудь монстр типа SOAP. Вопрос в том, зачем соблюдать какие-то стандарты и практики, если браузеры вроде бы позволяют делать что хочешь.

• Стандарт HTTP это стандарт. Его несоблюдение вредно для кармы и ведёт к постоянным проблемам с безопасностью, кэшированием и прочими "закидонами" браузеров, которые совсем не закидоны, а просто следование стандарту.
• Велосипеды со всякими {error: "message","result":...} невозможно нормально тестировать и отлаживать
• Поддержка большим количеством готовых клиентских библиотек на все случаи жизни. Те, кто будет вашим api пользоваться, скажут большое человеческое спасибо.
• Поддержка автоматизированного интеграционного тестирования. Когда сервер на любые запросы отдаёт 200 ОК — ну, это такое себе развлечение.

Жил на свете такой человек – Стивен Кови. Однажды он решил написать книгу о личной эффективности. Теперь эту книгу знают все, она называется «Семь навыков высокоэффективных людей». Она считается классикой, постоянно переиздается во всех мыслимых странах мира, за годы существования продано несколько десятков миллионов экземпляров. Сам Стивен Кови настолько разобрался в личной эффективности, что его личными консультациями не преминули воспользоваться несколько президентов, в т.ч. США.

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

Но я не про книгу хочу поговорить, а про неожиданное открытие, которое сделал Стивен Кови, когда ее писал. Он это явление назвал «социальный аспирин».

Продолжу тему мотивации, начатую в “Прогулке по заводу желаний”.

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

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

Перечисление разных эмоций можно встретить в разных хабро-хабах, например: Управление персоналом, Научно-популярное, Машинное обучение, Обработка изображений, Тестирование IT-систем, Разработка веб-сайтов.

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

Разрешите усомниться.

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



Борьба популяций цифровой плесени под воздействие испепеляющего солнца.

Предуведомление. Статья состоит из трёх частей, и первые две кажутся вообще друг к другу никак не относящимися, однако есть третья объединяющая их.

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

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

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

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

Или еще проще — проблемы нет, у вас воля слабая, отговорки ищете, возьми и сделай (just do it).

Позвольте усложнить.

Как выживать в турбулентной корпоративной среде. Только для теоретического изучения.

Не знаю, как вам, а мне приходилось работать в достаточно турбулентной корпоративной среде, и не один раз.

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

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

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

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

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

Юрий Андрейкович, Senior Product Manager в Wrike, рассказал на конференции ProductSense в Минске, когда и зачем надо удалять фичи из продукта.



Я работаю в Wrike — это сервис для совместной работы и управления проектами. В Wrike более миллиона пользователей, но наши прямые клиенты — это компании, которые платят за сотрудников. Таких примерно 17 тысяч.

Я не раз сталкивался с необходимостью удалять фичи из продукта, а иногда ко мне приходили с запросом: «У нас есть несколько тысяч пользователей, они чем-то пользуются, а мы хотим это удалить. Действуй». Я расскажу, на каких этапах жизненного цикла продукта стоит задуматься об удалении фичей и какие подводные камни можно обойти.

В рамках проходящей в данный момент выставки CES 2019 подразделение IBM Research провело анонс первой в мире квантовой системы, пригодной для коммерческого применения.

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

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

Так что в списке «Самые неразвивающиеся компаниии» остаются только франчайзи 1С. Там работает куча прекрасных людей, но то ли среда такая, то ли место проклятое — с ними что-то не так.

Они думают только о сегодняшнем дне. Возможно, виновата жесткая привязка к одному вендору, который разрабатывает и фреймворк, и прикладные решения. Никто же в здравом уме не будет в 21 веке строить долгосрочный бизнес, завязанный на один язык программирования, одну среду разработки, один рынок? А вот ковать железо, пока горячо — пожалуйста. Когда остынет, тогда и можно будет задуматься о чем-то серьезном.

Но мне, почему-то, кажется, что не все потеряно. Можно сделать лучше.

Еще со времен обучения в университете я использовал LaTeX для оформления лабораторных и курсовых работ. Познакомился впервые с LaTeX на Coursera, на курсе "Документы и презентации в LaTeX".

В этой заметке я расскажу, как я писал диплом с помощью LaTeX и почему я использовал GitHub, Docker и TravisCI.

Здравствуйте, коллеги.

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

Части 1-3: сетка, цвета и высоты ячеек

Части 4-7: неровности, реки и дороги

Части 8-11: вода, объекты рельефа и крепостные стены

Части 12-15: сохранение и загрузка, текстуры, расстояния

Части 16-19: поиск пути, отряды игрока, анимации

Части 20-23: туман войны, исследование карты, процедурная генерация

Части 24-27: круговорот воды, эрозия, биомы, цилиндрическая карта

Часть 12: сохранение и загрузка

• Отслеживаем тип рельефа вместо цвета.
• Создаём файл.
• Записываем данные в файл, а затем считываем его.
• Сериализуем данные ячеек.
• Уменьшаем размер файла.

Мы уже умеем создавать достаточно интересные карты. Теперь нужно научиться их сохранять.

Продолжая серию статей о «подводных камнях» не могу обойти стороной System.Net.HttpClient, который очень часто используется на практике, но при этом имеет несколько серьезных проблем, которые могут быть сразу не видны.

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