Да-да, это именно то, на что похоже — Google решил помочь путешественникам и командированным гражданам помочь с выбором отелей. При этом выбирать гостиницу можно как раз под свои нужды — вводим критерии, и на выходе получаем искомое. Критерии, которые необходимы системе для нормального поиска, это место, даты, ценовой диапазон и рейтинг (количество звезд и прочее). К сожалению, пока что Hotel Finder доступен только для жителей США (и почему я не удивлен? :)). Вернее, искать могут все, но только в пределах США.

Введение

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

В результате у кого-то возникает разочарование в камере и фотографии в целом, а другие проявляют терпение и пытаются освоить премудрости фотографии, чтобы раскрыть весь потенциал камеры с полноценным (или почти полноценным) сенсором.

Изначально я планировал написать одну статью, но по ходу дела понял, что объем получается слишком большой и решил разбить ее на несколько частей. В этой главе рассмотрю такие понятия как выдержка, диафрагма, ГРИП и светочувствительность, как эти параметры влияют на результат съемки. На очереди статья про типы и параметры объективов, работу со вспышками и советы по съемке в различных условиях.

1. Вы с утра выбежали из дома забыв включить компьютер, что бы поддерживать Torrent рейтинг?
2. Вы в очередной раз выбежали из дома, а придя на работу вспомнили что на домашнем ПК остались нужные файлы? или наоборот.
3. У вас отключили свет и ПК, Сервер, etc… отключились? но вам нужны они в рабочем состоянии?
4. Любой другой критический случай настигший вас в дороге.
В этой статье пойдет речь о том, как при помощи Wake On LAN, которая присутствует практически во всех BIOS с 2002 года, включит ваш компьютер по сети или через интернет.
С другого ПК, или мобильного устройства.

Вчера во ВКонтакте появилась поддержка открытого стандарта авторизации OAuth 2.0. Теперь интегрировать сайты и клиентские приложения с социальной сетью стало значительно проще.

Начало

Тема исследования связей в социальных сетях становится все более актуальной по разным причинам: попытка ответить на вопрос о степени связности участников сетей; скорости и путях распространения информации; об эффективности целевой рекламы, в конце концов. Да и сам процесс исследования и поиска неявных связей затягивает!

Для своих исследований в этом направлении я выбрал самый «кипящий» кусок рунета, а именно – русский сегмент Живого Журнала. Туманно сформулированный вопрос звучал примерно таким образом: можно ли выделить блоггерские «группировки» исходя из структуры связей между пользователями сервиса ЖЖ, т.е. располагая лишь информацией о «френдах».

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

Забегая вперед скажу: социальный граф русского ЖЖ в моем исследовании имеет 2,08 млн. вершин и 58,05 млн. дуг. Интересно? Тогда под катом довольно много букв, цифр и картинок.

Я работаю в израильском отделении большой американской компании. Приходится много работать с индусами и американцами, даже есть группы, в которых часть людей сидит в другой стране.
Поэтому раз в год нам проводят семинары о культурных различиях. Как надо общаться с коллегами из других стран.

Мой первый рассказ был об американцах.
Сегодняшний — об индусах.

С индусами я работаю много. Есть даже в фирме «мой» индус — архитектор как и я, который вместе со мной отвечал за Business Logic нашей новой аппликации. В то время мы с ним говорили по мессенджеру или по телефону каждый день, я его опекал во время визитов в Израиль, свозил по своей инициативе в Иерусалим и даже приглашал домой.

У меня с ним отличные отношения (хотя и не без трений), но, как выяснилось, не всё я делал правильно :)

Во первых всё, что я писал об американцах в плане «мягких» выражений — верно для индусов и вообще для всех. При общении с кем угодно лучше сказать «Отличная идея, у меня только несколько поправок» в ситуации когда Вы думаете «Что за чушь!?».

Но есть своя специфика. Вопросы рассовой политкорректности индусов волнуют меньше, а вот вопросы «потери лица» — больше.

Я работаю в израильском отделении большой американской компании. Приходится много работать с индусами и американцами, даже есть группы, в которых часть людей сидит в другой стране.
Поэтому раз в год нам проводят семинары о культурных различиях. Как надо общаться с коллегами из других стран.

