Товарищи программисты, если у вас есть солопроекты, то в чём вы ведёте учёт багов и прочего? Выкладывать исходники на публику не планирую, результаты – планирую.

А вот почему я хочу хостинг территориально в РФ:

Т.е. если мы используем любые криптоалгоритмы (ну, например, MD5 или CRC32 для подсчёта контрольных сумм файлов) и пытаемся хоститься на code.google.com или sourceforge.net, то надо либо согласиться с ограничениями на экспорт технологий из США, либо исключить эти технологии из проекта.

Пока данные ограничения есть только на этих двух сайтах, афаик.

Потырено с хабра.

UPD: самое смешное, что под это попадает весь софт под платформу .NET, ибо сборки от МС имеют strong name, т.е. цифровую подпись, т.е. в проекте используется криптография.

Первый, тестовый пост с моего варианта мобильного клиента для WordPress|MetaBlog.

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

Итак, задание – сделать конфигурируемый планировщик, позволяющий:

1. Иметь сколько угодно заданий
2. Имеющий заданную точность (у нас 5 секунд)
3. Конфигурация должна спокойно производится человеком, не имеющим технического образования и опыта программирования.
4. Каждое событие должно иметь следующие признаки:
   1. Время запуска
   2. Количество срабатываний (как конечное, так и нет)
   3. Интервал запуска
   4. Возможность разрешить или запретить запуск в любой из дней недели или день года, т.е. события только на 31.12 или только по вторникам, или наоборот в любой день, кроме вторников – реальность.

Исходя из этого, было придумано то, что видно в записи по линку выше. Сериализуется это (класс был переименован в Period) вот в такой xml:

Соответственно, просто пишем через пробел нужные нам дни недели/месяцы/дни и радуемся жизни.

Вопрос: как сделать лучше, не ухудшая читабельность конфига? Конфиг необязательно, но желательно, должен быть xml.

Мелкий тест.

Ниже длинный исходник на C#. Определить – WTF он или нет и предположить, зачем он нужен. Завтра выложу полный исходник с объяснениями.

Будете смеяться, но после того, как я оптимизировал создание карты с 10 секунд до 23 миллисекунд, мы упёрлись в производительность стандартных коллекций.

Раньше, когда небо было голубое и трава зелёная, монстров у нас было чётко заданное количество. Поэтому был массив. Сейчас, количество мобов меняется, поэтому, недолго думая, был всунут List<T>. Всё бы ничего, но сервер тут же стал жрать в 4 раза больше проца. Замеры показали, что почти вся нагрузка – пересчёт монстров, из которого половину времени мы сидим в геттера List<T>.Item.

Думаем, что делать

Наряду с мегаОС, гугло толкает свою платформу на мобильные устройства? Android. Успешно так толкает. Исследование среди разработчиков показывает успешность:

• 57% не устраивает получаемый доход.
• 90% сообщили, что число загрузок их приложений не превышает 10000.
• 43% считают, что «Google Checkout» тормозит продажи приложений и требуют упрощения системы платежей.
• 82% не устраивает дизайн Android Market, так как он усложняет поиск старых и заметность новых приложений.
• 46% уверены, что разнообразие версий Android на выпускаемых устройствах существенно усложнит разработку, по причине проблем совместимости.
• 68% разработчиков сомневаются в целесообразности развития и поддержке своих Android-приложений.

По какой-то малопонятной мне причине адаптеры нельзя наследовать от генерик-типов. Сволочи.

Грабли, как мне кажется, есть везде. В своё время, ни одна библиотека не прошла мимо меня в проект, кроме, пожалуй, Infragistics, без доработки. Поговорим о граблях в System.AddIn.

Для начала порекомендую прочитать статью в блоге Джейсона Хи (Jason He), которая называется «Coding patterns to avoid in addin pipeline development». Да и вообще, его блог почитать надо, он поподробнее Walkthrough в MSDN.

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

Затем мы работаем, всё ок. Для выгрузки аддона используем такой код: AddInController.GetAddInController(calc).Shutdown(). По идее всё хорошо, но есть одно но. Из-за того, что мы домен создали вручную, то автоматически инфраструктура System.AddIn его не выгрузит. Да, это может быть логично, но об этом нигде не написано.

Код ниже логичен, но будет падать, несмотря на то, что ссылка на домен у контроллера есть, и она живая. Просто разработчики посчитали, что раз AddIn отключен, то домен нам уже не нужен. Вообще, реализация AddInController’a с lock(this) и прочим меня ни разу не порадовала.

Правильный код вот такой: