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

Какие проблемы приходится решать:

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

Большинство современных устройств запоминают название Wi-Fi сети, к которой они успешно подключались хотя-бы один раз, и сразу же соединяются с ней, если «увидят» её в беспроводном эфире. Эту фичу беспроводных технологий всё чаще и чаще используют злоумышленники — создают т.н. rogue AP (поддельную точку доступа). Такие атаки с каждым годом становятся всё масштабнее, учитывая постоянно увеличивающийся рынок BYOD-устройств и количество критичной информации, содержащейся на них.

Часто бывает, что мы соединяем 2 коллекции или группируем коллекцию при помощи LINQ to Objects. При этом происходит сравнение ключей, выбранных для группировки или связывания.
К счастью, стоимость этих операций равна O(n). Но в случае больших коллекций нам важна эффективность самого сравнения. Если в качестве ключей выбраны строки, то какая из реализаций сравнения будет использована по умолчанию, подходит ли эта реализация для ваших строк и можно ли, указав IEqualityComparer<string> явно, сделать эту операцию быстрее?

clients.Join(orders, 
                   c => c.Name, 
                   o => o.ClientName, 
                   (c, o) => CreateOrederDto(c, o));

Как же выбирается реализация компаратора, если пользователь не указал её явно?

Большинство светодиодных ламп, которые я тестирую и о которых пишу, можно купить только в специализированных интернет-магазинах, однако обычные покупатели как правило покупают лампы в гипермаркетах. Я съездил в магазины Ашан и Леруа Мерлен, купил там 48 моделей светодиодных ламп и протестировал их. Лампы вернул обратно в магазины, так как там есть возможность возврата. О лампах из Леруа Мерлен расскажу в следующий раз, сегодня — 22 лампы из Ашана.

Мы продолжаем перевод серии статей Windows 10 по 10. Новая статья посвящена теме дизайна приложений. Перевод подготовлен студией Sly Lamb, специализирующейся на разработке приложений для платформы Microsoft.

Несколько вводных слов от руководителя студии Алексея Пережогина:

Добрый день! Прежде мы писали о нашем опыте адаптации дизайна iOS приложений под WP 8.х. Накануне выхода Windows 10 Mobile мы хотим обратить ваше внимание на изменения в гайдлайнах платформы Windows 10 по сравнению с прежним Modern UI (руководства, кстати, продолжают обновляться, и из последних новостей — появились шаблоны для дизайнеров в PSD (прежде были только в Illustrator и PowerPoint)).

Тема актуальна для Windows-разработчиков, которые планируют разрабатывать или портировать свои приложения под UWP. Поэтому мы решили перевести одну из очень полезных статей по проектированию приложений под Windows 10.

Вступление

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

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

Решение простое — оставить ключи родственникам/друзьям/соседям, чтобы они могли приехать и включить котел, случись какая-нибудь неприятность. Хорошо, если есть сосед, который будет каждый день заходить и проверять, всё ли в порядке. А если нет? Или он тоже решит уехать куда-нибудь на выходные?

Итак, я решил наладить выкладывание показаний счётчика куда-нибудь в Интернет, чтоб я мог находясь где-нибудь в дальней поездке периодически проверять, тратится ли газ, а если вдруг перестанет тратиться, то срочно звонить родственникам/друзьям/соседям (или кому там я оставил ключи), чтобы приехали и нажали кнопку.

Конечно, после простого выкладывания показаний в Интернет я решил не останавливаться на достигнутом и замутил ещё распознавание показаний и графическое представление, об этом читайте в части 2 данного топика.

Около года назад мы писали на хабре о работе с Lumia SensorCore SDK (обзор, создание приложения) — специальном API для работы с сенсорами на Lumia-устройствах. В Windows 10 на базе этих и других наработок в универсальной Windows-платформе (UWP) мы расширили API для работы с устройствами, добавив новые возможности для взаимодействия с контекстом пользователя. Ниже предлагаем вашему внимаю доклад с конференции Build на эту тему и перевод обзорной статьи, описывающей новые возможности.

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

