LostInWired

Первая встреча ОпенКофе.ру, как это было.

noreply@blogger.com (LostInWired) — Sat, 15 Sep 2007 20:16:00 +0000

Вот на такой пост на хабре я наткнулся недавно:

Стартует ОпенКофе.ру – открытый клуб для стартаперов, инвесторов и всех, кто так или иначе связан с темой стартапов.

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

Зябким субботним утром я собрался в путь. Как выяснилось, я немного перепутал время встречи и соотвественно опоздал, к счастью не сильно. Приятно удивило местечко: кафе ArteFAQ - очень приятное заведение для встреч: тихо, спокойно, бесплатный WiFi, вкусные сэндвичи и ненавязчивый персонал. Быстро поздоровавшись, я пристроился за столом. В этот момент как раз инициаторы идеи - ребята из dgtlpunkz.com рассказывали о себе. Потом предствился я и некоторые другие участники. Постепенно первое стеснение ушло и посыпались вопросы, в основном, к организаторам. Многие хотели знать какая реально цель была у инициаторов. Появился Александр Бадерко, он собственно и помог сформулировать ту часть повестки дня, в которой говорилось о цели проекта ОпенКофе. Было правильно замечено, что если у сообщества не будет конкретной цели, то рано или поздно все собрания превратятся в посиделки под пиво и что-нибуть покрепче. Александра в основном интересовала часть "стартапер-инвестор". Немного поразмыслив я предложил разделить стандартную встречу на две части. Первая - презентация заранее оговоренного списка стартапов. Вторая - фритолки. Как мне показалось, многим идея пришлась по душе. Наши ряды постепенно редели, а разговор переходил уже в сферу психологии стартаперства, мысль о бизнесе 4fun нравилась большинству. Под конец встречи Илья Удачин подвел итоги: порадовался тому, что были вынесены продуктивные решения, что было много идей и пообещал детально поработать над планом следующей встречи. Потом были разные фритолки и междусобойчики, но это уже другая история...

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

Забытая фаза проектирования

noreply@blogger.com (LostInWired) — Thu, 23 Aug 2007 17:06:00 +0000

Сейчас почти в каждой статье про web 2.0 и стартапы среди рекомендаций можно увидеть совет: бросьте долгие раздумья и пред-проектную документацию - делайте проект! И очень часто этот совет воспринимается буквально, первые строчки кода появляются еще до того, как идея окончательно сформируется. Что в итоге? А в итоге ядро системы за весь период разработки переписывается раз по 15, не говоря уже о фронтенде. Как следствие проект который был задуман как 1-2х месячный растягивается на пол-года - год. А код превращается в сборище багов.

Что же сделать что-бы этого избежать и при этом не заниматься планированием по пол-года?

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

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

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

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

Хватит описаний давайте перейдем к практике. Разделим весь проект на несколько частей.

Инициализация - здесь вы обсуждаете что вы примерно хотите получить, обмениваетесь мыслями.
Проектирование - вот она стадия которую забывают. О ней подробней ниже.
Кодирование - тут всё ясно надеюсь :)
Тестирование - А вот этой стадии без проектирования не бывает, если вы не знаете что хотели получить, как вы проверите что получили?
Интеграция - запускаем проект.

