Не секрет что каждый из нас хоть раз но мечтал получить в свои руки настоящий тепловизор. Ведь это уникальный шанс взглянуть на мир вокруг совершенно «другими глазами», увидеть скрытое и возможно даже глубже познать суть некоторых явлений. И единственной преградой к этой мечте служит цена подобных устройств. Несмотря на весь прогресс, она остается непомерно высокой для простого смертного.
Однако подобно лучу света в непроглядном мраке безысходности на свет появилась разработка двух студентов из Германии. Их устройство на базе микроконтроллера Arduino является довольно простым в изготовлении и существует аж с 2010 года.

С каждым днем сайты становятся все сложнее и динамичнее. Уже недостаточно просто «оживить» интерфейс — все чаще требуется создать полноценное одностраничное приложение. Ярким примером такого приложения является любая web-почта (например, Mail.Ru), где переходы по ссылкам приводят не к перезагрузке страницы, а только к смене представления. А это значит, что задача получения данных и их отображения в зависимости от маршрута, которая всегда была прерогативой сервера, ложится на клиент. Обычно эту проблему решают с помощью простенького роутера, на основе регулярных выражений, и дальше не развивают, в то время как на back-end этой теме уделяют гораздо больше внимания. В этой статье я постараюсь восполнить этот пробел.

Продолжаем публиковать статьи по следам Design Camp. Сегодня у нас на очереди доклад Егора Гилева (yegorg), который на момент кампа работал в компании Парксис, но в феврале 2013 г. ушел в свободное плавание и теперь вместе с ещё одним сооснователем студии Турбомилк Денисом Кортуновым работает над собственными проектами. Статья приведена как есть и отображает авторскую точку зрения на дизайн приложений под Windows Phone.

Я работаю дизайнером User Experience в компании Parcsis. В том виде, в каком она существует сегодня, она образовалась в результате слияния двух компаний: Parcsis и Турбомилк. Parcsis — это в некотором роде инкубатор, запускающий собственные интернет-проекты. Турбомилк — всемирно известная в узких кругах студия дизайна интерфейсов. Я являюсь сооснователем Турбомилка. Около полутора лет назад мы объединились, и команда дизайнеров Турбомилка стала отделом UX-дизайна объединённой компании.

В компании я слыву чудаком. Считается, что дизайнер должен работать на большом алюминевом маке и владеть айфоном, желательно последнего поколения. Я работаю на ноутбуке-трансформере с Windows 8, который купил в первый же день продаж Windows 8 в России. Телефоном у меня служит белая Lumia 710 — пока еще на Windows Phone 7.5. Вы не ошибётесь, если предположите, что я люблю Windows. Особенно новый интерфейс Windows, который раньше назывался Метро. Я его нежно люблю и как пользователь, и как дизайнер интерфейсов.

Возвращаясь к нашей компании. Один из основных проектов Парксиса называется «Право.ru». Этот проект в себя включает много всего интересного, но для сегодняшнего нашего разговора нам важна только одна его часть — та, которая является справочно-правовой системой, доступной как в вебе, так и на мобильных устройствах. Теперь и на Windows Phone:



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

Со времён MSIE4 и блокнота, Я люблю комментировать написанный код. Но одно дело, когда проект создаётся для себя, или при компиляции комментарии не попадут конечному пользователю. И совсем другое дело, когда написанные комментарии могут попасть конечному клиенту. Во первых, они ему не нужны, а во вторых, в комментариях может содержаться некий текст, который может подвергнуть опасности этот или другой проект. И в третьих, содержимые в клиентском коде (HTML, JS, CSS) комментарии, даже в сжатом виде, создают паразитный трафик.
Изучая такой код иногда можно натолкнуться на интересные вещи. Вот, к примеру, один из кусков комментариев на одном всеми известном сайте:

Правило №1 в DIY: никогда не довольствуйтесь тем, что вам дано. Вы можете проапгрейдить или улучшить все что угодно обладая скромными познаниями и приложив немного усилий, особенно если вы немного знакомы с электроникой. Под катом 10 домашних предметов, которые вы можете круто прокачать, используя капельку припоя и ряд DIY ноу-хау.

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

20-летнему юбилею тега IMG посвящается

