По следам IDF:
1) Референсный CloverTrail планшет имеет вес 600 грамм и толщину 8.5мм при 10" дисплее. При этом двухядерный 1.8ГГц атом заведомо быстрее всего, что есть на ARM, не говоря уж о софте.
2) CloverTrail+ обещает удвоение произвордительности CPU и GPU относительно Medfield при уменьшении энергопотребления. Учитывая, что и Medfield показывал очень высокую произовдительность, это будет платформа для самых быстрых смартфонов.

Так что сабж

Сабж

Задача: есть некий обработчик, для простоты пусть это будет компилятор. В процессе своей работы он может выдавать некоторое количество ошибок. Каждая ошибка характеризуется местом возникновения (файл, строка, колонка), уникальным символьным кодом и текстом с опциональными параметрами на нескольких языках. При этом текст должен выдаваться на языке, который выставлен у потока, выводящего ошибки, а не у потока компиляции (они могут не совпадать).
Вопрос — как сдизайнить прежде всего саму ошибку, чтобы максимально контролировать статически все аспекты при ее формировании.
Язык — C#.

Прошел месяц, въехали в квартиру

В очередной раз вспомнил нехорошим словом ограниченность существующих ЯП.

http://rsdn.ru/cse

Стоит ли дальше ковырять в этом направлении?

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

Есть, конечно, и недостатки, но мы их будем, по возможности, устранять.

Мой коллега ALM Ranger Tarun Arora написал очень адекватную статью. В ней рассматривается дилемма – когда лучше делать code review, до или после внесения изменений. Данная тема очень горячо обсуждалась среди рейнджеров, и все их комментарии Вы найдёте в статье.

VS 2012 Code Review – Before Check In OR After Check In? — http://geekswithblogs.net/TarunArora/archive/2012/09/18/vs-2012-code-review-ndash-before-check-in-or-after.aspx.

Кстати, обратите внимание, на один весьма неочевидный факт – VS 2012 позволяет делать Code Review не только для изменений, которые ещё не внесены в систему контроля версий, но и для тех, которые уже находятся там.

Источник: http://vstsblog.ru/2012/09/19/vs-2012-code-review-%d0%bb%d1%83%d1%87%d1%88%d0%b5-%d0%b4%d0%be-%d0%b8%d0%bb%d0%b8-%d0%bf%d0%be%d1%81%d0%bb%d0%b5-check-in/

Мой коллега ALM Ranger Tarun Arora написал очень адекватную статью. В ней рассматривается дилемма – когда лучше делать code review, до или после внесения изменений. Данная тема очень горячо обсуждалась среди рейнджеров, и все их комментарии Вы найдёте в статье.

VS 2012 Code Review – Before Check In OR After Check In? — http://geekswithblogs.net/TarunArora/archive/2012/09/18/vs-2012-code-review-ndash-before-check-in-or-after.aspx.

Кстати, обратите внимание, на один весьма неочевидный факт – VS 2012 позволяет делать Code Review не только для изменений, которые ещё не внесены в систему контроля версий, но и для тех, которые уже находятся там.

Источник: http://vstsblog.ru/2012/09/19/vs-2012-code-review-%d0%bb%d1%83%d1%87%d1%88%d0%b5-%d0%b4%d0%be-%d0%b8%d0%bb%d0%b8-%d0%bf%d0%be%d1%81%d0%bb%d0%b5-check-in/

Приглашаем всех желающих принять участие в бэта-тестировании наших блогов — http://blogs.rsdn.ru.