Java vs. C#… Что может быть лучше вечного спора? Нет, данная статья не посвящена очередному бенчмарку, и даже не является holy war, не стоит даже вопрос: «кто круче».

Для каждой задачи существует свой инструмент. Сравнивать C# и Ruby, например, не имеет смысла, т.к. их целевое предназначение совершенно разное, да и природа также. Однако именно C# и Java являются наиболее близкими по своей философии.

Очень часто коллеги, пишущие на Java, даже не подозревают о многих (!!!) вещах, которые предоставляет (или, наоборот не предоставляет) C#.

Если Вам интересно посмотреть на C# и Java без субъективизма, а также узнать внутреннее устройство той или иной возможности, тогда вперед.

Мы с другом решаем пойти в поход от Сан Франциско до Лос Аджелеса, чтобы заскочить в гости к нашим друзьям на Ньюпорт Бич. Посмотрим на карту и примерно прикинем путь по берегу:



Путь займёт около 400 миль, в день мы можем пройти 4 мили в час по десять часов, так что придём мы туда примерно через 10 дней. Мы звоним друзьям и бронируем столик на 6 вечера в воскресенье.

Осенью 2011 года Google обновил интерфейс Google Reader, но убрал его социальную часть. Реакция пользователей была негативной, петицию о возвращении старого ридера подписало более 13 000 человек, а в защиту уютного сообщества sharebros высказались публично все, кто мог, включая экс-проджект-менеджера Google Reader. Отчаявшись ждать, пока выйдут обещанные аналоги, мы втроём случайно объединились и сделали The Old Reader — примерно за шесть недель, в свободное от основных работ время.

Текущая бета-версия The Old Reader — это RSS-ридер с возможностью добавлять друзей, делиться записями друг с другом и обсуждать это в комментариях. Авторизироваться и искать друзей можно через Facebook и Google, а импортировать подписки — из Google Reader напрямую или из OPML-файла. The Old Reader не спамит ваши контакты и не мусорит в Фейсбук-таймлайн сообщениями вида «N прочитал очередную статью о новых десяти дизайнерских кедах этой недели» (но эту опцию можно, по желанию, включить отдельно).

Неделю назад утекла база хешей с LinkedIn, для других это событие может быть примечательным само по себе, но для меня, в первую очередь, это означает возможность провести анализ современных возможностей взлома паролей. И я не собираюсь рассказывать о том сколько раз слово «password» было встречено среди паролей и о том, сколько времени занимает перебор шестисимвольных комбинаций. Скорее буду пугать пользователей тем, насколько сложные пароли можно «взломать» за несколько часов. А программистам расскажу как это возможно эффективно реализовать, и в качестве небольшого подарка приложу программу, которую я написал для массового аудита. Присутствует и некоторый ликбез по использованию радужных таблиц с простыми выводами.

И так, за час удалось «восстановить» около 2.5 миллионов паролей на средней рабочей конфигурации, без специальных словарей и радужных таблиц. Среди найденных паролей присутствуют 16-символьные алфавитно-цифровые комбинации, и далеко не в единственном экземпляре.

В этом выпуске:

• IT-интегратор, переквалифицировавшийся из HR-агентства
• Люди в длинных одеждах в офисе Аби^*
• 6-летний водитель самосвала
• Скандалы, интриги, расследования

А если серьёзно, то расскажем в общих чертах о переписи в стране с особым восточным колоритом.

Как знают постоянные читатели нашего блога, мы делаем не только Lingvo и FineReader, но и программы, которые извлекают данные из форм. Некоторое время назад их стали активно использовать для обработки переписей населения: мы помогали считать переписные листы в Греции, Литве, Саудовской Аравии, Таджикистане и Кувейте. В Кувейте проект получился, пожалуй, самым интересным – о нем мы и расскажем под катом.
^{* Реальных фото не сохранилось, а выложенное воспроизвели по памяти}

В продолжение предыдущего топика "Как на самом деле работает мозг". На написание данного поста меня побудила, с одной стороны, замечательная книга «Grooming, Gossip, and the Evolution of Language» Робина Данбара (Robin Dunbar), а с другой — очередная порция «полезных» и «умных» советов в GTD и других блогах.

Для затравки — небольшая логическая задачка. Дан набор карточек; на каждой из них на одной стороне написана буква, на другой — цифра.
На столе лежат четыре карточки: «А», «Д», «5» и «6». Вам говорят: если на карточке (из числа лежащих на столе) на одной стороне гласная, то на обороте — чётная цифра. Какие из карточек достаточно перевернуть, чтобы однозначно подтвердить или опровергнуть это утверждение?

Подумайте немного, запишите ответ на бумажке и добро пожаловать под кат.

Наш новый знакомый W32.Flamer не перестает удивлять. Сегодня мы расскажем о потенциале использования технологий Bluetooth этим червём.

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

Фундаментальный поворот к параллелизму в программировании

Автор: Герб Саттер
Перевод: Александр Качанов

The Free Lunch Is Over: A Fundamental Turn Toward Concurrency in Software
(By Herb Sutter)

Ссылка на оригинал статьи: www.gotw.ca/publications/concurrency-ddj.htm

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

Данная статья достаточно старая. Ей уже 7 лет, если считать с момента ее первой публикации в начале 2005 года. Помните об этом, когда будете читать перевод, так как многие вещи, которые для вас уже стали привычными, для автора статьи в 2005 году были в новинку и только-только появлялись.

Канадский разработчик Стив Ханов (Steve Hanov) рассказывает о простом способе повысить эффективность A/B-тестирования.