25 февраля 1993 года Марк Андрессен (Marc Andreessen) написал:
Предлагаю новый опциональный HTML-тег: IMG
При нем должен обязательно указываться аргумент SRC=«url».
Тег отсылает к файлу растрового изображения (bitmap или pixmap). Браузер будет запрашивать этот файл в Сети, распознавать как изображение и вставлять в текст сообразно месту тега в коде страницы .

Допустим, вы нарисовали в Corel Draw! логотип компании и собираетесь разместить его на сайте не как-нибудь, а формате HTML5. И, соответственно, размещать картинку не в растровом формате, а в .SVG

Зачем мне картинка в SVG?

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

Онлайн-сервисы становятся все популярнее, постепенно усложняя функционал и улучшая интерфейсы. В этой подборке представлены онлайн-инструменты для кодеров.

Cloud9

«Это Google Docs, только для кода» — так говорят о проекте. Облачный сервис вырос из Mozilla Bespin. Основные фишки: SSH, drag-and-drop и возможность разработки оффлайн.

С недавнего времени я интересуюсь языком Scala. Пару месяцев назад я набрел на интересную серию статей от компании Twitter. Я сносно читаю на английском, но все же приятнее читать на русском языке, если есть нормальный перевод.
Благодаря труду Мариуса Эриксена (Marius A. Eriksen) и других людей серия статей увидела свет. Всех желающих узнать больше о Scala и помочь в улучшении перевода — приглашаю под кат.

Здравствуйте, изначально статья задумывалась как обзор плоттерного винила Oracal 651 в качестве замены фотобумаги для переноса тонера. Однако, в качестве примера я выбрал самодельную версию Arduino Mini (ATMega8) и решил довести статью до логического завершения.



Винил выгодно отличается от фотобумаги и разного рода подложек — процесс изготовления платы становится менее трудоемким и более экономичным, о самом ЛУТ можно почитать здесь.

И снова здравствуйте! Сегодня я поведаю о фильтре Блума — структуре данных гениальной в своей простоте. По сути, этот фильтр реализует вероятностное множество всего с двумя операциями: добавление элемента к множеству и проверка принадлежности элемента множеству. Множество вероятностное потому, что последняя операция на вопрос «принадлежит ли этот элемент множеству?» даёт ответ не в форме «да/нет», а в форме «возможно/нет».

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

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

Ролики с демонстрацией пиксельной подсветки выглядят довольно эффектно — куча разноцветных всплохов, динамичные отблески смотрятся просто замечательно и выглядят более подвижными по сравнению с другими типами подобной подсветки.
Желание поработать с управляемыми огоньками с помощью arduino побудили меня соорудить такую систему. Как оказалось, это довольно простое мероприятие, на которое в сумме было потрачено всего несколько часов (собственно, само сооружение — 10 минут, остальное — софт). Детали процесса сборки и программирования я и изложу в этой статье. Софт, выводы и демо прилагаются.

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

Я тут решил забить на всю работу и заняться чем-то для души. Снова взялся за паяльник. Решил автоматизировать дома всё и вся. На старой-то квартире у меня был умный дом или что-то типа того — мог свет в комнате включать через Интернет и всё такое.

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

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

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

С выходом .NET Framework 4.0 в состав BCL была добавлена библиотека Task Parallel Library (TPL), реализующая параллелизм на основе задач. В основе библиотеки лежат типы Task и унаследованный от него тип Task. Эти типы являются обёртками для асинхронных операций; они позволяют абстрагироваться от таких технических деталей, как, например, потоки и синхронизировать асинхронные операции друг с другом.

В этой же версии .NET Framework появился мини-framework для кооперативной отмены асинхронных операций. Состоит он из всего трёх типов:

• CancellationTokenSource — создаёт маркёры отмены (свойство Token) и обрабатывает запросы на отмену операции (перегруженные методы Cancel/CancelAfter).
• CancellationToken — маркёр отмены; позволяет несколькими способами отслеживать запросы на отмену операции: опросом свойства IsCancellationRequested, регистрацией callback-функции (через перегруженный метод Register), ожиданием на объекте синхронизации (свойство WaitHandle).
• OperationCanceledException — исключение, выброс которого по соглашению означает, что запрос на отмену операции был обработан и операция должна считаться отменённой. Предпочтительный способ генерации исключения — вызов метода CancellationToken. ThrowIfCancellationRequested.

