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

---

Хочу обсудить проблемы, связанные с предварительной оценкой времени и сроков проектов. В этой статье я расскажу как обстоят дела на проекте, который я веду немногим более 5 месяцев. Я приведу некоторые свои мысли, объясню какие эксперименты с оценками я делал и какие выводы получил по прошествию этого срока.

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

Прочитав статью «Усиливаем контроль типов: где в типичном C#-проекте присутствует непрошеный элемент слабой типизации?» был порядком удивлен, как ошибочностью данного подхода, так и тем, что никто не обратил на это внимание.

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

Проблема

Мы привыкли говорить о языках вроде C# как строго и статически типизированных. Это, конечно, правда, и во многих случаях тип, указываемый нами для некоторой языковой сущности хорошо выражает наше представление о ее типе. Но есть широко распространенные примеры, когда мы по привычке («и все так делают») миримся с не совсем верным выражением «желаемого типа» в «объявленном типе». Самый яркий — ссылочные типы, безальтернативно оснащенные значением «null».

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

Рассмотрим фрагмент кода:

public interface IUserRepo 
{
	User Get(int id);
	User Find(int id);
}

Этот интерфейс требует дополнительного комментария: «Get возвращает всегда не null, но кидает Exception в случае ненахождения объекта; а Find, не найдя, возвращает null». «Желаемые», подразумеваемые автором типы возврата у этих методов разные: «Обязательно User» и «Может быть, User». А «объявленный» тип — один и тот же. Если язык не заставляет нас явно выражать эту разницу, то это не означает, что мы не можем и не должны делать это по собственной инициативе.

До 28 октября я должен был принять решение, буду ли я работать в Amazon по окончанию стажировки. Оставалось совсем немного времени, но мой друг Дэниел убедил меня, что если я попробую попасть в Twitter, то как раз успею пройти все интервью. Я не смог устоять.

Сначала меня попросили решить пару вопросов с Codility, дав на все про все час времени. Вопросы попались средней интересности («является ли слово анаграммой палиндрома» и «посчитать количество седловых точек в двумерном массиве»). Я был не слишком уверен в получившихся решениях, но вскоре Джуди прислала мне письмо с приглашением на телефонное интервью в среду в 17:30.

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

Являясь разработчиком приложений для Windows Phone, я давно понял, что рынок мобильных приложений глобален и для успешного продвижения приложения, оно должно быть качественно локализовано для максимального количества доступных языков. Локализация приложений для Windows Phone подробно описана в документации по разработке приложений. Однако процесс локализации заголовков и заголовков плиток приложений отличается от локализации самого приложения и часто вызывает затруднения, так как требует подготовки отдельного файла ресурсов для каждого языка.

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

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

Инфраструктура .Net содержит встроенные средства генерирования кода (On-the-Fly Code Generation). Это позволяет .Net-программе в момент своего исполнения самостоятельно (без участия программиста) скомпилировать текст, написанный на каком-либо языке программирования и исполнить получившийся код. Логично было бы ожидать, что для осуществления этих действий в стандартной .Net-библиотеке предусмотрен простейший метод соответствующего класса. Но к сожалению это не так. Microsoft, проделав огромный путь по встраиванию в среду .Net средств генерирования кода, не сделала самый последний шаг навстречу простейшим потребностям программистов. Значит, придётся сделать этот шаг самостоятельно.

Самое простое средство предлагаемое Microsoft для решения описанной задачи — это класс CSharpCodeProvider, который входит в стандартную библиотеку .Net. Использование этого класса — не очень сложная задача, но тем не менее было бы полезно иметь инструмент, превращающий использование сгенерированного на лету кода в задачу тривиальную.

Техническое собеседование – практически неотъемлемый атрибут трудоустройства любого разработчика, а для старших разработчиков – проведение их (собеседований) ещё и чуть ли не повседневная обязанность. Но как за короткий срок (в идеале 20-30 минут) составить у себя более менее приемлемое представление о реальном опыте соискателя?

▌Вместо предисловия

---

Для начала хотелось бы сказать пару слов о новомодном тренде в области веб-дизайна и дизайна интерфейсов — плоском дизайне (Flat UI).

Flat, очень хорошо играет на контрасте. Metro особенно сильно выделяется в сфере UI.
Можно провести небольшую параллель: посмотрите на это надгробие. Оно прекрасно, не так ли?


Крупнее

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

Однако если на кладбище все надгробия будут такие же, как это, тогда это будет ужасающая серость и беда. Прелесть минимализма именно в контрасте.

---

Минимализм не должен быть в мейнстриме, ни в коем случае.

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

В 2010 году, когда на рынке смартфонов властвовали Apple, Samsung и HTC с нагромождёнными интерфейсами iOS, TouchWiz и HTC Sense, Windows Phone поражал воображение по внешности, дизайну.

