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

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

Эффект Glitch Лукаса Беббера выглядит очень круто — как будто вы смотрите на текст на старом мониторе, который слишком часто роняли на пол и у него «плавает» вертикальная синхронизация и сведение.

Реализация этого эффекта на CSS выглядит вполне убедительно. Мне пришлось немного поломать голову, чтобы выяснить, как он работает, и теперь я хочу объяснить это вам. Кроме того, я воспроизвёл этот эффект не только для текста, но и для растровых изображений и SVG, а так же написал несколько примесей Sass, чтобы облегчить работу с ним.

Если вы .NET программист, то вы наверняка объявляли и использовали события в своем коде. Несмотря на это, не все знают, как события работают внутри и какие особенности связаны с их применением. В этой статье я попытался описать работу событий как можно более подробно, включая некоторые частные случаи, с которыми редко приходится иметь дело, но про которые важно и\или интересно знать.

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


Последняя осень?

Признаться, я долго колебался как поступить — иллюстрировать свои рекомендации и советы примерами из личного опыта, либо ограничиться их перечислением с короткими комментариями. Так и не сделав выбор, решил сразу написать две статьи и выложить их одну за другой, с разницей в день. Эта рассказывает о моём опыте на примерах, которые я сопровождаю комментариями. Если у вас мало времени и вам более интересны краткие содержательные выводы и конкретные рекомендации, просьба не тратить время на мой сегодняшний опус, а прочитать мою следующую статью, которую я специально публикую одновременно с этой.
Конечно, можно было бы просто составить сухую выжимку из полезных рекомендаций, но, думаю, что легче они будут восприниматься, если будут подкреплены рассказом о моём личном личном опыте. Реальные события воспринимаются проще, чем на сухие строчки.
В этом посте я попробовал в качестве эксперимента выровнять фотографии по ширине текста. Надеюсь, этот эксперимент не вызовет отторжения в хабрасообществе.

(пятница)

Обычно развернутое приложение в файловой системе выглядит как-то так:



Совершенно незащищенное от инструментов типа рефлектора или IlSpy, но что если оно станет таким:



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

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

Предлагаю ознакомиться со способами, реализованными мной в приложении на системном уровне:

• Использование CSS и переключение классов вместо перестроения DOM дерева
• Повсемнестное кеширование выборок элементов ($('div.active_part span.highlighter')), атомарные операции по изменению (вместо всеобщей перерисовки, вместо переделывания больших участков DOM дерева)
• Минимизации чтений DOM во время записи изменений состояний
• Кеширование размеров и расположения элементов (это спасает от излишнего вычисления при считывании этих значений при наличии других изменений: чтение во время изменения множества частей дерева крайне негативно сказывается на производительности)
• Аккуратное, не затягивающееся накопление изменений, необходимых произвести в DOM
• Прикрепление частей изменяющихся коллекций единовременно (когда, например, в середину списка вставляется 3 новых элемента; createDocumentFragment) в конкретное место (after, before) вместо открепления всей коллекции от DOM и повторного прикрепления (и вместо того, чтобы перерисовывать весь список)
• Прогрессивный асинхронный рендеринг: картина прорисовывается сразу с небольшим количеством деталей, затем деталей появляется всё больше
• Клонирование нодов (как часть шаблонизации)
• Кеширование и использование кеша результатов парсинга DOM шаблонов

изображения из части с заголовком «Прикрепление частей изменяющихся коллекций единовременно...»

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

В этой статье хочу поделиться интересной историей, о необычном решении одной интересной задачи, которая попалась мне год назад. Всё описанное в статье делалось, прежде всего, «just for fun» и из чистого академического интереса…
Дело было год назад, как раз было свободное время и желание сделать что-нибудь полезное. Явно был некоторый интеллектуальный голод и острая нехватка чего-нибудь нового, какой-нибудь интересной задачи… Отсюда и попытки прилепить велосипед даже туда, куда он вообще не требовался… Собственно, таковым велосипедом и является всё нижеописанное…

1. Задача

На одном торгово-закупочном предприятии, достаточно остро стоял вопрос оптимизации закупок. У предприятия было несколько десятков основных поставщиков, но при этом у многих поставщиков пересечение товаров достигало 20-30%, а цены у всех разные. К сожалению, большинство товаров закупалось «по старой памяти», например привыкли, что товары группы A поставляет поставщик X, а товары группы Б поставщик Y, хотя если отбирать товары не группами, а штучно, то можно не слабо экономить. Для наглядности, покажу на примере:

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

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

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

Когда говорят про разработку игр, обычно речь идет о шейдерах, графике, AI и т.д. Крайне редко затрагивается серверная часть игровых проектов, а ещё реже — базы данных. Исправим это досадное недоразумение: сегодня я расскажу о нашем опыте работы с базами данных, который мы приобрели в ходе разработки Аллодов Онлайн и нашего нового проекта Skyforge. Обе эти игры — клиентские MMORPG. В первой зарегистрировано несколько миллионов игроков. Вторая разрабатывается студией в строжайшей секретности в недрах Allods Team.

