StyleCop — статический анализатор C# кода на предмет соответствия стилю — был официально представлен публике в начале 2008 года. По IT-меркам это довольно давно, однако этот полезный инструмент почему-то до сих пор не получил широкую популярность (по крайней мере ту, которую заслуживает).

Ниже я постараюсь проанализировать причины, а также расскажу о новом плагине к StyleCop.

Правила языка Java

Мы следуем стандартным соглашениям по оформлению кода на Java. Мы добавили к ним некоторые правила:

1. Исключения: никогда не перехватывайте и не игнорируйте их без объяснения.
2. Исключения: не используйте обобщенные исключения, кроме кода в библиотеках, в корне стека.
3. Финализаторы: не используйте их.
4. Импорты: полностью уточняйте импорты.

Большинство людей, имеющих отношение IT, хотя бы раз собирали компьютер собственными руками или составляли точный список его комплектующих. Это и интереснее, и эффективнее, и заметно дешевле, чем покупать системник c шаблонным железом в магазине.

Однако те, кто не занимается сборкой компьютеров регулярно, испытывают потребность перечитывать новости IT-рынка за последние несколько месяцев, для того что бы собрать наилучшую конфигурацию, сбалансированную по трем основным параметрам:
1. Производительность (не все мегагерцы одинаково полезны)
2. Совместимость (ATI и NVidia в SLI-режиме не дружат)
3. Экономичность (не у каждого из нас есть своя нефтяная вышка)

Идея стартапа заключается в создании сайта, на котором бы ежемесячно публиковалась наилучшая (по советам опытных хардварщиков) конфигурация компьютера на текущий момент, в 3-х ценовых категориях: за ~15, за ~30 и за ~45 т.р. (грубо: за 500, 1000, и 1500 долларов. Я выбрал эти диапазоны как наиболее популярные у людей, самостоятельно собирающих себе системы). Далее уже в зависимости от специфичных потребностей придирчивые пользователи могут сами заменить что-то в универсальной конфигурации на своё (например, поставить второй винчестер или топовую звуковуху).

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

Данная статья является продолжением статьи Рисуем кнопку в SVG, в которой рассматривались проблемы создания SVG-изображений, предназначенных для использования в качестве кнопок на веб-страницах. Здесь я перейду непосредственно к внедрению полученных картинок в HTML-код и расскажу, с какими проблемами столкнётся при этом разработчик, как эти проблемы можно решать и что делать с проблемами, которые решить не удаётся.

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

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

В последнее время развелось очень много различных AJAX-приложений. По сути автоматизация тестирования такого приложения не отличается от автоматизации тестирования обычного WEB-приложения, но есть несколько тонкостей. Одна из тонкостей — это как раз ожидание завершения всех AJAX-запросов. Например, если отметка некого checkbox'а на странице вызывает обновление какого-нибудь select'a по AJAX-запросу, то тест, который сразу после отметки выбирает конкретный option, свалится, т.к. этого option'a там не будет. А всё потому, что сам тест выполняется намного быстрее чем AJAX-запрос на обновление списка.

В данном случае у автоматизатора есть несколько выходов.

Введение

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

Microsoft предоставляет встроенное в Visual Studio средство, которое позволяет оценить код вашего проекта.



Получить оценку вашего кода можно нажав правой кнопкой на проекте и выбрав пункт “Calculate Code Metrics” (Эта функциональность доступна в Visual Studio 2008 Team System и Visual Studio 2010 начиная с Premium версии).

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

1. невозможно в наших условиях соревноваться с интелом или хотя бы TI в выпуске процессоров и прочих разных микросхем — цена вхождения очень высока, рынки сбыта поделены, и, по большому счету, нет необходимых знаний и опыта;
2. бессмысленно соревноваться с китайцами в производстве всевозможной массовой электроники — стоимость труда у них ниже, производственные мощности находятся у них же, рынки сбыта в руках крупных компаний;
3. можно окучивать отечественные рынки различной несложной электроникой — от сигнализаций до елочных гирлянд. Кто-то живет этим, но норма прибыли невысока, а мороки много;
4. можно участвовать в государственной программе поддержки бедных (РосПил). Отличная тема, но меня пригласить забыли.

Одна из немногих успешно работающих моделей — контрактные разработки для западных заказчиков. Идея проста: у нас заказывают наукоемкие исследования/разработки, результаты собирают вместе где-нибудь в Калифорнии (обычно по цепочке через нескольких посредников) и продают в конечном итоге какой-нибудь крупной корпорации-производителю электроники. Тому же Интелу, к примеру. Года через 2-3 все это возвращается к нам в составе сложных агрегатов (телефонов, мониторов и т.д.) в красивой коробке с клеймом “Made in USA” (что редко) либо “Made in China” (значительно чаще) по червонцу за пучок. Ситуация с одной стороны грустная — мы не владеем технологической цепочкой, а способны решать лишь отдельные задачи. Но есть и основания для оптимизма — таким образом российские разработчики входят в общемировую систему и получают ценный опыт. Компания, в которой я работаю, специализируется в основном на исследовательских разработках в области беспроводных коммуникаций. Исходя из этого я и буду вести дальнейший рассказ.

