Update
Новый вариант порошка и более подробный разбор во второй части: DIY порошок для посудомойки: разбираем промышленные средства и улучшаем рецепт

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

Есть очень много областей нашей жизни, где наше представление формирует исключительно маркетинговый буллшит. Увы, большинство людей даже не пытаются задумываться о том, что лежит в основе всего этого. Очень часто рыночная ситуация приводит к тому, что себестоимость продукта составляет 0.5% от его цены. Остальное маркетинг, наценки, логистика, упаковка и тому подобное. Почти все в курсе про концепцию продажи чернил для принтера по цене слез гималайских девственниц и настойчивые рекомендации производителей использовать только оригинальные расходные материалы. Например, совсем недавно меня озарило, что 1.5 грамма сухого вещества во флаконе удобрений для растений не могут стоить 200-250 рублей. А ведь именно такое количество может уместиться в относительно стабильном состоянии в виде раствора. Я сразу представил себе гектары полей и грузовики, которые везут тонны порошка. В результате перешел на расфасовки по 1 кг Буйских комплексных сухих удобрений. Можно ванну раствора приготовить.

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

TLDR:

70% прокаленной соды и 30% стирального порошка вместо моющего средства.
Если очень лень возиться с содой, то просто порошок Биолан или его аналоги. Сода удешевляет.
Пищевая соль «Экстра» вместо соли.

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

Пара примеров:

• «Удобный хостинг»: Предустановка панели управления и дозаказ лицензий на лету
• Как работает API нашего IaaS-провайдера
• Как мы разработали свой DNS-менеджер

Сегодня мы поговорим о том, как ускорить загрузку страниц, и взглянем на советы эксперта по Ruby Нейта Беркопеца (Nate Berkopec).

Ночная зала. Тысячи таинственных ликов в темноте, подсвеченных голубоватым свечением мониторов. Оглушительный треск миллиона клавиш. Подобные выстрелам автомата удары по клавишам «Enter». Зловещее стрекотание сотен тысяч мышек… Так, наверняка, играло воображение каждого разработчика высоконагруженной системы. И если его вовремя не остановить, то может выйти целый триллер или фильм ужасов. Но в данной статье мы будем гораздо ближе к земле. Мы кратко рассмотрим известные подходы к решению задачи поисковых подсказок, как мы научились делать их полнотекстовыми, а также расскажем о парочке уловок, на которые мы пошли, чтобы придать им скорости, но при этом не научить жадности к ресурсам. В конце статьи вас ждёт бонус — небольшой рабочий пример.

Около месяца назад попали в мое распоряжение модули Atmel ATZB-S1-256-3-0-C основанные на чипе ATmega256RFR2 объединяющим в себе 2.4Mhz трансивер, микроконтроллер AVX на 256 килобайт памяти и даже чип-антенну. Атмель обещали в свою очередь out of the box поддержку Zigbee для этих модулей и было принято решение строить наш mesh именно на них.

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

Звучит довольно просто, не так ли? На практике все оказалось намного прозаичнее. Основной проблемой оказалась недооценка технологической сложности атмелевского стека Zigbee, самого стандарта Zigbee, ну и переоценка собственных возможностей. Дело в том что сам я давно не програмировал на C, давно перешел на Matlab и Python, все указатели и другие средства управления ресурсами и процессами давно положил в тумбочку и выкинул ключ. Ну что-же… в мире ембеддед меня ждало много приятных неожиданностей.

В ассортименте компании «Мастер Кит» появилось заметное количество беспроводных устройств для домашней автоматизации, но вот собрать их в какую-то оптимальную систему управления домом часто бывает трудно из-за отсутствия необходимого, а главное удобного программного обеспечения. Для решения этой проблемы попробуем воспользоваться уже существующими популярными системами домашней автоматизации. Это реально! Например, система домашней автоматизации OpenHAB – это открытый проект, про который написано уже достаточно много даже в русскоязычной части Интернета.

