Из статьи интересно было узнать некоторые вещи о том, как написан майнкрафт. Хотя мораль, которую можно свести к одной фразе, «не пишите однопоточные игровые сервера», несколько тривиальна. Также не понравилось подчеркнуто агрессивное поведение автора в комментариях. Хороший программист это не тот, кто все знает, а тот, кто умеет учиться и воспринимать опыт других людей.
И да, числа, указанные в статье, это ни разу не «highload». Я, например, вообще не вижу проблемы с сохранением чанков на диск, если диск — это, например, кластер кассандры или другой NoSQL key-value storage.
Я когда-то делал презентацию со своими подобными находками для Idea и Eclipse (тут). Там первая половина посвящена хоткеям. Может, что-то будет полезно.
Время, необходимое на поиск пароля к одному хеш-значению по таким таблицам
По-моему, это, мягко говоря, ложь. Существующие No-SQL key-value хранилища данных (например, Project voldemort) имеют гораздо большую производительность. На один запрос будет уходить гораздо меньше секунды, с учётом указанного объёма. Возможно даже десятки миллисекунд.
Вы неправы, поскольку O-нотация указывает на ограничение алгоритма сверху. Ваш первоначальный алгоритм, где вы предлагаете линейно увеличивать N после каждого возвращения, в худшем случае будет работать следующим образом:
Максимальное количество возвращений пропорционально sqrt(N). При первом возвращении будет пройдено два шага (туда--обратно), при последнем — 2N шагов, следовательно, в среднем каждое возвращение будет занимать N шагов. Отсюда, сложность алгоритма в худшем случае пропорциональна sqrt(N)*N = N3/2. Выходит, действительно, не квадрат, но это всё равно хуже, чем N log(N).
Алгоритм, который предполагает после каждого возвращения увеличение N в два раза будет в худшем случае работать за N log2(N), поскольку количество возвращений в худшем случае будет пропорционально log(N), а среднее количество шагов для каждого возвращения будет составлять N.
Нотация O наиболее популярна как раз потому, что даёт наилучшее представление об эффективности алгоритма. На случайных данных алгоритмы, имеющие разную эффективность могут работать приблизительно одинаковое время, но вы же не будете спорить, что, например, bubble sort, с оценкой O(n2) менее эффективный, чем merge sort, с оценкой O(n log(n))? Хотя на некоторых наборах данных пузырёк работает за линейное время.
Ваше решение тоже работает за квадрат, хоть и с «хорошей» константой. И вы правы, чтобы получился логарифм, нужно как-то увеличивать n. Подумайте, как =)
Задачку hard в другой формулировке я часто на собеседованиях задаю. Очевидное решение работает за O(n2), однако мы с коллегами как-то на досуге придумали решение за O(n * log(n)). Можете подумать :)
Спасибо за отличную статью!
Интересно, а можно ли как-то обойти проверку видеокарты?
Кстати,
К примеру, как игрок может моментально переместиться из одной точки карты в другую за время, которое меньше секунды? Увы, сервер террарии считает это нормальным.
Программирование очень похоже на строительство.
Многие из присутствующих здесь этого не понимают, потому что работа, которую они выполняют аналогична самой простой работе в строительстве (читай, джамшутинг). А ведь знаете, в серьёзных фирмах есть такая должность «архитектор приложения» вот его-то как раз и можно сравнить с архитектором в привычном смысле. В таких фирмах на должном уровне и качество и контроль.
И не зря шаблоны проектирования какими мы их знаем в программировании пошли из архитектуры (см. Alexander C. «The Timeless Way of Building»).
Надеюсь, у всех из вас рано или поздно развеется романтический образ непризнанного героя-программиста, выполняющего уникальную работу, непосильную никому более. И вы поймёте, что мы всего лишь строители, пусть строим не дома.
Да, действительно, я невнимательно прочитал код. В таком случае, у Вас контроллеры перегружены кодом, связанным с логированием. Система связана (coupled) сильнее, чем должна быть. Предположим, Вы меняете сигнатуру класса User и нужно, чтобы логировалась новая структура. Вам придётся искать все места, где вы логируете User'а и вносить туда изменения.
А по-моему, данное «усложнение» разумно. В Вашем решении для каждого объекта независимо от класса приходится добавлять ещё один метод в класс LogUtil. При этом, если в вас 100500 классов, содержимое которых нужно логировать, у вас будет 100500 методов в классе LogUtil. Далее, если у Вас есть иерархия классов, как упростить логирование потомков за счёт повторного использования логирования предков? А как быть в случае, когда в качестве объекта логгирования приходит интерфейс, а нужна информация о действительной реализации инстанса?
Это преимущество предложенного мной варианта. Среди преимуществ Вашего вижу только одно — нет необходимости менять сигнатуру логируемых классов.
На мой взгляд, более правильно было бы сделать так:
Определить интерфейс Logable, в котором определить метод
public Action getLogAction();
В LogUtil написать методы public static Action getAction(Logable obj) {
return obj.getLogAction();
}
public static void logAction(Logable obj) {
log(getAction(obj);
}
Соответвенно, что именно логировать определять в наследниках интерфейса Logable.
Ещё вариант — поля и методы, которые необходимо логировать, аннотировать специальной аннотацией и метод log через reflection будет получать значения этих полей (не уверен, что этот метод хорош для данной задачи, но интересен).
Bar-коды или QR-коды? Мой андроидофон замечательно распознаёт qr-коды даже когда камера ещё не успела сфокусироваться причём снимать не обязательно из ровной позиции.
Ваш код хорошо читаем. Комментарии — это тоже очень правильно. Выше уже написали, что в данном примере комментариев избыточно много. Но, имхо, лучше, когда комментариев много, чем когда их нет. К сожалению, Вы совершенно не думаете о производительности.
И да, числа, указанные в статье, это ни разу не «highload». Я, например, вообще не вижу проблемы с сохранением чанков на диск, если диск — это, например, кластер кассандры или другой NoSQL key-value storage.
По-моему, это, мягко говоря, ложь. Существующие No-SQL key-value хранилища данных (например, Project voldemort) имеют гораздо большую производительность. На один запрос будет уходить гораздо меньше секунды, с учётом указанного объёма. Возможно даже десятки миллисекунд.
Максимальное количество возвращений пропорционально sqrt(N). При первом возвращении будет пройдено два шага (туда--обратно), при последнем — 2N шагов, следовательно, в среднем каждое возвращение будет занимать N шагов. Отсюда, сложность алгоритма в худшем случае пропорциональна sqrt(N)*N = N3/2. Выходит, действительно, не квадрат, но это всё равно хуже, чем N log(N).
Алгоритм, который предполагает после каждого возвращения увеличение N в два раза будет в худшем случае работать за N log2(N), поскольку количество возвращений в худшем случае будет пропорционально log(N), а среднее количество шагов для каждого возвращения будет составлять N.
Нотация O наиболее популярна как раз потому, что даёт наилучшее представление об эффективности алгоритма. На случайных данных алгоритмы, имеющие разную эффективность могут работать приблизительно одинаковое время, но вы же не будете спорить, что, например, bubble sort, с оценкой O(n2) менее эффективный, чем merge sort, с оценкой O(n log(n))? Хотя на некоторых наборах данных пузырёк работает за линейное время.
Интересно, а можно ли как-то обойти проверку видеокарты?
Кстати,
Есть такой предмет, как Magic Mirror
Многие из присутствующих здесь этого не понимают, потому что работа, которую они выполняют аналогична самой простой работе в строительстве (читай, джамшутинг). А ведь знаете, в серьёзных фирмах есть такая должность «архитектор приложения» вот его-то как раз и можно сравнить с архитектором в привычном смысле. В таких фирмах на должном уровне и качество и контроль.
И не зря шаблоны проектирования какими мы их знаем в программировании пошли из архитектуры (см. Alexander C. «The Timeless Way of Building»).
Надеюсь, у всех из вас рано или поздно развеется романтический образ непризнанного героя-программиста, выполняющего уникальную работу, непосильную никому более. И вы поймёте, что мы всего лишь строители, пусть строим не дома.
Это преимущество предложенного мной варианта. Среди преимуществ Вашего вижу только одно — нет необходимости менять сигнатуру логируемых классов.
Определить интерфейс Logable, в котором определить метод
public Action getLogAction();В LogUtil написать методы
public static Action getAction(Logable obj) {
return obj.getLogAction();
}
public static void logAction(Logable obj) {
log(getAction(obj);
}
Соответвенно, что именно логировать определять в наследниках интерфейса Logable.
Ещё вариант — поля и методы, которые необходимо логировать, аннотировать специальной аннотацией и метод log через reflection будет получать значения этих полей (не уверен, что этот метод хорош для данной задачи, но интересен).