Люди не очень любят регистрироваться. Это же нужно (в общем случае) придумать логин и пароль, зайти в свою почту, дождаться письма, открыть его, перейти по ссылке активации аккаунта, а потом еще этот логин с паролем не забыть. Но ведь уже давно есть способ, с помощью которого все эти шаги не нужны. Более того, не нужно вообще ничего вводить с клавиатуры, 2 щелчка мышью и все, человек зарегистрирован.

Продолжая тематику Многомерные кубы, OLAP и MDX и olap для маленькой компании, традиционно, предлагаю начать с простенького «Hello World» куба, который будет анализировать процессы и тенденции голосований на Хабре.

Итак, давайте попробуем создать свою первую OLAP систему.
Но, прежде чем, потирая руки, запускать Business Intelligence Studio, предлагаю вначале создать хранилище данных хабра-голосов, так называемый Data Warehouse.
Зачем? Причин в этом несколько:

• сама суть Data Warehouse-а хранить «очищенные» данные, готовые для анализа, поэтому даже его изначальная структура может сильно отличаться от структуры нашей хабра-OLTP базы данных
• в HabraDW (так мы его назовем) мы вынесем только ту информацию, которая нам нужна будет для анализа, ничего лишнего
• к Data Warehouse не накладываются требования нормализации. Даже наоборот, денормализировав некоторые данные можно добиться более понятной схемы для построения куба, а также скорости загрузки данных в куб

Вольный перевод довольно старой статьи с MySQL Performance Blog о том, что лучше сразу же настроить после установки базовой версии mySQL.

Начиная с версии 5.1 mySQL поддерживает горизонтальное партицирование таблиц. Что это такое? Партиционирование (partitioning) — это разбиение больших таблиц на логические части по выбранным критериям.. На нижнем уровне для myISAM таблиц, это физически разные файлы, по 3 на каждую партицию (описание таблицы, файл индексов, файл данных). Для innoDB таблиц в конфигурации по умолчанию – разные пространства таблиц в файлах innoDB (не забываем, что innoDB позволяет настраивать индивидуальные хранилища на уровне баз данных или даже конкретных таблиц).

Как это выглядит?

На написание меня сподвигли пара топиков про теории мотивации X и Y.

В качестве предисловия

Проблема мотивирования труда является одной из самых острых проблем, стоящих перед современным российским предприятием. Как правило, отечественные руководители рассматривают систему мотивации как инструмент, базирующийся на персональных выплатах работнику.
Согласно принятым системам мотивации на отечественных предприятиях работник получает:
• Базовую заработную плату в зависимости от иерархического уровня управления;
• Премии и бонусы по результатам деятельности подразделения за отчетный период;
• Премии и бонусы по результатам личной деятельности работника (личные бонусы и доплаты за исполнение проектов, комиссионные, поддержка обучающихся, и т.д.);
• Премии и бонусы по результатам деятельности организации в целом (годовые бонусы);
Но подобные схемы теряют свою эффективность

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

Известный консультант по корпоративной безопасности Роджер Граймс говорит, что ему надоело постоянно объяснять во время презентаций базовые факторы, которые влияют на безопасность политики паролей, принятой в организации. Он постоянно объясняет, почему восьми символов мало для надёжности паролей и какие ещё факторы могут помочь злоумышленнику эффективно подобрать пароль. Чтобы упростить себе задачу и продемонстрировать слабость средней политики паролей, Граймс составил Excel-таблицу (ZIP), в которой учёл все факторы: диапазон допустимых символов, длина пароля, количество вариантов в минуту, которые может пробовать злоумышленник, максимальное количество дней до смены пароля, модель энтропии.

Калькулятор показывает, сколько дней в среднем потребуется злоумышленнику, чтобы подобрать пароль при заданных условиях, сколько вообще существует возможных комбинаций и сколько из них реальных (с учётом реальной энтропии). Например, в дефолтном примере с 94 символами и длиной пароля в 8 символов при NIST-энтропии теоретическое возможное количество паролей превышает 6 квадриллионов, но количество вероятных паролей с учётом предположения о реальной энтропии — всего 16,8 млн. Для взлома такой защиты за допустимое количество дней нужно суметь установить скорость подбора всего 64,7 паролей в минуту.

