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

Вот вам примечательные цитаты о мастерстве писателя:

* Флобер, составляя план романа в течение многих месяцев, ежедневно работал по многу часов; а закончив план, говорил: "Мой роман готов, остается только его написать"

* Писать просто и ясно так же трудно, как быть искренним и добрым.

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

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

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

Немного из жизни, или Как мы Java в OracleDB бороли.

Так как мы ничего не боимся, в т.ч. нестандартных решений, а смотрим на всё открытыми глазами, то и в одной из задач закачку данных в БД из веб-сервиса сделали в лоб — на java написан клиент, который установлен в БД, и прикидывается PL/SQL пакетом. Таким образом, исключется лишний траффик на сервер приложений и потом в БД.
Если бы могли договориться с DBA сделать по-другому, поставив процесс java рядом с БД и настроив memshared-транспорт, так бы и поступили, но не вышло.

В общем, решение заработало. Стали выполнять тесты, и оказалось, что на мощном сервере это работает медленнее, чем на дохлом рабочем ноутбуке, а ещё и падает иногда с out of memory!

У руководителей проекта началась лёгкая паника, конечно же, а разработчики принялись храбро выдвигать гипотезы одну за одной:
- мало памяти
- GC тормозит
- JIT плохой
- стык с PL/SQL тормозит
- фаза луны мешает.

Но спасает, как всегда, чтение документации вслух. А конкретно, в Oracle используется Java-6 совместимая JVM (Aurora или JServer). Среди всяких интересных вещей там описана одна нужная: потоки в JServer реализованы по методу невытесняющей многозадачности. Т.е. если вы запускаете несколько потоков, выполняться они будут последовательно. Ну а наши гонщики за high performance, конечно же, сделали в java потоки, фьючерсы, всё очень асинхронно и "быстро".

Полечилось переписыванием на самый тупой последовательный вариант, а параллелизация была перенесена на уровень PL/SQL несколькими сессиями. Заработало в итоге 3-4 раза быстрее, чем если качать данные через dblink, на что и был исходный расчёт.

Тут и сказочке конец бы пришёл, да стало интересно, а как это в CLR, который в SQL ставится. Принялись смотреть, и удивились: оказывается, там поверх невытесняющей многозадачности реализована своя вытесняющая!
А конкретно, в разных "safepoint" (запуск gc, i/o, обращения в БД другие) исполнение переключается на другой поток. Гипотеза используется следующая: не может ведь поток работать и gc не вызываться. А если такое происходит (числодробилка), то диспетчер потоков этот факт отмечает, и следующий раз такой жадный до CPU поток свой квант получит позднее, или вообще будет пропущен.

"За полгода до окончания работы над аппаратным обеспечением IBM начала заниматься языком. Был создан “комитет по разработке передового языка”. Комитет состоял из представителей фирм “Lockheed”, “Union Carbait”, “Standard Oil ” из Калифорнии и специалисты из отделов программирования фирмы IBM. Комитет возглавил Джорж Рэдин. Они приступили к работе в октябре 1963г, и к февралю 1964 г. спецификации языка были завершены."

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

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

1. Его компилятор (транслятор/интерпретатор) был бы очень рано забутстраплен с его же стандартной библиотеки. Пользу eating your own dog's food невозможно переоценить.

2. Я бы исключил из него математику (всю). Даже a = a+1 нельзя было бы написать. Вообще её наличие в языке уходит корнями в Fortran и другие мастодонты, а у нас немного другие нужды. Есть итераторы, есть ranges, хотите математики - велкам в библиотеки, не устраивайте мне тут mathcad. Заодно и массивы выкинул бы.

3. Уровни доступа переоценены. Достаточно было бы всего 2 -- public и package-protected (доступен только в этом пакете). Сделать public поля нельзя.

4. Пакеты. Само собой. Вложенные пакеты запретить. Вложенные классы - в пакет, в класс, в метод - разрешить.

5. Сделать метод или класс закрытым от наследования нельзя

