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

Локализация здесь осуществляется довольно нехитро. Все строки, требующие перевода, оборачиваются в макрос _TR():

wprintf(L"%s\n", _TR("Some translating string"));

Макрос возвращает нужную версию текста в зависимости от текущего используемого языка. Определён он следующим образом:

#define _TR(x) g_Translator.Translate(x)

Здесь происходит обращение к глобальному объекту g_Translator, который в функции Translate() считает в рантайме crc32 от указанной строки, ищет в своей xml-базе перевод с совпадающей контрольной суммой и возвращает его.

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

Немного погуглив по запросу «compile-time crc32» я быстро понял, что задача это не самая тривиальная, а готовых решений мне найти так и не удалось.

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

• заполнить стол значками до предела, периодически «удалять неиспользуемые»
• оставить на столе корзину и красивую картинку, удалять со стола всё, регулярно чистить корзину
• расположить на столе часто используемые ярлыки и некоторые рабочие документы

UPD: Пока в комментах побеждает вариант неиспользуемого стола.
Всё это — варианты нормы, единственный недостаток — рабочий стол не помогает в организации работ. Это примерно как обвинить кота, что он не приносит тапочки. Но ведь мог бы и приносить!!! Достаточно правильно расчертить дорожки.

Сначала я подумал, что я гений и заработаю миллионы на этой идее, но потом решил вбить в поисковик «Organizing desktop wallpaper». Нафантазированная яхта и девушки-поклонницы исчезли, но стало ясно, что, во-первых, желание вполне адекватное, а во-вторых уже есть готовые варианты, чтобы взять и использовать. Т.е. хотя бы тапочки. Картинка выше взята из статьи How to Design and Create a Clean, Organized Desktop.
Ниже будет список найденных статей и вариантов, а также я расскажу о своей идее и тех задачах, которые она должна решать:

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

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

Несмотря на свою простоту как физического смысла, так и математической записи:

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

Причем проверить качество реализации ПИД регулятора крайне легко.

На проектах использую Twitter Bootstrap и jQuery UI для прототипирования интерфейсов различных элементов страниц в т.ч. форм.

На днях понадобилось дополнить форму одним полем. Был выбран наиболее подходящий формат, в виде набора переключателей (элемент input, тип radio).

В Twitter Bootstrap, набор переключателей представлен в виде набора кнопок и не работает напрямую с элементом input, что предполагает написание дополнительного кода для обработки событий. Библиотека jQuery UI, имеет решение подобной задачи, и вся обработка событий уже реализована.

Не так давно, в команду пришлось приглашать нового программиста и знакомить его с Erlang. Для ускорения процесса обучения я решил перевести уже давно лежавший у меня материал Erlang Programming Rules and Conventions. Чем в принципе и хочу поделиться с хабровчанами. Надеюсь что он будет полезен тем, кто собирается изучать или уже использует этот замечательный язык. Сразу скажу, что перевод вольный, так что не критикуйте сильно.

Cуществует уже несколько десятков JavaScript-фреймворков для построения сложных приложений в браузере. Чтобы сравнить их между собой и выбрать наиболее подходящий, примитивного примера вроде классического «Hello, world» явно недостаточно. Более сложные и реалистичные примеры программ в книгах и документации каждого фреймворка могут сильно отличаться, и сравнивать их между собой затруднительно. Проект TodoMVC решает именно эту проблему. Это набор примеров реализации одного и того же простого, но вполне законченного веб-приложения с использованием разных фреймворков + эталонный пример на чистом JavaScript.

Приложение TodoMVC — это список дел. Дела можно добавлять, помечать как выполненные и удалять. Список должен сохраняться в локальном хранилище браузера. Приложение должно по возможности использовать стандартный шаблон HTML и CSS. Вот подробная спецификация приложения.

— Какое отношение имеет морская свинка к морю?
— Примерно такое же, как утконос к проектированию дирижаблей.

Введение.

Я имею обыкновение во время прогулок прокручивать информацию из нескольких источников, сопоставляя куски. Одна из любопытных находок – почти полное соответствие статистических наблюдений Демарко и Листера в «Peopleware» и теоретических выкладок Голдратта в «Критической цепи».