Мой первый рассказ — об американцах.

Вообще, они от нас (израильтян) в шоке. На семинаре показывали интервью с американкой, которая полгода работала в израильском офисе американской компании. Первое время ей казалось, что все агрессивны и грубы. Потом поняла, что это такая манера общения — люди повышают голос и перебивают друг друга во время дискуссий, люди могут сказать коллеге (и даже начальнику!), что он не прав и т.д.

С большим стыдом вспоминал, как я повторял «I disagree!» на последнем Face2face.

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

Кстати, сказать, как у нас «Та уборщица… какая? Ну, эфиопка ...» или «В соседнем отделе есть такой мужик умный, индус низенький такой» — тоже нельзя.
Надо объяснять о ком идет речь, не используя национальность, религию и сексуальные предпочтения.

Итак, правила для общения с американцами:

Совсем недавно серверное подразделение HP выпустило весьма интересный и в чем-то даже неожиданный продукт. Он получил говорящее название Microserver – даже не видев самого устройства можно, с одной стороны, примерно представить, о чем идет речь, а с другой – нафантазировать чего угодно. Новый сервер рассчитан на небольшие рабочие группы и ориентирован на применение в офисах, но и дома использовать его не воспрещается. На волне интереса к этой модели я решил написать пару постов о том, чем Microserver может быть полезен, и к чему его удалось приспособить.



Осторожно, много фото!

По просьбам трудящихся пишу статью про Spring IoC. Я не настолько гуру в этом вопросе, впрочем могу кое-что поведать.

Написал Стивен Тови в 2:29 утра по программированию (шутка юмора Google Translate)
Вступление от себя: эта заметка, прорекламированная Алёной C++, предназначена в основном разработчикам игр для консолей, но будет, наверное, полезна и всем, кому приходится сталкиваться с экстремальным аллоцированием динамической памяти. Возможно, любители посравнивать управление памятью в C++ и Java тоже найдут над чем задуматься.

Оригинал с небезынтересной дискуссией в комментариях: altdevblogaday.org/2011/02/12/alternatives-to-malloc-and-new

Обязательная вступительная басня

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

Рассмотрим ситуацию, когда необходимо обрабатывать столкновения между объектами. Как вы в этом случае поступите? Вероятно, самым простым решением будет проверить каждый объект с каждым другим объектом. И это правильное решение, и все будет замечательно до тех пор пока объектов не много. Как только их станет порядка нескольких тысяч, вы заметите, что все стало как-то медленно работать. А если частиц несколько десятков тысяч или сотен? Тогда все замрет. Вот здесь уже интересно, на какие хитрости и оптимизации вы пойдете, чтобы решить такую проблему.

Для простоты, будем рассматривать 2D случай, частицы круглые, радиус частиц у всех одинаковый.

Содержание

1. Обзор алгоритмов
1.1. Полный перебор
1.2. Sweep & Prune
1.3. Регулярная сеть
2. Некоторые оптимизации
2.1. Sweep & Prune
2.2. Регулярная сеть
3. Сравнение скорости выполнения
4. Приложение (программа и исходный код)
5. Заключение

Знаете сколько в памяти занимает строка? Каких только я не слышал ответов на этот вопрос, начиная от «не знаю» до «2 байта * количество символов в строке». А сколько тогда занимает пустая строка? А знаете сколько занимает объект класса Integer? А сколько будет занимать Ваш собственный объект класса с тремя Integer полями? Забавно, но ни один мой знакомый Java программист не смог ответить на эти вопросы… Да, большинству из нас это вообще не нужно и никто в реальных java проектах не будет об этом думать. Но это, ведь, как не знать объем двигателя машины на которой Вы ездите. Вы можете быть прекрасным водителем и даже не подозревать о том, что значат цифры 2.4 или 1.6 на вашей машине. Но я уверен, что найдется мало людей, которые не знакомы со значением этих цифр. Так почему же java программисты так мало знают об этой части своего инструмента?

Integer vs int

