В тематическом блоге «Программинг микроконтроллеров» уже было несколько статей по поводу выбора первого микроконтроллера и начала работы с ним. Не менее интересны были и комментарии к таким статьям. Одна из мыслей, которая несколько раз поднималась там — это что не все, кто имеют интерес к МК, приходят к ним от транзисторов. Некоторые (дай бог, чтобы побольше), приходят к ним со стороны (прикладного) программирования. Рекомендовать таким людям брать в руки паяльник — не разумно, у них и так есть вещи, которые они могут «попаять». Так мы приходим к слову «Arduino», которое уже многие слышали. Среди бывалых с паяльниками существует стереотип — Arduino это платка на AVR для ленивых. Так ли это? Эта статья — попытка наглядно показать, что Arduino — это не про AVR и не про лень, Arduino — это архитектурно-независимая электронно-механическая платформа совместимых компонентов, по (относительной) значимости не менее важная, чем (в свое время) IBM S/360, IBM PC или USB.

Начало и оглавление см. в первой части.

Так что там про инсайд?

Если ты руководишь компанией, то определённо располагаешь бóльшим объемом информации, чем какой-нибудь миноритарий, купивший её акции на бирже через Интернет.

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

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

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

История, стоящая за спиной Stuxnet — червя ориентированного на Иранские атомные электростанции, была описана уже не раз (в том числе и на Хабре) с того момента, как прошедшей весной группа разработчиков из Symantec выпустила этот документ — досье, посвященное этому беспрецедентно сложному творению чьих-то рук. Но видеть — значит верить. И у меня был шанс присутствовать на специальном брифинге в штаб-квартире Symantec, расположенной в Mountain View — California, где Патрик Гарднер, директор их группы безопасности, показывал как все происходило на самом деле. Это был великолепно.

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

Этот софт очень специфичен, и затрагивал отдельный программируемый логический контроллер от компании Siemens, проводящий серию из 9 000 различных центрифуг, используемых для разделения урана. Червь начисто уничтожал около 1000 из них, наносив серьезный ущерб и отбрасывая всю атомную программу Ирана на год, или даже более, назад.

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

1. Выучить новый язык программирования

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

Среди языков программирования отличный познавательный эффект и наверстывание опыта дают: Lisp (или Scheme), Форт, PostScript или Factor (стековые языки программирования), Haskell (строго типизированный, чистый функциональный язык) либо OCaml (объектно-ориентированный язык функционального программирования), Пролог (логическое программирование), Erlang (отличные паралельные вычисления).

Введение

С момента написания мной предыдущей статьи по оптимизации этой связки прошло довольно много времени. Тот многострадальный Pentium 4 c 512Мб памяти, обслуживающий одновременно до тысячи человек на форуме и до 150,000 пиров на трекере уже давно покоится на какой-нить немецкой, свалке, а клуб сменил уже не один сервер. Всё сказанное в ней всё ещё остаётся актуальным, однако есть вещи которые стоит добавить.
Статья большая, так что будет поделена на логические блоки:

0. Зачем вообще что-то оптимизировать?
  
1. Оптимизация ОС (FreeBSD)
  1.1 Переход на 7.х 
  1.2 Переход на 7.2
  1.3 Переход на amd64
  1.4 Разгрузка сетевой подсистемы
  1.5 FreeBSD и большое кол-во файлов
  1.6 Softupdates, gjournal и mount options
  
2. Оптимизация фронтенда (nginx)
  2.1 Accept Filters
  2.2 Кеширование
  2.3 AIO
  
3. Оптимизация бэкенда
  3.1 APC
  3.1.1 APC locking
  3.1.2 APC hints
  3.1.3 APC fragmentation
  3.2 PHP 5.3
  
4. Оптимизация базы данных
  4.1 MySQL 
  4.1.1 Переход на 5.1
  4.1.2 Переход на InnoDB
  4.1.3 Встроеный кеш MySQL - Query Cache
  4.1.4 Индексы
  
4.2 PostgreSQL
  4.2.1 Индексы
  4.2.2 pgBouncer и другие.
  4.2.3 pgFouine
  
4.3 Разгрузка базы данных
  4.3.1 SphinxQL
  4.3.2 Не-RDBMS хранилище
  4.4 Кодировки
  4.5 Асинхронность
  
Приложение. Мелочи.
  1. SSHGuard или альтернатива.
  2. xtrabackup
  3. Перенос почты на другой хост
  4. Интеграция со сторонним ПО
  5. Мониторинг
  
 6. Минусы оптимизации