По мнению автора, это первый калькулятор, который высчитывает не теоретическую, а практическую скорость взлома парольной защиты.

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

Не буду растекаться по древу насчет «до 5-7 тыс. у.е. в месяц в качестве физлица вы никому в упор не интересны».

Допустим без юрлица ну никак нельзя, да еще и на сайт с рекламой денег нет.  Что делать? 

По шагам:
1. Изучаете товары (Я.Маркет, запросы в Директ, ближайший рынок) на предмет «что бы такого не слишком приевшегося и конкурентного, но при этом простого в доставке, и чтобы геморроя с гарантиями/лицензиями поменьше.
Хинт: сувениры, игрушки, коллекционеры всех мастей. Берете одну/несколько специфических ниш для отработки.
Не надо брать строительство, окна, бытовую технику/электронику. Там, где кокурентов дофига.

2. Идем на ближайший рынок, торговый комплекс, а лучше отраслевую выставку(там народ крупнее и плотнее).

Memcached community предприняло немало попыток написать «родные» патчи для кода memcached, добавляющие в него поддержку тэгов. Наиболее известный из таких патчей — проект memcached-tag. К сожалению, memcached-tag все еще очень далек от стабильной версии: нетрудно написать скрипт, приводящий к зависанию пропатченного memcached-сервера. Похоже, на момент написания данной статьи не существует ни одного надежного решения проблемы тэгирования на уровне самого memcached-сервера.

Библиотека Dklab_Cache

Dklab_Cache — это (в основном) библиотека поддержки тэгирования ключей для memcached, использующая интерфейсы Zend Framework. Сама библиотека написана на чистом PHP. Вот полный список возможностей библиотеки:

• Backend_TagEmuWrapper: тэги для memcached и любых других backend-систем кэширования Zend Framework;
• Backend_NamespaceWrapper: поддержка пространств имен для memcached и др.;
• Backend_Profiler: подсчет статистики по использованию memcached и др. backend-ов;
• Frontend_Slot, Frontent_Tag: каркас для высокоуровневого построения систем кэшиирования в сложных проектах.

Собственно, для поддержки тэгов имеется класс TagEmuWrapper. Он представляет собой декоратор («обертку») для backend-классов кэширования Zend Framework. Другими словами, вы можете с его помощью «прозрачно» добавить поддержку тэгов в любую подсистему кэширования Zend Framework. Мы будем рассматривать backend для работы с memcached: Zend_Cache_Backend_Memcached, но, если в вашем проекте используется какой-то другой backend-класс, вы можете подключить тэгирование и к нему без каких-либо особенностей.

TagEmuWrapper реализует стандартный backend-интерфейс Zend_Cache_Backend_Interface, поэтому с точки зрения вызывающей системы он сам является кэш-backend'ом. Вообще, Zend Framework хорош тем, что на уровне интерфейса он поддерживает тэги с самого начала! Например, в методе save() уже имеется параметр, позволяющий снабдить ключ тэгами. Однако ни один из backend-ов в составе Zend Framework тэги не поддерживает: попытка добавить тэг к некоторому ключу вызывает исключение (в частности, для Zend_Cache_Backend_Memcached).

Технические подробности, документацию, а также примеры использования можно посмотреть тут: dklab.ru/lib/Dklab_Cache

Что такое тэги?

Работа с типичной кэширующей системой (в том числе с memcached) заключается в выполнении трех основных операций:

• save($data, $id, $lifetime): сохранить данные $data в ячейке кэша с ключом $id. Можно указать «время жизни» ключа $lifetime; спустя это время данные в кэше «протухнут» и удалятся.
• load($id): загрузить данные из ячейки с ключом $id. Если данные недоступны, возвращается false.
• remove($id): очистить ячейку кэша с ключом $id.

Предыстория
Введение в Open Telecom Platform/Открытую Телекомуникационную Платформу(OTP/ОТП)
Введение в gen_server: «Erlybank»

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

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

Цель: Сначала мы расширим сервер, добавив поддержку ПИН-кода для аккаунтов и авторизации через ПИН-код. Потом мы будем использовать gen_fsm чтобы создать бэкенд банкомата. Проверка данных будет проводиться на стороне сервера.

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

Простой цифровой термометр с подключением через COM-порт.