Как же выглядит процесс разработки?

Автовставка точек с запятой (";") — одна из наиболее спорных особенностей яваскрипта, вокруг которой скопилось много непонимания.

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

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

С чего начать?

Пишем своё первое приложение на Android
Пишем первое приложение для Android
Создаем файловый менеджер
Основы программирования под Android на примере игры Судоку
Создание приложения в стиле Android
Спокойной ночи!

Как-то раз в одной неглупой статье один неглупый хабраюзер рассказал одну неглупую идею. Суть её была в том, что в его компании настроена система, контролирующая написанный программистами код в момент попытки добавления его в репозиторий и отклоняющая код, не проходящий по некоторым критериям. Мне идея понравилась. Я (и еще 3 человека) попросили автора развить мысль и написать статью об этом, но она так и не появилась. И я решил разобраться сам.

Раз за разом я читаю, что удобные библиотеки для создания классов на Javascript, видите ли, не соответствуют идеологии языка и тем, кто их использует просто необходимо учить язык. Такое говорят невежды, которые и сами толком не разобрались ни в самом языке ни в библиотеках, которые они критикуют. И так часто говорят, что я решил написать этот топик и просто давать ссылку

var Foo = new Class({
	Extends: Bar,
	initialize: function(firstname, lastname) {
		this.parent(firstname);
		this.lastname = lastname;
	},
	sayHello: function(){
		alert(this.lastname || this.firstname);
	}
});

CANVAS шаг за шагом:

1. Основы
2. Изображения
3. Понг
4. Пятнашки

Если верить англо-русскому словарю, то можно узнать что canvas переводится как холст, а если верить википедии, то можно узнать что тег canvas, это элемент HTML 5, который предназначен для создания растрового изображения при помощи JavaScript. Тому как создать это растровое изображение и будет посвящен мой небольшой текст. Прежде чем начинать пробовать свои силы в этом не легком деле рекомендуется уже иметь базовые знания о том что такое HTML и с чем едят JavaScript.

Этот пост поможет начинающим сэкономить несколько часов(дней) для настройки среды Visual Studio для разработки под Arduino на языке С/C++.

Проблема

ExtJS — прекрасная библиотека с огромным числом возможностей. На http://dev.sencha.com/deploy/dev/examples/ можно найти множество демонстрационных исходных кодов, доступных для использования в реальных проектах, однако, конечно, ответа на все вопросы это не даст.
Мне было необходимо сделать обоюдное перетаскивание между TreePanel и GridPanel. Найдя на форуме ExtJS и в интернете вообще лишь отрывочные сведения, я решил написать это самостоятельно. Как это у меня получилось — под катом.

На Хабре присутствует много постов на темы «как начать свой бизнес», «где снять офис», «сколько я потратил на оформление» и т.д. Очень печально, что многие из этих статей заканчиваются словами надежды, что через полгода-год я опишу, что получилось, а что нет. Спустя полгода-год не так много пользователей в итоге могут описать, что получилось, ведь не многим удалось добиться успеха, а свои ошибки мы не любим освещать.

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

Все началось с ...

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

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

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

Итого, я решил сделать собственный «велосипед».

Введение

Статья посвящена работе с MVVM и WPF. В ней описывается процесс разработки twitter client. Процесс разработки разбит на шаги. В конце каждого шага читатель параллельно пишущий приложение должен иметь работающее приложение. Каждый последующий шаг добавляет какую-то функциональность к написанному на предыдущем шаге. Используется thirdparty библиотека TweetSharp. Ссылку на исходный код, а так же оригинал статьи, написанный мной на английском, можно найти тут.
Статья рассчитана на новичков в WPF разработке. Но предполагается, что читатель имеет некоторый начальный опыт работы с WPF, в частности освоил data binding.
Я не буду писать зачем нужно использовать MVVM – считаю, что об этом хорошо написано в статье “Приложения WPF с шаблоном проектирования модель-представление-модель представления” от Джоша Смита. Если вы не хотите читать эту статью – просто поверьте мне – неверное спроектированное GUI в случае с WPF превращается в большую головную боль.

Аспектно-ориентированное программирование

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

PostSharp

Фреймворк PostSharp — это реализация аспектно-ориентированного подхода для .NET. PostSharp в отличие от многих своих аналогов работает как пост-компилятор, то есть он вносит изменения в MSIL (Microsoft Intermediate Language).
PostSharp позволяет легко создавать атрибуты, которые меняют поведение методов, полей и типов. Для этого нужно унаследовать класс атрибута от одного из предоставляемых библиотекой базовых классов, реализовать его виртуальные методы и применить этот атрибут.