Дисклеймер

Недавно по работе возникла задача генерации тайлов на основе OSM данных. Поискал, прочитал несколько статей, но везде фигурировали *nix-системы, а у меня был в наличии сервер под управлением Windows. В конце-концов, более-менее внятный туториал нашёлся, но он слегка устарел и не везде подробен, посему пришлось повозиться. После удачного завершения подумал, что мой опыт будет полезен.

Кого заинтересовал, прошу под кат.

Разработка веб API это нечто большее чем просто URL, HTTP статус-коды, заголовки и содержимое запроса. Процесс проектирования – то, как будет выглядеть и восприниматься ваш API – очень важен и является хорошей инвестицией в успех вашего дела. Эта статья кратко описывает методологию для проектирования API с опорой на преимущества веба и протокола HTTP, в частности. Но не стоит думать, что это применимо только для HTTP. Если по какой-то причине вам необходимо реализовать работу ваших сервисов используя WebSockets, XMPP, MQTT и так далее – применяя большую часть всех рекомендаций вы получите практически тот же API, который будет хорошо работать. К тому же полученный API позволит легче разработать и поддерживать работу поверх нескольких протоколов.

Хороший дизайн затрагивает URL, статус-коды, заголовки и содержимое запроса

Обычно руководства по проектированию Web API фокусируются на общих концепциях: как проектировать URL, как правильно использовать HTTP статус-коды, методы, что передавать в заголовках и как спроектировать дизайн содержимого, которое представлено сериализованными данными или графом объектов. Это всё очень важные детали реализации, но не настолько в смысле общего проектирования API. Проектирование API – это то, как сама суть сервиса будет описана и представлена, то что вносит значительный вклад в успех и удобность использования Web API.

Хороший процесс проектирования или методология предоставляют набор согласованных и воспроизводимых шагов для создания компонентов сервисов, которые будут доступны в виде Web API. Это значит, что такая прозрачная методология может быть использована разработчиками, дизайнерами и архитекторами для координации своих действий по реализации ПО. Использованная методология так же может уточнятся со временем по мере того, как улучшается и автоматизируется процесс без ущерба для деталей методологии. На самом деле, детали реализации могут меняться (например, платформа, ОС, фреймворки и стиль UI) независимо от процесса проектировки, когда эти две активности полностью разделены и задокументированы.

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

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

На перевод этой статьи меня подтолкнуло обсуждение записей «Почему WPF живее всех живых?» и «Семь лет WPF: что изменилось?» Исходная статья написана в 2011 году, когда Silverlight еще был жив, но информация по WPF не потеряла актуальности.

Сначала я не хотел публиковать эту статью. Мне казалось, что это невежливо — о мертвых надо говорить либо хорошо, либо ничего. Но несколько бесед с людьми, чье мнение я очень ценю, заставили меня передумать. Вложившие много усилий в платформу Microsoft разработчики должны знать о внутренних особенностях ее работы, чтобы, зайдя в тупик, они могли понимать причины произошедшего и более точно формулировать пожелания к разработчикам платформы. Я считаю WPF и Silverlight хорошими технологиями, но… Если вы следили за моим Twitter последние несколько месяцев, то некоторые высказывания могли показаться вам безосновательными нападками на производительность WPF и Silverlight. Почему я это писал? Ведь, в конце концов, я вложил тысячи и тысячи часов моего собственного времени в течение многих лет, пропагандируя платформу, разрабатывая библиотеки, помогая участникам сообщества и так далее. Я однозначно лично заинтересован. Я хочу, чтобы платформа стала лучше.

Здравствуйте, коллеги!

Хочу снова поделиться интересным случаем решения проблемы, и сэкономить вам время и нервы на её решении. Принесли мне тут на днях для реанимации ноутбук вот с такими же симптомами:



