Инструмент для создания цветовой схемы

http://colorscheme.ru/

удобно

Сам себе - как вести корпоративный Твиттер

http://habrahabr.ru/blogs/twitter/63654/#habracut

tbd - почитать комментарии

[link] Как прочитать параметры с биометрического паспорта

Статья, как на Java написать приложение чтобы читать данные с биометрического паспорта.

http://developers.sun.ru/content/view/384/85

на почитать - статья Владислава Балина - "Оценка трудозатрат по разработке ПО"

http://gaperton.livejournal.com/34265.html

HTTP ПЫЩ

Мне кажется, назрела необходимость что-то в протоколе HTTP менять. Вот возьмем методы GET и POST - у каждого свои достоинства и недостатки.

HTTP POST позволяет передавать на сервер большие объемы данных

HTTP GET не имеет проблем с двойным post-ом.

Явно не хватает какого-то метода, который объединит в себе плюсы обоих подходов.

Название ПЫЩ еще не занято. Мне кажется, можно использовать его.

Вариант, как это можно сделать

Пример запроса

ПЫЩ HTTP/1.1 /someform/[LARGE_DATA_IN_QENCODING]

где в large data может быть что угодно, хоть аттачи в mime multipart

Сервер вернет

200 ПЫЩ /new/unique_new_url

Ну а браузер должен отобразить такой URL клиенту в адресной строке.

[Link] Microsoft guidelines on Ribbon

Себе, чтоб не забыть

http://msdn.microsoft.com/en-au/library/cc872782.aspx

Матрица компетентности программиста

Перевод

1 часть: http://spreadsheets.google.com/pub?key=pmAWNZu8sBj_tXy5ms5foVQ 

2 часть: http://docs.google.com/View?docid=d28gm4q_56hmv6f72z

Оригинал http://www.indiangeek.net/wp-content/uploads/Programmer%20competency%20matrix.htm

На мой взгляд, это офигенно. Практически готовая аттестационная таблица для разработчиков.

Есть ли жизнь просле спецификации?

Функциональность бизнес-приложения - совместное дело заказчика и разработчика

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

Спецификация здесь является только точкой отсчета - слепком того, как разработчики (я имею в виду всю команду - начиная от бизнес-аналитика и кончая последним PMом :-) поняли свою задачу. Если затем кто-то из игроков по какой-то причине встает в позу и начинает "пенять на спеку" то дело швах.

Даже при самом мегакомпетентном заказчике, он какие-то вещи не поймет, пока не начнет системой пользоваться хотя бы в тестовом режиме

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

Что же можно пожелать командам, работающим над бизнес приложениями?

Заказчику

• Назначать менеджером со своей стороны гибкого человека, который абсолютно "в теме" бизнес контекста, желательно с минимальными техническими скиллами (как вариант -- хорошо работает связка "бизнес-спец"+"спец от ИТ").
• Быть готовым к длительной фазе приемки. Быть готовым за нее платить :-). 
• Запланировать пилотную эксплуатацию систему на живых пользователях. 
• По возможности, не привязывать к первой версии системы критичных дедлайнов.

Исполнителю

• Заложить в бюджет проекта достаточное количество времени и денег на доработку системы после старта приемочного тестирования.
• Не надеяться, что после того как спецификация будет написана, она не изменится.
• Не пытаться сделать абсолютно всеобъемлющую спецификацию чисто аналитически -- все равно только после того, как заказчик посмотрит на готовую систему, он поймет, чего на самом деле хотел.
• Проектировать систему так, чтобы было легко вносить очевидные бизнес - изменения (добавить поле, добавить/удалить/изменить валидатор, поправить алгоритм постройки отчета, поправить права на функциональность и т п).