Мы написали веб-приложение для управления освещением при помощи системы NooLite.

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

Демо (вместо включения/выключения света в демо-режиме выдается текстовое сообщение о выполнении действий).

Мы использовали ASP.NET MVC на стороне сервера, JQuery Mobile на клиенте (собственно, в первую очередь интересно было управлять освещением именно с телефона). СУБД не требуется (настройки хранятся в конфигурационном файле). Для отправки команд с компьютера на управляющие блоки используется USB-адаптер PC118.

Скачать приложение можно здесь. Там же можно отдельно скачать .NET библиотеку, реализующую API для управления системой NooLite. Исходный код всего этого на Google Code.

Под катом находится инструкция по установке и настройке «с нуля».

Любите ли вы радиоуправляемые машинки так же, как любим их мы? Если да — добро пожаловать под кат.

Всем привет, нас зовут Leto, мы — английская компания, основанная двумя русскоязычными парнями. Мы создаем стартапы для наших клиентов. Иногда они обычные люди, которые решили начать свой бизнес и запустить стартап (например Sorted), а иногда это большие и состоявшиеся компании (например 20th Century Fox), которые пытаются запустить новый продукт или услугу. Мы помогаем им улучшить концепт, проработать бизнес-модель, мы разрабатываем сам продукт и создаем дизайн, запускаем, раскручиваем, анализируем — вобщем, мы стараемся делать все (или все из того, что требуется). Если вам знаком термин “lean startup”, то наш бизнес — это “lean startup as a service”.

Как и любой компании-разработчику, нам нужен был инструмент для управления проектами (или попросту “трекер”). Как и полагается, мы перепробовали много разных сервисов, но все как-то не подходило, и в результате мы создали свой очередной трекер простой и удобный сервис, который использовали внутри компании и давали своим клиентам. Почему, зачем и что из этого вышло — читайте под катом.

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

В итоге получилась система, сочетающая включение/выключение света как с помощью выключателей, так и через интернет — с помощью кнопок на веб-страничке.
Как это получилось — читайте под катом.

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

Пару лет назад, когда стоял вопрос отделки новой квартиры, возникла тривиальная, казалось бы, задача.
Дано:

• Кухня-студия (кухня совмещенная с холлом/коридором), три точки освещения.
• Необходимо управлять освещением из двух точек. У входа в квартиру и на кухне.

Варианты решения:

• Покупаем, так называемые, проходные выключатели, ставим три штуки на кухню, три в коридоре — вот оно счастье. Вот только получилось, что от коридора на кухню нужно вести 9 жил кабеля, некрасиво, спрятать некуда.
• Покупаем готовые решения по управлению одним источником с нескольких точек.
  Точных чисел не помню, но получалось что-то около 10000р за точку освещения + 1000р за каждый выключатель, итого 36000р. Жаба.
• Как это ни странно, но эту идею высказала жена, в общем-то далекая от IT: “ А помнишь, ты светофор в Яндексе делал? Может тут тоже что-то сам сообразишь?”
  В самом деле, а почему бы и нет, подумал я?

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

Наверняка каждый сталкивался с историями – «Здравствуйте, мне надо проехать в компанию, которая у вас на территории находится», получая в ответ, что «пропуск не заказан», «нельзя» или и вовсе глухие ворота высотой метра 4. Притом сам въезд как правило охраняется очень разным контингентом – от не совсем трезвого дяди Васи со стаей собак до реальных профи на важных объектах.

Задач, решаемых IT-средствами, тут три:

• На большую часть объектов, где въезд контролирует человек, можно зайти, использовав социнжиниринг, денежную купюру или, наоборот (реже), не войти из-за ряда причин, связанных с человеческим фактором. Нужно делать так, чтобы те, кому нужно въехать, всегда могли это сделать, а те кому не нужно — не могли.
• При этом издевательство с пропусками лучше пропустить. В идеале – ещё и пропустить стадию выхода из машины вообще. Ваш контакт отправил информацию о том, что вам можно — и ворота открываются автоматически.
• Служба безопасности должна чётко контролировать перемещения, иметь возможность выяснить, чья вот это машина стоит на территории и видеть перемещения людей по объекту за любой срок.

