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

• ExecutionEngineException
• StackOverflowException
• OutOfMemoryException

И это нормальное поведение. Почему?

Перевод статьи Vincent Driessen: A successful Git branching model

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



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

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

1. Почему стоит начать работать «в белую»
2. Почему на начальном этапе ИП лучше ООО
3. Что делать, если партнёров несколько

Если вы – начинающий или уже опытный фрилансер и подумываете о работе «в белую», но ещё точно не определились с вопросами «Стоит ли оно того?» и «ИП или ООО?», вэлком

Прочитайте пару объявлений об открытых вакансиях в геймдеве, и Вы увидите, что в большинстве из них наниматель ищет людей со страстью к компьютерным играм. Это звучит очень заманчиво, романтично и оптимистично. Объявления рассказывают, как много всего интересного делается в компании, как увлечены играми её работники — и вот они ищут себе таких же коллег. «Вау!» — говорит себе молодой наивный читатель — «У меня огромная страсть к играм! Эта работа для меня!»

Отладка параллельного кода – процесс утомительный и умозатратный. Ошибки распараллеливания проблематично отловить из-за недетерминированности поведения параллельных приложений. Более того, если ошибка обнаружена, ее часто сложно воспроизвести снова. Бывает, что после изменения кода, сложно удостовериться, что ошибка устранена, а не замаскирована. Чаще всего, ошибки в параллельной программе являются гейзенбагами. Порой испытываешь острую потребность в максимально удобных и функциональных инструментах отладки параллельных программ.

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

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

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

Dapper.NET — это «мини-ORM», как ее называют сами разработчики, на которой работает движок StackExchange и сайт StackOverflow в частности.

Сегодня Sam Saffron (@samsaffron, один из разработчиков платформы) выложил ее в OpenSource на Google Code.

Основная фишка этой микро-библиотеки — производительность в тех случаях, когда надо запустить, например, 500 select-команд подряд и замапить тысячи результатов в объекты определенных классов. Разработчики утверждают, что скорость их решения практически не уступает «ручной» работе с SqlDataReader.

Желание просмотра iptv по wi-fi возникла одновременно с приобретением ноутбука. Поскольку мой провайдер транслирует некодированый сигнал, то нужда в приставке отпадала, и для реализации желания требовался только раутер, способный «показывать» iptv. После недолгих мучений выбор пал на ZyXEL nbg460n, который должен был удовлетворить все возникшие потребности, при этом мною, человеком неискушенным в этих вопросах, предполагалось, что iptv само собою будет раздаваться и по wi-fi, но как раз с этим возникла проблема.

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

Честно говоря, написание этого текста преследовало вполне корыстные цели: он является некоторой лакмусовой бумажкой для отправки людям, с которыми предстоит сотрудничать.

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

Продолжаем маршалировать. На этот раз будет рассмотрен способ вызова С-шных функций из C# без использования P/Invoke( [DllImport] ). А если быть до конца точным, то [DllImport] использовать все же придется, но только один раз. По существу, данная статья является статьей о маршалинге делегатов в указатели на функции и обратно.
Итак, приступим.

Каждый раз, когда я собираюсь писать статью, особенно если она часть курса, я пытаюсь понять, кому она будет нужна и как её будут использовать. И когда коллеги предложили мне взяться за написание небольшого вводного курса по разработке под Windows Phone, первое, что я сделал, я просмотрел все доступные материалы претендующие на роль обучающего курса или книги. Несмотря на то, что платформа Windows Phone достаточно молодая, материалов по ней, как русскоязычных так и англоязычных великое множество.

Когда-то во время учебы в университете, преподаватель, проверяя лабораторную работу по C++, вдруг неожиданно для меня задал вопрос: “А зачем вам здесь #include “%имя_библиотеки%”? Вы можете пояснить, для каких частей кода нужна каждая директива include?” Та директива, что «бросилась ему в глаза», была добавлена при попытке использовать какой-то класс. Класс, видимо, не прижился в лабораторной и его использование было благополучно удалено, а include остался…

Программируя в С#, с использованием Visual Studio, мы так же сталкиваемся с неиспользуемыми директивами using. Но Visual Studio может помочь справиться с проблемой, достаточно для .cs файла вызвать команду “Remove Unused Usings”. Правда есть еще одно место, которое так же не мешало бы время от времени чистить. Это ссылки (References) проекта. Как ни печально, но для C# проекта такой команды нет. В MS Connect даже баг создали по этому поводу. А вот для VB.NET проектов такая функция есть (найти её можно в свойствах проекта), но по злой иронии судьбы для VB.NET проектов нет команды для удаления неиспользуемых Imports (usings в C#) :)

Подогреваемые жаждой сделать полезное коллегам, независимые разработчики решили написать небольшие расширения для Visual Studio. А тут еще и Extension Manager из Visual Studio 2010 так упростил процесс распространения расширений. Пример таких расширений можно найти здесь и здесь. Невозможно судить об алгоритмах, используемых в этих расширениях. Хотя не буду скрывать, что после того как первое расширение бессовестно удалило из проекта приличную часть реально нужных для компиляции сборок, мы все таки посмотрели его рефлектором… Разбираться со вторым уже не стали. В общем-то, проблема одинакова, а ключевое словосочетание можно найти в пред-предыдущем предложении: нужных для компиляции.

