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

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

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

Дальше текст немного в «чёрном» стиле Славы Панкратов (case), но это нынче модно. Я надеюсь, вас не смутит обращение на «ты», поскольку оно лучше передаёт эмоциональную составляющую и смысл статьи.

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

Вот что у нас получилось.

Если вы словили OutOfMemoryError, то это вовсе не значит, что ваше приложение создает много объектов, которые не могут почиститься сборщиком мусора и заполняют всю память, выделенную вами с помощью параметра -Xmx. Я, как минимум, могу придумать два других случая, когда вы можете увидеть эту ошибку. Дело в том, что память java процесса не ограничивается областью -Xmx, где ваше приложение программно создает объекты.

Старожилы Интернета хорошо помнят, что первыми по-настоящему популярными многопользовательскими компьютерными играми были текстовые RPG, известные под сокращённым названием MUD (от английских слов «многопользовательское подземелье»). Передвижения и сражения персонажей происходили в них через подачу простых текстовых команд, и происходящее в игре поступало к игрокам в виде литературного текста, описывающего события. Обычным средством для связи игрока с игровым сервером в те годы был стародавний протокол telnet (технически одарённые игроки нередко использовали в игре не стандартный клиент telnet, а специализированные игровые текстовые консоли для MUD, обеспечивающие макроподстановки, горячие клавиши, и запись маршрута странствий, и подчас даже наскриптовывание автоматических действий — например, автоматизацию поедания пищи голодным персонажем).

В феврале 2010 года на Хабрахабре (в том же блоге «IM», где я сейчас это пишу) появилася блогозапись «„Снежки“ — мега-шутер в джаббере», автор которой (likegroof), в общем-то, перенёс в Jabber принципы MUD-боёвки: персонажи подают простые текстовые команды, сервер сообщает им о достижениях и состоянии персонажа. Это многие отметили тогда же и там же в комментариях.

В том же 2010 году некий DM, действующий под псевдонимом MuzzY, регистрирует домен JabberGames.Ru и создаёт джабберный MUD «Камень судьбы», в настоящее время довольно развитый — к нему даже существует плагин для QIP Infium, обеспечивающий графику:



В феврале нынешнего (2011) года Андрей Фоменко (вдохновлённый этими событиями давний любитель интерактивных текстовых игр) объявил в своём блоге о том, что и сам начал держать у себя дома на компьютере MUD для Jabber, открытый круглосуточно, где играют до 30 человек одновременно.

Да ведь это тенденция, господа.

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

Начать статью я хотел бы с констатации того факта, что прямо за окном находится 2011 год (пруфлинк), середина апреля. Напоминаю я это в первую очередь себе, поскольку меня периодически посещают в этом сомнения. Дело в том, что как по работе, так и ради хобби я часто читаю код на С++, написанный лет 10-20 назад (но поддерживаемый и поныне) или код написанный совсем недавно, но людьми, которые учились программировать на С++ те же 20 лет назад. И вот после этого у меня и возникает ощущение, что никакого прогресса за эти годы не было, ничего не менялось и не развивалось, а по Земле до сих пор бродят мамонты.

Жизнь — дерьмовая штука. По крайней мере, так считают многие «взрослые» люди, с которыми мне довелось общаться. Они постоянно жалуются на свою работу, неудовлетворительные отношения и раздолбаев-детей, которые никак не хотят становиться такими, какими хотят их видеть родители. Жизнь для этих людей — это бесконечная карусель разочарований, неприятностей и несбывшихся надежд. Они встают рано утром с больной головой, заливают в рот пару литров кофе и едут на работу в состоянии, которому позавидовали бы самые отъявленные зомби. Они ненавидят свою работу и считают, что их занятия бессмысленны и никому не нужны. Но, не смотря на это, они с упорством леммингов продолжают делать эту работу, день за днём, год за годом. Они продираются сквозь собственную жизнь, надеясь, что всласть поживут потом, когда отработают 10-20-30 лет. Так вот, это всё херня. Когда вам будет пятьдесят, вы настолько устанете от такой жизни, что единственным вашим желанием будет лечь и сдохнуть. Да и здоровье будет уже не то, потому что вы слили его, занимаясь всякой ерундой, до которой вам даже не было дела. Так что, когда вы выйдете на пенсию, вы не поедете в Африку охотиться на львов, потому что солнце плохо сказывается на вашем давлении. Вы также не поедете на Северный полюс, потому что у вас артрит и холод — не лучшее для него лекарство. Южный полюс отпадает ещё и потому, что вы недолюбливаете пингвинов, что неудивительно, учитывая ваш 30-летний стаж работы сисадмином. Так что же вам остаётся? Поездки на дачу и вечера в уютной компании телевизора, вот что. Прожив 30 лет в постоянной борьбе с самим собой, у вас просто не останется сил на то, чтобы оторвать задницу от дивана.

