Хотите знать, как религия влияет на рабочий день, у кого самый длинный обеденный перерыв, и правда ли, что Москва никогда не спит? Но это же Хабр, а не жёлтая газета, так что историю вам поведает самый объективный рассказчик из всех — данные пользовательской активности.


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

Что-то в этом роде произошло со мной, когда я наткнулся на логи sci-hub. Вроде в интернете полно открытых данных, но чтобы заполучить журнал учёта на 195 миллионов записей — это не каждый день так везёт. Несколько недель я изучал доставшееся мне богатство, а теперь пришёл на хабр, чтобы рассказать вам, что я нарыл.

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

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

Мы — математический лагерь «Слон» — уже давно проводим летние и зимние школы для учеников 8-11 классов. Основной вид деятельности на школе — работа над крупной задачей, проектом. Это может быть что угодно от моделирования сложной физической системы до программы взлома шифров или написания игрушки под Android. Большая часть проектов на школе так или иначе связана с программированием, но редко программирование является самоцелью проекта. Школьники, которые еще не успели стать матерыми программистами, да еще и в условиях вечной нехватки времени пишут код «шоб работало». Так что мы не понаслышке знаем, что такое плохой код и каждый год встречаем всё новые, иногда удивляющие даже нас, способы сделать код нечитаемым — и каждый год решаем, что делать с этой проблемой.

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

Еще одной идеей было использовать git, «чтобы дурь каждого видна была». Тогда ближе к концу проекта можно было бы пересмотреть, с чего все начиналось и куда вывернуло, ужаснуться и делать по-другому. Однако эта идея не прошла проверку временем. По нашему опыту, школьников сложно научить пользоваться системой контроля версий, да еще и регулярно. Им непонятно, для чего СКВ нужны, а потому им скучно. Кроме того, отнимать пару часов только на освоение git — безумное расточительство для проекта длиной в одну неделю. Да и не для того системы контроля версий изначально задумывались.

Решение же, которое мы использовали этой зимой нам самим очень понравилось, поэтому считаем нужным поделиться своим методом. Мы назвали его «Безумное чаепитие».
Итак, задача: научить школьников писать понятный и аккуратный код. При этом надо сделать этот процесс увлекательным…

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

Данная статья написана под влиянием книги Дэвида Коупленда «Build Awesome Command-Line Application in Ruby» (купить, скачать и изучить дополнительные материалы). Большая её часть будет посвящена проектированию дизайна CLI-приложений вне зависимости от используемого языка. По ходу будут обсуждаться и вещи специфичные для ruby, но не страшно, если вы его не знаете, кода будет не слишком много. Можно считать эту статью довольно подробным обзором вышеупомянутой книги с вкраплениями собственного опыта. Книжку рекомендую!

Для начала я задам вопрос. Если посмотреть на сообщества IT-шников, можно заметить, что несмотря на обилие программ с красивым графическим интерфейсом, приложения командной строки остаются весьма популярны. Почему?
Ответов несколько. Во-первых, это красиво удобно — если вы можете описать задачу командой в командной строке, то её гораздо проще автоматизировать, чем если вам приходится анализировать передвижения мыши и клики на разные пункты меню. Во-вторых, это даёт возможность комбинировать программы невероятным числом способов, чего сложно добиться с помощью графических интерфейсов.
В значительной степени философия Unix базируется на том принципе, что множество маленьких утилит, каждая из которых умеет делать свою конкретную задачу — это лучше, чем одна многофункциональная программа-универсал. И это одна из причин успеха Unix-систем в мире IT-шников.
Наверное, каждый понимает, что обычного пользователя вряд ли удастся сманить от GUI к CLI, давайте сосредоточимся на нас, «компьютерщиках» и конкретизируем наши пожелания к CLI-приложениям.

Недавно вышла книга The dRuby book — distributed and parallel computing with Ruby (перевод японской книги, написанной автором самой библиотеки). В этой статье я попытаюсь дать обзор глав книги, касающихся библиотеки DRb. Если вам захочется ознакомиться с темой более подробно, книгу можно купить или скачать. Сразу скажу, что я не буду говорить в этом посте ни о синхронизации потоков, ни о библиотеке Rinda.

Предположим, что вы пишите систему, которая работает с более чем одним процессом. Например, у вас есть веб-сервер, который в фоновом режиме запускает задачи, работающие долгое время. Или вам просто нужно обеспечить пересылку данных из одного процесса в другой и координировать их. Для таких ситуаций и нужна библиотека DRb. Она написана целиком на Ruby и включена в стандартную библиотеку, поэтому начать работать с ней можно моментально. Для её подключения достаточно написать require 'drb'

Достоинства библиотеки DRb большей частью проистекают из динамичности самого языка Ruby.
Во-первых, при затрате минимальных усилий на подготовительном этапе, дальше вы работаете с объектами не задумываясь, где они расположены: в одном процессе или в другом. Библиотека полностью маскирует от вас все технические детали.
Во-вторых, вы не обязаны жестко прописывать интерфейс. Любой руби-объект может выставить свой интерфейс наружу — таким образом вы можете как воспользоваться функциональностью одного из стандартных классов типа Hash или Queue, а можете сделать свой класс с любым интерфейсом. Кроме того вам ничто не мешает менять интерфейс прямо в процессе исполнения, и даже использовать method_missing для обработки любых запросов. И уж разумеется, обновление интерфейса сервера вообще никак не влияет на клиента, если тот не вызывает методы, которые изменили сигнатуру или поведение. Таким образом сервер и клиент максимально независимы.
И наконец, клиент даже не обязан знать классы объектов, которые ему возвращает сервер, он может их использовать и без этого. Таким образом сервер волен скрыть столько много деталей, сколько ему угодно.
Но, конечно, есть и подводные камни, и их предостаточно. К счастью, dRuby несложен в понимании, ну а понимание его устройства позволяет большей части проблем просто не допускать. Документация к этой библиотеке, к сожалению, не проясняет множества моментов, поэтому статья будет интересна и новичкам, и людям уже поработавшим с библиотекой.

Добрый день, Хабр.
Я около года работаю с Ruby и хотел бы написать о некоторых вещах, которых лично мне там часто не хватает, и которые я хотел бы видеть встроенными в язык. Пожалуй лишь пара из этих пунктов являются действительно серьезными недоработками, с остальными можно легко справиться подручными средствами.
Вроде бы недоработки и мелочь, но они ощутимо осложняют работу — приходится писать собственные библиотеки вспомогательных методов, которые и в гем не выделишь — уж больно маленькие, и без них некомфортно. А порой открываешь чужой код — и видишь там точно такие же вспомогательные функции как у тебя. Это как мне думается знак, что стандартная библиотека языка недоработана. Что же, будем надеяться, кто-нибудь из разработчиков прочтет текст и закоммитит патч. ;-)
Итак, начнем по порядку:

• Перегрузка метода разными списками аргументов, как в C++
• Отобразить хэш и получить из него другой хэш, а не массив
• Преобразовать экземпляр класса в экземпляр его же собственного подкласса
• Разные рюшечки