Введение

Все началось с того, что я стал системным администратором у одного провинциального Интернет-провайдера. Помимо администрирования различного рода ресурсов, мне в присмотр достался один молодой, но бурно развивающийся ресурс. Ресурс представлял из себя классический LAMP проект. Сайт, на котором генераторами контента являлись обычные пользователи.
* К слову, в то время я ничего не понимал в *nix системах, хоть и все сервера которые мне достались, были именно на нем, разбирался я во всем этом достаточно быстро.

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

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

Речь пойдёт о далёком 2005 году, когда только-только вышла Civilization4 от Sid Meier. К тому времени я плотно висел в Civilization3, прошёл её раз дцать на самых разных картах, и тут вышла долгожданная четвёрка. Это были годы P3-512Mb для mid-end и P4-1Gb в hi-end. Только топовые конфиги в те годы имели два гига памяти на борту.

Civilization 4 вышла с графикой уровня года 2002-2003го, что в принципе нормально для мэинстрима тех времён, особенно учитывая что это пошаговая стратегия, а не шутер. Но жрала с течением игры до 900Mb оперативки, что приводило к жуткому свопу, особенно на больших картах, особенно к концу игры, особенно на ноутбуках. Народ недоумевал, я тоже. Учитывая, что в те же годы вышел Far Cry с куда более красивой графикой, и который вполне игрался на максимуме даже с 512Mb на борту, такое поведение Civilization 4 выглядело крайне странным. Захотелось разобраться и покарать…

Представьте, что вы поехали в другую страну, у вас собой есть смартфон и вам очень нужно зайти с него в интернет (например синхронизировать контакты или поставить какой-то софт). Какие есть варианты?
— Первый вариант — это мобильный интернет. К сожалению, это не всегда просто и не всегда дёшево.
— Второй вариант — WIFI. Вам повезло, если вы можете подключиться к WIFI там, куда вы прибыли, и в этом случае задача уже решена.
— Третий вариант — LAN. А что если у нас есть только LAN? Самое простое — это захватить с собой из дома небольшую точку доступа, но что если вы её не взяли с собой или у вас её нет? В этос случае вам поможет случайно захваченный с собой ноутбук или нетбук :)

Имеем

— EeePC 901 с Ubuntu 10.10
— Смартфон
— Локальная сеть

Задача

— Получить доступ в сеть со смартфона используя WIFI

Наверняка многие из вас слышали и знают про системы идентификации музыки вроде TrackID, Shazam, MusicBrainz или онлайновой Audiotag.info, позволяющие по записанному отрывку песни узнать ее название. Все они в достаточной степени хороши, но имеют общий недостаток — закрытый код и, соответственно, ограниченную сферу применения. TrackID вы можете использовать только на телефонах Sony Ericsson, Shazam — тоже только на телефонах, хотя и на более обширном списке платформ, а Music Brainz вообще неясно, работает ли вообще.

Ребята же из компании Echo Nest, решили, что распознавание музыки должно быть таким же доступным миру явлением, как электронная почта или DNS :), и выпустили своё детище полностью под MIT License. А детище, надо сказать, у них очень серьёзное — еще бы, если основателями компании являются доктора наук из MIT Media Lab .

Тот зверьфункционал, который они выпустили на свободу, не ограничивается только распознаванием музыки по записанному отрывку, но и позволяет делать такие вещи, как поиски дубликатов музыки, массовое распознавание и заполнение тэгов в музыкальных коллекциях, проверка аудио/видео на содержание того или иного материала, синхронизация коллекций из различных музыкальных пространств (iTunes <-> Last.fm <-> Spotify, например) и много чего еще.

Бэкапил историю сообщений из Skype самописной утилиткой, год назад она работала отлично, а теперь стала люто тормозить. Это неприемлемо, тк. в том числе ради скорости экспорта она и была написана, поэтому полез в профайлер. По итогам узнал всякое и получил множественные просветления. Оказывается, breakpoint на функцию в подгруженной системной DLL ставить приходится с подвывертом, а не просто по имени, но таки можно и нетяжело. Оказывается, Skype API написан местами зверски криво, отчего и тормозища. Оказывается, чужие бинарники иногда можно очень легко подхачить и подоптимизить (слава MS Research!). Оказывается, профайлер может сильно врать, а не просто слегка подбрехивать. Ключевые слова для нетерпеливых: C++, VS, CodeAnalyst, Skype COM API, MS Research, Detours, SQLite; а для всех остальных подробности под катом.

