?

Log in

No account? Create an account

Когда начинать стартап
mkizub

Прочитал на хабре статью Прикладная S-образность: Планируем Стартап, в котрой автор рассматривает различные периоды жизненного цикла технологий, с целью нахождения места, когда стартап имеет лучшие шансы на успех... У него всё хорошо и правильно написано. Очень советую почитать.

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

Чтоб применять его модель к стартапам, надо вначале понять, откуда же берётся эта S-образная кривая в развитии технологии, чем определяется жизненный цикл технологии (а в реальности - любой сложно организованной системы, развивающейся в большем целом). Достаточно подробное описание причин, приводящих именно к такой форме кривой количественного развития я довольно давно описал в своей работе - "Путь улитки". В принципе, эта работа была посвящена человеку и технологии саморазвития, но начало, описание развития и его этапов - общее для всех систем. Там есть примеры и технологий. Очень советую прочитать первую часть ;) , потому что дальше я буду опираться именно на причины (качественные), а не следствия (количественные).

Проблема № 1 (в вычислении "подходящего" момента для стартапа). На этапе I возможны разные источники развития (появления) технологии. Если у нас вариант появления "телевидения", то идея простая и очевидная, нужна только критическая масса телестанций и телевизионных приёмников. Но есть и другие варианты. Скажем, появление "радио". Да, радио было громоздким (антенны и приёмники), дорогим, мало приспособленым для адресной передачи информации - по сравнению с существовавшими тогда, и уже довольно развитыми, проводными средствами передачи информации (телеграф, телефон). Но для радио нашлась чудесная ниша - передача сообщений между кораблями (в море) и передача данных через океан. Тут ещё очень удачно и ионосфера Земли подвернулась (которая отражала радио-сигнал, иначе он уходил-бы в космос, и не доходил до Америки). То есть, если вы нашли нишу для технологии, где она может расти и развиваться, и не испытывать конкуренции с существующими технологиями - можно смело делать стартап.

Проблема № 2 - как определить точку, когда начальное развитие переходит в экспоненциальное? У неё простое решение, если вы понимаете откуда взялась эта S-образная кривая. Технология переходит к экспоненциальному развитию в тот момент, когда она становится в среднем "лучше" существующих (конкурирующих) технологий. Кстати, может и никогда не стать лучше, или другая новая технология её обгонит. Но если вы "в теме", вы специалист в этой новой технологии - то этот момент определяется достаточно просто.

Проблема № 3. Ну почему он решил, что стадия экспоненциального развития - это лучшее время для стартапа?! С чего начинается стартап вообще? С инновационной идеи. Так вот, II-я стадия (экспоненциального роста) - это, как правило, худшее время для новых идей. На этапе экспоненциального роста нужно расти, а не улучшать, делать более сложной технологию. У вас и так купят, спрос всегда превышает предложение. Надо делать больше, дешевле, проще. Если какая-то из набора альтернативных реализаций технологии вырвалась вперёд - то она всё дальше будет уходить вперёд, несмотря на огромные усилия отстающих. Вспомните те-же системы комманд процессоров. Какие-бы лучшие архитектуры не придумывали, доминирует та, что в какой-то момент стала самой массовой - x86. Это эффект положительной обратной связи - чем больше спрос на x86 процессоры, тем больше их делают, тем дешевле их делать, тем более они "стандартней и совместимей", тем больше на них спрос. Если вы вырвались вперёд с вашей реализацией базовой идеи, лежащей в основе технологии - вы удачный стартап. Но пытаться догнать лидера, выдумав новый стартап - практически бесполезно. Можно, как смогла Microsoft задавить Borland. Но это исключение из правила, а правило - лучше не пытайтесь, если у вас нет задела с I-го этапа.