Давным-давно вышел ADO.NET 2.0, а вместе с ним и сборка System.Transactions, содержащая класс TransactionScope — путеводитель в мир легкого и непринужденного использования транзакций. В сегодняшней статье я рассмотрю некоторые нюансы, возникающие при использовании этой дырявой, но такой симпатичной абстракции.

 

Компания Pluralsight, при поддержке Microsoft, делает прекрасное предложение для веб-разработчиков и предлагает бесплатный доступ к своему профессиональному видео-курсу обучения технологии ASP.NET MVC 3. Предложение ограничено по времени, курс будет свободно доступен только до 18 марта. Курс подготовлен на английском языке.



Курс состоит из следующих частей:

• введение: новый проект, шаблон MVC, маршрутизация, контроллеры, представления, создание действия;
• движок представлений Razor: преимущества Razor, создание простого представления, смешивание кода и разметки, модели и ViewData, HTML-хелперы, частичные представления, модель компоновки представления, код для автоматического запуска, конфигурация;
• контроллеры: глобальные фильтры действий, кэширование результатов вложенных действий, ViewBag, новые результаты действий, валидация запросов;
• модели: валидация в MVC3, аннотация данных, пользовательские атрибуты валидации, модели с поддержкой валидации, клиентская валидация, пользовательская клиентская валидация, удаленная валидация;
• NuGet: средство управления пакетами, зависимости пакетов, использование PowerShell, пользовательские пакеты;
• Dependency Injection: инъекции зависимостей, использование IDependencyResolver, инъекция в контроллерах, инъекция в представлениях, активаторы, расширяемость фильтров, расширяемость моделей.

Pluralsight делает весьма и весьма качественные видео-курсы, поэтому рекомендую всем не упустить возможность и ознакомиться с этим бесплатным предложением. Очень хороший шанс начать изучать ASP.NET MVC или узнать что нового было представлено в MVC3.

Задача: создавать PDF-документ с использованием библиотеки iText. При этом пользователь должен сам задавать используемые шрифты, из установленных в системе. Шрифты как TrueType так и Type1.
В iText есть статический класс предоставляющий доступ к системным шрифтам FontFactory. При получении шрифта нужно правильно указать его кодировку. Тут и возникли проблемы. Для ТТ и Т1 кодировки разные, и в .NET нет штатных средств позволяющих отличить ТТ-шрифт от Т1.

Сей пост навеян неожиданным для меня интересом хабранаселения к посту уважаемого Milfgard из Мосигры про производство в Китае. Дело в том, что один из моих интересов как раз в производстве батарей – Denaq. И производство расположено ну конечно же в Китае. Я не стану рассказывать про организацию производства, там свои замечательные фокусы есть. Я расскажу именно про заказ чего-то под себя и покупку всякого опта. Что-то вроде алгоритма украшенного реальными историями из личного опыта. Это все будет про электронику, так как я сам именно ею занимаюсь. Истории и иллюстрации я буду выделять курсивом. Кому скучно читать общие выводы – читайте только их.

На сайте есть написанный на Silverlight редактор кода c подсветкой синтаксиса и небольшой учебник по F#

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