Все мы знаем, что в java — everything is an object. Кроме, пожалуй, примитивов и ссылок на сами объекты. Давайте рассмотрим две типичных ситуации:

//первый случай
int a = 300;
//второй случай
Integer b = 301;

В этих простых строках разница просто огромна, как для JVM так и для ООП. В первом случае, все что у нас есть — это 4-х байтная переменная, которая содержит значение из стека. Во втором случае у нас есть ссылочная переменная и сам объект, на который эта переменная ссылается. Следовательно, если в первом случае мы определено знаем, что занимаемый размер равен:

sizeOf(int)

то во втором:

sizeOf(reference) + sizeOf(Integer)

Забегая вперед скажу — во втором случае количество потребляемой памяти приблизительно в 5 раз больше и зависит от JVM. А теперь давайте разберемся, почему разница настолько огромна.

Из чего же состоит объект?

Прежде чем определять объем потребляемой памяти, следует разобраться, что же JVM хранит для каждого объекта:

• Заголовок объекта;
• Память для примитивных типов;
• Память для ссылочных типов;
• Смещение/выравнивание — по сути, это несколько неиспользуемых байт, что размещаются после данных самого объекта. Это сделано для того, чтобы адрес в памяти всегда был кратным машинному слову, для ускорения чтения из памяти + уменьшения количества бит для указателя на объект + предположительно для уменьшения фрагментации памяти. Стоит также отметить, что в java размер любого объекта кратен 8 байтам!

1. Вместо вступления.

Недавно пришлось разбираться в работе алгоритма Shift-Or, который позволяет найти подстроку в строке. По результатам этого разбора я и решил написать этот пост в надежде, что кому-то он поможет понять, как работает этот алгоритм, быстрее чем мне.

Собственно, главное отличие алгоритма от, например, «наивного сравнения», заключается в том, что в его основе лежит логические операции, а именно логическое умножение (оно же AND, оно же конъюнкция).

Введение

Алгоритмы нечеткого поиска (также известного как поиск по сходству или fuzzy string search) являются основой систем проверки орфографии и полноценных поисковых систем вроде Google или Yandex. Например, такие алгоритмы используются для функций наподобие «Возможно вы имели в виду …» в тех же поисковых системах.

В этой обзорной статье я рассмотрю следующие понятия, методы и алгоритмы:

• Расстояние Левенштейна
• Расстояние Дамерау-Левенштейна
• Алгоритм Bitap с модификациями от Wu и Manber
• Алгоритм расширения выборки
• Метод N-грамм
• Хеширование по сигнатуре
• BK-деревья

А также проведу сравнительное тестирование качества и производительности алгоритмов.

Вступление

Доброго времени суток, %habrauser%! Думаю, в этой статье я не открыл ничего нового. Просто меня самого заинтересовала тема продуктивного сна. Несколько последних лет я был приверженцем мнения, что сон – это бесполезная трата времени, к сожалению необходимая организму. И посему, я максимально старался сократить время сна. Но чем больше я это делал, тем больше я начинал походить на зомби. И тогда я стал искать альтернативу. И результатом обобщения всей найденной мной информацией и стала эта статья. Итак, поехали!

О чем эта статья

Одной из отличительных особенностей платформы Java является ее независимость от используемого инструментария. Вы можете разрабатывать сколь угодно большое Java приложение при помощи блокнота (vi) и командной строки. Понятно что так никто не делает и все используют какую-то IDE. Как следствие независимости от инструментов — IDE для Java много. Все это хорошо но есть одна особенность. Если Ваш коллега делал приложение и для сборки проекта использовал IDE_A то в IDE_B которая стоит у Вас — собрать приложение не получится.
В общем-то это давно уже не проблема. Хорошей практикой считается использовать систему сборки не зависящую от IDE. Для Java их две это Apache-Ant и Maven (тоже в общем-то Apache). Но тут есть один подводный камень. Если в Delphi или Visual Studio, чтобы создать и собрать приложение надо кликнуть в кнопку new пройтись по шагам визарда и нажать кнопку собрать, то написание ant скрипта для сборки например web приложения, особенно для начинающего разработчика, задача не тривиальная.
В статье рассматривается сборка и деплой Java web приложения шаг за шагом.