Проблема № 4. Момент перехода от стадии экспоненциального развития (II) к стадии стагнации (III) - это время разорения, укрупнения крупных компаний, лидеров II-го этапа. Конечно, на стади II спрос был колоссальным, и даже отстающие имели возможность жить. Большие деньги (ожидаемые от стартапа) они не заработали, но на жизнь хватало. А вот когда технология упёрлась в потолок количественного роста - аутсайдеры вылетают. Но в то-же время, этот переходный период - период изменения приоритетов с количества на качество продукта. И если у вас есть более качественный вариант реализации технологии - вы можете "неожиданно" обойти даже лидера. В то-же время, это время перехода от единого, массового продукта - к большому набору узко-специализированных продуктов. Дело в том, что сделать "лучше" (качественней) можно (и легче всего) за счёт узкой специализации. Если идея вашего стартапа из этой области - самое время для его организации.

Проблема № 5. Время стагнации (III-й этап, внутреннего качественного развития, при фиксированном, нерасширяющемся количественно рынке сбыта). Крупные корпорации, укрупнившиеся и выжившие в момент перехода от II-го к III-му этапу - слишком большие и неповоротливые монстры. Кроме главного направления использования технологии (оккупированого ими), обычно существует ещё множество мелких ниш, слишком мелких и неинтересных монстрам, но которые вполне могут прокормить мелкий бизнес. Это не время для стартапов нацеленных на "по быстрому срубить много бабла", но это отличный период для небольшого стабильного бизнеса в рамках развитой технологии.

Проблема № 6. Почему умирают технологии? Потому, что некая новая технология прошла свой I-й этап, и начала вытеснять старую. А откуда они берутся, эти новые технологии? Из развития старой, и чаще всего, на стыке нескольких технологий. Я только что написал, что период стагнации - удобный для небольшого бизнеса на переферии технологии? Так вот, из этой "переферийной" части старой технологии, очень часто, и вырастают новые. Те самые, которые нашли незаполненную, небольшую нишу, в которой разививались и крепли, где формировали свою "новую экосистему". Вначале доступность телефонов, а потом и SMS сообщения - окончательно вытеснили, похоронили телеграммы. Но ведь SMS - это и есть, по существу, телеграмма. Грубо говоря (чтоб не придумывать пример получше), если вы в телеграфном бизнесе нашли небольшую нишу для телеграмм, из вашего предприятия можно сделать стартап для технологии SMS. Конечно, IV-ый этап (умирания технологии) - не время для вложения денег и создания стартапа в эту старую технологию. Но если вы придумали, как перенести старую технологию в новую, то это может быть отличным стартапом. В том числе и потому, что он может воспользоваться "преемственностью", подхватить пользователей умирающей технологии, и сделать их пользователями вашей новой технологии.


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


PS А хабрахабр - козлы. Закрылись там, и тусуются в своей песочнице. Правда, иногда там очень интересные вещи проскакивают, вот и приходится читать ;)

IDE для Ant-а, продолжение
mkizub
Неспешно делаю IDE для ant-а.
Точнее, начальную поддержку сделал быстро. За 3-4 дня, фактически, большую часть времени занял импорт. Пока остановился, понемногу причёсываю. Вот так выглядит сейчас



Конечно, ничего особенного там нет. Просто потому, что его нет в SymADE. Ошибки и предупреждения выводятся в консоль, а не в GUI список ошибок. Help-а нет, списка short-cut-ов нет, и так далее. Потом, надо взять тесты Ant-овские, и потестировать импорт/экспор из/в Ant-овский XML и так далее.  Баги всякие править надо, а то за 3-4 дня работы безбаговой программы не сделаешь ;)

Ну и синтаксис какой-то надо придумать получше. А то пока просто почти калька с XML-я, только что лишние  слова и теги поубирал, вместо "this is a ${property.name}" просто рисую "this is a property.name" другим цветом и шрифтом. Этого, наверное, мало...

Короче, начать и кончить. Какое-то время развлекался оптимизацией кода по скорости и памяти. Отдохнул от Ant-а немного, теперь буду его понемногу причёсывать.
Tags: , ,

Занимаюсь IDE для ANT-а
mkizub
Ant, кто не в курсе - это такой make для явы.