Для одного из проектов по автоматизации потребовалось сделать устройство, которое является подчинённым 1-Wire устройством, принимает команды от мастера и выставляет на своих выходах значение аналогового сигнала в диапазоне от 0 до 10В.
Проанализировав линейку стандартных микросхем 1-Wire от Maxim, стало ясно, что нет микросхемы, которая позволит реализовать подобный функционал.
Потому было принято решение реализовывать 1-Wire slave на микроконтроллере. Надеюсь, данный материал будет интересен и полезен людям, которые делают «умный дом» своими руками, т.к. 1-Wire достаточно популярная шина в подобных проектах. В качестве камня был выбран МК Cortex M0+ ATSAMD20G16 от Atmel, но о реализации в коде расскажем во второй части. Забегая немного вперед, скажу что в третьей части цикла пойдет речь о реализации собственного семейства устройств для линуксовой библиотеки OWFS (One Wire File System). А сегодня расскажем о некоторых аппаратных решениях, к которым мы пришли в процессе разработки.

Революция о которой так долго говорили большевики свершилась. Теперь вы можете взять карточку памяти microSD, записать на неё файлы дистрибутива AMS и ваша Arduino превратиться в маленькое (или большое, это как посмотреть) чудо. Вам больше не нужны «костыли» с поддержкой стороннего сервера, Arduino Mega Server стал полностью автономным и вполне «юзабельным» в одиночном режиме работы. И это открывает для всех нас очень интересные перспективы.

Да, это снова Ардуино, но не спешите закрывать страничку, на этот раз вас ждёт нечто действительно новое и интересное. В основном в этой статье речь пойдёт о микроконтроллерных платах Arduino Mega и плате сетевого интерфейса Ethernet Shield W5100 и о том чуде, которое можно с ними сотворить если позволить себе выйти за рамки стереотипов.

Мой обычный вечер — это посиделки за компьютером. Холодными вечерами частенько появлялось желание сделать моё место отдыха комфортнее. Точнее, периодически было просто холодно ногам. Идеи были различные, вплоть до покупки USB тапочек с подогревом. Однако, все они казались мне нелепыми и отметались. И вот однажды, просматривая YouTube канал одного из любителей Arduino, я наткнулся на видео, где рассказывалось про инфракрасную плёнку. Увидев эту плёнку, я сразу понял: «Вот то, что мне надо!»

Данный проект можно кратко описать так: я положил кусок инфракрасной плёнки под дополнительный слой паркета, добавив к нему систему автоматического управления с помощью Arduino, нескольких датчиков и VB.NET. Теперь по порядку, что и как получилось.

Не секрет, что каждый интернет-магазин должен помогать пользователям найти то, что им нужно. Особенно, если товаров у вас много (> 10). На помощь приходит каталогизация товаров, но разбить товары по категориям — полдела. Товары внутри категории нужно уметь фильтровать по их свойствам. Особенно, если товары у вас разношёрстные, например, одежда, электроника, ювелирные изделия и т.д. И тут любой разработчик, пишущий свой e-commerce продукт, сталкивается с неприятными реалиями жизни: у товаров могут быть совершенно разные свойства, у некоторых товаров они могут отсутствовать, некоторые товары по одному свойству могут попадать под разные значения (цвет платья то ли синий, то ли голубой, соответственно, неплохо бы его показать и по синему и по голубому цвету). Проще говоря, у вас EAV. Бывает ещё, что EAV вам диагностирует заказчик ближе к концу разработки, а то и просит добавить фильтр по динамическим свойствам уже после релиза.

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

Основные проблемы, которые встречаются в библиотеках валидации данных

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

Проблема №2. Процедурное описание правил валидации. Я не хочу каждый раз думать про алгоритм валидации, я просто хочу описать декларативно, как должны выглядеть правильные данные. По сути, я хочу задать схему данных (почему не «JSON Schema» — в конце поста).

