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

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

Цель Поставил себе цель: сделать небольшую андроид аппликачку за малое количество времени от начала до конца. Благодаря вулкану застрял на чужбине на несколько дней, были свободные вечера в отеле, чем я и воспользовался. Результат 2 вечера и 3 часа в самолете, 25 долларов гуглу, 30 долларов амазону, «Аппликачка» Bullshit! (market://search?q=pname:com.acxe12.bullshit) и промо-сайт http://bullshit.acxe12.net

Как и что получилось?

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

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



SunCalc показывает на карте для выбранного места и даты траекторию движения солнца и фазы освещённости в течении суток (и еще пару приятных мелочей).

Что такое Bundler?

Это менеджер для управления зависимостями gem'ов в ruby приложениях. Эта утилита позволяет легко устанавливать необходимые gem'ы для вашего приложения, при этом вовсе не зависеть от установленных в системе. Если вы использовали Rails для своих разработок, то вы вспомните, как задавали зависимости gem'ов c помощью config.gem в enviroment.rb, Bundler решает эту задачу намного удобнее и проще. Его включили в Rails 3.0 по умолчанию и теперь, именно он используется для управления зависимостями gem’ов в данной версии фреймворка. Эту утилиту можно использовать для любого ruby фреймворка.

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

Сухая теория

И так, наша задача сгенерировать текст. Это значит, нам нужно взять слова и выстроить их в определенном порядке. Как определить этот порядок? Мы можем пойти следующим образом: построить фразы, наиболее вероятные для русского языка. Но что значит вероятность фразы языка? С точки зрения здравого смысла это бред. Тем не менее, эту вероятность можно задать формально как вероятность возникновения последовательности слов в неком корпусе (наборе текстов).

Под катом описано как шейпировать трафик в Linux и что для этого нужно знать.

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

Передо мной возникла необходимость настроить резервное копирование на новом Linux-сервере, задачка эта оочень важная, но уж больно скучная: нужно написать и отладить скрипты, которые будут архивировать нужные папки (причем желательно делать инкрементальные архивы), базы данных, хранилища subversion, а затем переносить эти архивы на удаленный сервер. По этому я попробовал нагуглить готовое решение для этой задачки и в результате наткнулся на backup-manager — замечательный опенсорсный набор bash-скриптов, позволяющих:

• архивировать любые папки, в том числе и создавать инкрементальные архивы. В конфиге просто указывается список директорий, которые должны быть скопированы, а также «черный список» файлов, которые копироваться не будут.
• делать резервное копирование баз данных MySQL. В конфиге указываются логин и пароль mysql-юзера, имеющего доступ к базам, а всю остальную работу backup-manager делает сам.
• делать резервное копирование svn-репозиториев, причем бэкап делается не копированием папки с хранилищем, а с помощью команды svnadmin dump.
• шифровать архивы.
• копировать созданные архивы на удаленные сервера по FTP, SSH или (это самая важная для меня фича) в хранилище Amazon S3, а также записывать их на DVD.

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

Давайте каждый попробует ответить на вопрос: как установить apache на сервер? Этот вопрос порождает ещё десяток: какая ОС стоит на сервере, какую версию ставить, где лежат конфиги по-умолчанию и т.д. и т.п.

А теперь давайте попробуем ответить на вопрос: как установить apache на 1000 серверов? Тут, при стандартном подходе, вопросов возникнет ровно в 1000 раз больше. Часть из вас наверняка подумали, что можно написать скрипт на shell/perl/python/ruby, который будет обходить все сервера и устанавливать apache, другая часть подумала о distributed shell'ах (PDsh, dsh, etc), кто-то же подумал монтировать rootfs серверов по NFS.

В ряде случаев выше предложенные варианты решений удовлетворительны, но на практике я нигде не видел полностью гомогенных систем (зачастую, внутри компании можно встретить не только разные версии ОС, но и различные дистрибутивы. Также в России/СНГ очень распространена каша из FreeBSD/Linux в ядре проектов), так что вряд ли за адекватное время будет возможно написать скрипт, который установит и настроит apache на зоопарке в 1000 машин под CentOS, Debian, Ubuntu, FreeBSD всевозможных версий.

По моим наблюдениям, очень мало IT подразделений, даже очень крупных компаниий, используют в своей работе SCM (Software Configuration Management). В этом посте я постараюсь описать все преимущества использования Chef в IT инфраструктуре на простых примерах и больших масштабах.

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

Интернет – это не только web. Помимо контента (и устройств его хранения и обработки), отображаемого на web страницах важны ещё и линии связи. Причём важнее всего дальнемагистральные направления, т.к. провайдеров в городе может быть несколько, а вот соединение между городами и странами могут обеспечить немногие. Тем более, если речь идёт о разных континентах, тогда приходится топить сотни километров оптоволокна в пучинах мирового океана.

Введение

Автоматизированное управление конфигурацией ваших компьютеров — необходимо для любой компании с большим парком компьютеров.

Сейчас среди администраторов очень популярен Puppet, но, по моему мнению, продукты с самописным DSL (предметно-ориентированным языком программирования) — ограниченны по своей природе.

Chef использует DSL, основанный на Ruby, что придаёт ему изящество и неограниченную расширяемость.

Update: spanasik поправил меня, Puppet также имеет в дополнение к внешнему DSL ещё и внутренний DSL, основанный на Ruby.

Настрой себе IPv6 за несколько простых шагов.

Уже давно являюсь пользователем продукции Apple. Старенький макбук полностью справляется с теми задачами, что на него возлагаются. В основном конечно развлекательные. Но в последнее время стало не хватать места на 40 гиговом жестком диске. И вот наконец у меня зачесались руки настроить свой домашний сервер, как хранилище. Некоторое время работал по ftp, но это было не удобно. Было принято решение настроить наконец Appletalk, не зря же он есть и заодно приручить к нему TimeMachine:-)

