Как видите, вопрос о возможности миграции Ruby-on-Rails приложения на GAE не так прост. Более того, по мере исследования знак ответа (да-нет) несколько раз менялся. В финале было решено портировать код поддерживающий ActiveRecord на DataMapper и пробовать переносить остальной Ruby код без изменений. Клиент одобрил бюджет. Сейчас мы в архитектурной итерации строим прототип для проверки работоспособности JRuby-Rails-DataMapper-GAE.
Для нас Google App Engine новая платформа и мы начали исследование. Результаты Вы можете посмотреть на этом :
Предыстория задачи такова. Некоторое время назад мы разрабатывали Вэб-приложение на RoR. По характеру организации бизнеса это был стартап, причем финансировался он самим заказчиком, без *ангелов* и инвесторов. Свою часть работы мы сделали, Вэб-апп выложили на панамский хостинг ServerPronto. Впоследствии проект не вышел на самоокупаемость, но забрасывать его заказчик не хотел, поскольку у него возникли новые идеи и старый сервис он собирался через некоторое время сделать площадкой для дальнейшего развития. Теперь о главном он захотел перенести приложение на Google App Engine. Просто он прочитал про новую возможность бесплатного хостинга и обратился к нам с просьбой изучить возможность такого перенесения и оценить бюджет этой операции.
Дальше я приведу пример с использованием mind42 для исследовательской задачи по определению возможности миграции готового Ruby-on-Rails приложения на .
возможность устанавливать метки типа «вопрос», «да» или «нет» на ветку это значительно повышает читабельность ММ.
демократичный бесплатный аккаунт;
командная работа (иногда исследвание должно вестись 2-мя людьми одновременно);
возможность добавлять гиперссылки на ветки ММ;
Какие у нас были требования к иструменту ММ во время этого исследования?
Как видно, победителем соревнования стал инструмент
Отчасти такому решению способствовало наличие большого количества онлайн инcтрументов для построения ММ. Вот к примеру результат исследования рынка бесплатных онлайн ММ инструментов с поддержкой командной работы (для записи истории исследования использовался ):
Что мы используем сейчас? .
Как мы все это проделывали раньше? Исследователь на протяжении, скажем, дня, блуждал по Вэбу и читал. У него накапливались десятки открытых вкладок и окон браузера, что-то он отмечал как закладку, что-то терял В конце дня он оценивал прогресс, и, например, решал что исследование можно закончить. Далее он открывал редактор и копировал туда некоторые линки, добавлял пару предложений и шел на митинг. При этом пропадала цепочка идей и решений, которые возникали и принимались во время исследования. Их приходилось восстанавливать в ходе дискуссии.
Такие задачи получают опытные разработчики или «сеньоры» и нередко только на представление результатов исследования на митинге нужно потратить от 30 минут до 2-х часов. Проблема в том, что во время исследования его исполнитель принимает определенные решения, и эти решения также важны, как и выводы сделанные на основании исследования. Иногда случается так, что решение было принято не правильно, или была упущена некоторая деталь либо цепочка рассуждений. Нередко исследование возобновляется для проверки дополнительных идей и вариантов.
Очень часто, особенно на архитектурной итерации, нужно провести некоторое исследование, или, проще говоря, *погуглить*. Например, нужно выяснить стыкуется ли что-то с чем-то, и каким образом, поддерживает ли одно что-то другое что-то и т.д. Часто ответ на вопрос не похож на уверенное «Да» или «Нет», имеются определенные условия, возможности обхода проблем и т.д. Задачи на исследование, пожалуй, даже важнее и критичней задач имплементации. Они влияют на фундаментальные идеи и архитектурные решения, на которых мы строим Систему; и, разумеется на успех проекта в целом.
Хочу поделться одной простой идеей, которую мы взяли на вооружение для исследовательских задач.
Доброй всем пятницы.
Mind maps вместо закладок
5 февраля 2010 в 15:47
Mind maps вместо закладок / Хабрахабр
Комментариев нет:
Отправить комментарий