Проблема №3. Описание правил валидации в виде кода. Казалось бы, это не так страшно, но это сразу сводит на нет все попытки сериализации правил валидации и использования одних и тех же правил валидации на бекенде и фронтенде.

Проблема №4. Валидация останавливается на первом же поле с ошибкой. Такой подход не дает возможности подсветить сразу все ошибочные/обязательные поля в форме.

Проблема №5. Нестандартизированные сообщения об ошибках. Например, «Field name is required». Такую ошибку я не могу показать пользователю по ряду причин:

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

То есть, нужно возвращать не сообщение об ошибках, а стандартизированные коды ошибок.

Проблема №6. Числовые коды ошибок. Это просто неудобно в использовании. Я хочу, чтобы коды ошибок были интуитивно понятны. Согласитесь, что код ошибки «REQUIRED» понятней, чем код «27». Логика аналогична работе с классами исключений.

Проблема №7. Нет возможности проверять иерархические структуры данных. Сегодня, во времена разных JSON API, без этого просто не обойтись. Кроме самой валидации иерархических данных, нужно предусмотреть и возврат кодов ошибок для каждого поля.

Проблема №8. Ограниченный набор правил. Стандартных правил всегда не хватает. Валидатор должен быть расширяемый и позволять добавлять в него правила любой сложности.

Проблема №9. Слишком широкая сфера ответственности. Валидатор не должен генерировать формы, не должен генерировать код, не должен делать ничего, кроме валидации.

Проблема №10. Невозможность провести дополнительную обработку данных. Практически всегда, где есть валидация, есть необходимость в какой-то дополнительной (часто предварительной) обработке данных: вырезать запрещенные символы, привести в нижний регистр, удалить лишние пробелы. Особенно актуально — это удаление пробелов в начале и в конце строки. В 99% случаев они там не нужны. Я знаю, что я до этого говорил, что валидатор не должен делать ничего кроме валидации.

3 года назад, было решено написать валидатор, который не будет иметь всех вышеописанных проблем. Так появился LIVR (Language Independent Validation Rules). Есть реализации на Perl, PHP, JavaScript, Python (мы на python не пишем — фидбек по ней дать не могу). Валидатор используется в продакшене уже несколько лет практически в каждом проекте компании. Валидатор работает, как на сервере, так и на клиенте.

Задумал я как-то в одной из конструкций применить вот такую кнопку с индикацией состояния:



Внутри — пара замыкающих или переключающих контактов и светодиод (опционально — уже с гасящим резистором на выбор для питания от 5, 12, или 24 В). Все бы с ней хорошо, но разместить кнопку планировал на приборной панели автомобиля, а управляющий блок — в моторном отсеке. А тянуть отдельные провода для контакта и для индикации уж очень не хотелось.

Как это решить, и что для этого нужно — под катом

Всем привет! Мы, в компании Cackle, занимаемся разработкой облачных SaaS-решений для сайтов с 2011 года. Наши продукты установлены более чем на 10 000 сайтах, каждый день мы обрабатываем в среднем 65 миллионов уникальных хитов. Полоса пропускания (bandwidth) в пики доходит до 780 мбит/сек, а БД в сутки принимает до 120 миллионов запросов на чтение, и до 300 тысяч запросов на запись. Такие нагрузки заставляют изобретать непростые решения, частью которых мы и хотим поделиться.

Предыстория

Хотелось создать своего робота, а так же автоматизировать управление светом и климатом дома. С этой целью начал изучать имеющиеся возможности. Для себя я разделил все решения на две группы: системы в которых код на контроллере выполняется в одном главном цикле (arduino, lego и т.п.) и системы состоящие из параллельно работающих процессов обменивающихся между собой сообщениями.
Интуитивно выбрал вторую группу, так как хотелось найти максимально простое решение с дружественным пользовательским интерфейсом. Из наиболее популярных представителей этого «семейства» очень понравились Microsoft Robotics Studio и ROS. Но к сожалению, на текущий момент, привязать их к конкретному железу весьма не просто, да и разобраться в них с нуля так же весьма не тривиальная задача. В итоге принял решение писать сам, но «кодить» на C очень не хотелось, Душа просила чего-нибудь попроще и полегче. В итоге выбрал Python. А учитывая, что по мимо робота и «умного дома» в голову начало лезть куча других идей, то решил сразу сделать небольшой фреймворк, в котором основной упор был бы сделан на простоту разработки.

