О публикации кода на Github или другом открытом хостинге часто говорят, как о такой живительной эвтаназии, после которой патчи, фиксы, сообщения о проблемах и прочие коммиты от сторонних разработчиков польются рекой. У меня пока противоположный опыт. В парочку моих относительно заметных проектов вообще никто и ничего реально не привнес, не говоря уж об остальных проектах. Более того, я несколько раз делал очень серьезные изменения/улучшения в чужие проекты, но их авторы морозились и не приняли изменения. Исходя из этого я развил теорию: мол, вся эта открытость и коллаборация — это красивые слова, реально все пилят что-то свое и зарабатывать деньги или пиар кому-то другому совершенно не горят желанием. Чтобы проверить теорию, я посчитал кое-какую статистику по всем репозиториям на Github, у которых больше 700 звездочек, таких чуть больше 4 тысяч.

Эта статья иллюстрирует т. н. компромисс скорости и памяти — правило, которое выполняется во многих областях CS, — на примере разных реализаций хеш-таблиц на Java. Чем больше памяти занимает хеш-таблица, тем быстрее выполняются операции над ней (например, взятие значения по ключу).

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

API — это большая сила и большая ответственность. У хорошего API будут благодарные пользователи; поддержка плохого превратится в кошмар.

Публичный API — не воробей, опубликуешь — не уберешь. Есть только одна попытка сделать все правильно, поэтому постарайся.

API должно быть легко использовать, но сложно использовать неправильно. Сделать что-то простое с помощью такого API должно быть просто; сложное — возможно; сделать что-то неправильно должно быть невозможно, или, по крайней мере, трудно.

API должен описывать сам себя. Изучение кода на таком API не вызывает желания читать комментарии. Вообще, комментарии редко нужны.

Перед разработкой API собери требования с долей здорового скептицизма. Осознай общие задачи и реши их.

Оформляй требования как шаблоны использования API. Сверяйся с ними в процессе проектирования.

Этот пост — вольно-краткий перевод документа State of the Values, предложения по введению типов-значений в JVM и сам язык Java, который написали Джон Роуз, Брайан Гоетц и Гай Стил, разбавленный моими мыслями. Опущены детали предложения по реализации типов-значений на уровне байт-кода, что не очень интересно для большинства Java-программистов.

---

Важнейшая мысль: объектная (ссылочная) идентичность нужна только для поддержки изменяемости объектов. Объект может изменить состояние, но по ссылке мы всегда можем проверить, что это «тот же» объект. Поэтому типы-значения будут строго неизменяемые.

Предполагаемые варианты использования типов-значений:

• Числа: комплексные, беззнаковые, 128-битные, с фиксированной запятой и т. д. Все, что не описывается имеющимися примитивами.
• Алгебраические типы: Optional, Choice<T,U>, перечисления
  Кортежи: пары, тройки, ...
  Итераторы, курсоры
  «Уплощение» сложных структур
  

Целевые фичи:

Rust — компилируемый мультипарадигмальный язык, позиционируется как альтернатива С/С++ с уклоном в параллельные вычисления, безопасность и удобство работы с памятью.

Что нового в Rust 0.10:

Цель опросов — узнать «расклад сил» на домашних компьютерах и ноутбуках. Во всех опросах можно выбирать несколько вариантов.

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

Предыдущие опросы про дистрибутивы:
Какие дистрибутивы свободных ОС Вы используете? — 13 января 2010
Какие дистрибутивы Linux вы используете на десктопах? — 27 ноября 2011

Предыдущие опросы про рабочие среды и оболочки:
Ваша домашняя «рабочая среда»? — 15 июня 2007
Каким рабочим столом преимущественно пользуетесь? — 17 июля 2009
Какой рабочей средой вы обычно пользуетесь? — 11 января 2012
Ваша основная среда рабочего стола в linux — 22 мая 2012

Пост боли.

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

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

Ужас	Нормально	Лучше всего
На JavaScript-е На javascript'e	На JavaScript На Яваскрипте, на Джаваскрипте	На JS
php-шник phpист	PHP-программист Пехепист	Избегать таких выражений, если это возможно без ущерба для смысла. Просто «программист».

Давно на Хабре не было опросов про популярность языков программирования. Идея опроса возникла из спора о популярности языка D в топике о новых возможностях C++. Существующие рейтинги: RedMonk, TIOBE, LangPop.com слишком косвенно меряют непонятно что.

Цель этих опросов: определить соотношение кол-ва людей, которые пишут на том или ином языке сейчас.

90% контента на Хабре генерируют обычные пользователи. Привлечение специалистов к написанию постов в интересах не только сообщества, но и владельцев сайта. В этом плане у Хабра есть давняя проблема: отдача от поста зачастую обратно пропорциональна трудности его создания. Частично ее решили выделением «тематических» хабов. Инвайты и баллы в ППА дают только за посты в тематических хабах. Однако, у этой системы есть проблемы:

