Сразу предупреждаю: не копируйте примеры кода из этой статьи и не запускайте их в своей командной оболочке.

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



Часто это принимает форму грубо замаскированных команд, вроде той, что показана ниже. Её запуск приведёт к выполнению в текущей директории команды rm -rf *, которая всё удалит. Вот эта команда:

$(echo cm0gLXJmICoK | base64 -d)

Много лет назад я наткнулся на людей, которые играли в такие игры, и решил их проучить.

Обычно повышение зарплаты выглядит следующим образом. Способ №1, гуманитарный: сотрудник через год работы задумывается, что что-то пошло не так, и пора просить повышения. Дожидается своего локального максимума усилий, и на этой волне идёт к руководителю просить больше денег. С точки зрения теории игр это выглядит как «ну, я попросил, вдруг прокатит». Никаких доводов повышать оклад у руководителя нет.

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

Разработчики традиционно пользуются способом №2: сначала проходят где-то несколько собеседований, собирают офферы и приходят с ними к руководителю. «Смотри, вот тут мне предлагают на 20% больше, но мне у нас нравится, повышай на 15%, а то я перейду». Это уже предмет обсуждения. В банальном случае проще повысить и сохранить ценного сотрудника, но это обеспечит проигрыши в связанных играх. То есть создаст прецедент. Поэтому решение принимается (в упрощённой модели) с некоторой долей рандома.

У нас у многих математика в анамнезе. Рассматривая эту игру дальше, можно сделать простой вывод, что такой диалог для сотрудника всегда стрессовый, и он случается в момент после кризисного. То есть сначала человек беспокоится, потом делает потенциально невыгодные действия (проходит собеседования в других местах), потом приходит. Части надо повышать, части не надо. Следующий вопрос: можно ли найти функцию, которая обеспечит справедливую оценку? Будет ли эта функция снимать вот эти стрессовые ситуации?

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

Иллюстрация: Юлия Прокопова

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

Поэтому я оптимизирую настройки, чтобы показывать действительно, действительно хорошие буквы. Для этого необходим хороший монитор. Не просто нужен, а ОБЯЗАТЕЛЕН. А под «хорошим» я имею в виду настолько хороший, насколько это возможно. Это мои мысли, основанные на моём собственном опыте того, какие мониторы лучше подходят для программирования.

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

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

Дисклеймер

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

1. Структура доклада

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

Ключевая проблема для слушателя – отсутствие вводной части. Выводы он может сделать и сам, а вот стартовать с опозданием сложно и неприятно. Он ещё не понял, что вы будете про пищеварение, а уже нужно вникать в строение эпителия тонкого кишечника. Результат – ваш доклад попадает в слушателя не на все 100%, а имеет шансы и вовсе пролететь мимо.

Целью данной публикации не является полный анализ синхронизаторов из пакета java.util.concurrent. Пишу её, прежде всего, как справочник, который облегчит вхождение в тему и покажет возможности практического применения классов для синхронизации потоков (далее поток = thread).

В java.util.concurrent много различных классов, которые по функционалу можно поделить на группы: Concurrent Collections, Executors, Atomics и т.д. Одной из этих групп будет Synchronizers (синхронизаторы).



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

Я покажу как собрать простой, но достаточно мощный, генератор на 220 вольт.

Потребуется:

— коллекторный мотор, можно другой на 12 вольт
— насадка на ось мотора — патрон от дрели
— бесперебойник UPS или инвертор с 12 на 220
— диод на 10 ампер: Д214, Д242, Д215, Д232, КД203 и т. д.
— провода
— велосипед
— и желательно аккумулятор на 12 вольт

Сборка:

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

Скачать перевод в виде документа Mathematica, который содержит весь код использованный в статье, можно здесь (архив, ~5 МБ).

Введение

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

Предположим, что у нас есть несколько последовательных метаграмм, скажем:

мнение-мление-тление-трение-прение-поение-роение-рдение-бдение-биение

они образуют цепь метаграмм, или цепочку слов.

Отсюда проистекает игра под названием цепь слов (word ladder), которую придумал в далеком 1879 году Льюис Кэрролл.