6. Никаких setter-ов и getter-ов - только функции/методы. Ссылки на объекты и другие сущности должны быть first-class citizens, а не стыдливо вести себя как бесплотные указатели, унаследованые из си.

7. Модули - как класс, но существует в едином экземпляре, как пакет.

8. Типобезопасные макросы в языке иметь хорошо и правильно, но не на уровне syntax tree, а выше. Хотя можно не прятать это в компилятор, а выпустить macros sdk

9. JIT и эффективный GC переоценнены, а вот repl и хороший анализ ошибок - их, наоборот, не хватает

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

Мне кажется, уже на этом можно не одну голову сломать, но труд этот будет вознагражден.

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

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

А в следующем сообщении я расскажу, как это устроено внутри — там есть, хоть и некрупные, изюминки в архитектуре.

(напоминаю, что багрепорты по квесту, если такое желание появилось, следует направлять в Телеграме @meowthsli)

Постик про архитектуру игр в @MadMudBot.

Как и обещал, рассказываю про внутреннее устройство приложения. Устроено всё относительно просто и стандартно: приложение реализовано на java 8 при помощи каркаса Spring Boot, и развёрнуто в JBoss Wildfly в IaaS-провайдере Openshift. Почему использую сервер приложений — очень удобен для управления, предоставляет полезные сервисы JavaEE: транзакции, встроенный IMDG (in-memory data grid) Infinispan, пулинг и управление соединениями к БД — всё там есть.

Если кто не знает, развёртывание в OpenShift выглядит так — пушишь код в репозиторий, там срабатывает триггер и развёртывает master на сервере.

Основной нюанс архитектуры связан с тем, что я решил отказаться от использования реляционной СУБД для хранения оперативных данных (при этом я по прежнему использую реляционную БД Postgres для хранения данных билллинга — для надёжности). Почему так сделал ? Типовые задачи онлайн игры "вынуть игровой мир" - "обновить" - "положить игровой мир обратно" не очень хорошо ложатся на паттерн работы с реляционной БД, и требуют при написании кода подключения головного мозга, а не только спинного. Лениво.

Поэтому было решено для оперативного хранения взять кэш-провайдер Infinispan, встроенный в сервер приложений. Этот IMDG, который предоставляет в java интерфейс обычной хэш-мапы, хранящей объекты по ключу. Ключом, как вы понимаете, является идентификатор игрока. С "задней стороны" кэш подстрахован (стандартный механизм infinispan) технологией персистирования объектов в кэше в постоянное хранилище — на случай перезагрузок сервера и т.п. Сохраняется всё в большую плоскую таблицу в БД. Это был самый простой вариант, хотя можно настроить и файл, и что-то ещё. Сохранение данных выполняется кэшом тогда, когда ему кажется нужным, т.к. асинхронно и незаметно для клиентов infinispan. Так реализовано сохранение игрового мира в процессе игры. Заработало всё сразу же.

Создание же игрового мира выполняется из текстового файла, в котором описана структура лабиринта, а дополнительная логика (зомби, аптечки, инвентарь) реализованы кодом (50 строк на java).

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

Для более сложной игры я бы взял для реализации какой-нибудь агентный фреймворк (типа Akka), там сериализация доступа выполняется просто и понятно. В данной ситуации я поступил по-другому: обмен с Telegram API выполняется при помощи очередей сообщений,  которые наполняют и разбирают специальные I/O потоки, а вот превращением входной команды пользователя в выходное сообщение (входная очередь -> выходная очередь) занимается один выделенный рабочий поток. Т.е. на самом деле несколько потоков никогда не работают со структурами игры, всегда только один, тем достигается согласованность и отсутствие конфликтов.

Планирование разных отложенных действий (например, оповещений пользователя) сделано на базе стандартных шедулеров java 8, который позволяет это сделать экономно и не требует блокирования множества потоков на ожидании таймера и т.п.

Вот и все основные моменты. Надеюсь, было интересно

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

