jrhAp2aK

Хорошая статья, я думаю, он с удовольствием почитает;-)

Ничего не работает и всем пофиг

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

Data Context Interaction (DCI) — эволюция объектно-ориентированной парадигмы

Со всем полностью согласен. Но ключевая фраза «Это не ООП подход.»
Я именно это и хотел сказать, что не всё так гладко в ООП.
В данной статье, по сути, описывается метод реализации на ООП читабильности функционального подхода, когда выделяются отдельно стуктуры данных (в данном случае аккаунт), и отдельно действия (в данном случае транзакция и её контекст).
Из чего следует вопрос, а зачем тогда так следовать ООП?
Это напоминает ситуацию когда для вместо того, чтобы написать простую функцию с аргументами делают класс, в конструктор которого передают аргументы, и пишут отдельный метод вроде «run» для вызова. Спрашивается, зачем?

Data Context Interaction (DCI) — эволюция объектно-ориентированной парадигмы

Раза 3 прочитал статью и пытался понять, зачем городить такую сложную структуру классов когда можно написать одну функцию вроде:

def transfer source_account_id, destination_account_id, amount
  def transfer_out account, amount
    raise "Insufficient funds" if account.balance < amount
    account.decrease_balance amount
    account.update_log "Transferred out", amount
  end

  def transfer_in account, amount
    account.increase_balance amount
    account.update_log "Transferred in", amount
  end

  transfer_out Account.find(source_account_id), amount
  transfer_in Account.find(destination_account_id), amount
end

Аккаунт — это данные, трансфер — это некоторое действие. Всё просто и понятно. Вся логика локализована в одном месте.
Я что-то не понимаю, да?

Кабины для сна Sleepbox поступили в продажу

Это уже будет скорее краш-тест))

Клиент-серверное общение в Unity3d

Ну да, это стандартно, иначе сложно придумать, но я к тому, что у нас это всё описывалось в thrift модели данных.

Клиент-серверное общение в Unity3d

Выстрел — это эвент, в котором параметры примерно следюущие: кто, куда, чем и как.
Этот эвент передаётся по сети всем заинтересованным (кто в области видимости) игрокам.
Далее выстрел долетает до цели, генерируется эвент «попадание выстрела», который состоит из эвента «дамаг» и взрыв". Аналогично передается всем. Клиенты отрисовывают взыв.
Примерно так.
А полностью объекты передаются не часто, например, при заходе игрока в игру.

Клиент-серверное общение в Unity3d

Ну вот как раз унификация типов данных очень упростила разработку.
Мы всё сетевое взаимодействие строили по модели: запрос -> ответ(большей частью только статус: ок/не ок) + список эвентов.
Эвенты тоже были объектами модели данных и в них были все изменения.
Также сохраняли в базу в сериализованном виде.

Клиент-серверное общение в Unity3d

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

Немецкое правительство выложило все законы на гитхаб в machine-readable формате

Нужно ещё и закон-ревью организовать! )

Клиент-серверное общение в Unity3d

А не смотрели в сторону protobuf/thrift/asn.1?
Эти технологии отлично решают задачу сериализации.
Особенно в геймдеве где довольно сложная логика и модель данных.

Что я постиг в программировании

Ещё, имхо, в пункте "4. За дублирование придется поплатиться" есть один подвох. Если с этим переусердствовать, то можно подвести по сути разные случаи под одну гребёнку.
Т.е. если два куска кода решают с виду одинаковые задачи, но по сути они разные, то написание для них общего кода может потом аукнуться проблемами.
Например, вы у вас в системе есть 2 разных протокола (допустим, для 2х типов клиентов), и так случилось, что одна команда и там, и там, совпадает по набору аргументов. В этом случае если у них будет общий код (допустим для парсинга), то изменения в одном, затронут и другой, чего по логике быть не должно, и это будет неприятной неожиданностью.
Пример, конечно, сильно утрирован, но суть объясняет.

Интернет-гиганты против закона о реестре сайтов

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

Представляем — Prose: редактор содержимого для GitHub

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

Представляем — Prose: редактор содержимого для GitHub

Очень классный ресурс, давно такого ждал.

Из недочётов заметил что на просмотр некоторых файлов (Makefile постоянно) вылезает: «The requested resource could not be found».
Плюс из разметки понимает только Markdown, а сам гитхаб больше. ;-)
Так же содержимое не всех файлов показывается при редактировании.
И ещё хотелось бы переключение по веткам.

Изучить Github за 15 минут

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

Крестики-нолики на Erlang

OTP — это не фреймворк, это скорее стандартная библиотека плюс архитектурные рекомендации, которые учитывают знания и опыт разработчиков. Поэтому писать можно и без, только зачем изобретать велосипед и собирать грабли, когда можно это всё обойти?
А если интересно более глубоко опробовать Erlang, то этот же проект, только на OTP и Cowboy с вэбсокетами будут отличным продолжением. ;-)

Крестики-нолики на Erlang

Cowboy + websockets тут идеальны будут.
Писать на Erlang без OTP — довольно бессмысленно.
Обычно при появлении в коде в чистом виде оператора отсылки сообщения ("!") и/или функции «spawn» (особенно без link) говорит, что что-то тут не так…

Как решить проблему 10 000 соединений?

Erlang?

Меня в Гугле забанили

А кто мешает большому китайскому файерволу снифать процесс обмена ключами при установлении ssl соединении и спокойно читать весь последующий траффик?