Здравствуй, уважаемый Хабр!

Многие из нас проводили разного рода манипуляции с аудиофайлами. Часто тут хочется намного большего, чем позволяет стандартный инструмент Windows под названием «Звукозапись». Тут на помощь приходят специализированные инструменты, платные и бесплатные, которые найти не проблема. Но что делать, если требуется выполнение очень специфичных операций? Настолько специфичных, что инструменты для их выполнения стоит еще поискать? Что это могут быть за операции? Какие для этого используются инструменты? Об этом пойдет речь в этой статье, она же — обзор моего нового продукта.

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


Вот так выглядит ленточное хранилище (наше было поменьше) и библиотечный робот (наш такой же). Китаец в комплект не входит.

Часть 1. Коробка

Помню, стояли последние дни ноября. Уже думая об окончании рабочего дня, я планировал свой вечер, когда вдруг мне сообщили, что в славном сибирском городе N у нашего заказчика сломалась ленточная библиотека. Запчасть сразу же отправили транспортной компанией, но вот уже 3 дня, как она все еще была в пути. Транспортная компания невнятно объяснялась и хмыкала в телефон, а заказчик стал не в шутку нервничать. Прогнозы были неопределенные, поэтому было принято решение везти еще одну запчасть своими силами на самолете. Сотрудник склада вручил мне габаритную коробку весом килограмм десять, обклеенную штрих-кодами и стикерами, и радостно хлопнул меня по плечу со словами: «Только не вздумай в багаж сдавать — помнут».

Коробка меня, безусловно, беспокоила, но не меньшее беспокойство мне внушал пакет с сухим молоком, который в последний момент мне вручил менеджер проекта. «У них там какие-то траблы с молочкой сейчас… из-за непогоды что ли… ребята местные просили 2 кг им привезти. Тебе ж не сложно?» — сказал он. По выражению его лица и характерному жесту ладони, как бы прикрывавшей мне рот, было ясно, как он сейчас хотел, чтобы я оказался сговорчивым или даже немым.

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

Для тех, кому лень — буквально абзац краткого содержания предыдущих серий. 6 месяцев назад я написал модуль для Ruby on Rails, который помогает определять источники постетителей сайта и использовать полученные данные для разных маркетингово-аналитических садомазо развлечений. Сейчас я решил познакомиться поближе с JS и портировал его на JavaScript, о чём и собираюсь рассказать в этом посте.

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

Самое очевидное решение — использовать акселерометр. Я купил один из первых попавшихся — BMA150 от Bosch.

Роб Грин, владелец собственного консалтингового агентства в Лос-Анжелесе, уже долгое время работает в сфере SEO. За эти годы он видел множество интернет-магазинов и может четко сказать, чего не хватало большинству из них. Он собрал список из 46 самых актуальных советов, которые он давал своим клиентам.

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

2. Дайте клиенту увидеть стоимость доставки без регистрации.

3. Если вы доставляете товар в различные регионы (страны), сделайте список регионов в алфавитном порядке.

Фигура Джона Кармака в индустрии компьютерных игр (далее по тексту КИ) неоднозначна. Существует большое количество слухов и скандалов, связанных с его именем. Многие считают его неприятным человеком, и многие также считают его гением. Эти два свойства, кстати, не взаимоисключающи. Можно быть не самым приятным в общении человеком, но при этом делать удивительные вещи. В этой публикации мы не рассматриваем все заслуги Джона перед КИ, не обсуждаем его прения с членами команды, и не стараемся раскопать наибольшее количество скандалов. Даже историю Id Software затрагиваем не полностью, лишь вскользь касаясь пройденных Джоном вех.

Любой разработчик со стажем и любой отдавший всю свою жизнь индустрии может быть предметом глубоких исследований, множества публикаций, и даже книг. Однако все понимают, надеюсь, как много нужно времени, чтобы собрать всю эту информацию воедино, проверить и сопоставить факты, связаться с фигурантами, выработать четкую стратегию изложения. Чем больше проходит времени, тем плотнее пелена истории покрывает удаляющиеся от нас годы, откуда можно было бы извлечь знание. Одно дело если ты был очевидцем его, если читатель (или писатель) представляет старый пласт игроков и пласт людей интересующихся. Совсем другое дело если с материалом знакомятся люди, которые вообще не знакомы с играми Wolf3D, Doom, Quake и кому наборы букв IDDQD и IDKFA ничего не говорят. Как рассказать все и не утомить читателя? Как сосредоточиться на главном? Как не потратить недели и месяцы на публикацию казалось бы ненужной статьи?

Ответ прост. Выбрать то главное, что нужно донести до читателя. Выбрать стержень. Первопричину. То, что побудило написать эти строки. И я точно знаю, чего хочу в данный момент. Рассказать о том, почему я считаю Джона — человеком на острие ножа. Человеком авангарда. Рисковым экспериментатором и первопроходцем.

Баста карапузики, кончилися танцы.