На сайте programmers.stackexchange.com люди задают различного рода вопросы, связанные с программированием и не только. Вот, на мой взгляд, наиболее интересные(ответы, правда, на английском).

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

Недавно в RSS пришла статья, которую хотел оформить переводом — So you just deleted your production database — what now?. Однако комментарии к статье, да и последний абзац заставили задуматься — а на сколько просто восстановить удаленную базу данных.
И дабы не плодить непроверенной информации — перевод перевоплотился в исследование метода восстановления информации из случайно удаленной базы MySQL.

Недавно я сдавал экзамен Oracle Certified Professional Java Programmer (бывший Sun Certified), и за время подготовки прорешал огромное количество различных задачек. Отдельные задачки по джаве иногда появляются на хабре и вызывают немалый интерес, поэтому я решил поделиться накопленным и сделать небольшую подборку.

Итак, ниже представлен десяток наиболее, на мой взгляд, интересных задач по Java SE из более чем 1000, проработанных мной. Сложность варьируется от средней до ооооооочень сложной. Решение большинства задач практически не требует знания API, достаточно логики и фундаментальных основ Java.

К слову, сложность экзамена Oracle Certified Professional Java Programmer гораздо ниже чем сложность данного теста, поэтому все, кто правильно ответит хотя бы на половину этих вопросов, может смело сдавать этот экзамен без всякой подготовки.

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

ВНИМАНИЕ: во второй половине статьи — ответы и подробные пояснения по соответствующим нюансам JAVA.

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

В общих чертах проект в ИТ состоит из следующих этапов. Сначала вы узнаете о потребности кого-то в чем-то (или создаете эту потребность). Потом вы третесь возле заказчика, всячески облизывая его и склоняя в сторону откровенного разговора. Я намеренно выношу за скобки коррупционные сделки и буду рассказывать только о сделках в рамках закона.Когда клиент созревает для встречи, вы устраиваете шоу, в ходе которого продается идея и рисуется картина прекрасной жизни, которая наступит после внедрения вашего решения. Потом контракт и аванс. Потом обследование и долгая нудная работа по проектированию. Потом сдача проектных документов. Потом реализация и запуск решения. Потом ввод в действие. Каждый этап закрывается актом, на основании которого вам на счет падает копейка. Вот такой бизнес. Конечно, я утрирую, и иногда все может быть наоборот. А иногда — и шиворот навыворот.

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

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

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

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

Следы от пуль

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

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

Логично заключить, что нужно добавить брони в тех местах, где больше всего следов. Но это неверно.

Не обманывайтесь — каждый хочет продать свой стартап. Мы все восхищаемся тем, как Groupon и другие компании превращаются в миллиардных гигантов, хотя, в общем-то, это ложь самим себе. Даже Ларри Пейдж и Сергей Брин хотели продать Google за $1 миллион Yahoo в течение 10 секунд после начала работы, однако последняя ответила отказом.

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

Говоря «процесс» я имею ввиду абсолютно все, что вам нужно сделать с момента основания собственного бизнеса до того момента, когда вы получаете наличные за свою долю в нем. Любые действия стремятся именно к этому финальному моменту.

1. Готовьтесь за год вперед. Основательно готовьтесь ко встрече с каждым, кому вы хотите продать свой бизнес. Начинайте разговаривать с ними уже сейчас. Первая компания которую я продал (в 1998) начала вести переговоры со всеми рекламными агентствами за год до фактической продажи. Я не был готов (всмысле, я бы продал ее сразу, но она была слишком мала), поэтому я держал каждого потенциального покупателя в курсе ежемесячными рассылками. И завтраками или обедами каждые три месяца, просто для того чтобы рассказывать новости о бизнесе, в общем. К тому моменту, когда я был окончательно готов продать компанию, мы получили 4 или 5 срочных предложений. Наконец, мы продали ее компании, с которой я даже не контактировал ранее, но она слышала о нас потому что все остальные обсуждали это.

Американский стандарт интеллектуальных транспортных систем U.S. Dot ITS описывает весь комплекс автоматизированных систем управления транспортом. Стандарт настолько масштабен, что втиснуть его описание в один или даже два поста нереально. Так как большинство описанных в нем систем для нас недостижимое светлое будущее, то и делать этого не стоит. А вот что стоит сделать — это рассмотреть то, как он устроен изнутри, какие находки сделали неизвестные американские (ой ли?) ИТ-специалисты, проделавшие весьма значительный объем работы за счет налогоплательщиков.

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