Библиотека log4net известна и в представлении не нуждается. В ней есть практически всё, что нужно, «из коробки». Однако, есть специфические ситуации, в которых необходимо добавлять/расширять функциональность библиотеки. Конкретная ситуация: есть некоторая библиотека, которая выполняет логирование через log4net в некоторый логер (или несколько — не суть). Эта библиотека используется в N службах. Как сделать так, чтобы логирование происходило в единственный файл? Под катом объяснение, почему FileAppender+MinimalLock не подходит, и реализация Appender'а, который решает задачу. Отдельно хочу сказать, что вопрос о логировании в БД, по сети и т.п. в статье не рассматривается, т.к. это гораздо более серьёзная задача, которая (особенно для больших систем) требует длительного обдумывания и внедрения.

Я могу ошибаться, но мне кажется что всем хорошо известный Spring Framework достиг своей вершины к версии 2.5 (когда внедрили активное использование аннотаций) и дальше идет по сути дела «полировка» — даже major-релиз 3.0 не сильно отличается от 2.5. Тоже самое можно сказать и про грядущий 3.1 — небольшие улучшения, фишечки — но не более того. Однако одна «фишечка» в 3.1 показалась мне особенно интересной — это кеширование.

Получить годные цифры бенчмарка это полдела, однако вторая половина их правильно интерпретировать, узнать что-то новое, и суметь применить. 100x отличия промеж дебажным и нормальным билдом удивили, решил копнуть глубже. По итогам получше узнал, что происходит в дебаге; поискал отличия между 2005 и 2008 студией (не нашел); выяснил, как ускорить дебажный билд в 3 раза за пару минут (ставим блок против удара в спину); методом «взять и запустить» получил результаты, отличающиеся от авторских в 3.5 раза (адская сила x64 в действии!); и для смеха замерил плохой, негодный недовектор против хорошего (плохой оказался до 100 раз быстрее). Подробности под катом.

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

1. Введение

В данной статье я хотел бы рассказать об этих трёх буквах, постоянно находящихся на слуху, но для многих являющихся тайной за семью печатями, а так же привести ряд ресурсов, с которыми неплохо было бы познакомиться при желании продолжить развитие в проектировании на основе предметной области (DDD: Domain Driven Design).

Это перевод поста из Facebook Engineering Blog, который интересен, наверное, даже не столько сутью решения, которое в нем описано, сколько рассказом о «кухне» разработки в Facebook. Речь идет об обновленном функционале просмотра фотографий, который появился в конце сентября 2010 г. и был немного еще улучшен на днях.

Задумавшись об обновлении Photo Viewer, мы столкнулись с множеством трудностей. Очевидно, что фотографии это наиболее востребованная функция Facebook. Ежедневно наши пользователи загружают более 100 миллионов фотографий, а предназначенный для этого функционал был создан довольно давно и явно нуждался в доработке.

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

Как нам это удалось
Мы начали с составления списка текущих проблем:

• Наибольшие проблемы возникали с надежностью. Изображения загружались медленно, и иногда процесс зависал на неопределенное время. Пользователям приходилось обновлять страницу в браузере, чтобы увидеть фотографии и комментарии к ним.
• При просмотре фотографий из Ленты новостей приходилось либо открывать их в новой вкладке, либо мириться с тем, что после просмотра нужно было заново прокручивать ленту вниз, чтобы вернуться к предыдущей позиции. Для разбирающихся в компьютере людей это не составляло особых проблем, но многие из наших пользователей испытывали связанные с этим неудобства.
• Функционал просмотра комментариев к фотографиям был также реализован не самым удобным образом. Процесс выглядел так – нужно было посмотреть фотографию, промотать страницу вниз, чтобы увидеть подпись и комментарии к ней, а потом вернуться обратно наверх, и так каждый раз.
• JavaScript, предназначенный для загрузки и кэширования фотографий, а также для публикации комментариев, был также реализован не самым лучшим образом. Он оставался неизменным на протяжении многих лет, на фоне того, что технологии работы браузеров и требования к ним значительно ушли вперед.

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

Я ошибался дважды, выбирая работу. Совсем не от того, что неверно выбрал карьеру специалиста в сфере информационных технологий. Это очень, очень, очень интересная работа. Почти как работа капитана космического корабля… ;)

Я выбирал компании, но не выбирал боссов. И в этом состояла моя ошибка. Думаю, что не только моя…