Теперь подробнее о проектировании.
В случае небольшой команды, я не предлагаю использовать какое-то супер навороченное ПО. Давайте ограничимся просто Wiki. Я выбрал для себя DokuWiki, вы может использовать любую другую. Воспользуемся стандартами IEEE для проектного менеджмента, хотя следовать ему дословно не будем.
Первый документ который нам понадобится SPMP (Software project management plan) он же "План управления программным проектом". Тут укажем кто за что в проекте отвечает, как будет происходить управление, какие методы вы будете использовать. Для тех кому нужны конкретные примеры в конце приведу несколько ссылочек.
Дальше нам понадобится SRS (Software Requirements Specification) она же "Спецификация требований к ПО". Это очень важный документ, тут расписываются все функции которые должны быть реализованы в системе. Требования к интерфейсу, а так же use cases. Нарисуйте структуру вашего сайта, создайте прототип. Под прототипом я не имею ввиду что-то действительно работающее. Прототип это набросок пользовательского интерфейса. Можно воспользоваться например MS Visio. Я бы рекомендовал всегда делать прототип фронэнда, даже если кажется что всё просто. Если просто - так это займет 5 минут, а вдруг вы что-то забыли? Тут не идёт разговора о графическом дизайне или чем-то подобном. Просто кнопки, формы и поля ввода, также и их практическое расположение на странице не имеет сейчас никакого решающего значения.
Теперь перейдем к SCMP (Software configuration management plan), он же "План управления конфигурациями ПО". Тут я редко придерживаюсь стандарта, но всё же документ необходим. Здесь описывается какое ПО вы используете при разработке, как упорядочиваются версии. Как происходят сборки итд.
Ну и наконец SDD(Software Design description), он же дезигн док. Вооружившись списком требований описанных в SRS начинаем проектировать нашу систему. Описываем архитектуру проекта, основные пакеты и классы. Степень детальности описаний определяем индивидуально.

Вот собственно и всё, не так много как казалось. Из личной практики: раздел в SRS в вики можно использовать как систему управления требованиями. Просто присвойте каждой функции свой номер, статус и приоритет. Не стоит создавать себе проблем с лишним софтом.

Теперь пара ссылочек:
Документация к Open Source MOORPG Ireon - практический пример заполнения некоторых документов.
SPMP стандарт (eng) здесь

При желании все стандарты находятся гуглом.

Почему же большинство стартапов так и останутся в планах?

noreply@blogger.com (LostInWired) — Thu, 23 Aug 2007 15:10:00 +0000

Для начала давайте посмотрим как планируются большинство стартапов на просторе рунета сейчас. Обычно берут уже успешную идею, реализованную где-нибудь на западе, и пытаются переделать её под себя. Например был digg, стал портал про памперсы с возможностью голосования за статьи или новости. Или например web IM. Что делают с ним? Ну конечно же прикручивают тонны опций, галочек, рюшечек и говорят, что теперь продукт подходит всем, за счет кучи менюшек настраивается под любого.
А так ли это на самом деле?

К сожалению - нет. На самом деле обилие настроек и опций "убивает" программу. Чем меньше галочек и менюшек, тем проще пользоваться программой. Тем меньше тратится времени на поиск нужной функции. Попробуете понаблюдать за собой, какую часть функционала например MS Word вы использует? Окажется что 20%-30%.

Вот тут и появляется основное правило, которое очень хорошо подходит к стартапам. Делайте как можно меньше функций! Ваши пользователи хотят чтобы софт\сайт\сервис работал, а не был панацеей на все случаи жизни. Боритесь против каждой новой функции, учитесь минимализму. К тому же это приносит много плюсов и для разработчиков: меньше кода, проще поддерживать, быстрее разработать.

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

Избавившись от кучи функций вам будет легче понять работоспособность вашей идеи. Как только вы уберете всю мишуру останется только самое нужное и важное. Можно будет легко сравнить с другими проектами, спросить у друзей мнение итд. Задумайтесь, если без рюшечек ваш проект становится неинтересным, возможно вы не за ту идею взялись?

Пишем стартап на java или к черту XML! Часть 1.

noreply@blogger.com (LostInWired) — Sun, 29 Jul 2007 20:03:00 +0000

