Спасибо тебе Артем, то, о чем так долго говорили большевики свершилось, это маленькое чудо размером 2 704 байта умеет переключать раскладки по назначенной клавише. Достаточно добавить в авторан этот магический запускаемый файл с параметром 20. И вуаля, мы переключаем капслоком языки!

http://haali.cs.msu.ru/winutils/ 

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

http://unattended.msfn.org/unattended.xp/

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

А теперь это делается вот так:

 post :change_avatar, 
:avatar => ActionController::TestUploadedFile.new(
Test::Unit::TestCase.fixture_path + '/files/spongebob.png', 
'image/png')

Только зачастую то что хочется - не совсем ТО ЧТО НАДО. Впрочем, это применемо не только к рельсам.

Вот хочет заказчик "вот тут пимпу зелёную". И твой священный долг убедить заказчика, что на самом на деле он не хочет "пимпу зелёную", а что и красная пимпа тут "стилизирована" на странице и достаточно неплохо смотрится. 

Главная Проблема Заказчика это то, что он зачастую НЕ ЗНАЕТ чего хочет. Вследствие чего возникают "зелёные пимпы", функционал, который будет использован ОДИН раз. 

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

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

Типичный случай печального исхода - выход за временные, функциональные и/или финансовые рамки проекта. По статистике 90% (!) проектов имеют такой печальный исход.

Вывод: всегда нужно подходить к проекту с мыслью о главном - для чего и для кого он нужен.

Винда для слабых компьютеров, превращающая ваш старый компьютер  в "тонкий клиент", т.е. поднимает весь hardware, и имеет совсем базовый набор утилит для удаленного подключения и запуска терминальной сессии.

Об этом очень подробно со скриншотами написано у нашего друга brj.

Вот ведь неосвещенная тема попалась, ведение TODO проекта. Как его ведут? Кто его ведет? Зачем и когда?

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

А делается это путем достижения соглашения с самим собой о пометках, которые я буду использовать для маркировки элементов в TODO.

Вот моя маркировка:

LEGEND:
+ сделано
? требует согласования
* все согласовано, остается сделать
-----------------ADMIN----------------------------------
+ при входе администратора - сводка (новых участков, участников)
+ указать на карте координаты
* загрузка картинок
? нанесение лого на загружаемое изображение (размеры лого, позиция) 

Таким образом отфильтровав файл по ^* .* мы получим все задачи, которые необходимо только сделать и так далее. После выполнения строчки с * я меняю * на +, копирую строку в файл DONE, который потом подставляется в svn commit -F DONE. Но тут уж необходима дисциплина, что бы не забывать удалять из сделанных строки при добавлении новых коммитов.

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

Второй способ, ну скорее не способ, а дополнение, мы ставим в комментариях пометки TODO: сделать то-то.

А затем в любимом редакторе (vim) вызываем grep по файлам проекта на предмет строчек с TODO. К слову, в vim есть для этого специальное удобное окно Quickfix. Используя плагин Project я могу <leader>G комбинацией полнить grep по открытой папке проекта. 

Вот как-то часто приходится подключаться на удаленные десктопы, как любят выражаться на LOR, legacy os. А еще у меня аутлук в терминале, а еще мне на сайты иногда нужно через IE смотреть, в общем rdesktop, конечно же, наше всё. Но, мне неудобно было переключаться из rdesktopa в X11 и обратно, окно rdesktop перехватывало фокус и клавиатурный ввод и не отпускало покуда не выведешь мышь из окна, что, конечно же, порядком поднадоело.

Также поднадоело набирать логин, пароль, выбирать домен и прочее.

TFT моник у меня 19" в разрешении 1280x1024.

Посему зародился минискрипт запуска удаленной консоли в двух вариантах.

Первый вариант - запуск в окне 1024x768, что-нибудь быстро поделать и закрыть окно rdesktopa.

Второй вариант - люблю запустить на отдельном workspace в гноме (как правило на последнем) так что бы rdesktop был на все окно (fullscreen) c аутлуком, браузером, и, самое главное, работали бы горячие клавиши моего gnome. Другими словами, поработав в винде я хочу нажать, Win+1 и перейти на рабочий стол №1. И обратно, нажав Win+4 хочу перейти в мой fuulscreen rdesktop. Что и обнаружилось возможным благодаря опции запуска rdesktop -K.

первый и второй скрипт называю rd и rd2 соответственно, аккуратно укладываем в ~/bin/ (у меня оттуда запускаются личные, локальные шелл-скрипты). Cкрипты принимают параметром имя хоста. 

Итак, вариант №1:

nexus@nexus:~$ cat /home/nexus/bin/rd
rdesktop -u nexus -d it -p mymegapass -a 16 -g 1024x768 $1

Второй вариант:

nexus@nexus:~$ cat /home/nexus/bin/rd2
rdesktop -u nexus -K -D -d it -p mymegapass -a 16 -g 1280x1024 $1

Удачи! 

* для тех кто не знает что такое LOR:
главный сайт о линукс всея рунета
http://linux.org.ru

* legacy OS - Microsoft Windows

Много чего было перепробовано мной в качестве ICQ клиента под Ununtu.

GnomeICU, Gaim, CenterICQ-utf8, LICQ.

Требования к icq клиенту были не такие уж и высокие, нужно что бы клиент умел подтягивать серверный контакт-лист, корректно отправлял и принимал сообщения как напрямую, так и в режиме отправки через сервер, имел нормальную history, корректно работал с именами в cp1251 и в utf-8. В общем я хотел миранду под линукс :)

Печали моей до недавних пор не было предела, потому как GnomeICU не корректно работал с кириллицей( а то и вовсе сваливался), Gaim из ветки edgy отображал контакт-лист в кривом utf-8 (русские имена), но отправлять-то отправлял нормально, даже задание хитрой локали RU-CP1251 при запуске не полечило контакт-лист. Centericq, который хорошо работал на FreeBSD с локалью KOI8-R, в моей utf-8 консоли просто подглюкивал. Ну а Licq просто не понравился своим Qt интерфейсом. Но, о чудо, я вижу licq-nd