Ясно, что далеко не для каждого начального слова может быть составлена такого рода цепь, а некоторые слова, по-видимому, должны порождать довольно длинные цепи.

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

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

Например, в REG.RU на сегодня в словарях более 15000 фраз, из которых порядка 200 используют склонение, и более 2000 используют подстановку переменных. Каждый день добавляется не менее 10 фраз. И это при том, что мы пока только начали локализацию сайта и впереди планы на новые языки.

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

DON'T PANIC.

Недавно был опубликован пакет BabelFish 1.0, предназначенный для интернационализации JavaScript-приложений.

Идеи, лежащие в его основе, настолько пришлись нам по душе, что мы даже перенесли их на Perl в виде CPAN-модуля Locale::Babelfish, и используем это для Perl-приложений. Но вернёмся к JavaScript-реализации.

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

TL;DR: Работа с таймзонами — это боль и унижение. Никогда не работайте с таймзонами!

Итак, все кругом твердят вам, что при получении времени от пользователя нужно сразу же переводить его в UTC, работать со временем нужно только в UTC и хранить время тоже нужно строго в UTC. Совет, на первый взгляд, выглядит разумным, и следование ему делает вашу жизнь проще… Если только ваша программа не предполагает сложной работы с датами. Записать в базу данных дату и время регистрации пользователя на сайте? Сохранить время отправки сообщения или дату создания заказа в интернет-магазине? Вывести сообщение в лог с указанием даты-времени? Используйте UTC и всё будет в порядке, можете даже не читать эту статью дальше. Любое текущее время можно совершенно спокойно конвертировать в UTC и забыть о проблемах. Но что, если мы хотим работать с временем в будущем? Или в прошлом? Например, если мы пишем сервис календаря, или сервис для отложенной отправки сообщений?

В этой статье я подробно расскажу и покажу, как правильно и быстро прикрутить распознавание русской речи на движке Pocketsphinx (для iOS порт OpenEars) на реальном Hello World примере управления домашней техникой.
Почему именно домашней техникой? Да потому что благодаря такому примеру можно оценить ту скорость и точность, которой можно добиться при использовании полностью локального распознавания речи без серверов типа Google ASR или Яндекс SpeechKit.
К статье я также прилагаю все исходники программы и саму сборку под Android.

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

План лекции:

1. Виды и области применения рекомендательных систем.
2. Простейшие алгоритмы.
3. Введение в линейную алгебру.
4. Алгоритм SVD.
5. Измерение качества рекомендаций.
6. Направление развития.

Не кажется странным, что навязчивое гудение компьютера всеми воспринимается «как норма»? Можно вообразить весь ужас происшествия, если внезапно эти же звуки начнёт издавать любимый телевизор. Расценивать такое событие можно будет только как серьёзную поломку. Так почему компьютер не сделать, подобно телевизору, таким же уютно тихим?!

Итак, настала пора отступить от стереотипов и поменять хорошее на лучшее!

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

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

Не помню, где первый раз увидел, но был очарован заставкой DropClock, о которой уже упоминалось на Хабре.

=>

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

Идея:

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

Если вы подозреваете, что у вас дома завёлся полтергейст, хотите приглядеть за ребёнком, интересуетесь, чем занят кот в ваше отсутствие или хотите застукать Деда Мороза прямо под ёлкой, то всё, что для этого нужно — ноутбук или ПК с веб-камерой и бесплатная программа Ivideon Server.



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

Во многих компаниях, как и моей, есть много проектов и продуктов. И у продуктов бывают веб-интерфейсы, чтобы этими продуктами как-то манипулировать. В нашем случае это простенькие RESTful веб-сервисы, а поверх них ещё более простенькие веб-странички с формочками и кнопочками. Все эти веб-странички до того похожи друг на друга, что возникла мысль написать унифицированный продукт, который бы спрашивал сервер о поддерживаемых сервисах, и получал бы полное описание параметров к этим сервисам, так чтобы можно было нарисовать те самые простенькие формочки. То есть, веб-сервисы должны описывать себя, достаточно исчерпывающе, чтобы наш клиент мог построить GUI для них, и ничего не надо было бы делать руками. Как раз такая картинка гуглится по запросу «REST»:

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