Суть заключается в использовании жадного алгоритма (epsilon-greedy method) для решения задачи о многоруком бандите. Другими словами, при выборе между вариантами A/B-тестирования Стив предлагает отказаться от полного рандома, а в 90% случаев выбирать лучший вариант по результатам накопленной к настоящему моменту статистики.

Метод прост до гениальности.

Недавно начала вести курсы по основам тестирования, и так получилось, что группа собралась из одних программистов. И каково же было мое удивление, когда люди, задействованные в разработке программного обеспечения, ничего не знают о тестировании. Умные ребята, продвинутые программисты, хорошо разбирающиеся в своей предметной области, ничего не знают о том, как тестировать ими же написанное программное обеспечение.
Несмотря на то, что тестрование существует уже давно, это еще молодое развивающееся направление, про которое зачастую мало что знают, за пределами отдела тестирования. И тогда я задумалась, почему люди идут работать тестировщиками, или наоборот не идут. Движут ли ими какие-то предубеждения и мифы. Как-то на глаза попалась статья Майка Брауна (Mike Brown) про 5 мифов в тестировании, переводом которой хочу с вами поделиться:

Привет!

Ребята с ресурса Data Visualization собрали несколько очень интересных решений для представления данных:



Datavisualization.ch Selected Tools

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

Datavisualization.ch является одним из ведущих ресурсов в интернете, рассказывающих о визуализации данных и инфографике. На сайте обсуждаются и исследуются интересные и инновационные идеи в этих областях.

Много лет подряд в качестве системы контроля версий для большого количества проектов использовали только SVN. Но наступил момент, когда количество разработчиков на одном из проектов заметно увеличилось, проект уже запущен в работу, и нужно как активно разрабатывать параллельно несколько фич, так и фиксить уже имеющиеся баги в оперативном режиме. Единый trunk в SVN не позволяет этого делать, а организация бранчей в нем же превращает жизнь разработчиков в ад. Поэтому было принято решение о переезде этого проекта с SVN на Git.

Разрабатывая приложения, мы постоянно сталкиваемся с новыми подходами, языками и концептами. И постоянно мы мечемся в сомнениях «смогу ли я быть на волне, оставаться конкурентоспособным, учитывая все изменения и тренды?». Давайте задумаемся на мгновение, вспомнив фразу из моего любимого фильма «Касабланка» — в любви законов новых нет — так создан свет.

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

Давно не было таких чудесных работ, все гениальное просто.

(Перевод)

Последние несколько лет я провел в изучении и экспериментах со многими языками программирования. В частности, я начал использовать Scala как основной язык, стараюсь использовать функциональный стиль везде где это возможно. Меня также весьма заинтересовал Haskell (чистый функциональный язык) и Clojure (современный диалект Лиспа).

Таким образом, я постепенно отказываюсь от объектно-ориентированной парадигмы, несмотря на то, что использовал в основном её последние 17 лет моей профессиональной деятельности. У меня появляется чувство, что объекты это то, что мешает нам писать лапидарный, структурированный и повторно используемый код.

Этот текст — перевод статьи Джеймса Алтачера, посвященной прокрастинации (или отлыниванию от работы), то есть тому, чем многие из нас регулярно занимаются. Автор высказывает свою точку зрения — прокрастинация не является исключительно негативным явлением и может обладать преимуществами.
Джеймс Алтачер (James Altucher) – предприниматель, инвестор, управляющий директор Formula Capital, основатель Stockpickr.com. Известный блоггер. Обладатель именной статьи про себя в Википедии.

Существует стереотип, что «IT»-шник должен сидеть в полумраке, освещаемый лишь светом монитора. Не знаю как вам, а мне всегда было комфортнее при ярком освещении. Сначала это было 3x100W обычных лампочек, потом 250W люминесцентных ламп, после последнего переезда — одна 500W галогенка… Но этого все-же было недостаточно. Всегда хотелось иметь такое освещение, чтобы не хотелось свет сделать ярче. О создании такой люстры я сейчас и расскажу.

Обновляя недавно дизайн своего хомяка, подумал – а не сделать ли мне какую-нибудь необычную страницу с 404-й ошибкой? Поскольку в детстве я был впечатлен Жизнью Конуэя (как возможно и многие из читателей), решил её на JS и реализовать.

Казалось бы, что сложного в Жизни: если у занятой клетки 2 или 3 соседа – она остается, если у пустой ровно 3 – рождается? В этой статье я расскажу о своей оптимизации алгоритма и отрисовки на canvas-е, некоторых не очевидных моментах целочисленной/бинарной арифметики в JavaScript.

Забегая вперед, конечный результат можно увидеть тут, исходники видны там же (да еще и по лицензии CC BY).

В этой статье Джон Скит будет описывать как простейшие конструкции языка замедляют вашу программу и как их можно ускорить.

Как и в любой работе, сваязанной с производительностью приложений, результат может варьироваться в зависимости от условий (в частности, например, 64-разрядный JIT может работать несколько иначе), и в большинстве случаев это не должно вас волновать. Несмотря на это, относительно небольшое количество разработчиков пишут продакшен-код, состоящий из большого количества микрооптимизаций. Потому, пожалуйста, не принимайте этот пост как призыв к усложнению кода ради иррациональной оптимизации, которая якобы ускорит вашу программу. Используйте это только там, где это реально может понадобиться.

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

Мы все «немного читали» об оптимизации работы с памятью, и у нас отложилось, что полезно, когда «кэш остается горячим», то есть данные, к которым часто обращаются потоки, должны быть компактными и находиться в ближайшем к процессорному ядру кэше. Все так, но когда дело доходит до того, чтобы делиться доступом, потоки становятся злейшими врагами [производительности], а кэш не просто горячий, он аж «горит адским огнем» – такая во круг него разворачивается борьба.

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