В предыдущей части мы детально рассмотрели «читерские» приёмы обхода «защит» (скрытие SSID, MAC-фильтрация) и защит (WPS) беспроводных сетей. И хотя работает это в половине случаев, а иногда и чаще — когда-то игры заканчиваются и приходится браться за тяжёлую артиллерию. Вот тут-то между вашей личной жизнью и взломщиком и оказывается самое слабое звено: пароль от WPA-сети.

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

К концу статьи вы поймёте, почему ленивый 20-значный пароль из букв a-z на пару солнц более стоек, чем зубодробительный 8-значный, даже использующий все 256 значений диапазона.

Оглавление:
1) Матчасть
2) Kali. Скрытие SSID. MAC-фильтрация. WPS
3) WPA. OpenCL/CUDA. Статистика подбора

Вот так неожиданно, через 15 лет после начальной публикации, обновилась спецификация HTTP/1.1
Обновлений много, я бы даже сказал, дофига. Добавили много проясняющего текста, разбили спецификацию на 6 RFC (раньше было 2), добавили новый статус 308, стандартизировали X-Forwarded-For (теперь он просто Forward), и еще много всего.

Неполный спискок изменений:

• Новый статус 308 — Permanent Redirect, но с отправкой этих же самых данных. Т.е. запрос не меняется на GET, как раньше.
• Новый заголовок Forward, который призван заменить X-Forwarded-For и X-Forwarded-Proto
• Убрано ограничение на 2 подключения к серверу
• Убрана поддержка HTTP 0.9
• Убрана кодировка ISO-8859-1 по умолчанию
• Убран заголовок Content-MD5
• Запрет использования Content-Range на POST-запросах
• Добавлено кеширование кодов 204, 404, 405, 414 и 501
• Изменена документация кодов 301 и 302 таким образом, чтобы позволить перенаправлять метод с POST на GET. Т.е. задокументировали текущую реализацию всех браузеров.
• Добавлены разграничения между запретом отправки referer и случаем, когда referer нет. Теперь следует отправлять Referer: about:blank, если referer-а не было.
• Location теперь может перенаправлять на ссылку с хештегом.

Начиная с версии 1.5, в Firefox появился механизм кеширования, сохраняющий состояние страницы в памяти. Кеширование действует на одну сессию браузера. Перемещаясь по посещенным страницам с использованием кнопок «Назад/Вперёд», нет необходимости загружать страницу с сервера целиком. При этом вся страница, включая js-скрипты, как бы «консервируются» в том состоянии, в котором они были, когда пользователь их покидал. Данный механизм позволяет производить навигацию по посещенным страницам крайне быстро. Состояние кеша остается неизменным, пока действует сессия браузера (пока пользователь не закроет закладку, или браузер).

Не «баг», а «фича»

Помимо прочего, непонимание данного механизма браузеров вызывает настоящую головную боль у разработчиков. Рассмотрим пример.
Есть форма, данные которой мы хотим отправить на сервер. Мы хотим как-то визуализировать этот процесс и запускаем спиннер при отправке формы. Браузер переходит на следующую страницу. Если мы вернемся назад, используя кнопку браузера «Назад» (или через window.history.back()), то скорее всего увидим, что спиннер так и вращается, хотя на самом деле уже ничего не происходит.

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

Хочу обратить внимание уважаемого сообщества на небольшой, но достаточно обидный косяк, который допускать в 2014-ом году просто стыдно.

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

Первая мысль: почему они научили роботов писать, но не научили читать? Darpa делает прямоходящих роботов, японцы делают человекоподобных роботов, весь мир помешался на роботах… но никто не научит бедняжек читать?

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

… а именно как писать LL парсеры для не очень сложных структур при помощи конструирования сложного парсера из более простых. Изредка возникает необходимость распарсить что то несложное, скажем некую XML-подобную структуру или какой нибудь data URL, и тогда обычно возникает либо простыня хитрого трудно читаемого кода либо зависимость от какой то ещё более сложной и хитрой библиотеки для парсинга. Здесь я собираюсь совместить несколько известных идей (какие то из них попадались на Хабре) и показать как можно просто и лаконично написать довольно сложные парсеры уложившись при этом в совсем немного строчек кода. Для примера я буду писать парсер XML-подобной структуры. И да, я не буду вставлять сюда картинку для привлечения внимания. В статье вообще картинок нет, поэтому читать будет трудно.

Думаю, вы уже и так поняли, в чем суть идеи, но на всякий случай распишу. На фотографии я сплю прямо около офиса Google в Нью-Йорке. Рядом со мной табличка, на которой акрилом выведен QR-код. Как вы можете догадаться, в QR-коде зашифрована ссылка на созданную мной страницу в интернете, где описано почему и зачем мне прямо сейчас нужно дать кучу денег.

Предыстория

Я путешествую вокруг света автостопом последние полтора года, и в конце ноября оказался в Нью-Йорке. Так случилось, что мой компьютер приказал долго жить, а на новый денег не нашлось. На дворе стояла середина декабря, и весь мир готовился к скорым праздникам. Денег решительно не было, а Хабр почитать охота. Одним прекрасным бруклинским утром мне в голову пришла идея выпросить у Нью-Йорка новый компьютер к Рождеству.