Многие знают о ”культе карго” — удивительном явлении, имевшим место во время Второй мировой войны. В ходе боевых действий удаленные острова в Тихом океане вдруг стали стратегическим объектом, американцы построили на них военную базу, и местные туземцы были осчастливлены продуктами цивилизации, которые доставляли грузовые самолеты. Туземцы решили, что хитрый белый человек, который сам не производит никаких материальных ценностей, получает их напрямую от богов, выполняя загадочные ритуалы: марширует с палками по плацу, сидит возле ящика с антенной и молится на непонятном языке, призывая небесных птиц. Когда война окончилась, американцы оставили острова и их наивных обитателей. Когда же позднее на остров вернулись исследователи, они с удивлением обнаружили туземцев с нарисованными нашивками, марширующих по плацу и шаманов, призывающих ”карго” в деревянных наушниках перед муляжом радиостанции.

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

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

Введение

Мне очень нравится Дмитрий Потапенко. С ним можно найти не так много видео на Ютубе, но я пересмотрел все. Если кто не знает — это человек, владелец около 15 магазинных и ресторанных сетей, ведет бизнес в РФ, Болгарии и Чехии, под ним работают 7000 человек, суммарный оборот $140 млн в год. До кучи, в прошлом — двухкратный чемпион мира по каратэ, в 25 лет стал вице-президентом Грюндиг по СНГ.
В общем, крутой мужик.

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

Стратегия важнее тактики

Стратегические просчеты невозможно компенсировать тактическими успехами.
«О войне», фон Клаузевиц

Это же можно сказать и про проект. Выбрали десктопное приложение вместо того, чтобы писать под Web — огромный просчет. Выбрали неверную сферу и под нее угрохали огромное количество средств — никак не реализовать. Выбрали неправильный приоритет по функционалу на месяц, конкурент вас обогнал — опять же, потеря может быть критической. Выбрали неверную технологию — вместо быстрого языка PHP писать на «правильном» типа Ява — опять же потеряли стартовую скорость, еще не выйдя на орбиту.

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

Перебрал множество мелочей, а основные проблемы остались. “Хотя, действительно, работал”, — говорит Olegapro.

Данная статья может показаться банальной, но иногда что-то полезное забывается, а читать на импортном языке лень и книжки под рукой нет. Поэтому я, обратившись к гуглу, нашел хорошее описание процесса создания обработчика конфигурационной секции файла app.config в .net приложениях, перевел его, дополнил замечаниями (курсив) и комментариями и решил опубликовать.

Я уверен, что многим из вас приходилось использовать файл конфигурации App.Config для хранения инициализирующих или конфигурационных данных приложения. И я так же уверен в том, что многим из вас хотелось создать в данном файле свои собственные структуры для хранения настроек. Но в итоге приходилось использовать встроенные возможности секции <appSettings> и получать значения, используя конструкцию вида:

ConfigurationManager.AppSettings["MyKey"]

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

Итак, для того что бы загрузить свою структуру данных из файла App.Config нам потребуются следующие классы:

1. ConfigurationSection — Этот объект вернет нам пользовательскую секцию.
2. ConfigurationElementCollection — Это собственно коллекция элементов, которые мы определим в пользовательской секции.
3. ConfigurationElement — Это сам элемент, описывающий какую-от определенную вами сущность.

И опять, привет хабравчанам!

Буквально несколько дней назад — начал цикл статей, о том, как можно создавать крутые игры с помощью XNA Framework, своей студии у меня нет, поэтому ограничимся только 2D играми.

На этот раз — мы более подробно рассмотрим Draw и напишем свою первую систему частиц.

Привет всем начинающим геймдевелоперам и просто хорошим людям. Сегодня, я хочу познакомить вас с замечательным фреймворком XNA (набор инструментов с управляемой средой времени выполнения dotNet). Программировать мы будем на C#.
Для того, чтобы познакомить вас с XNA ближе, я предлагаю написать простую «музыкальную» 2D игрушку. Остальное под катом.

Не так давно публике была представлена платформа Windows Phone. Платформа очень интересная в плане разработки, т.к. присутствует поддержка .Net Framework, мультизадачность и XNA Framework, причем отличия у XNA от десктопной версии минимальны.

Вначале ложка дегтя: выяснилось, что пока на Windows Phone не будет полноценной поддержки собственных шейдеров, но обещается ряд предустановленных с широкими возможностями настройками. Что-ж, не будем огорчаться, всему свое время.
Для работы нам понадобится Windows Phone Developer Tools

Все телефоны на базе Windows Phone согласно требованиям Microsoft имеют аппаратное ускорение графики поддерживающее 3D рендеринг. В XNA 4.0 включено 5 основных эффектов шейдеров для 3D графики и несколько опций для их дополнительной конфигурации. Это основная палитра для использования в 3D играх для телефона. Вы можете скачать пример, чтобы познакомиться с тем как они работают. В этой статье приведен обзор всех пяти шейдеров, и они проиллюстрированы короткими роликами, которые дают понять об их основных визуальных возможностях.