Сразу сделаю отступление — указанный в описании видео метод реанимации в данном случае не помог совершенно никак. Почему — описано ниже.

Предыстория проста: работали себе пользователи на ноуте спокойно, ничего страшного не делали. Система предложила обновиться до 8.1 — согласились. Система начала обновляться, ушла на перезагрузку и на этом всё. Неустранимый BSOD с кодом ошибки «ACPI_BIOS_ERROR». До меня ноутбук уже таскали к местному знатоку, он попробовал всё, что смог навскидку проверить, после чего развел руками и отправил ко мне, потому что в придачу к стабильному BSODу ноутбук категорически отказывался реагировать на горячие клавиши входа в меню UEFI и/или выбора загрузочного устройства. Совсем, абсолютно. При этом и с внешних устройств грузиться даже не пытался, упорно запускаясь с внутреннего винта и разумеется снова уходя в бесконечное кольцо попыток загрузки.

От переводчика: англоязычные it-блоггеры обычно начинают такие статьи со слов I'm so excited. Про Wix# я узнал совершенно случайно и спешу поделиться этим открытием с хабрасообществом, т.к. каждый, кто имел дело с «голым» WiX, знает, насколько неприятным может быть этот процесс. И вот теперь можно сделать msi-дистрибутив, написав всего лишь несколько строчек на C#! По-моему, это круто! А относительно недавно (4 дек 2014) автор Wix# Олег Шило дал интервью изданию InfoQ. Перевод этого интервью я и представляю вашему вниманию. И прошу не судить строго за кальку некоторых слов — тот же «деплоймент» мне как-то ближе, чем «развертывание».

Есть такие хорошие роутеры Mikrotik. И с недавнего времени есть у них функционал «IP-Cloud». Помимо прочего он позволят получить субдомен, который будет привязан к пользовательскому роутеру, не имеющему постоянного IP-адреса. Или имеющего, для нас это не важно — важно то, что получаемое имя не произвольное, а вида серийный номер+.sn.mynetname.net

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

Перейти ко второй части

Для начала, нам потребуется:

1. 2015 студия
2. SDK для разработки расширений
3. Шаблоны проектов
4. Визуализатор синтаксиса
5. Крепкие нервы

Полезные ссылки: исходники roslyn, исходники и документация roslyn, roadmap с фичами С# 6.

Наверное вас смутило, что вам потребуются крепкие нервы и вы хотите пояснения. Все дело в том, что весь API компилятора — это низкоуровненное кодогенерерированное API. Вы будете смеяться, но простейший способ создать код — это распарсить строку. Иначе вы либо погрязнете в куче нечитаемого кода, либо будете писать тысячи extension-методов, чтобы ваш код выглядел синтаксически не как полная кака. И еще две тысячи extension-методов, чтобы оставаться на приемлемом уровне абстракций. Ладно, я вас убедил, что писать Roslyn расширения к студии это плохая идея? И очень хорошо, что убедил, а то кто-то из читающих эту статью может написать второй ReSharper по прожорливости ресурсов. Не убедил? Платформа все еще сырая, бывают баги и не доработки.

Введение

Паттерн MVVM хорошо известен, о нем написано много статей, наверное каждый NET-разработчик сталкивался или слышал об этом паттерне. Цель этой статьи – рассказать о собственной реализации этого паттерна.
MugenMvvmToolkit — является кроссплатформенной реализацией паттерна MVVM и на текущий момент поддерживает следующие платформы:

• WinForms
• WPF
• Silverlight 5
• Silverlight for WP7.1, WP8, WP8.1
• Xamarin.Android
• Xamarin.iOS
• Xamarin.Forms
• WinRT XAML framework for Windows 8 Store apps

Продолжаем тему интересного на .Net, от чего мир Java будет посмеиваться (хотя у них это также возможно сделать), а приверженцы С++ говорить: «чего они только не сделают чтобы не учить C++».