В Ivideon нет рекламы. Вообще. Даже несмотря на то, что существенная часть наших пользователей подключены бесплатно.
Мы запустили сервис видеонаблюдения почти год назад и он был бесплатным без всяких ограничений для всех. Три месяца назад мы запустили коммерческие тарифы и ввели ограничения. Две камеры — бесплатно, включая возможность их трансляции на собственном сайте, а дополнительные камеры — за небольшую абонентскую плату. Большинству не корпоративных пользователей двух камер более чем достаточно.

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

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

Но речь не об этом. С момента появления нашего блога и нашей первой статьи на Хабре о том как создавался Ivideon, мы ни разу не рассказали о том, а что же мы сделали и зачем? То, что обычно компании первым делом публикуют на Хабре в виде собственной рекламы, мы пропустили. Позвольте нам сделать это сейчас и не получить уж слишком много минусов. Тем более мы просто хотим рассказать о нашем продукте, который позволяет не только в реальном времени наблюдать за яйцами.
Если просто, то Ivideon дает удобную возможность объединить в одном интерфейсе личного кабинета неограниченное количество камер, разбросанных географически. Они могут находиться как в одном офисе, так и на разных континентах.

2 февраля 2012 года микроблоггерка, действующая под псевдонимом «Лоличка», попросила:

— Если уж вы произносите «Java» как «Ява», то будьте любезны говорить не «jazz», а «йаззь».

(Конец цитаты.)

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

Очевидно, он в той же мере касается и джаваскриптов.

В жизни каждого умного дома возникает закономерный вопрос – как маленький нежный микроконтроллер своими пятью вольтами сможет коммутировать 220 вольт переменного тока?

Самый простой вариант – реле. Тут вам и гальваническая развязка, и замыкаешь что хочешь, хоть постоянный, хоть переменный, мало, много. Но и минусы у реле очень неприятные.

Первый – щелкает. Раздражает. Да, человек – штука такая, ко всему приспособится, и можно привыкнуть, но зачем привыкать к плохому?

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

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

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

Рассмотрим это на гипотетическом примере, близком к мобильному маркетингу. Допустим, что есть группа пользователей, из которых 5000 — пользователи iOS, а 10000 — Android. Средняя конверсия составляет 5%: 4% для iOS и 5,5% для Android. Согласитесь, что менеджер по продукту на основе этих данных может принять вполне конкретные решения …и совершить ошибку. Рассмотрим данные подробнее — с разбивкой по устройствам. Из пяти тысяч пользователей Apple в группе оказывается 1500 iPad (конверсия 6,67%) и 3500 iPhone (2,86%), а в группе платформы Google 8000 планшетов (6,25%) и 2000 смартфонов (2,5%). То есть выясняется, что конверсия в обеих группах устройств Apple оказывается выше, если рассматривать их в отдельности.



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

Чтобы избежать таких ошибок, не объединяйте разнородные группы. Ниже список критериев, которые нужно использовать в мобильном маркетинге для разделения данных на группы:
— регионы или страны;
— типы и платформы устройств;
— источники получения информации;
— поведенческие сигналы;
— дата установки (в случае изучения сезонности спроса).

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

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

Но вот сегодня утром — всё как-бы спокойно. Вчерашний баг закрыт, продукт собирается нормально. Ты включаешь компьютер, логинишься — и перед тобой «чистый лист». Да, задач ещё много, но в данный момент ты ещё не приступил ни к одной. Тянет почитать почту, проверить новости. Ты ещё не «в контексте» работы. Вот уж когда начнёшь работать — тогда только держись! Но ещё ведь не начал. Ну и дальше стандартное «Хабр, новости, друг скинул ссылку на смешное видео, надо попить чаю, ой уже скоро обед» и т.д.

Что же делать?

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

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

Ларри Пейдж и Сергей Брин всерь­ез считали, что их компании управленцы незачем. В 2002 году они попытались выстроить горизонтальную оргструктуру — без менеджеров, руководящих программистами. Так, считали они, ничто не будет мешать быстрому обмену и появлению идей. Кроме того, им хотелось воссоздать ту атмосферу студенческой жизни, которая так нравилась им в университете. Эксперимент длился недолго: спустя несколько месяцев его пришлось прекратить. Брин и Пейдж изменили свое мнение о внутреннем устройстве компании, когда сотрудники валом повалили к Пейджу с вопросами, далекими от творчества: с финансовыми отчетами, жалобами друг на друга и т.п. А уж когда компания стала расти, ее основатели убедились, что управленцы полезны и в других отношениях: объясняют стратегию, значимость проектов и их очередность, налаживают сотрудничество в коллективе, следят за карьерным ростом людей и за тем, чтобы все рабочие процессы и системы соответствовали задачам бизнеса.

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

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

Проходит день, неделя, месяц, три… Да, посещаемость неплохая. Да, пользовательская база растет. Но хочется большего. Как понять, чего не хватает вашим пользователям? Какие их потребности сервис не охватывает? Что делать неудобно? А что наоборот, сделано здорово, и менять ни в коем случае не стоит?

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