Murgab

Отличный лайфхак для путешественников с сильно ограниченным бюджетом. Можно одним махом посетить и Дублин, и Париж, и Бали:

Ну и, заодно, как тут подсказали, для особых экстремалов, из Минска есть прямые рейсы на Марс (с пересадкой на/в Юпитере):

(При этом все дороги проходят через Бобруйск!)

Немного освежим память классикой баяностроения:

Ну… или если выйти за рамки еще немного дальше, то:

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

И это еще в лучшем случае, т.к. здесь иерархия не такая ветвистая и мало узлов. Бывают случаи, где вывод совершенно нечитаем человеком. И вот в таких случаях можно использовать какой-то инструмент для того, чтобы «причесать JSON» (еще это называют термином pretty print).

Один из нескольких вариантов — замечательная утилита jq, делающая JSON вполне удобочитаемым и визуально структурированным:

Как видно, запрос curl-лом мы отправили по конвейеру в jq ., в данном случае точка после команды является аргументом, означающим, что от jq требуется выдать все узлы, находящиеся в корне иерархии. Вместо точки можно указывать конкретный путь, состоящий из ключей, разделяемых точками — например:

В данном примере мы попросили вывести jq лишь необходимую часть JSON, а именно — раздел weather со всем содержимым. Можно фильтровать и дальше по дереву. Например, jq .person.name.surname.

Информация об установке (например, в Ubuntu jq уже есть в репозитариях — sudo apt install jq) и примеры фильтров доступны на официальном сайте jq.

Как гласит недавний отчет Stack Overflow (а также отчеты GitHub), самый популярный язык программирования в мире на данный момент — JavaScript. Отчасти язык популярен своей небывалой распространенностью в браузерах, отчастью он обязан своей популярностью и серверной платформе NodeJS, позволяющей писать программы, выполняемые не только в браузерах клиентских машин, но и на серверах.

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

Такая модульность стала своего рода традицией экосистемы NPM. Модули стали писать по случаю и без. На каждый чих — свой модуль, и вряд ли еще остались слова английского (и не только) языка, не занятые под название модуля с модной припиской “JS” на конце.

И вот эта страсть к высокодробной модульности и вышла NPM и его обитателям боком. На неделе разгорелся небольшой скандал на почве обрушения части NPM из-за смешного инцидента. Некий Азер Кочулу (Azer Koçulu), автор более 250 модулей к NodeJS, являвшийся владельцем модуля под названием kik, получил письмо от сотрудников мессенджера Kik, попросившего его уступить им «кошерное» название в NPM. Азер отказался пойти навстречу, и сотрудники мессенджера Kik отправили аналогичное письмо руководству платформы NPM. NPM решила отнять у Азера красивое имя для модуля и отдать его мессенджеру Kik. Тут Азер, по понятным причинам, негодуя от такой несправедливости, выпилил весь свой зоопарк модулей с NPM (напомню, это более 250 наименований)...

И тут главный прикол всего цирка: оказалось, что от его модулей зависит куча крупных проектов, в числе которых такие монстры, как Фейсбуковский React, JavaScript-транскомпилятор Babel и, по цепочке, огромное количество других модулей и программ. А так как Азер отозвал свои поделия, то вся эта инфраструктура рухнула как карточный домик. И что еще более смешно в этой непростой ситуации, модуль под названием leftpad, от которого зависило множество других крупных проектов, состоял из… 11 строчек кода! И ладно бы в этих 11 строках кода были бы заключена вселенская мудрость или хотя бы результат большой научной работы, сконцентрированный в лаконичную формулировку (E = mc²). Нет, модуль делал довольно тупую и банальную вещь — добавлял нули или пробелы в левой части заданной строки или числа!

module.exports = leftpad;
function leftpad (str, len, ch) {
  str = String(str);
  var i = -1;
  if (!ch && ch !== 0) ch = ' ';
  len = len - str.length;
  while (++i < len) {
    str = ch + str;
  }
  return str;
}

То есть, сложно представить себе более банальную вещь, чем эти 11 строчек кода (две из которых — фигурные скобки). В Python, например, эта функция вообще встроена в язык и делается простейшим форматированием строки:

'{0:06d}'.format(6)

То есть, крупнейшие и сложнейшие проекты включили в себя модуль из десятка строк тупого кода, который можно было бы оформить буквально за две минуты самостоятельно (без создания лишних зависимостей). И в среде NPM такое на каждом шагу — это часть культуры! Прекрасным примером этому может послужить небольшое исследование Дэвида Хейни (David Haney), который прошерстил NPM на предмет наличия подобных «модулей».

Например, оказалось, что есть такой замечательный модуль, как isArray. Этот модуль скачало 880 000 человек за один день, кроме того, он был загружен 18 миллионов раз только в одном феврале этого года! От этого модуля напрямую зависят 72 пакета в NPM. И что же это за чудесный модуль такой?

return toString.call(arr) == '[object Array]';

А модуль этот состоит из одной. ОДНОЙ! Строчки дурацкого кода, приведенного выше. И призван проверять — не массив ли перед нами…

Есть еще один чудесный модуль с говорящим названием is-positive-integer (GitHub), до смешного банальный — он проверяет, положительное ли целое число ему передано. Состоит из целых четырех строк кода (!!!) и (внимание!) требует три зависимости для своей работы! То есть требовал, недавно автор «отрефакторил» свой код, и теперь его важнейший модуль не требует зависимостей вообще (вот он — подвиг программиста)!

А вот еще один пример, приведенный в комментариях на Хабре — очередной модуль «для проверки типа» — isnumber. Одна тупая строчка:

return !isNaN(parseFloat(n)) && isFinite(n);

И вот такая вот развесистая система приводит к тому, что какой-нибудь Babel включает в себя 41 000 файлов (и это свежеустановленный пакет!), а также генерирует чистый шаблонный проект (jspm/npm) с… более чем 28 000 файлов! Эта, вроде бы неплохая изначально идея компактных модулей, была доведена до полнейшего, абсолютного, феерического абсурда. Мало того, что с каждой такой дурацкой зависимостью вы добавляете еще одну точку отказа в своем коде (которую нельзя потом оперативно отладить), так еще и автоматически полагаетесь на качество кода горе-программистов (типа упомянутого выше, что проверял положительность целого числа тремя зависимостями).

P.S. Кстати, теперь уже печально известный модуль leftpad, удаленный Азером, в итоге восстановили без его одобрения, в качестве экстренной меры, чтобы не «поломать систему».

Crontab.guru — очень удобный сервис для проверки/составления правил планировщика cron. Вбиваете в пять полей цифры и смотрите по описанию сверху — совпадает ли «формула» с желаемым поведением.

Cостоялся релиз первой стабильной версии операционной системы MenuetOS 64.

Операционная система написана полностью на ассемблере (!), уже поддерживает работу с сетью (TCP/IP, адаптеры Ethernet), различные устройства вроде принтеров, веб-камер, USB-накопителей и даже DVB-тюнеров. Имеется поддержка аудиокодеков AC97 и Intel HDA (ALC662/888).

Ах да, работа над проектом ведется 15 лет, и, как упоминается на официальном сайте, ОС умещается на одном флоппи-диске (а это 1,4 мегабайта).

Под катом еще несколько любопытных скриншотов...

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

Исследователям из IBM удалось собрать аппарат, записывающий до 220 терабайт данных (что примерно в 110 раз больше чем на обычном жестком диске компьютера!) на одну катушку обычной дешевой магнитной пленки:

Исследователи записали 123 миллиарда бит несжатых данных на каждый квадратный дюйм дешевой магнитной ленты. На весь картридж поместили 220 терабайт информации. Так ученые превысили в 88 раз существующий с 2012 года стандарт LTO-6, который предусматривал 2,5 ТБ данных на продукт среднего класса.

Это устройство, как утверждают ученые из IBM, способно записывать данные на магнитную ленту с эффективностью в 123 миллиарда бит на квадратный дюйм. Ученые использовали кассету диаметром 10 сантиметров и шириной 2 сантиметра.