Статья представляет собой описание процесса разработки и развертывания приложения Windows 8.1. Мнение автора основано на опыте собственной разработки, а также работы с разработчиками мобильных приложений. Весь процесс работы над приложением разбит на 4 этапа.

Хочу поделиться опытом разработки приложения на Windows Phone 7.5, миграции его на Windows Phone 8, и что я думаю о перспективах в целом. Информация будет интересна в первую очередь начинающим разработчикам, так как сам я только недавно перешел с web разработки на мобильную и опыта у меня еще не очень много.

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

Введение

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

В этой статье я хочу рассказать о проблемах использования интерфейса IEnumerable. Мы рассмотрим, какие проблемы может принести использование этого интерфейса, когда его на самом деле нужно использовать, и чем его заменить.

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

Захотелось поделиться с сообществом собственными наблюдениями на тему карьерного роста технаря.

Информация основана на опыте в больших западных конторах, которые делают реальные продукты. Всё изложенное ниже не претендует на абсолютную истину.

Начнем сначала: вы свежий выпускник тех. вуза. Вам 22-23 года, вся жизнь впереди и она прекрасна. В этом прекрасном будущем есть, скорее всего, есть жена-модель, дом – полная чаша, несколько машин, и первый миллион к 30 годам.

Карьера представляется немного смутно, но в целом, понятно: начинаем активно и качественно работать, нас, несомненно, замечают и продвигают. Множество фильмов и книг именно так нам и обещают: много и хорошо работай –> и всё будет хорошо.

Вы устраиваетесь на работу, ваше звание — инженер или разработчик. У вас появляются коллеги. Почти все они старше вас. И тут вы, возможно, заметите, что на таком же уровне, как и вы, есть очень пожилые люди. Прямо 30-40 летние мужики, может даже 50ти летние “стариканы”. И многие из них тоже закончили похожие вузы, и многие совсем не дураки, но как-то не сложилось с карьерным ростом…

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

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

Не редко оказывается так, что даже если инструмент предоставляет очень хорошие возможности для модульных тестов – то эти возможности оказываются практически неприменимы для UI-тестов.

Так случилось и в моей практике, когда я решил использовать data-driven тесты в фреймворке Ms-Test. В этой статье я более детально опишу проблему и свое решение, за которое до сих пор не пойму – мне нужно гордиться или стыдиться.

Обработка исключений появилась в mainstream языках программирования вот уже более трех десятилетий назад, но сегодня все еще можно встретить разработчиков, которые боятся их использовать. Некоторые считают, что генерация исключений в конструкторе повредит их хрупкой карме и их настигнет кара в виде поддержки кода двадцатилетней давности, написанного стадом безумных индусов. Некоторые все еще застряли в эпохе языка С и даже в языке C# интенсивно используют коды возврата в виде магических чисел или даже строк, считая, что исключения придумали трусы, а настоящие самураи могут обойтись и без них. (Хотя мы-то с вами знаем, что настоящие самураи следуют “Принципу самурая” и никаких кодов возврата не используют).

Дополнительную сложность добавляют конкретные платформы и языки программирования. Сегодня на собеседовании C# разработчика, когда речь заходит об обработке исключений, обязательно прозвучит вопрос: “А в чем отличие “проброса” исключения с помощью конструкций throw; и throw ex;?”. И хотя, это страшный баян и большинство разработчиков давно знают правильный ответ на этот вопрос, в реальном коде встретить “некошерный” вариант очень даже просто.

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

Вопрос о выборе цикла for/foreach стар, как мир. Все мы слышали, что foreach работает медленнее for-а. Но не все знаем почему… А вообще так ли оно?

Когда я начинал изучать .NET, один человек сказал мне, что foreach работает в 2 раза медленнее for-а, без каких-либо на то обоснований, и я принял это как должное. Теперь, когда чьих-то слов мне мало, я решил написать эту статью.

В этой статье я исследую производительность циклов, а так же уточню некоторые нюансы.

Итак, поехали!

Не секрет, что создание дизайна приложения под Windows Phone или Windows 8 занимает гораздо меньше времени, чем под iOS или Android. И дело тут не только в специфике дизайна. Главным фактором экономии времени является налаженный алгоритм взаимодействия дизайнера с разработчиком. Инструмент, который соединяет дизайн и код — Blend, входящий в пакете Visual Studio.



Как это работает?
Как правило дизайнеры создают макеты либо в Adobe Photoshop, либо в Adobe Illustrator. При создании макетов в этих программах можно следовать нескольким правилам, которые позволят разработчику эффективно обработать макет в Blend.

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

Сразу оговорюсь, что примеры приводятся применительно к языку C# и платформе .NET. Соответственно, в других языках/платформах подходы и реализации могут отличаться.

Итак…