• Судя по списку «тематических» хабов, их точнее описывает слово «техничность». Корреляция между «техничностью» поста и темой (хабом) далеко не 100%. Результат: авторы стремятся добавить пост хоть в один тематический хаб, иногда необоснованно.
• На мой взгляд, «техничность» — это немного не та метрика, которую надо поощрять. Что я предлагаю взамен — ниже.
• Поощрения не распространяется на карму, рейтинг и обеспечение внимания к посту.

Разделение новостей и статей решит проблему поощрения гораздо лучше.

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

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

Около месяца назад на Хабре была статья про Trove — самую часто упоминаемую библиотеку, когда спрашивают про структуры данных с примитивами на Java. Примерно за пару дней до этого я сел эту библиотеку переписывать. Время решительно кончилось, поэтому делюсь поиском с вами, хотя не очень-то надеюсь, что кто-то продолжит это дело.

На данный момент сделаны хеш-таблицы 6 типов: множества примитивов, объектов и все 4 варианта мапов: примитив — примитив, примитив — объект, объект — примитив и объект — объект, над которыми нависает туча обобщающих интерфейсов.

Меня всегда удивляло, почему все подобные библиотеки создают еще одну иерархию типов, а не встраиваются в давно уже зарекомендовавший себя стандартный каркас коллекций Явы. Никаких принципиальных проблем с этим я не видел и не вижу. Поэтому над моей тучей интерфейсов, как на пантеоне, возвышаются java.lang.Iterable, java.util.Collection и java.util.Map. Я не зря дал ссылки на документацию по Java 8. Реализованы почти все методы из будущих интерфейсов, кроме spliterator(). Можно начинать привыкать.

Вопрос возник, потому что сам очень плохо помню стандартные АПИ языков, на которых часто пишу (Python, Java, JS). Это снижает производительность и настораживает: доктор, а я один такой?

В опросе верстальщики могут считать «стандартной библиотекой» атрибуты HTML-тегов и CSS-свойства.

На идею опросов меня навела статья человека, на год отказавшегося от интернета.

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

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

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

Вот как на жизненные ориентиры мужчин влияет пристрастие к спиртному:

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

В анализе Фейсбука, который провел Стивен Вольфрам, мне особенно понравились графики изменения интересов людей в зависимости от пола и возраста. Поэтому я решил посчитать нечто похожее для отечественной соцсети ВКонтакте. В анкете ВКонтакте есть любопытная группа полей — «Жизненная позиция», по значениям которых можно искать фактически в реляционном стиле. Поэтому от меня не требовалось разворачивать мощную data mining инфраструктуру, а лишь обработать результаты нескольких сотен GET-запросов.

Для начала — общее кол-во людей по возрастам:

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

GHC (Glasgow Haskell Compiler) — стандартный компилятор Хаскеля. GHC — один из самых крутых компиляторов в мире, но к сожалению без дополнительных телодвижений скомпилированные им программы по скорости больше напоминают интерпретируемые, т. е. работают очень медленно. Однако если раскрыть весь потенциал компилятора, Хаскель приближается по производительности к аналогичному коду на C.

В этой статье я обобщаю опыт выжимания максимума из GHC при создании dataflow-фреймворка Yarr.

Зондирование обстановки на Реддите показало, что едва ли хоть кто-то всерьез занимается обработкой изображений на Хаскеле, несмотря на то, что достаточно популярная библиотека Repa предполагает работу с изображениями как одно из основных приложений. Надеюсь, ситуацию сможет изменить библиотека Yarr (документация, гитхаб).

Я называю библиотеку dataflow-фреймворком, потому что она обобщена для обработки массивов (от одномерных до трехмерных) элементов любых типов, в том числе векторов чисел, например координат, комплексных чисел. Но основное предполагаемое применение — обработка двумерных массивов из векторов цветовых компонент, т. е. изображений. Фреймворк непосредственно не содержит алгоритмов обработки изображений, а предоставляет мощную инфраструктуру для их написания.

 

В моей статье полугодичной давности о длинной арифметике есть замеры скорости (throughput в тактах) очень коротких фрагментов кода — всего по несколько инструкций. Методика измерения была кривовата, но давала правдоподобные результаты. Потом выяснилось, что результаты таки неверные — поверхностный подход всегда сказывается.

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

 

Да, об «агрессивной» политике распространения своего софта компанией Mail.ru Group и про Guard@Mail.Ru в частности уже не раз писали на Хабре (для тех, кто все пропустил — ссылка1, ссылка2), но я считаю необходимым придать подробному разбору новых особенностей работы программы самую широкую огласку.

Итак, теперь десктопная экосистема Mail.ru умеет

• Без предупреждения удалять из системы продукты Рамблера, QIP, get-styles и панель Яндекса для Оперы.
• Перенаправлять любые запросы к Firefox на Поиск@Mail.ru.
• Предлагать установить браузер Интернет@Mail.ru во время использования других браузеров.
• Ну и разумеется, защита поисковых настроек стала еще надежнее!

Установить Guard@Mail.ru очень просто. Для этого достаточно снять соответствующие галочки при установке Агента, ICQ, Спутника и других программ Mail.ru.

Подробности, скриншоты, детали расследования — roem.ru/2012/03/02/mail43740