Меня зовут Андрей Фролов. Я ведущий программист Allods Team и работаю в команде сервера. Мой опыт разработки — почти 10 лет, но в игры я попал только в октябре 2009. В коллективе я уже больше трёх лет, с марта 2010. Начинал работу на Аллодах Онлайн, а сейчас на Skyforge. Занимаюсь всем, что так или иначе связано с сервером Skyforge и базами данных. В этой статье я расскажу о базах данных в онлайн-играх на примере Аллодов и Skyforge.

Здравствуй, Хабр!



Осенью прошлого года я открыл Хекслет – образовательный проект с бесплатными онлайн-курсами по программированию на русском языке. Спустя неделю стартовал первый курс – Разработка под OS X. Это был очень интересный опыт, но было допущено много ошибок в разработке этого проекта.

Сегодня я рад объявить о перезапуске Хекслета! Что вас ожидает:

• Новый сайт и удобный, быстрый движок. Со старым было столько проблем, что многие студенты просто не могли им нормально пользоваться.
• Улучшенный формат курсов. В первой версии я пытался эмулировать физический университет в интернете, а нужно было делать изначально онлайн–курс.
• Личное общение с преподавателем. Эту особенность хочется сделать важным отличием от други образовательных проектов.
• Новые, интересные курсы и планы на будущие курсы.

Уже сейчас можно записаться на три первых курса:

1. Разработка приложений на Java
2. Структура и интерпретация компьютерных программ (SICP)
3. Разработка под OS X

Трейлер очень интересного курса SICP:



Под катом – описания текущих и будущих курсов.

JavaScript принято считать прототип-ориентированным языком программирования. Но, как ни странно, этим подходом практически никто не пользуется: большинство популярных JS-фреймворков явно или неявно оперируют классами.
В этой статье я хочу рассказать об альтернативном способе программирования на JavaScript, без использования классов и конструкторов — чистым прототипным ООП и особенностях его реализации на ECMA Script 5.

По-настоящему хороший комментарий — тот,
без которого вам удалось обойтись.
Дядюшка Боб

В последнее время меня стали очень утомлять оживлённые дебаты о том, нужно ли комментировать код. Как правило, по одну сторону баррикад — самоуверенные джуниоры, имеющие непререкаемую позицию вида «А как же его не комментировать, ведь без комментариев непонятно будет!». По другую — умудрённые опытом сеньоры. Они понимают, что если возможно обойтись без комментариев, то «Лучше бы, чёрт возьми, так и сделать!». Наверное, у многих жажда комментировать идёт со студенческой скамьи, когда товарищи преподаватели заставляли комментировать каждую строчку, «чтобы студент лучше разобрался». В реальном проекте не должно быть кучи комментариев, которые только и делают, что засоряют код. Впрочем, я не агитирую вообще не писать комментарии, но если вам удалось написать такой код, который не требует пояснений, то расценивайте это, как свою маленькую победу. Сразу хотелось бы сослаться на нескольких очень умных книжек, на основе которых формировалась моя позиция. Я люблю и уважаю авторов этих работ, полностью разделяя их мнение.

• С. Макконнелл, «Совершенный код. Мастер-класс»
• Р. Мартин, «Чистый код. Создание, анализ и рефакторинг»
• Д. Босуэлл, Т. Фаучер, «Читаемый код, или Программирование как искусство»

Перевод статьи Дэвида Альберта — Understanding C by learning assembly.

В прошлый раз Аллан О’Доннелл рассказывал о том, как изучать С используя GDB. Сегодня же я хочу показать, как использование GDB может помочь в понимании ассемблера.

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

^{Тут наверняка есть косяки, просто мы ещё не открыли коробку}

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

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

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

ХО-ХО-ХО! Праздник к нам приходит! Всегда coca-co… HTML5!
Выпал снежок и как-то незаметно пришло праздничное, предновогоднее настроение. Чтобы как-то поддержать праздничный дух, мы решили сделать небольшой сюрприз от издательства и порадовать наших читателей бесплатной электронной книгой Марка Пилгрима «HTML5. Руководство разработчика» (DIVE INTO HTML5). Оригинал книги также есть в бесплатном варианте в Интернете.

Прежде чем скачать книгу целиком, предлагаем вам познакомиться с первой главой:

Глава 1. Как мы сюда попали?

Приступим

Недавно я прочел высказывание одного разработчика для платформы Mozilla, где говорится о той напряженности, которая всегда сопутствует разработке стандартов:

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

Пока я буду рассказывать, как появился HTML5, помните эти слова.

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

Не секрет, что по темпам развития технологий и числу профессий в IT индустрии, сегодня компьютерная графика занимает одно из лидирующих позиций.

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