В топике – про эволюцию от верёвочки на входе до современных систем распознавания номеров.

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

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

Велосипед

Итак, Вася долго трудился рядовым программистом, ведущим программистом и наконец стал Руководителем. У него есть команда отчаянных головорезов разработчиков в количестве двух единиц. Безусловно талантливых и знающих свое дело специалистов.

Вася получает первый заказ — надо сделать … велосипед.

От переводчика:
Немало копий сломано в спорах о том, когда уместнее KISS, а когда DRY, когда лучше как можно быстрее и проще решить задачу любыми средствами, а когда стоит создавать красивые и универсальные абстракции. Натан Марц, автор популярного фреймворка Storm, используемого в Твиттере, предлагает свой вариант. Чтобы не создавать тонны бесполезного кода ради абстрактной универсальности и в то же время не позволять системе превращаться в кашу из костылей, он использует «разработку через страдание» (suffering oriented programming).

---

Однажды меня спросили: «Как ты решился пойти на такой страшный риск — писать Storm одновременно с запуском стартапа?» (Storm — фреймворк для распределённых вычислений в реальном времени). Да, пожалуй, со стороны создание такого крупного проекта для стартапа кажется крайне рискованным. Тем не менее, с моей точки зрения это вообще не было рискованным делом. Трудным, но не рискованным.

Я использую стиль разработки, который сильно уменьшает степень риска таких больших проектов, как Storm. Я называю этот стиль «разработкой через страдание». В двух словах: не занимайтесь реализацией технологий, от отсутствия которых вы не испытываете страданий. Этот совет применим как к большим, архитектурным решениям, так и к маленьким повседневным задачам. Разработка через страдание существенно уменьшает риск, гарантируя, что вы всегда работаете над чем-то важным, и что вы хорошо разобрались в предметной области, прежде чем вложить в решение много сил.

Я придумал такую мантру разработки: «Сначала сделай, чтобы было. Затем — чтобы было красиво. Затем — чтобы было быстро».

Данная статья давно назревала в моей голове, но совсем в ином формате.
Прочитав последние несколько неуклюжих статей на тему WEB-сервисов (например: http://habrahabr.ru/blogs/development/108973/) и применения в них REST технологии, решил что настало время все-таки откинуть лень, выделить время и написать «переформатированную» в своей голове статью.
Итак, кратко, что Вы найдете в статье и кому она будет полезна:

— новичкам, которые интересуются или планируют написать WEB-сервис для проекта
— профи вряд ли найдут что-то новое для себя
— общая идеология REST
— применение CRUD в WEB-сервисах
— принципы KISS при построении раутеров
— лучшие практики
— немного пиара ;)
— ссылки, литература

В руководстве по Prism можно найти небольшое упоминание о том, как обрабатывать запрос на взаимодействие с пользователем с помощью класса InteractionRequest. Напомню, о чём там шла речь:

Использование объектов запроса на взаимодействие

Один из подходов к осуществлению взаимодействия с пользователем при использовании шаблона MVVM — позволить модели представления посылать запрос на взаимодействие непосредственно в представление. Это можно осуществить с помощью объекта запроса взаимодействия (interaction request), сопряжённого с поведением в представлении. Объект запроса содержит детали запроса на взаимодействие, а также делегат обратного вызова, вызываемый при закрытии диалога. Также, данный объект содержит событие, сообщающее о начале взаимодействия. Представление подписывается на это событие для получения команды начала взаимодействия с пользователем. Представление обычно содержит в себе внешний облик данного взаимодействия и поведение (behavior), которое связано с объектом запроса, предоставленным моделью представления.

Добрый день, уважаемый %habrausername%!

Судя по предыдущим постам, многие из вас интересуются hand-made автоматизацей своего жилища. Я долго собирался с мыслями и идеями по итогам построения первого «умного дома» и теперь хочу поделиться своими наработками с вами.

Зачем?

