Думаю, многим разработчикам на управляемом коде всегда интересовало: сколько же байт занимает экземпляр объекта? А каков лимит размера одного объекта в CLR? Существуют ли различия в выделении памяти между 32-битными и 64-битными системами? Если данные вопросы для Вас не пустой звук, тогда прошу под кат.

Доброе время суток Хаброжители.

Буквально на днях, ко мне и моим коллегам обратились «опытные пользователи» Excel. По специфике работы «опытные пользователи» часто используют офисный пакет для оформления документации. Как ни странно, таблицы Excel так же часто встречаются. Как и на Хабре, не допустимо выпускать документы с орфографическими ошибками. Стандартной возможности excel, по подсветке орфографических ошибок нет. В связи с этим я разработал Add-ins для Excel который бы реализовывал такой функционал.

Лучше один раз увидеть, чем 100 раз услышать.
Уверен, не я один часто делаю скриншоты.
Проиллюстрировать баг, отправить смешную картинку знакомому,
вставить в комментарий на каком-нибудь ресурсе, etc.
А началось всё с разочарования в некогда любимом Gyazo,
а именно сам скриншот уже трудно найти под кучей рекламных блоков.
Когда я пересмотрел аналоги, они мне показались чересчур громоздкими.
Пройти через несколько окон, чтобы просто сделать скриншот? Нет, спасибо.

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

Суть

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

Примерный алгоритм работы видится мне таким:

• При запуске программа делает скриншот.
• Устанавливает его фоном для окна, развёрнутого на весь экран.
• Мышкой выделяем нужную область на экране.
• Готово, картинка улетает на сервер.

Увиденный недавно топик, про валидацию css в Visual Studio подстегнул к написанию похожей вещи про валидацию Яваскрипта.
Когда яваскрипт в веб-проекте занимает достаточно большую долю кода, и клиентские скрипты вырастают за рамки «инлайн-скриптов» с одной-двумя строчками вызова jquery-плагинов, вопрос проверки их валидности встает достаточно явно (даже для .net-разработчиков, достаточно далеких от js в принципе :)).

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

Если кратко, то проверять яваскрипт можно с помощью jslint, jshint и google closure. Нетрудно догадаться, что у последнего возможности наиболее широкие, и для его интеграции в Visual Studio существует как минимум пара готовых решений.
В этой статье я расскажу об еще одной утилите интеграции google closure в Visual Studio, а именно — jsvalidator, небольшой open-source проект, который и был мной написан после вышеупомянутого анализа.
Ключевое отличие моей реализации — в простоте интеграции и возможности конфигурирования отображения определенных типов предупреждений.

Есть некоторые категории знаний, которые профессиональный разработчик познает в процессе своей работы, не прилагая к этому особенных дополнительных усилий. Вот, например, мало кто из нас читал замечательную книгу по регулярным выражениям Джеффри Фирддла, чтобы познакомиться с одноименной темой. Безусловно, есть масса людей, для которых «регвыры» стали смыслом жизни и без подобных фундаментальных знаний никак не обойтись. Но в большинстве случаев пары мелких статей и справки в соответствующем разделе документации будет достаточно для более или менее комфортной работы с регулярными выражениями (если такое понятие, как «комфортная работа» с регулярными выражениями вообще существуетJ).

Аналогичным образом мы обычно относимся и к изучению юнит тестирования. Ведь юнит-тесты – это же не rocket science; для их изучения не требуется многолетняя подготовка и множество бессонных ночей проведенных за изучением толстенных «талмудов» от гуру юнит-тестирования. Концепцию автоматизированного тестирования кода можно объяснить за 10 минут, а познакомившись с одним из тестовых фреймворков семейства xUnit (еще 15 минут), вы сможете работать с любым другим фреймворком практически сразу же. Затем нужно будет потратить еще 20 минут на изучение какого-нибудь изоляционного фреймворка, типа Rhino Mocks, и, вуаля, у нас есть еще один профессионал в области юнит-тестов.