Пост подготовлен с целью помочь программистам при подготовке к собеседованиям по программированию. Здесь рассматриваются все основные темы, которые, как минимум, желательно знать перед собеседованием. Использован собственный опыт, опыт и рассказы коллег, специализированная литература.
Некоторые рассмотренные здесь темы могут вообще не пригодиться некоторым программистам, а могут и быть обязательными, решать вам. Мой совет – старайтесь как можно больше изучать темы/разделы/аспекты указанные здесь.
И так, в качестве обязательных знаний:

• Структуры данных
• Алгоритмы и «концепции»
• Язык программирования

В последние годы тема юнит-тестов, регрессивного тестирования, continuous integration, TDD, BDD, etc становится все популярней и все больше разработчиков начинают активно применять данные техники в своих проектах. При этом отдельным вопросом встает проблема автоматического тестирования пользовательского интерфейса в десктопных приложениях. В этой статье я постараюсь рассмотреть уже существующие решения, а так же привести вариант своего велосипеда написания тестов для UI на .net.

Введение

Воскресное утро, время для еще одного эпизода в серии Безумные Воскресения. Еще раз в одной категории с риском разрыва мозгов, но ведь это как раз то, что нам нравится, не так ли? На этот раз мы рассмотрим бестиповое лямбда-исчисление в C#. Но погодите, разве C# не типизированный язык? Действительно. Но значит ли это, что все, что вы делаете на C# должно быть статически типизировано? Не обязательно: типизация присутствует в языке как инструмент, который вы можете либо не трогать, либо применить. В этом топике мы рассмотрим как новое ключевое слово dynamic из C# 4.0 под несколько странным углом…

В далекие времена, для IT-индустрии это 70-е годы прошлого века, ученые-математики (так раньше назывались программисты) сражались как Дон-Кихоты в неравном бою с компьютерами, которые тогда были размером с маленькие ветряные мельницы. Задачи ставились серьезные: поиск вражеских подлодок в океане по снимкам с орбиты, расчет баллистики ракет дальнего действия, и прочее. Для их решения компьютер должен оперировать действительными числами, которых, как известно, континуум, тогда как память конечна. Поэтому приходится отображать этот континуум на конечное множество нулей и единиц. В поисках компромисса между скоростью, размером и точностью представления ученые предложили числа с плавающей запятой (или плавающей точкой, если по-буржуйски).

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

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

Часть 1 и Часть 2 в этом цикле статей показали, как создать приложение, используя mochiweb, и как передавать сообщения подключенным пользователям. Мы уменьшили постребление памяти до 8 Кб для каждого подключения. Мы повторили c10k тест. Мы сделали графики. Это была забава, но теперь пора повторить все для 1 миллиона соединений.

Это статья покрывает следующее:
• Использование базы данных Mnesia;
• Генерация правдоподобного набора данных вида «friends» для миллиона пользователей;
• Настройка Mnesia и ввод наших данных;
• Открытие миллиона соединений с одной машины;
• Сравнительный тест с 1 миллионом пользователей;
• Libevent + Си для обработки соединений;
• Финальные выводы.

Один очень близкий мне человек, поклонник Хабра, захотел внести вклад в развитие блога Cisco. Являясь яростным поклонником того, что создает эта корпорация, он захотел поделиться опытом. =) Надеемся росчерк пера удался.

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

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

Мне не удалось обнаружить такую статью. Это побудило меня написать эту статейку для тех, кто также как и я столкнется с вопросом, что это за зверь IPTV и как с ним бороться.

Поучительная история о техниках оптимизации наглядно.

Техзадание

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

Executing original code… done
Executing optimized code… done
Checking results… PASSED
Number of runs: 3
Original code average time: 11.954537 sec.
Optimized code average time: 1.052994 sec.
Speedup: 11.35

Разрешено использовать любые техники оптимизации, компилятор GCC с любыми опциями, и, скажем, сервер с двумя четырехъядерными процессорами Intel Xeon E5420 2.5 GHz.
Вот, кстати, код:

Защита .NET приложений — всё же, во что заворачивать селёдку?

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

Итак, что мы имеем:

hg review — полезная плюшка для mercurial'а

У git'а есть GitHub, а у Mercurial'а есть hg review. На самом деле я сравнил козу с бояном.

Ревью кода.

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

И вот появился проект, который дает нам инструмент, а как его использовать — решать нам.

Было время, когда я ничего не знал про VCS, ни что это такое, ни тем более зачем это мне. И верхом своих достижений считал папочку с архивами версий. К моменту осознания необходимости системы контроля версий я уже набил шишек и прочувствовал необходимость такого инструмента. Но борландовский аналог CVS меня не впечатлил. У каждого файла свой номер версии. Как мне получить срез определенного релиза я так и не разобрался. А в это время SVN победоносно шла сквозь умы разработчиков. Черт, это было то, чего мне так не хватало. Прочитав доку и начав работать я просто влюбился в нее. Да, были трудности и определенные неудобства, но куда без них.
Так я и работал бы в SVN, но ничего не стоит на месте. В интернете уже потекли тонкие ручейки новостей про Git. Я не кидаюсь за каждой новой технологией, и прошло уже достаточно много времени, пока мне не прожужжали этим Git’ом все мозги. Мне стало любопытно, я вначале присматривался, примерялся, а потом плюнул и начал новый проект на Git. Мучался с ребятами 2 недели, накачал литературы, написал шпаргалку… ничего, привыкли, … а потом меня поперло.

Теперь меня регулярно просят рассказать про Git и что в нем такого. Уже надоело, поэтому этот пост для тех, кто еще сомневается.

Распараллеливание кода без зависимостей

Введение

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

Предлагаемые решения в .NET 4

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

Для распараллеливания «идеальных» циклов предоставляются следующие варианты:

• класс System.Threading.Tasks.Parallel с методами For (), ForEach ()
• Parallel LINQ с методом расширения AsParallel ().

Внутренняя модель nVidia GPU – ключевой момент в понимании GPGPU с использованием CUDA. В этот раз я постараюсь наиболее детально рассказать о программном устройстве GPUs.