Концепция

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



Сеть процессов строится на базе стандартного Python модуля multiprocessing. Система обмена сообщениями и разделяемая память реализованы при помощи Redis.

Каждый Bubot имеет встроенный веб-сервер веб-сервер Tornado, который позволяет контролировать состояние, управлять роботом, на ходу менять параметры (калибровать) робота, а также закладывается возможность обмена данными между роботами.
Bubot не является системой реального времени, хотя Bubot возможно интегрировать с кодом реального времени.

Содержание

• Введение
• Величины, типы и операторы
• Структура программ
• Функции
• Структуры данных: объекты и массивы
• Функции высшего порядка
• Тайная жизнь объектов
• Проект: электронная жизнь
• Поиск и обработка ошибок
• Регулярные выражения
• Модули
• Проект: язык программирования
• JavaScript и браузер
• Document Object Model
• Обработка событий
• Проект: игра-платформер
• Рисование на холсте
• HTTP
• Формы и поля форм
• Проект: Paint
• Node.js
• Проект: веб-сайт по обмену опытом
• Песочница для кода

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

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


Встречи моноциклистов

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

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

TL;DR: Работа с таймзонами — это боль и унижение. Никогда не работайте с таймзонами!

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

У меня есть мечта: однажды система налогообложения станет прозрачной, доступной для понимания и продуманной с точки зрения удобства предпринимателей. К сожалению, на текущий момент налогообложение Украины стоит по простоте ведения на 181 месте из 183 и служит скорее обогащению бюджета на штрафах, чем развитию малого бизнеса. Упрощенная система все больше становится номинальной с выходом новых указов, снова и снова заставляющих погружаться в дебри законопроектов. Доходит до того, что сама налоговая вынуждена публиковать разъясняющие свои же требования письма.

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

На любом околосетевом форуме легко найти с десяток веток о выборе оборудования для BGP-пиринга с возможностью «держать две, три, пять, двадцать пять фулвью». Большинство таких веток выливается в холивары на тему Cisco vs. Juniper или еще чего похуже. Офлайновое же их развитие нередко напоминает мультфильм о шести шапках из одной овичины. В общем, бывает смешно.

И крайне редко обсуждается вопрос о необходимости этого самого фулвью.

После публикации своего первого поста «Почему я люблю Microsoft. Заметки Зомби» я получил достаточно много писем с похожей просьбой — написать подробнее об используемых продуктах.
Просили — получите. При написании статья я поставил себе цель — описать основной маршрут. Расписывать тонкости установки и настройки нет смысла — их достаточно в Интернет. Я старался, чтобы прочитав этот пост администратор знал названия продуктов и технологий, для чего они нужны и потом уже мог ловко нагуглить всё остальное. Для того, чтобы облегчить поиск ключевые названия будут на английском. Если какая-то аббревиатура незнакома — это повод про неё почитать. И, да, я буду описывать решения от Microsoft, так как что-то смыслю только в них. Хочу сразу предупредить что топик очень конспективный.

Навеяно темой Cisco: Пути сертификации неисповедимы.

1. Подготовка к 640-802. Теория.
2. Подготовка к лабе. Практика.
3. Подготовка к экзамену. Регистрация и порядок.
4. Сертификат.

1. Подготовка к 640-802. Теория.

Для получения статуса CCNA существует два пути — это экзамен 640-802 или пара 640-822 + 640-816. В данном обзоре рассматривается исключительно первый вариант, в терминологии циско т.н. композитный экзамен(13).

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