Почему я выбираю Dropbox

Изначально я выбрал Dropbox 1,5 года назад. Тогда мне его порекомендовали коллеги.
С тех пор появилось много других аналогичных сервисов, но до сих пор Dropbox остаётся моим любимым онлайн-хранилищем и механизмом для синхронизации файлов между устройствами.
Основной причиной для этого является то, что мои файлы легко загружается на все устройства, прежде всего мобильные, прямо в файловую систему как нормальные файлы, доступные оффлайн.
То есть перед выходом дома я могу закинуть на домашнем компьютере файл в папку Dropbox'а, и он или успеет автоматически загрузиться или потом я смогу загрузить его по 3G или Wi-Fi.

Очень удобно так иметь под рукой книги, другие материалы, новинки музыки.

Однако я должен сказать, что за удобство использования Dropbox на моих мобильных устройствах стоит сказать спасибо приложению Dropsync, которое позволяет на Android'е делать то, что клиент Dropbox позволяет делать на ПК и даже больше.

Вторая причина - это интеграция с другими приложениями.
У Dropbox есть хорошая поддержка со стороны большого числа мобильных приложений и онлайн-сервисов. И даже на сайте Facebook можно добавлять файлы в группы Facebook напрямую из Dropbox!

Продвинутым пользователям понравится статья на Хабре "Подборка сервисов для расширения возможностей вашего Dropbox". Для меня открытием стал IFTTT (он будет отвечать за публикацию ссылок на эту статью в Twitter и Facebook, кстати :-)).

Вы можете завести свой Dropbox сегодня и получить сразу 2 Гб бесплатного места для хранения своих файлов! (а я получу немного свободного места :-)).

Кстати, можно прокачивать свой Dropbox по размеру. Рецепты можно найти через Google. Например, несколько есть здесь.
В частности, сейчас у меня 5,88 Гб бесплатного места + 48 Гб на 2 года от Samsung.

Какими онлайн-хранилищами пользуетесь вы, и что вам в них нравится?
Чтобы ещё вы бы хотели узнать про Dropbox?

СРАКИ, или RASCI по-русски

Сегодня наши QA сделали отличный обучающий семинар по моделированию бизнес-процессов. На одном из слайдов, в качестве небольшого отвлечения, показали шутку, которую я придумал год назад под впечатлением от PDCA по-русски.

Причём я уже про неё даже забыть успел.

Google для Вашего бизнеса - бесплатно

Вы владеет кафе или магазином и хотите, чтобы Ваши клиенты находили Вас при поиске местных услуг через Google Maps?

Теперь Вы можете разместить подробную информацию о Вашем бизнесе на Google.

Вы можете указать там часы работы, принимаемые карты оплаты и прочее. Даже оформить купоны/флаеры для печати для привлечения потенциальных клиентов.

См. подробнее: http://www.google.com/local/add/analyticsSplashPage?gl=RU&hl=ru.

Хвастливый Галилей

"Я никогда не встречал человека настолько глупого, что я не мог у него чему-нибудь научиться." - сказал как-то основатель экспериментальной физики Галилео Галилей.

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

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

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

Но много ли "Галилеев" в наших рядах?...

Не спешите выкидывать свои старые визитки!

После того, как переходишь на новое место работы, остается целая куча неактуальных визиток. Но не спешите их выбрасывать, если они односторонние: их можно использовать для составления списков товаров, когда собираетесь в магазин или на рынок. Размер визитки будет в самый раз, чтобы вместить количество товаров, покупаемых за один заход.

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

Постоянная техническая задолженность

На этой неделе как-то за чаем мы с коллегами как-то разговорились о принципах разработки ПО.

Я рассказывал о метафоре технической задолженности (Technical Debt), придуманную Уордом Каннингемом (Ward Cunningham). Развивая мысль, лежащую в основе этой метафоры, я озвучил вывод, что лучше изначально все делать правильно и по уму, пусть и несколько дольше, лишь бы не наращивать техническую задолженность лишний раз.

Одна из коллег заметила, что это как-то не сочетается с таким принципом гибкой разработки, как YAGNI. Я как-то попытался объяснить это противоречие, но мне свое объяснение не очень понравилось. Это заставило меня задуматься.

Вообще, мысли, стоящие за этими двумя выражениями, не находятся в прямом противоречии. В противоречии находятся их крайние вариации. И это лишь еще одно подтверждение того, что в нашей работе всегда будет полно компромиссов, любую концепцию надо рассматривать критично и применительно к случаю (см. статьи No Best Practices и Better Best Practices), и ничему нельзя следовать слепо.

Но больше всего меня заставило задуматься возникшее понимание того, что техническая задолженность не может быть равна нулю в принципе (вернее, теоретически может, но на очень короткий срок). Статья Стива МакКоннелла (Steve McConnell), которую я прочитал после, хорошо объясняет почему это нормально и разумно.

Но я бы хотел отметить один тип непреднамеренной технической задолженности, не выделенный в той статье. Даже если техническая реализация системы идеально соответствует предметной области и ожиданиям заказчика, изменения в последних, происходящие со временем, будут постепенно перемещать сделанные технические решения качественно из категории "ясные и правильные" ("clean and correct") в категорию "сделанные наспех и неряшливые" ("quick and dirty"). Добавление этого типа позволяет четко определить рефакторинг, как собственно способ сокращения существующей технической задолженности.

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

Таким образом, можно расширить рекомендацию из статьи Стива до "Будьте уверены, что вы имеете правильный тип технической задолженности, и под наименьшие проценты."

P.S. Ссылки на ресурсы, посвященные раскрытию метафоры технической задолженности, я собрал здесь.

P.P.S. Метафоры Adapt To Adapt и Code Momentum выражают очень близкие мысли к метафоре технической задолженности.

Поехали!

Ну что сказать, скоро 29, а дневничок-то пустоват. Буду потихоньку исправлять ситуацию. Тем более, что уже есть, что сказать...