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

Хочу представить программную платформу автоматизации для дома на базе Node.js, которую можно скачать со всеми исходниками и установить прямо сейчас практически одним кликом (Windows) или одной командой (Linux/Debian).

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



У меня сейчас не топовая, довольно старая конфигурация, но её производительность мне вполне подходит:
Intel Core 2 Duo E7500 2.93Ггц
8Гб DDR3 SDRAM
2Тб HDD Seagate 5900 Green
Я путём небольших вложений заставил-таки свой компьютер работать бесшумно.

Рассмотрим по отдельности все шумные узлы системного блока, такие как:

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

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

Функция распознавания речи с некоторого времени доступна в браузере Google Chrome. Посмотреть как это выглядит можно, например, здесь.

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

Как это часто бывает, все уже сделано за нас в этой статье. Все оказывается очень просто, необходимо сделать POST запрос на адрес www.google.com/speech-api/v1/recognize со звуковыми данными в формате FLAC или Speex. Реализуем демонстрацию распознавания WAVE-файлов с помощью C#.

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

Вероятно, многие видели американский сериал «Lie to me». На бит-торрент трекерах он распространяется под названием «Теория лжи», а первый канал его показывает отчего-то под названием “Обмани меня”. Сериал рассказывает о команде суперпрофессиональных психологов, занимающихся расследованиями самого разного рода: от брачных дел до поимки маньяка-убийцы. Объединяет эти расследования только одно: всегда нужно выявить лжеца, узнать в чем он лжет, что скрывает – и тем самым решить дело. Именно распознавание лжи – профессиональная область героев сериала, именно для решения этой задачи их нанимает ФБР, полиция, пожарные и многие другие.

Однако, немногие видевшие сериал знают, что у доктора Кэла Лайтмана, главного героя, блестяще исполненного Тимом Ротом, есть вполне реальный прототип – выдающийся психолог, профессор Калифорнийского Университета Пол Экман. Манипуляции, микровыражения, техники выявления лжи, столь ярко демонстрируемые в каждом эпизоде, стали известны именно благодаря многолетним исследованиям доктора Экмана и его коллег. В 1985 году он написал книгу «Telling Lie», в которой подробно, почти скрупулезно рассказал о своих работах, разобрал виды и классифицировал признаки лжи, изложил техники выявления обмана в самых различных обстоятельствах: повседневной жизни, уголовных расследованиях и политике. Как оказалось, в закрытых и секретных организациях, вроде ЦРУ, АНБ и ФБР, психологических журналов особенно не читали, а книга, напротив, стала известна, а вместе с ней и её автор. Доктора Экмана начали приглашать для проведения тренингов и семинаров; выяснилось, что люди, стоящие на страже национальных интересов разбираются во лжи ничуть не лучше нас с вами. Т.е. они, как и большинство простых обывателей, думают, что способны выявить обман, но в действительности их результаты в среднем не лучше случайного угадывания, более того они часто просто не знают куда смотреть – таковы результаты исследований Экмана и его коллег.

В 1992 году «Telling Lie» была переиздана и дополнена с учетом опыта работы с секретными службами, а в 2009 году в издательстве «Питер» эта книга вышла в русском переводе под названием «Психология лжи». Найти книгу можно, к примеру, на ozon.ru

Как продавать и убеждать, где черпать силы и вдохновение для того, чтобы выбраться из сложной экономической ситуации? Оказывается, все это мы можем почерпнуть из классических кинокартин.
В Carbucks.ru мы любим фильмы. Картины снимают, чтобы развлекать, реже — информировать, а иногда они даже учат нас. Они могут вдохновлять или вновь вселять веру в человечество, а иногда фильмы напрямую завязаны на том, что влияет на множество аспектов в нашей жизни – на деньгах. Порой снимается кинофильм, который дает понятие о реальном управлении деньгами, финансами и дает стоящие бизнес-советы (конечно, как дополнение к основной сюжетной линии). Предлагаю вам почерпнуть немало полезной информации из перечисленных ниже 10 фильмов, которые расскажут вам о деньгах все, даже если это и не очевидно на первый взгляд.

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

А как делать этот самый рефакторинг, если даже неизвестно, с чего начать? Как осушить болото кода и не утонуть нем?

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

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

Расскажу, что и как было, на дворе 2007, жил во Владивостоке, у меня заканчивалась аспирантура, мне было 25 и очень хотелось немного улучшить уровень жизни. Был закончен универ по специальности АСУ и было 2.5 года опыта работы программистом в довольно известном владивостокском интернет проекте.

Если так посмотреть, варианты были уехать в Москву, или куда еще подальше.
Подумал, что в Москву всегда успеется, а вот куда подальше было бы неплохо.

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

Итак что было сделано:

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