Механизм отмены через CancellationToken является стандартным для TPL — есть перегрузки методов, принимающих CancellationToken, исключения OperationCanceledException специальным образом обрабатываются и т.д. Однако, как и в любом другом API, есть свои тонкости, хитрости, best practices.

Это перевод нашумевшей статьи с TechCrunch от Джеймса Альтушера — инвестора, программиста, автора статей и немного предпринимателя. Его последние книги: Я был слеп, но теперь я вижу и 40 альтернатив колледжу. Читайте его в Twitter @jaltucher.

Люди читают TechCrunch потому, что они хотят что-то создать, они не желают следовать приказам всю жизнь и хотят финансовой свободы. Давайте начистоту. Эти три пункта кажутся притягательными. Да благословит Вас Бог. Надеюсь, что когда Вы их обретете, Вы сможете сохранить их. Большинству людей (например, МНЕ), нужно просто немного покататься на американских горках, потому что мы тупые. Но некоторые люди умные.

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

На Хабре довольно много упоминаний о BDD. К сожалению, статьи, которые я читал, так и не дали мне ответа на вопрос «а зачем мне все это нужно?» Ответ пришел с неожиданной стороны. Когда я всерьез занялся вопросом автоматизации приемочного тестирования, мне под руку попалась книга Gojko Adzic (не уверен в транскрипции, поэтому не стал переводить имя автора) Specification By Example.
Читая ее, я не уставал удивляться: каждая новая глава описывала шишки, которые я набивал на своем личном опыте, и предлагала решения аналогичные или лучшие, чем те, к которым я приходил сам методом проб и ошибок.

Эта статья – первая в цикле «BDD для прагматиков». В ней описаны ключевые элементы наиболее эффективного, на мой взгляд, процесса разработки коммерческого ПО в современных условиях. Два продолжения будут посвящены работе со SpecFlow и автоматизации приемочного тестирования.

Прим. перев.: это перевод статьи Six years of WPF; what's changed?, написанной 3 августа 2012 года. Сейчас WPF уже не шесть, а семь лет, однако ничего не изменилось.

До перехода в Octopus Deploy на полную ставку я провёл год за написанием на WPF системы оценки рисков для трейдеров в инвестиционном банке. До того я работал консультантом, по большей части фокусируясь на WPF. Последние шесть лет я жил и дышал технологией, и в этом посте я хочу поделиться некоторыми мыслями о прошлом и будущем WPF и XAML.

Шесть лет назад я написал статью про валидацию в WPF на Code Project. Ещё я написал свой error provider, который поддерживает IDataErrorInfo, потому что — вы не поверите! — WPF 3.0 не поддерживал IDataErrorInfo. Позже я работал над несколькими опенсорсными WPF проектами вроде Bindable LINQ (первоначального реактивного программирования для WPF, ещё до изобретения Rx) и Magellan (MVC для WPF а-ля ASP.NET). Я даже некоторое время состоял в клубе, посвящённому превозносению MVVM и киданию ссылок на Code Project, известном как WPF Disciples («Приверженцы WPF»).

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

Вот как в далёком 2006-м году выглядела разметка относительно простого окошка (код позаимствован из проекта, над которым я тогда работал):

	<Window x:Class="PaulStovell.TrialBalance.UserInterface.MainWindow"
	  xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
	  xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
	  xmlns:tb="clr-namespace:PaulStovell.TrialBalance.UserInterface"
	  xmlns:tbp="clr-namespace:PaulStovell.TrialBalance.UserInterface.Providers"
	  xmlns:system="clr-namespace:System;assembly=mscorlib"
	  Title="TrialBalance" 
	  WindowState="Maximized"
	  Width="1000"
	  Height="700"
	  Icon="{StaticResource Image_ApplicationIcon}"
	  Background="{StaticResource Brush_DefaultWindowBackground}"
	  x:Name="_this">

Только взгляните на все церемонии! x:Class! Пространства имён XML! Почему бы не объявить всё это в одном месте, почему бы стандартные пространства имён не включать неявно?

К счастью, сейчас 2013-й год, и WPF был проделан огромный путь. Вот так код будет выглядеть сегодня:

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

Для тех кто хочет преодолеть прокрастинацию быстро, просто прочитав эту статью