Внезапно оказалось, что Shoreline firewall совсем не освещен на Хабре, несмотря на то, что является крайне удобным инструментом (и весомым аргументом против pf в холиварах) для настройки файрволла под линуксом.

Просьба не холиварить на темы «Линукс — говно, у нас в OpenBSD круче», «А у меня Kerio WinRoute, а вы все неудачники» и подобные.
Статья для тех, кто выбрал Linux из каких-то соображений и не хочет тратить уйму времени на изучение iptables (а там есть, где запутаться).

Посему, под катом простыня

Привет, %username%
Тут я хочу рассказать о том, как я настраивал кеширование на одном сервере, точнее VDS. Характеристики сервера: 2000MHz, 2GB RAM, 80Gb HDD, технология виртуализации — OpenVZ.
Было решено использовать Nginx версии 0.7.64. На сервере находилось около 200 сайтов. И несколько высоко нагруженных проектов. Вот эти самые проекты и давали ощутимые тормоза и нагрузку на сервер. Мы будем рассматривать DLE в этом примере.

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

Следует отметить, что под клиентом воспринимается обычный аккаунт на LAMP (Linux+Apache+Mysql+PHP), с одним-двумя виртхостами и работающим со всеми опциями php.ini по умолчанию. Основное — это 16MB RAM и 30 сек исполнения. Вполне достаточно для большинства движков — Wordpress, Drupal и Joomla.

Передо мной частенько вставала задача написать какой-нибудь Java-сервис. В качестве ОС мы используем по большей части линукс, так что удобнее всего управляться с такими сервисами — работать с ними как с демонами. То есть, запускаем:

start-stop-daemon --start --make-pidfile --pidfile /var/run/myservice.pid --exec /usr/bin/java — -jar myservice.jar

, и останавливаем:

start-stop-daemon --stop --quiet --oknodo --pidfile /var/run/myservice.pid

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

Но все не так страшно, благо JVM начиная с 1.3.1 позволяет обрабатывать сигналы. За ответом как — под хабракат.

Беспрецедентные объемы данных заставляют разработчиков и бизнес приглядываться к альтернативам реляционных баз данных, используемым вот уже более тридцати лет. В совокупности все эти технологии известны как «NoSQL базы данных».


Основной проблемой является то, что реляционные базы данных не могут справляться с нагрузками актуальными в наше время (мы говорим о high-load проектах). Есть три конкретные проблемных области:

• горизонтальное масштабирование при больших объемах данных, например как в случае Digg (3 терабайта для зеленых значков, отображаемых, если ваш друг сделал dugg на статье) или Facebook (50 терабайт для поиска по входящим сообщениям) или eBay (2 петабайта в целом)
• производительность каждого отдельного сервера
• не гибкий дизайн логической структуры.

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