Новые языки программирования незаметно убивают нашу связь с реальностью

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

Разработка Технического задания по ГОСТ 34 легко и просто

Между тем в стране по прежнему разрабатывается множество АС, не ориентированных на персонал, а не на потребителей. И именно для их реализации зачастую ГОСТ 34 и применяется.

Важнейшие заблуждения о разработке игр

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

Корпоративный Рататуй

Спасибо!

Корпоративный Рататуй

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

Kotlin: копаем глубже. Конструкторы и инициализаторы

Причем в этом коде оба присвоения будут в конструкторе. Но по факту срабатывать будет только последнее. Каким образом компилятор вымарывает первое срабатывание — большой вопрос.
И еще огромный вопрос вот в чем — а не может ли такого быть, что переменная объявляется фактически не финальной? Или финальная переменная действительно каким-то образом переписывается (хотя в JSR 133 это вроде невозможно)
То есть, могу ли я, имея несколько потоков, ухитриться получить одним из потоков первое значение вместо второго?

Kotlin: копаем глубже. Конструкторы и инициализаторы

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

fun main(args: Array<String>) {
  val a = ThreadTest()
  println(a.bul)
}

class ThreadTest {
  constructor() {
    println("constructor")
  }
  init {
    println("init_start")
    bul = f1()
    println("init_end")
  }

  private fun f1(): Int {
    println("assign1")
    return 3
  }

  val bul = f2()

  private fun f2(): Any {
    println("assign2")
    return 2
  }
}

Результат:

init_start
assign1
init_end
assign2
constructor
2

Kotlin: копаем глубже. Конструкторы и инициализаторы

Точно, сам в этом убедился. Определенно это какой-то баг.
Даже еще интереснее!

class ThreadTest {
  constructor() {
    println("c1")
  }
  init {
    println("init_start, $bul")
    bul = false
    println("init_end")
  }
  val bul: Boolean = true
}

Не компилируется!

Kotlin: копаем глубже. Конструкторы и инициализаторы

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

БД — это не только хранилище данных

А ещё это называется упущенная выгода =)

БД — это не только хранилище данных

К счастью, «родная БД» наоборот становится все лучше и лучше, однако от проблем это не избавляет — её всё равно не слишком хотят (и напрасно, кстати)

БД — это не только хранилище данных

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

БД — это не только хранилище данных

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