Для makefile-ов своего синтаксиса нет, а используется XML. Получается жутко расширяемо. Но XML для человека не очень удобен.
Недавно наткнулся на пост, в котором человек искал редактор для Ant-а с простым и понятным синтаксисом, мол, XML его уже достал. Пока build.xml небольшой - ещё ничего. А как что-то реальное, а не hello world построить - то километровой длинны.

Меня эта мысль зацепила. Ant-ом пользовался, особенно когда в esmertec работал. Как make он вполне удовлетворял наши потребности, но его необозримые и фактически нередактируемые (в связи с размерами) файлы заставляли использовать его только в крайних случаях. По факту, даже свою версию make-а там написали, которая вызывала legacy анализаторы написанные на C, perl, python, и конечно ant-е. Ну да не об том речь.

Смотрите. Отказаться от Ant-а уже невозможно. Для него написаны куча расширений, он поддерживается практически всеми java-IDE и средами разработки. Но редактировать его невозможно, вот пример - для автоматизации создания build-файлов в формате xml  понаписали десятки надстроек над этим Ant-ом. Maven, Ivy и прочая и прочая. Стали бы их создавать, если бы эту конфигурацию проекта и его сборки можно было легко записать в xml файле?

И решил я написать IDE для Ant-а. Задача самая простая, какая может быть для SymADE-а. Импортировать xml, нарисовать в своём синтаксисе, отредактировать (используя автокомплит), проанализировать простейшие ошибки, экспортировать обратно в xml.

Вот такое получилось после двух дней работы (в основном импорт писал). Конечно, ещё работать и работать, неделю, не меньше. ;)

AntIDE
Tags: , ,

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

рисование блоков в SymADE
Tags: ,

Редактирование кода программы как дерево, а не текст
mkizub
Чтобы понять, чем SOP/SymADE отличается от MPS или IP надо вначале разобраться, что у них общего.

Прежде всего, все эти средства разработки программ предполагают переход от представления программы в виде текста к представлению (редактированию и хранению) в виде дерева. В таком подходе нет ничего нового, именно эту идею использует Lisp, что в конечном итоге позволяет ему быть столь мощным средством мета-программирования. Например, возьмём такой простой кусочек кода как выражение 2 * (a + 1). В Lisp-е он будет записан как (* 2 (+ a 1)) - согласно простым правилам: каждый элемент кода кроме простейших атомом отделяется скобками, первым элементов в скобках является "символ" операции, и затем аргументы той операции. В данном случае у нас есть операция умножения (символ *), с аргументами 2 и (+ a 1), то есть второй элемент это операция сложения (символ +) над аргументами a и 1. Это выражение разбирается Lisp-ом и хранится внутри него в виде дерева. Такой синтаксис, конечно, менее удобен, чем привычная нам со школьной скамьи запись. Но он позволяет одну важную вещь - в любом месте программы мы можем использовать любой код (значение которого определяется символом, первым элементом в списке). Что в свою очередь является фундаментом (синтаксическим) для мета-программирования.


Одна из идей лежащих в основе SymADE/MPS/IP - это хранение и манипуляция кодом программы так-же как в Lisp-е, в виде дерева. Но при этом мы можем определять удобный для нас "синтаксис", только в данном случае - это просто способ отображения кода на экране. Тот-же код, который в Lisp-е мы вынуждены хранить и редактировать как (* 2 (+ a 1)), то есть списки/дерево структурированне лишь скобками, в SymADE/MPS/IP может быть отображён привычным нам образом, как  2 * (a + 1). При этом внутри программы мы всё так-же имеем дерево, но за счёт специально задаваемых правил отображения, мы можем показать это дерево в том виде, который нам удобен.