В данной статье мне хотелось бы предложить несколько вариантов того, как стоит создавать статьи, как их подавать и как поддерживать жизнь своей статьи.

В свете глобальной борьбы со спамом, пиаром, seo и прочей рекламой, многие стали боятся использовать эти инструменты во благо.
С другой стороны большое количество пользователей (в том числе авторов контента) не имеют понятия о поисковой оптимизации и других средствах распространения информации.
Но ведь мы пишем, фотографируем, поём чтобы нас читали, смотрели, слушали!?
Для этого, прежде всего, необходимо, чтобы этот контент нашли!

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

Для этого необходимо сделать определенные действия и об этом я и хотел написать.

Вторая часть

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


Итак, досталась мне хиленькая VDS от FirstVDS — с Debian и ISPManager.
Попытки оптимизировать ее работу вылились в следующее:

1. Оптимизация Apache и установка Nginx
2. Установка eAccelerator

Ну и для души —

3. Установка SVN
4. Установка Trac.

С момента покупки смарта на Android меня заинтересовало его функциональное наполнение. На практике оказалось, что Android способен выполнять практически любую задачу, решаемую на обычном ПK, только медленнее и не всегда удобнее. Зато дополняет ПК он прекрасно, и механизмов использования возможностей смарта на ПК и возможностей ПК на смарте — уйма.

Статья ориентирована в основном на формирующихся и будущих пользователей Android-смартфонов; надеюсь, что продвинутые пользователи также найдут в ней что-то новое и/или внесут свою лепту. Под катом по пунктам, в вопрос-ответном стиле.

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

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

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

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

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

На тему систем централизованного управления конфигурациями на Хабре написано немало статей и, в частности, про Chef есть несколько хороших статей. Однако, количество релизов Chef растет, и я решил немного освежить его описание для читателей Хабра. Статья предназначена как для новичков, так и для тех, кто уже знакомился с системой, но по какой-то причине отложил изучение и хочет все-таки продолжить. А продолжать стоит! Поскольку, Chef полезен и для администрирования нескольких VPS, и для управления большим парком серверов. Особенно, если вам часто приходится заниматься настройкой серверов с нуля, подключением дополнительных нод в кластер и т.д.

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

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



Лекции читает Олег Викторович Сухорослов, старший научный сотрудник Центра грид-технологий и распределенных вычислений ИСА РАН. Доцент кафедры распределенных вычислений ФИВТ МФТИ. Кандидат технических наук.

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

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

В предыдущей статье мы заглянули внутрь процессора, пусть и гипотетического. Мы выяснили, что для корректного выполнения параллельного кода процессору необходимо подсказывать, до каких пределов ему разрешено проводить свои внутренние оптимизации чтения/записи. Эти подсказки – барьеры памяти. Барьеры памяти позволяют в той или иной мере упорядочить обращения к памяти (точнее, кэшу, — процессор взаимодействует с внешним миром только через кэш). “Тяжесть” такого упорядочения может быть разной, — каждая архитектура может предоставлять целый набор барьеров “на выбор”. Используя те или иные барьеры памяти, мы можем построить разные модели памяти — набор гарантий, которые будут выполняться для наших программ.

В этой статье мы рассмотрим модель памяти C++11.

abstract: разница между текущей производительностью и производительностью теоретической; latency и IOPS, понятие независимости дисковой нагрузки; подготовка тестирования; типовые параметры тестирования; практическое copypaste howto.

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

Лирика

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

• научная публикация, в которой скорость кластерной FS оценивали с помощью dd (и включенным файловым кешем, то есть без опции direct)
• использование bonnie++
• использование iozone
• использование пачки cp с измерениема времени выполнения
• использование iometer с dynamo на 64-битных системах

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

Привет всем. Основываясь на предыдущем опыте, считаю нужным сразу расставить все точи над ё. Описанная ниже методика — не мое изобретение. Однако из собственного опыта могу уверить вас, что она работает. Ровно так, как обещано.
Идея, описанная в посте, появилась давно (под катом есть история), в том виде, в каком расскажу ее я, по большей части она представлена в чудесных книгах Тони Бузана Use You Head и The Speed Reading Book (в последней много воды).

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

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

Прежде чем приступить к самому главному, прошу вас пройти тест из шести вопросов на Да/Нет.

1. Чтение со скоростью свыше 1000 слов в минуту невозможно?
2. Медленная скорость чтения способствует лучшему пониманию текста?
3. Пропускать слова во время чтения — плохая привычка, ухудшающая понимание текста?
4. По умолчанию мы все читаем с «естественной» для нас скоростью, а следовательно, наилучшей?
5. Если вы не поняли слово или предложение, лучше перечитать его и понять?
6. Ваши глаза находятся в непрерывном движении во время чтения?
За результатами и, наконец-то, интересными штуками добро пожаловать под кат.