В данной заметке мы напишем по сути – простенькое ядрышко профилировщика памяти для платформы .Net, который будет снимать дамп с SOH кучи (а в перспективе и с LOH).

Для написания статьи нам понадобится код из статьи Получение указателя на объект .Net и Ручное клонирование потока (измерение размера объектов).

Наши цели на сегодня:

• Научиться итерировать кучу .Net
• Научиться находить начало кучи .Net
• Попробовать сытерировать все объекты чужого домена.

Ссылка на проект в GitHub: DotNetEx

Добрый день, уважаемые разработчики (просто не знал, с чего начать пост). Предлагаю перед тем как начнется трудовая неделя немного подразмять мозги (совсем немного) и построить свой Small Objects Heap для .Net. Вернее даже не Small Objects Heap, а Custom Objects Heap.

Как все мы знаем, в .Net существует две группы куч: для больших и малых объектов. Как выяснить, во сколько нам обойдется объект можно при помощи кода из этой статьи (он нам пригодится): Ручное клонирование потока, а получить указатель на объект и по указателю получить сам объект можно научиться, прочтя эту статью: Получение указателя на объект .Net. Также нам понадобится статья корейского (южно-) программиста по перенаправлению указателя на скомпилированную часть метода на другой метод: 실행 시에 메서드 가로채기 — CLR Injection: Runtime Method Replacer 개선

Так что давайте поэкспериментируем и напишем библиотеку, которая позволит:

• Аллоцировать участок памяти
• Разметить его как набор объектов определенного .Net типа
• Выделять объекты с этой памяти
• Возвращать их обратно

Ссылка на проект на GitHub: DotNetEx

Добрый вечер!

Предлагаю вашему вниманию проект, над которым я работаю последние полтора года. Это программный продукт (если быть точным, .NET Windows Service), с помощью которого вы можете организовать на своем компьютере управляющий центр «умного дома». Хотя это всего лишь мое хобби (моя основная работа — веб-разработчик на .NET), многие люди, которым я показывал мой проект, высоко его оценили. Я пишу эту статью, чтобы попробовать заинтересовать вас.

Введение

Большую часть времени, разработка под Windows Runtime приносит ни с чем не сравнимое удовольствие. Дел-то всего ничего: налепил контролов, добавил щепотку MVVM, а потом сидишь, и любуешься своим кодом. Так происходит в 99% случаев. В оставшейся сотой доле, начинаются настоящие пляски с бубном.

На самом деле, я утрирую, к языческим ритуалам прибегаю только в совсем безвыходных ситуациях. А вот WP разработчикам есть за что поругать MS, начав хотя бы с бедных Silverlight разработчиков, на долю которых пришлись все несчастья. Ну да ладно, это всё уже в оффтопик ушло.

Кэп, ты где?

Итак, мысленно перенесемся в гипотетическую ситуацию. У нас есть приложение, пусть это будет клиент для kinopoisk.ru под Windows 8.1. И постер какого-либо голливудского AAA проекта с многомиллионным бюджетом и супергероями из любимых нами комиксов. Задача – отобразить пользователю постер в идеальном качестве. Под словом «идеальное» я имею в виду соответствие 1 пиксель изображения == 1 пиксель физический.

Казалось бы, пустяк, создаем Image и присваиваем его свойству Source нужный BitmapImage с картинкой. Вот только размер картинки настораживает – 9300 x 12300. Взяв в руки калькулятор, начинаю считать: 9300 * 12300 пикс * 4 Б/пикс = 436 МБ. Довольно внушительная цифра, но в 21 веке такими вещами уже не удивишь. Средний настольник 2010 года без проблем переваривает такие объемы данных, так что жмём F5 и наслаждаемся своим творением. Всё отлично работает, по меньшей мере на моём компьютере, и ладно. На этом статью можно было бы и закончить…