Зачем это нужно? Для этого есть несколько причин. Первая - мы можем отображать нашу программу так, как нам удобно, не ограничивая себя проблемами однозначности синтаксиса, да и сам парсер для разбора текста (для преобразования его во внутреннее представление компилятора) нам не нужен. Второе, это возможность отображатьодин и тот-же код по разному для разных программистов, в зависимости от их предпочтений - начиная с правил оформления кода (отступы, пробелы, переносы строк), и кончая возможностью задать совершенно другой "синтаксис" отображения (одни предпочитают С-подобный синтаксис, другие Pascal-евидный и так далее). Третье, это возможность отображать программу с разным уровнем детализации. Скажем, адепты функционального программирования очень гордятся автоматическим выводом типов функций и переменных, что позволяет им зачастую не указывать эти типы, за счёт чего программа получается намного более компактной и удобной для чтения. Но автоматический вывод типов - ничто, по сравнению с возможностью произвольно задавать уровень детализации отображения программы. Вместо автоматического вывода типов мы можем просто задать нашему IDE не отображать типы - и получить более компактное отображение кода. Мы даже можем задать совершенно "высокоуровневое" отображение кода, чтоб он выглядел как UML диаграммы. При этом мы не меняем сам код, и не генерируем из UML код на другом языке программирования - мы просто таким способом отображаем нашу программу. Четвёртая причина - это полноценная интеграция вновь определённых понятий в IDE. То есть при редактировании кода мы получаем авто-дополнение кода при редактировании, быстрый переход в место определения символов или нахождение всех мест где они используются, мы можем задавать рефакторинг (преобразование узлов дерева одного типа в узлы другого типа) и так далее.


Но есть и ещё одна, на мой взгляд, самая главная причина, по которой имеет смысл отказаться от текстового (Lisp-подобного) представления в пользу кода хранимого в виде дерева с произвольным отображением. Ведь в чём главная сила Lisp-а, ради чего он жертвует выразительностью синтаксиса? Ради возможностей предоставяемых мета-программированием! Возможности писать код который будет генерировать код для вашей программы, проверять правильность кода вашей программы и так далее. Так вот, мета-программирование становится особенно нужным, когда размер кода проекта становится настолько большим, что его уже невозможно поддерживать и развивать используя ограниченный набор понятий языка общего назначения. Использование мета-программирования позволило-бы уменьшить код таких больших проектов в десятки раз, вновь сделав его достаточно простым и понятным, для дальнейшего развития. Но увы, Lisp предоставляет возможности мета-программирования только для программ написанных на Lisp-е. Если ваш проект был написан на С, С++, C#, Pascal, Java и пр. - ничем вам мета-программирование Lisp-а не поможет. Так вот, IDE подобное SymADE/MPS/IP - может вам помочь в этом случае. Для этого необходимо определить в этой среде набор понятий подобный набору понятий в C, C++, C#, Pascal, Java и пр., а затем экспортировать старый проект в данную среду. После этого программист будет видеть код в привычном ему виде, и может продолжать редактировать его как если-бы это был код на его старом языке программирования, но плюс к этому - он получает возможность определять и использовать новые понятия, специфические для его проекта.


Возможность интеграции в IDE вновь созданных языков программирования или расширения существующих языков программирования, а так-же возможность плавного перехода к использованию мета-программирования - это столь важные преимущества SymADE/MPS/IP-подобных IDE, которые позволят в самом ближайшем времени (в течении нескольких лет) стать им одними из доминирующих средств разработки программ. Особенно в областях, где важно применение DSL (Domain-specific language), и при разработке крупных программных проектов.


Но эти преимущества - это только начало. Точнее, MPS от JetBrains и IP от Intentional Software только приближаются к реализации этих возможностей, и это практически все идеи, заложенные в них. Но в SOP заложено намного больше. Несмотря на технологически подобную реализацию (внутреннее представление программы в виде дерева, хранение его в виде дерева, и произвольное отображение этого дерева, изначальная интеграция новых понятий и языков в IDE), фундамент у SOP намного глубже, и в перспективе позволит пойти намного дальше, чем MPS и IP.


В следующем посте я наконец дойду до различий между SOP/SymADE и MPS, IP.

Tags: , , ,