Всем привет, я вернулся из затянувшегося отпуска и пары срочных контрактов. Это значит, что канал возобновит работу.

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

Давайте поймём, что такое "неполные" требования. Может, аналитик слушал заказчика, но не всё записал? Или заказчик сам не понимает, что ему нужно, а потом поймёт? Или аналитик записал не то? Не очень понятно.

Что вообще такое "полные" требования, в противоположность "неполным"? Требования пришли в конечную точку, и больше не будут меняться? Требования были изложены на 100% верно с первого раза? В крупном проекте так не бывает почти никогда.

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

Более-менее (((адекватный))) взгляд на предмет такой — полных требований не бывает вовсе, они невозможны, они несбыточная абстракция. С этим надо согласиться.  А если их не бывает, почему вас теперь это беспокоит? Вы всегда в своей практике работали с неполными требованиями, и это никого не вгоняло в панику. Более того, и все остальные тоже работают с неполными требованиями, в 99.9% случаев.

Придётся смириться, что любые требования неполные, включая те, с которыми вы когда-либо работали. Это должно немного успокоить и воодушевить. Т.е. работайте так, как работали ранее.

Собственно, вопрос сводится к тому, как вообще работать с требованиями, которые всегда изменяются. Здесь приходят на помощь несколько неидеальных, но неплохих методик:
- итеративная разработка (она была и есть даже в waterfall-модели)
- инженерия требований (как суперпроцесс над практикой анализа требований https://ru.wikipedia.org/wiki/%D0%90%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D1%82%D1%80%D0%B5%D0%B1%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B9)
- техника Impact Mapping, которая хорошо раскрыта, например, тут https://habrahabr.ru/post/246401/

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

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

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

Это будет не ООП, не ФП, и не другие П, ДДД и ТДД. Это будет контрактно-ориентированное программирование.
Положительный эффект от него заметен настолько явно, что в своей работе мы закрепили это даже в соглашениях о кодировании:
- все без исключения публичные функции и методы имеют неотключаемые в релизе проверки входных аргументов и выходных результатов
- все остальные функции и методы могут иметь отключаемые или неотключаемые в релизе проверки входных аргументов и возвращаемых значений
- любой код может иметь отключаемые в релизе проверки в середине логики.

Судя по количеству дефектов в джире, это реально работает, без регистрации и СМС. Часто отпадает даже необходимость в тестах и отладчике.

» Судя по количеству дефектов в джире, это реально работает, без регистрации и СМС
QA-инженеры НЕНАВИДЯТ этот способ! Нужно ВСЕГО ЛИШЬ добавить ... (via @bitrmn)

Чем умнее программист, тем дальше бежать за архитектором, когда придётся переписать

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

Советы молодым архитекторам Френку Ллойду Райту

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

- Забудьте обо всех архитектурах мира, если не понимаете того, что они были хороши в своём роде и в своё время.

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

- Берегитесь архитектурных школ во всём, кроме обучения инженерному делу.

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

- Немедленно начните вырабатывать в себе привычку задумываться «почему» по поводу всего, что Вам нравится или не нравится.

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

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

- «Мыслите простыми категориями», как говаривал мой учитель, имея при этом в виду, что целое сводится к его частям и простейшим элементам на основе первоосновных принципов. Делайте так для того, чтобы идти от общего к частному, никогда их не путая, иначе запутаетесь сами.

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

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

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

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

Франк Ллойд Райт, Молодому архитектору  Будущее архитектуры, М., «Госстройиздат», 1960 г., с. 175-176.

Источник: http://vikent.ru/enc/7655/

.. Не пытайся всё сделать сразу. Ибо сказано — всякий узел Системы должен быть сделан идеально, но не всякий — именно сейчас

То, что предлагает Telegram к ICO (Ton) — похоже, первая в мире криптофраншиза. За исполнение и соблюдение бизнес-модели отвечает сильная криптография

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

Однако многочисленные недавние исследования указывают на несоответствие этих взглядов реальности.

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

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

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