Вообще, идея этого поста пришла мне в голову в тот самый момент, когда я, не имея до этого за плечами полноценного опыта фриланса, решил всерьез освоить oDesk. Да, если кто не знает, oDesk — это одна из крупнейших в мире фриланс-бирж. Итак, дело было в июле этого года. Официальной работы к тому времени у меня уже полгода как не было, все подработки закончились, новых серьезных заказов не предвиделось, и oDesk представлялся мне весьма перспективным вариантом. Аккаунт, как водится, был зарегистрирован «про запас» еще за год до того, но висел все это время без дела, поэтому начинать нужно было с нуля. При этом я был почти уверен, что руководство, хотя бы самое краткое, на тему, как и с чего начинать, я где-нибудь (уж на Хабре-то точно!) да найду.
Возможно, я плохо искал. Однако все, что мне попалось по теме, сводилось только к тому, что не нужно сразу загибать цены, лучше начинать с небольших. Примерная цитата: «начинайте с $10 в час, со временем, дорастете и до $15». Дорастать до $15, да еще и со временем, мне категорически не хотелось, я был уверен, что можно зарабатывать значительно больше. Да и кроме того, меня волновало огромное количество вопросов. Как заполнять профиль? На какие проекты откликаться? Как составлять cover letter? Как, черт побери, получить этот первый заказ, когда все тебе отказывают?
В тот момент я решил, что если все у меня получится, обязательно напишу то самое руководство для новичков, которого я не нашел.

Что имелось вначале

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

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

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

При решении задачи использовались следующие инструменты: NuGet, TeamCity, NAnt, Visual Studio 2010, SlowCheetah.

Недавно я попал на новый проект, с задачей создать небольшое приложение с нуля. Разговариваю с тестером:
— А как тебе новые версии поставлять?
— Можешь как все остальные на проекте, через SVN.
— То-есть ты сама билдить будешь?
— Да нет… Бинарники оттуда беру.

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

Нашей компании уже 6 лет. Она была основана на принципах agile и росла на них. Мы использовали Extreme Programming с самого первого дня, добавили немного Scrum позже и в конце концов переключились на Kanban. Хочется поделиться бесценным опытом и рассказать об изменениях нашего процесса разработки за последние 4 года.

В прошлой статье была затронута тема информационной безопасности такой крупной компании, как Google.
Настало время посмотреть в сторону отечественного производителя, а именно, компании Яндекс и её сервиса карт.
С чего все началось. Стоял я, значит, как-то в пробке и думал, что заставляет всех людей ездить теми или иными маршрутами. Ответ очевиден: много чего.
Однако не последнюю роль определенно играет наличие пробок и разного рода дорожных ситуаций (ДТП, ремонт полотна, камеры).
Кроме того, эти факторы учитывают и все современные навигаторы при прокладке маршрута.
Что ж, попробуем повлиять на дорожную обстановку, хотя бы виртуально…

Я собираюсь сделать Java-веб-приложение (да, это будет Java, по некоторым причинам, которые сейчас озвучивать не хочу). В процессе работы, я оцениваю кучу J2EE portlet-enabled JSR-compliant MVC role-based CMS web service application container фреймворков.

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

Давайте представим, что я решил сделать шкафчик для специй.

Ниже краткое изложение опубликованного ранее поста Почему я ненавижу фреймворки :

В средневековые времена программирования, к данным мы применяли функции. Для того, чтобы нарезать хлеб, брали структуру «хлеб» и передавали ее как параметр функции «нарезать»:

нарезать(хлеб);

Есть много споров о плюсах и минусах ORM, попробуем сделать акцент на плюсах при его использовании в ERP приложениях.

Я 5 лет разрабатываю платформу для ERP, разработал три версии платформы. Всё начиналось с EAV, после была нормальная модель, хранимые процедуры, view-хи, и сейчас эволюционировало до использования ORM. Позвольте поделиться опытом, почему ORM — хорошо.

Для демонстрации преимуществ такого подхода я разработал небольшое приложение для риэлтерского агентства (вдохновение черпал из Циан, из него же и модель данных) и попробую описать, почему благодаря ORM я все сделал за 1 день.