Гранд Макет — это макет России. Если говорить точнее, то это не макет страны, а собирательные образы российских городов, выполненные с большой детализацией, с движущимся транспортом и интерактивными сценами.
Я не Надя и телефон не зеркалка, поэтому фотографии «какие есть». Зато их много, а в конце поста есть даже видео.
Вычислительная геометрия сложна, но интересна. И это совсем не то же, что школьная геометрия на тетради в клетку. Здесь свои задачи, проблемы и методы.
Например, возьмём простейшую задачу: даны две невырожденные окружности, нужно определить, касаются ли они.
Очевидно, нужно найти расстояние между центрами и сравнить его с суммой радиусов:
Не прошло и года, а я уже подготовил пост про новогоднюю поездку в Норвегию. Фотографий Надя сделала много. Старался выбрать самые-самые, было трудно. Все фотки кликабельны.
Ехали через Эстонию, чтобы сэкономить на билетах. В Таллине были один вечер и одну ночь, меня город не сильно впечатлил.
Тут относительно недавно пробегали две статьи, в которых авторы затрагивали тему анализа хеш-функций с целью определить, какая лучше: Заметки о реализации hashCode() в Java и Changes to String internal representation made in Java 1.7.0_06 (перевод). В обеих статьях анализ проводился очень простой: генерировалось большое множество объектов нужного типа, для них вычислялись хеш-коды и среди хеш-кодов искалось количество коллизий (совпадений).
Я считаю, что такой анализ недостаточно хорош. Главное применение хеш-функций в Java — это в основанных на хешировании коллекциях, куда объекты складываются, распределяясь по ячейкам (бакетам, bucket) согласно своим хеш-кодам. Количество ячеек ограниченно, поэтому чтобы определить, в какой из них место объекту, берётся остаток от деления хеш-кода этого объекта на количество ячеек, которое из соображений производительности выбирается из степеней двойки. Так вот, равномерность распределения объектов по бакетам играет решающую роль в производительности коллекции, а значит очень важно, помимо количества коллизий, анализировать и её.
Легко показать, что малое число коллизий хеш-функции не всегда коррелирует с равномерным распределением объектов внутри хеш-таблицы. Достаточно взять любую хорошую хеш-функцию f(x) и получить из неё новую: h(x)=2*f(x). Количество коллизий у новой функции будет ровно таким же (для простоты забудем про переполнение), но при этом все её значения будут чётными, и распределение получится очень неравномерным.
На следующей неделе (13-21 июля) я буду в Нижнем Новгороде и на Бору.
Блог penguindaily.com физически переместился на ~7000 км и хостится теперь не у Selectel в Петербурге, а у Amazon на Elastic Cloud 2 в США, который обещает быть дешевле и надёжнее. Посмотрим.
Также в качестве http сервера теперь используется не Apache2, а более экономный nginx.
Кажется, переезд прошёл гладко, и никакие ссылки не пострадали.
Самый длительный пассажирский безостановочный авиарейс, который когда-либо выполнялся, это рейс SQ 21 Singapore Airlines. Длительность перелёта между Нью-Йорком и Сингапуром составляет почти 19 часов. В самолёте нет мест эконом-класса, зато есть специальное отделение для трупа, на случай если кто-нибудь из пассажиров умрёт во время перелёта. В ноябре этого года компания прекратит осуществлять этот рейс.
Остальное под катом.
Этот вопрос мне задали года полтора назад на первом телефонном собеседовании в Майкрософт. Я ответил что-то невнятное типа «ну концентрировать весь concurrency-related код в как можно меньшем числе классов, чтобы удобнее было разбираться в проблеме». Это собеседование я не прошёл.
Java Concurrency in Practice для решения проблемы дедлоков предлагает, по крайней мере в главе про дедлоки, следующее решение:
If you must acquire multiple locks, lock ordering must be a part of your design: try to minimize the number of potential locking interactions, and follow and document a lock ordering protocol for locks that may be acquired together.
Однако более полный ответ на этот вопрос я увидел, как ни странно, в Чистом коде Боба Мартина, в той главе, которая там вроде как ни к месту. Там приводятся следующие обязательные условия возникновения дедлока:
И предлагаются способы исключить каждое условие:
Mutual Exclusion:
От Lock and Wait избавиться можно так: проверяем ресурс перед захватом; если он занят, то освобождаем все захваченные ресурсы. Этот подход может привести к новым проблемам: Livelock и Starvation.
No Preemption: разрешаем потокам запрашивать ресурсы друг у друга. Я никогда в жизни такого не видел и не представляю, как это хорошо реализовать. Пишут, что это непросто.
Circular Wait: Вводим порядок, в котором ресурсы могут быть захвачены. Это невозможно, если до захвата одного ресурса мы не узнаем, какой ресурс понадобится следующим.
* * *
Особые юмористы могут отметить при ответе на вопрос, что переход на один лок или один поток также решает проблему.
Годная и подробная статья про технический долг. Основные идеи:
За то, что в нём из-за слишком умной адресной строки не работает очень важный для меня сценарий — поиск по закладкам из адресной строки — которым я часто пользуюсь в Chrome:
Моя закладка на второй строке. Браузер Яндекса в том же случае ставит популярные запросы выше моей закладки:
Меня это не устраивает, так как добавлять в закладки полезные страницы, затем быстро находить их по названию невероятно удобно.
Ну а в целом Яндекс.Браузер мало отличается от Google Chrome, разве что шпионит в пользу другой стороны :)