Осенью 2011 я крутил в голове:
[1] «Стоя на плечах гигантов» Эли М. Голдратт © Eliyahu M. Goldratt, 2008
[2] «Производственный менеджмент: управление потоком» Одед Коуэн, Елена Федурко
[3] «История одной доски» (http://cartmendum.livejournal.com/tag/theboard).

Далее хотелось бы написать: «Как вдруг…», — но это будет неправдой. Это случилось не вдруг. Мне понадобилось пару недель, но, в конце концов, в голове сложилась достаточно цельная картинка.

За что именно я зацепился:

• Таичи Оно (Öno Taiichi) не понимал, почему его система работает.
• Существует несколько разных типов производственных потоков – V, A, T, I. Каждый тип потока ставит особые задачи.
• Неудачи внедрения доски Максима Дорофеева в некоторых подразделениях
• Ряд компаний не смог внедрить систему Тойота, несмотря на все приложенные усилия.
• Система Тойота и система Форда основывается на одинаковых принципах, но прикладные решения ограничены определенными типами производства.

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

Теперь хочу подробно разобрать пример построения контрольной карты Шухарта на основе реальных данных. В качестве реальных данных я взял историческую информацию о завершенных личных задачах. Эта информация у меня есть благодаря адаптации под себя модели личной эффективности Дэвида Аллена Getting Things (про это у меня тоже есть старый слайдкаст в трех частях: Часть 1, Часть 2, Часть 3 + Excel-табличка с макросами для анализа задач из Outlook ).

Постановка задачи выглядит так. У меня имеется распределение среднего числа завершенных задач в зависимости от дня недели (ниже на графике) и нужно ответить на вопрос: «есть ли что-то особенное в понедельниках или это всего лишь погрешность системы?»



Ответим на этот вопрос при помощи контрольной карты Шухарта – основного инструмента статистического управления процессами.

Американская компания Bocoup, как и многие другие веб-разработчики, постоянно использует в работе известный «пуленепробиваемый» шаблон для создания HTML5-сайтов HTML5 Boilerplate. Однако, сотрудники Bocoup решили не только пользоваться, но внести свой вклад в общее дело и выкатили для всеобщего пользования не менее концептуальную вещь — Backbone Boilerplate, набор лучших средств и приёмов для создания приложений Backbone.js.

Прямо из коробки мы получаем:

• Backbone, Underscore и jQuery, всё это на базе HTML5 Boilerplate.
• Инструмент Windows/Mac/Linux для прекомпиляции шаблонов, связывания и минификации всех библиотек, кода приложения и CSS.
• Лёгкий веб-сервер node.js.
• Многочисленные сниппеты кода для Backbone, облегчающие жизнь.

В Backbone Boilerplate логичная и элегантная файловая система (отдельно код, вспомогательные файлы, тесты, билды) и есть возможность создавать собственные классы Models/Collections/Views/Routers внутри модулей.

Разработчики говорят, что проект появился в результате их долгих попыток работать с другими шаблонами: оказалось, что в одних нет процесса сборки, другие налагают излишние ограничения. Новый Backbone Boilerplate призван исправить ситуацию и вполне может стать каноническим, каким стал тот же HTML5 Boilerplate.

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

Если вы не понимаете, что побудило сделать git именно таким, то вас ждут страдания. Используя множество флагов (--flag), вы сможете заставить git работать так, как по вашему мнению он должен работать, вместо того, чтобы работать так, как git того хочет. Это как забивать гвозди отверткой. Работа делается, но хуже, медленнее, да и отвертка портится.

Как известно, CoffeeScriptпредлагает несколько иной набор управляющих конструкций, нежели JavaScript.

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

Обзор практически всех *top утилит под linux (atop, iotop, htop, foobartop и т.д.).

top

Все мы знаем top — самую простую и самую распространённую утилиту из этого списка. Показывает примерно то же, что утилита vmstat, плюс рейтинг процессов по потреблению памяти или процессора. Совсем ничего не знает про загрузку сети или дисков. Позволяет минимальный набор операций с процессом: renice, kill (в смысле отправки сигнала, убийство — частный случай). По имени top суффикс "-top" получили и все остальные подобные утилиты в этом обзоре.

atop

Atop имеет два режима работы — сбор статистики и наблюдение за системой в реальном времени. В режиме сбора статистики atop запускается как демон и раз в N времени (обычно 10 мин) скидывает состояние в двоичный журнал. Потом по этому журналу atop'ом же (ключ -r и имя лог-файла) можно бегать вперёд-назад кнопками T и t, наблюдая показания atop'а с усреднением за 10 минут в любой интересный момент времени.

В отличие от top отлично знает про существование блочных устройств и сетевых интерфейса, способен показывать их загрузку в процентах (на 10G, правда, процентов не получается, но хотя бы показывается количество мегабит).

Незаменимое средство для поиска источников лагов на сервере, так как сохраняет не только статистику загрузки системы, но и показатели каждого процесса — то есть «долистав» до нужного момента времени можно увидеть, кто этот счастливый момент с LA > 30 создал. И что именно было причиной — IO программ, своп (нехватка памяти), процесор или что-то ещё. Помимо большего количества информации ещё способен двумя цветами подсказывать, какие параметры выходят за разумные пределы.

Если кто помнит, в первой части своей статьи о гарантиях я упоминал о «подразумеваемых гарантиях» (Implied Warranties), которые автоматически являются частью контрактов на разработку ПО, т.к. они закреплены законодательно. В британском законодательстве эти гарантии закреплены в The Sale of Goods Act 1979 и The Supply of Goods and Services Act 1982. Напомню, что к «Implied Warranties» относятся: 1) Warranty of Title, 2) Infringement Warranty, 3) Warranty of Merchantability, 4) Warranty of fitness for а specific Purpose.Мы говорили о том, что если прямо не исключить действие этих гарантий, то они будут распространяться на правоотношения в рамках этого контракта. Теперь я предлагаю рассмотреть варианты исключения действия этих подразумеваемых гарантий.

В первую очередь стоит отметить, что если мы говорим о праве Великобритании, то все исключения «warranties» должны соответствовать требованиям, которые предъявляет UTCA (Unfair Contract Terms Act 1977). В соответствии с UTCA, некоторые «implied warranties» вообще не могут быть исключены (например, «Warranty of Title»), а некоторые, могут быть исключены только целесообразно — «only if reasonable» (например, «Warranty of fitness for а specific Purpose»). Если суд придет к выводу о том, что условие об исключении гарантии идет в разрез с требованиями этого нормативного акта, то это условие будет считаться недействительным. Во избежание рисков, связанных с нарушением UTCA, и в целях обеспечения исключения максимального числа гарантийных обязательств, разработчик может воспользоваться следующей конструкцией: «Other warranties are excluded to the maximum extent permitted by law».