Когда я первый раз взялся писать на java под web, то был ужасно шокирован количеством xml`я, для нормально проекта его нужно было писать просто тонны! Незнаю как вам, но мне мягко говоря это задачу усложняло раз в пятьсот, ибо ни читаемости кода, ни удобству отладки такой подход не способствовал. К тому же HTML превращался во что-то жуткое. Плюнув на жалкие попытки въехать в мышление программистов, создавших таких уродцев, я занялся поисками юзерфрендли фреймфорка, и к счастью его нашел.

Представляю вашему вниманию в девичестве Wicket, а ныне Apache Wicket :)
Оффициальный сайт
Примеры

Наш стартапчик мы будем писать на базе Wicket+Databinder. Что такое датабиндер? Это расширение к викету, позволяющее удобно работать с Hibernate? Что такое Hibernate? Видимо вы никогда не писали на java, если задаете такие вопросы.
Hibernate это система позволяющая удобно работать с базами данных, при том код получается полностью объектным и абсолютно независящим от того какую БД вы используете.

Я постараюсь рассказать подробно обо всем, поэтапно чтобы можно было легко въехать даже абсолютному новичку. Под новичком я имею ввиду человека знающего хоть немного Java, а не полного ньюба. Итак, приступим. Для начала нам понадобится Maven, у кого есть - хорошо, у кого нет идем
сюда и качаем последнюю версию. Распаковываем архив, прописываем путь к папочке в переменную PATH. У кого линух в ~/.bashrc прописываем

export PATH=/usr/local/maven-2.0/bin:$PATH

(ну или где там у вас лежит папочка с мавеном)
у кого винда Мой компьютер > Свойства > Дополнительно > Переменные среды
в PATH добавьте путь. Итак Maven готов.
Теперь идем сюда и качаем "Class Files 1.0.1B".
Потом в консоли

mvn install:install-file -DgroupId=javax.transaction \
-DartifactId=jta -Dversion=1.0.1B -Dpackaging=jar \
-Dfile=jta-1_0_1B-classes.zip

Дальше всё проще. Качаем и распаковываем архивчик : http://webfile.ru/1482376
Теперь в консоли , заходим в папку с проектом и вводим

mvn idea:idea

Это конечно если вы работаете с IntelliJ Idea, если нет и у вас Eclipse или NetBeans, то читаем тут и дальше уже сами, ибо ни еклипс, ни нетбинс я не знаю :)
После ввода этой команды Maven создаст вам файлики для вашей IDE и скачает нужные библиотеки. Сам скачает, всё верно :) Тут обращу ваше внимание на то, что Maven должен выдать Build Successful, если пишет Error, то что-то не так - пишете в коментах, помогу.

Итак теперь загружаем проект в IDE. Открываем scr>main>java>hibernate.properties
Это настройки к вашей базе данных, как видите там всё просто :) К слову о настройках самой БД, предполагается, что у вас дефолтная таблица InnoDB, кодировка UTF8 и существует пустая база myExample (всё для mysql) . Изменяем настройки под себя и сохраняемся.

Сейчас в консоли можно ввести mvn jetty:run в папке с проектом и если ничего экстраординарного не произойдет у вас по адресу http://localhost:8080/myExample/app/ будет висеть веб-сервер. Жмем Ctrl+C в консоли и останавливаем тем самым веб-сервер.

Теперь у нас есть настроенный проект, осталось только начать писать код :)

Продолжение следует.

P.S. Тому кто раньше не использовал maven, советую начать осваивать хотябы основные функции, потом еще спасибо скажете :)

При цитировании ссылка на это блог обязательна!

А где же все стартаперы?

noreply@blogger.com (LostInWired) — Sun, 29 Jul 2007 17:39:00 +0000

Если почитать топики создаваемые на хабрахабре например, создается впечатление, что почти каждый второй делает свой стартап и при этом претендует чуть ли не на лавры гугла. А если есть хотя бы идея стартапа, значит потребуется команда для реализации этих идей. Я решил проверить это утверждение, но потратив на поиски около часа я не нашел абсолютно ничего толкового. Такое ощущение, что никому вообще не нужны партнеры. Максимум что выдают поисковики это сообщения из форумов "до 15 и младше". Где же все сообщения вроде "Ищу команду для создания стартапа" или "Команда программистов ищет дизайнера для создания стартапа".
Да хотябы opensource проект какой-нибуть пропиариался, но нет! Всё это как-то странно, не верю я, что у людей планирующих новый проект "на кухне под закуску", всегда всё ОК с человеческим ресурсом, по себе знаю.

Сразу оговорюсь я искал только в рунете, но может не там искал? Где вы стартаперы? Откликнитесь!

P.S. Думаю не плохо бы поучаствовать в интересном opensource проекте в свободное время, вопрос в другом, а есть ли такие? :)