«Лента в самом деле растет», — говорит Марк Ланц, руководитель исследовательской группы IBM Research в Цюрихе, Швейцария. В то время как на потребительском и SMB рынках спрос на магнитные ленты падает из-за снижения цен на жесткие диски, архивные технологии «возрождают» это устройство хранения информации. Еще один фактор возрождения магнитной ленты — замедление роста объемов жесткого диска, который с трудом поспевает за законом Мура, отмечает Ланц.

IBM пока не анонсирует готовый продукт, но видит его будущее в облачных системах хранения. По данным Ланца, несколько компаний предлагают облачные решения с использованием магнитной ленты. Преимущество технологии — в цене: каждый гигабайт стоит от 2 до 3 центов. А минус — во времени, потому что от нескольких десятков секунд до минуты требуется для доступа к файлам. Технология подходит для тех данных, работа с которыми не требует высокой скорости. В частности, около 80% корпоративных данных можно записать на ленту.

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

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

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

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

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

Инженеры уже давно присматривались к алюминию как к недорогой и практичной замене лития, однако до сего момента им не удавалось сделать батарею, выдававшую приемлемое напряжение после множества циклов зарядки и разрядки. В отличие от предыдущих неудачных прототипов алюминиевых батарей, умиравших после сотни циклов зарядки, экспериментальная батарея выдержала в лаборатории 7500 циклов без какой бы то ни было деградации. Для сравнения, типичная литий-ионная батарея теряет 80% ёмкости после 600 циклов зарядки/разрядки.

Батарея состоит из алюминиевого анода и графитового катода, погруженных в электролит и заключенных в гибкую полимерную оболочку. Такое сочетание было найдено в ходе экспериментов практически случайно. По словам исследователей, прототип выдаёт напряжение порядка 2 В и имеет удельную ёмкость порядка 70 мA-ч/г.

Удельная энергия типичной литий-ионной батареи составляет от 100 до 265 Вт-ч/кг. Для новой батареи этот показатель составил порядка 140 Вт-ч/кг. Плотность тока алюминиевого прототипа — 3000 Вт/кг, что более чем на порядок превосходит аналогичный показатель литий-ионных батарей.

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

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

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

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

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

1. Для создания нового пароля вы берете префикс — началом вашего нового шифра будет надпись на «пробеле» карточки. В случае с приведенной выше картинкой, это sh(/J3Hq.
2. Далее вы добавляете свое секретное слово, пусть это будет MURGAB ;) — каждую букву этого слова вы кодируете в соответствии с виртуальной клавиатурой. То есть, MURGAB превращается в u92s. — эту белиберду добавляем к *sh(/J3Hq, получается — sh(/J3Hqu92s.***.
3. Затем добавляем к нашему итак уже непростому паролю окончание — название сайта. Кодируем его точно так же, в соответствии с виртуальной клавиатурой. Например, сайт для которого создаем пароль — vk.com, который через «аналоговое кодирование» превращается в M1.mqu — этим и завершаем созданный пароль: sh(/J3Hqu92s.*M1.mqu.

sh(/J3Hqu92s.*M1.mqu — готовый пароль для ВКонтактика

Расшифровать такой пароль при наличии карточки или ее фотографии на смартфоне, будет очень даже просто — вбиваете код с карточки, вбиваете свое секретное слово, а затем название сайта, на который хотите зайти. При этом все, что нужно помнить для захода на ЛЮБОЙ сайт с суперсложным паролем — это ваш простейший секретный код.

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

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

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

Хороший пример книжной тягомотины — очередная книга, которую я начал читать, с очередным желанием ее тут же забросить. Вот, полюбуйтесь-ка, 14-я страница:

Книга REST in Practice, если это конечно кому интересно

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

На следующей странице меня уже просят рассказать — нравится ли мне эта книга? Причем рассказать это предлагают предварительно вручную перепечатав километровый машинный урл с бумаги в браузер (книга о современных web-технологиях):

А еще через три страницы — на 18-й — мне рассказывают кому они выражают свою признательность. Конечно, тем, кого я знать не знаю и никогда в жизни не узнаю.

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

Книга Eric Sink on the Business of Software

Здесь автор сразу говорит «простите, не мог удержаться от такой маленькой глупости, как „раздел благодарностей“, но все равно этот раздел все пропускают, так ведь?».