• Java собеседование. Коллекции
    0
    Или я не понял ваше решение, или оно не верное. В приведенном куске кода что хранится в массиве Versions? А еще лучше, пожалуйста, приведите код решения целиком (clear, put и get).
  • Java собеседование. Коллекции
    0
    Софистика по поводу константы 264 и утверждение, что элементарные операции над long нельзя считать O(1) выглядит занудством.

    По поводу head() — тут поможет связывать элементы двусвязным списком и хранить ссылку на голову. Да, хорошее дополнение.
  • Java собеседование. Коллекции
    0
    Есть же get и put, который можно вызвать с null.
    По поводу MAXINT — никто не заставляет использовать int для хранения версии.
  • Java собеседование. Коллекции
    0
    Оттуда же:
    Uniformly, methods of the Java Collections Framework (and the Google Collections Library too) never restrict the types of their parameters except when it's necessary to prevent the collection from getting broken.
  • Java собеседование. Коллекции
    +1
    Все, что вы написали — верно. Но к исходному вопросу отношение имеет слабое.
    Я думаю, вы сами понимаете, насколько нецелесообразно выбирать в качестве скалярной операции byteCode инструкцию.
    Теоретизирование на тему гипотетических архитектур, специально заточенных на оптимизацию отдельных операций, также считаю не относящимся к исходной задаче.
    Константы, конечно, имеют огромное практическое значение, но на ассимптотическую оценку не влияют.
  • Java собеседование. Коллекции
    +1
    Все равно я не могу придумать, как обнулить кусок пямяти длиной n (n → ∞) быстрее, чем за O(n).
  • Java собеседование. Коллекции
    0
    Вы не согласны?
  • Java собеседование. Коллекции
    0
    вы считаете, что это O(1)?
  • Java собеседование. Коллекции
    0
    Задачка не сложная, не спорю. Хотя 90% junior-to-middle java developers из тех, кого я собеседовал, не могли написать работающую реализаци задачки на merge двух отсортированных массивов, не говоря уже о красивом коде.
  • Java собеседование. Коллекции
    +3
    Вот вам задачка на коллекции.
    Нужно придумать реализацию структуру данных со следующим интерфейсом:
    Object get(int index);
    void put(int index, Object value);
    void clearAll();
    

    Эта структура данных является массивом. Размер (максимальное количество элементов) фиксирован и задается при создании. Метод get может возвращать как Object так и null, в случае, если по данному индексу не было put c момента создания или с момента вызова clearAll().
    И теперь самое важное. Методы get put и clearAll должны гарантированно работать за O(1).
  • Комментарий из публикации, перенесённой в черновики.
  • Как не нужно писать большие сервера
    +2
    Я почитал ваши комментарии выше. В современных высоконагруженных системах горизонтальная масштабируемость идет перед вертикальной. Ок, ваш сервер на C будет держать 100000 коннекшнов против 20000 на джаве. А что если у вас завтра будет 10кк? И тут уже выплывают совершенно другие узкие места, такие, как взаимодействие с БД, синхронизация и транзакции между разными нодами в кластере. А тут уже необходимо писать максимально простой и высокоуровневый код. И чем больше задач ложится на «стандартные» хорошо протестированные фреймворки, тем лучше.
    Я считаю, что система, где с нагрузкой справляется один сервер, не является highload.
  • Как не нужно писать большие сервера
    +2
    Разве? По-моему, synchronized в общем случае работает на порядок шустрее локов из util.concurrent. Я это утверждаю на основе своих личных тестов. Synchronized также меняет имплементацию в зависимости от использования.
  • Как не нужно писать большие сервера
    +1
    Сейчас есть JIT, есть разные реализации GC, некоторые из них параллельные и неблокирующие. В целом можно сказать, что джава сейчас почти не отстает от си в производительности. Можно нагуглить уйму статей на эту тему.
    Правда, я не совсем понимаю, что вы имеете в виду в данном случае под конечным автоматом. Насколько я понимаю, реализация простого конечного автомата не требует GC.
  • Как не нужно писать большие сервера
    +2
    Например, тут.
  • Как не нужно писать большие сервера
    +1
    Не за что. Советую прочесть книжку Java Concurrency in Practice (Brian Goetz & Kº). Если будут вопросы — обращайтесь.
  • Как не нужно писать большие сервера
    +2
    Что вы конкретно хотите? Добавление в конец какой структуры? Если очереди, то, например, вот. Вообще, concurrency framework на java предоставляет отличный базис для имплементации подавляющего большинства задач, связанных с многопоточностью.

    Кроме того, если душа лежит к message-oriented программированию, то есть несколько реализаций Actors model на джаве.
  • Как не нужно писать большие сервера
    +6
    «Стандартные» структуры не threadsafe.
  • Как не нужно писать большие сервера
    +2
    Загуглите java.util.concurrent.
  • Как не нужно писать большие сервера
    0
    В джаве можно использовать sun.misc.Unsafe для выделения памяти вне кучи. Как раз для тех, кто «знает, что он делает».
  • Как не нужно писать большие сервера
    +14
    Из статьи интересно было узнать некоторые вещи о том, как написан майнкрафт. Хотя мораль, которую можно свести к одной фразе, «не пишите однопоточные игровые сервера», несколько тривиальна. Также не понравилось подчеркнуто агрессивное поведение автора в комментариях. Хороший программист это не тот, кто все знает, а тот, кто умеет учиться и воспринимать опыт других людей.
    И да, числа, указанные в статье, это ни разу не «highload». Я, например, вообще не вижу проблемы с сохранением чанков на диск, если диск — это, например, кластер кассандры или другой NoSQL key-value storage.
  • Клавиатура, идея, две руки
    0
    Визуальный оргазм!
  • Продуктивное использование PHPStorm
    +1
    Я когда-то делал презентацию со своими подобными находками для Idea и Eclipse (тут). Там первая половина посвящена хоткеям. Может, что-то будет полезно.
  • Сердечные мониторы овец против вероломных волков
    +1
    Можно заодно издавать какой-то резкий звук (сирену). Думаю, волки будут пугаться, по крайней мере, первое время.
  • Анализ возможностей массового аудита на основе утечки хешей из LinkedIn
    0
    Время, необходимое на поиск пароля к одному хеш-значению по таким таблицам

    По-моему, это, мягко говоря, ложь. Существующие No-SQL key-value хранилища данных (например, Project voldemort) имеют гораздо большую производительность. На один запрос будет уходить гораздо меньше секунды, с учётом указанного объёма. Возможно даже десятки миллисекунд.
  • О глупости умных людей
    0
    Вы неправы, поскольку 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))? Хотя на некоторых наборах данных пузырёк работает за линейное время.
  • О глупости умных людей
    0
    Нет. Тоже n2 будет.
  • О глупости умных людей
    0
    Ваше решение тоже работает за квадрат, хоть и с «хорошей» константой. И вы правы, чтобы получился логарифм, нужно как-то увеличивать n. Подумайте, как =)
  • О глупости умных людей
    +1
    Задачку hard в другой формулировке я часто на собеседованиях задаю. Очевидное решение работает за O(n2), однако мы с коллегами как-то на досуге придумали решение за O(n * log(n)). Можете подумать :)
  • Terraria: или пишите игры правильно
    +1
    Спасибо за отличную статью!
    Интересно, а можно ли как-то обойти проверку видеокарты?

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

    Есть такой предмет, как Magic Mirror
  • Вы НЕ инженер-программист!
    +1
    Программирование очень похоже на строительство.
    Многие из присутствующих здесь этого не понимают, потому что работа, которую они выполняют аналогична самой простой работе в строительстве (читай, джамшутинг). А ведь знаете, в серьёзных фирмах есть такая должность «архитектор приложения» вот его-то как раз и можно сравнить с архитектором в привычном смысле. В таких фирмах на должном уровне и качество и контроль.
    И не зря шаблоны проектирования какими мы их знаем в программировании пошли из архитектуры (см. Alexander C. «The Timeless Way of Building»).
    Надеюсь, у всех из вас рано или поздно развеется романтический образ непризнанного героя-программиста, выполняющего уникальную работу, непосильную никому более. И вы поймёте, что мы всего лишь строители, пусть строим не дома.
  • Keep API simple
    0
    Да, действительно, я невнимательно прочитал код. В таком случае, у Вас контроллеры перегружены кодом, связанным с логированием. Система связана (coupled) сильнее, чем должна быть. Предположим, Вы меняете сигнатуру класса User и нужно, чтобы логировалась новая структура. Вам придётся искать все места, где вы логируете User'а и вносить туда изменения.
  • Keep API simple
    0
    А по-моему, данное «усложнение» разумно. В Вашем решении для каждого объекта независимо от класса приходится добавлять ещё один метод в класс LogUtil. При этом, если в вас 100500 классов, содержимое которых нужно логировать, у вас будет 100500 методов в классе LogUtil. Далее, если у Вас есть иерархия классов, как упростить логирование потомков за счёт повторного использования логирования предков? А как быть в случае, когда в качестве объекта логгирования приходит интерфейс, а нужна информация о действительной реализации инстанса?
    Это преимущество предложенного мной варианта. Среди преимуществ Вашего вижу только одно — нет необходимости менять сигнатуру логируемых классов.
  • Keep API simple
    0
    На мой взгляд, более правильно было бы сделать так:
    Определить интерфейс 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 будет получать значения этих полей (не уверен, что этот метод хорош для данной задачи, но интересен).
  • Оригами и расширенная реальность (продолжение)
    +1
    Bar-коды или QR-коды? Мой андроидофон замечательно распознаёт qr-коды даже когда камера ещё не успела сфокусироваться причём снимать не обязательно из ровной позиции.
  • Разбор XML при помощи Simple Framework
    0
    Скажите, а чем это лучше/хуже XStream?
  • Говнокод: врага надо знать в лицо
    0
    Согласен.
  • Говнокод: врага надо знать в лицо
    +1
    Вы молодец :)
  • Говнокод: врага надо знать в лицо
    0
    Ваш код хорошо читаем. Комментарии — это тоже очень правильно. Выше уже написали, что в данном примере комментариев избыточно много. Но, имхо, лучше, когда комментариев много, чем когда их нет. К сожалению, Вы совершенно не думаете о производительности.
  • Говнокод: врага надо знать в лицо
    0
    Мой вариант не претендует на идеальность и он не объектно-ориентированный, поскольку используются статические методы класса.
    По поводу примера по Вашей ссылке, я рассматривал подобную реализацию, согласен, она гораздо лучше читается, но не выдерживает совершенно никакой критики как по производительности, так и по используемой памяти (а что, если n будет равно 100000000?). Тут, мне кажется, уместнее всё же сохранять баланс между тривиальной оптимизацией и размером кода.