В целом задачу можно решить как с помощью ant так и с помощью maven, здесь будет рассмотрен ant. Для начинающих он проще и нагляднее.

Примечание 10 лет спустя

Решил посмотрел на свою статью написанную 10 лет назад. Звучит старомодно, в 2021 я в общем случае не рекомендую собирать Java приложения при помощи ant. НО если уж у вас возникла такая необходимость, то статья все еще может помочь. Пусть живет.

Данный пост является началом серии статей про оптимизацию и улучшение производительности GWT-приложений. Поскольку материала у меня накопилось достаточно много, решил разбить его на 2-3 части.
Приступим к описанию того, что нас ждёт в первой статье.

Готовясь к собеседованию, я решил освежить память да и вообще поискать каверзные и малоизвестные нюансы языка Java. Выборку пяти наиболее интересных на мой взгляд моментов я вам и предлагаю.

Вот уже подоспела и вторая часть статьи.


1. Нестатические блоки инициализации.

Всем, я думаю, известно, что в Java существуют статические блоки инициализации (class initializers), код которых выполняется при первой загрузке класса.

class Foo {
	static List<Character> abc;
	static {
		abc = new LinkedList<Character>();
		for (char c = 'A'; c <= 'Z'; ++c) {
			abc.add( c );
		}
	}
}

Но существуют также и нестатические блоки инициализации (instance initializers). Они позволяют проводить инициализацию объектов вне зависимости от того, какой конструктор был вызван или, например, вести журналирование:

class Bar {
	{
		System.out.println("Bar: новый экземпляр");
	}
}

Такой метод инициализации весьма полезен для анонимных внутренних классов, которые конструкторов иметь не могут. Кроме того, вопреки ограничению синтаксиса Java, используя их, мы можем элегантно инициализировать коллекцию:

Map<String, String> map = new HashMap<String, String>() {{
	put("паук",  "арахнид");
	put("птица", "архозавр");
	put("кит",   "зверь");
}};

Очень даже мощное средство, не находите?

JFrame frame = new JFrame() {{
	add(new JPanel() {{
		add(new JLabel("Хабрахабр?") {{
			setBackground(Color.BLACK);
			setForeground(Color.WHITE);
		}});

		add(new JButton("Торт!") {{
			addActionListener(new ActionListener() {
				public void actionPerformed(ActionEvent event) {
					System.out.println("Хабрахабр - торт!");
				}
			});
		}});
	}});
}};

Остальные четыре пункта под катом.

В заметке обсуждаются алгоритмы решета для поиска простых чисел. Мы подробно рассмотрим классическое решето Эратосфена, особенности его реализации на популярных языках программирования, параллелизацию и оптимизацию, а затем опишем более современное и быстрое решето Аткина. Если материал о решете Эратосфена предназначен в первую очередь уберечь новичков от регулярного хождения по граблям, то алгоритм решета Аткина ранее на Хабрахабре не описывался.

На снимке — скульптура абстрактного экспрессиониста Марка Ди Суверо «Решето Эратосфена», установленная в кампусе Стэнфорского университета

Timsort, в отличии от всяких там «пузырьков» и «вставок», штука относительно новая — изобретен был в 2002 году Тимом Петерсом (в честь него и назван). С тех пор он уже стал стандартным алгоритмом сортировки в Python, OpenJDK 7 и Android JDK 1.5. А чтобы понять почему — достаточно взглянуть на вот эту табличку из Википедии.



Среди, на первый взгляд, огромного выбора в таблице есть всего 7 адекватных алгоритмов (со сложностью O(n logn) в среднем и худшем случае), среди которых только 2 могут похвастаться стабильностью и сложностью O(n) в лучшем случае. Один из этих двух — это давно и хорошо всем известная «Сортировка с помощью двоичного дерева». А вот второй как-раз таки Timsort.

Алгоритм построен на той идее, что в реальном мире сортируемый массив данных часто содержат в себе упорядоченные (не важно, по возрастанию или по убыванию) подмассивы. Это и вправду часто так. На таких данных Timsort рвёт в клочья все остальные алгоритмы.