SOP - Семантически-ориентированное программирование
mkizub
Семантически-ориентированное программирование (SOP), это новая парадигма программирования, хотя и не совсем в привычном понимании этого термина. Обычно мы к парадигмам программирования относим процедурное (императивное) программирование, функциональное, логическое и т.п. К ним можно также отнести ООП, мета-программирование и подобные концепци. Собственно говоря, само слово "парадигма" - означает устоявшийся набор приёмов, понятий, ценностей, способов решать задачу. И оказывается, что "парадигм" в процессе программирования используется несколько больше. Скажем, такой способ решать задачи как использование IDE, баг-трекинга, unit-тестов, методологий организации работы коллектива программистов и многое другое.

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

Судя по названию, парадигма Семантически-ориентированного программирования предполагает, что программист будет писать программы используя термины максимально приближённые к содержанию решаемой задачи. По существу - это написание DSL (domain-specific language) или eDSL (embedded DSL), с последующим решением задачи используя уже этот специально написанный для решения задачи язык. Это оно, спросит искушённый читатель? - Да, верно, но не только это.

Дело в том, что хотя средств для создания DSL вполне хватает - используют их достаточно редко, предпочитая пользоваться языками общего назначения - C++, Java, Haskell и др. Хотя казалось-бы, пусть мы будем долго запрягать, зато быстро доедем... Так-то оно так, но не совсем так. Раз уж мы не пишем эти языки так часто, то на это должны быть какие-то объективные причины. Вот некоторые из них. Например, то-же использование современных IDE позволяет в несколько раз повысить производительность труда программиста (конечно, в основном для больших проектов). Дело не только в удобстве редактирования и отладке, но и в том, что IDE позволяет ориентироваться в огромном по размере коду проекта. Да, написать собственный DSL можно сравнительно быстро и легко, и он позволит значительно увеличить производительность труда программиста. Но увы, при этом мы потеряем возможность работы в IDE, которое, в лучшем случае, превратиться в простой редактор. Не очень-то много мы и выиграем, а может и проиграем.

Другая возможность, сравнительно редко нами используемая - это мета-программирование. В каком-то смысле мета-программирование является просто средством для создания DSL (а чаще eDSL). Существуют языки которые изначально создавались с расчётом на постоянное расширение средствами мета-программирования, оно в них встроенно изначально. Это такие языки как Forth, Lisp и т.п. Цена их использования - менее удобный синтаксис, чем у языков не имеющих встроенных средств мета-программирования. И увы, они тоже "не пошли", хотя средств в их развитие вложено очень не мало. Возможно, в частности не пошли и потому, что при написании небольших и средних проектов - мета-программирование не особенно и нужно. А вот когда проект становится действительно большим, и тут-бы и использовать его в полный рост... Увы, вам понадобиться вначале переписать весь код на Lisp, и только потом вы получите возможности мета-программирования. Стоит ли говорить, что "за такие деньги" никто мета-программирование не купит.

Вот эти, и многие другие проблемы, возникающие при попытке перейти от программирования с использованием языков общего назначения к семантическому программированию, и призвано решить SOP. Дать в руки инструмент, не просто предназначенный для быстрого и легкого создания DSL/eDSL, но позволяющий использовать всю мощь мета-программирования не принося в жертву другие парадигмы и технологии (такие как IDE), позволяющий "плавно" войти в использование мета-программирования и так далее.

Для реализации этой парадигмы я пишу SymADE (Symbolic Adaptable Development Environment), разработка которого ведётся по адресу http://symade.tigris.org . Технологически реализация подобна IP (Intentional Programming - http://www.intentsoft.com) и MPS (Meta-programming system, реализующая Language-oriented programming - http://www.jetbrains.com/mps). Но именно технологически, потому как в плане идеологии эти системы больше ориентированы на расширение синтаксических возможностей и изначальной интеграции созданных DSL в IDE. А SOP предлагает намного больше, намного. Но об этом я напишу в следующий раз ;)
 
Tags: , , ,