Кто есть кто на рынке облачных IDE?

    С момента публикации обзора облачных IDE прошло около двух лет. Хватило ли разработчикам этого времени, чтобы перевести онлайн IDE из категории интересных игрушек в разряд реально используемых в разработке инструментов и сервисов? Однозначный ответ дать сложно. Переворот не совершен, но наступление облачных IDE стало ещё более напористым. Развитие облачной индустрии подстрекает команды новаторов к нестандартным ходам. Кстати, одно из самых распространенных заблуждений — cloud IDE — это обычный редактор в браузере, напичканный всякими довесами и рюшечками. Как раз такие проекты и не имеют шансов стать полноценной заменой оффлайн средам разработки. А вот идея иметь все средства разработки, а также сервисы для запуска, тестирования и развертывания приложений в облаке, весьма и весьма прельщает. А если это ещё и выгодно с точки зрения финансов и времени? Тогда, возможно, стоит задуматься. Ниже представлены небольшие обзоры самых интересных, на мой взгляд, облачных IDE: Cloud9 и Codenvy.

    Cloud9

    image

    Cloud9 является ярким представителем облачной IDE. Американо-голландская команда регулярно обновляет свой сервис, добавляя новые возможности редактора, поддерживаемые языки и PaaS. Cloud9 отличается от Codenvy, и не только дизайном. Впрочем, дизайн Cloud9 заслуживает отдельных эпитетов — сделано необычно. Если в Codenvy расположение меню можно назвать классическим, то впервые попав в Cloud9 нужно немного освоится. Плюс это или минус — решать вам.

    Регистрация и создание проектов

    Чтобы зарегистрироваться в Cloud9 достаточно ввести желаемое имя пользователя (это будем имя вашего домена), email (туда придет линк для подтверждения регистрации) и выбрать пароль. Быстрый доступ к виртуальному рабочему месту — основная фишка любого облачного IDE, и Cloud9 не является исключением. Регистрация заняла около двух минут. Если у вас есть учетные записи на GitHub или Bitbucket, то регистрация становится ещё проще.

    По умолчанию в Cloud9 доступен один демо-проект с 5 простенькими приложениями на HTML, Node.js, PHP, Python и Ruby. Само собой, вы можете создавать новые проекты, загружать файлы с локальных дисков, или же прибегнуть к помощи Git или Mercurial для работы с удаленными репозиториями.

    Поддерживаемые языки, платформы и PaaS-ы

    Как уже было сказано, Cloud9 поддерживает HTML, Node.js, PHP, Python и Ruby. А вот список PaaS-ов явно хромает. Зарегистрировавшись с бесплатным аккаунтом, среди поддерживаемых PaaS-ов удалось увидеть только Heroku, Windows Azure Cloud Services и Windows Azure Websites. На сайте также заявлена поддержка CloudFoundry, однако этот PaaS оказался доступен только из командной строки. Была замечена поддержка OpenShift, но оказалось, что этот PaaS не используется как полноценная платформа для развертывания приложений, а всего лишь как один из удаленных репозиториев.

    Редактор

    Cloud9 поддерживает основные фишки, такие как автозаполнение кода, подсветка синтаксиса, навигация по коду, свертывание кусков кода, форматирование и т.д. Интерфейс редактора также настраивается (окна, вкладки). Присутствует возможность настраивать горячие клавиши.

    Запуск и отладка приложений

    Cloud9 не были бы облачной IDЕ, если бы пользователи не могли запускать и “дебажить” приложения в облаке. Стоит всего лишь кликнуть на иконку с бегущим человеком, и приложение запускается на локальном сервере Cloud9. Тоже самое касается и запуска в режиме отладки. Таким образом разработчики могут “доводить до ума” приложения до развертывания их на PaaS-ах.

    Система контроля версий

    Cloud9 поддерживает Git и Mercurial. Обе системы контроля версий доступны только в консольном режиме, однако, вряд ли это можно считать недостатком. Поддерживается работа с удаленными репозиториями, а значит — вы без труда сможете бекапить код на GitHub и тянуть проекты в Cloud9.

    Приглашения в проекты/совместное программирование

    Cloud9 предлагает следующие возможности приглашения и “расшарки” проектов:

    * инвайт с помощью email
    * поделиться в Twitter
    * поделиться в Facebook

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

    Стоимость

    За $12/месяц Cloud9 предлагает 6 приватных воркспейсов, полный доступ в консоль и терминал, подключение к собственной виртуальной машине, неограниченное количество ftp и публичных воркспейсов, и неограниченное количество приглашенных пользователей.

    Общее впечатление

    Cloud9 оставила весьма неплохие впечатления, и вне всяких сомнений, проект будет развиваться. Удобная работа с файлами, нужные и важные функции редактора, полноценный режим совместного редактирования… Вместе с тем, ни на секунду не покидало ощущение того, что Cloud9 — идеальна для работы с файлами, но не проектами в целом. Впрочем, возможно, это всего лишь ощущение, не имеющее ничего общего с реальностью )

    Codenvy



    За прошедшие 2 года команда сменила не только имя (ранее проект носил имя Exo IDE). Стартовав, как компонент продукта компании eXo Platform, Codenvy отправились в самостоятельное плавание. Про амбиции Codenvy (envy — завидовать. англ.) говорить не стоит. Темпы развития продукта говорят сами за себя — ребята намерены бороться за львиную долю рынка, который, к слову, находится в фазе становления. Как говорится, кто первый — того и тапки.

    Кстати, собирая информацию о Codenvy, удалось обнаружить ресурс codenvy.ru — простенький некоммерческий блог информационно-просветительской направленности. Контента не много в силу возраста блога, но обновляется с завидной регулярностью. Так что, интерес русскоязычного сообщества присутствует, и, стоит надеятся, он будет только расти.

    Разработчики из Codenvy снабдили свое IDE детище дюжиной новых фишек, охватывающих всевозможные аспекты разработки: от новых PaaS-ов и рефакторинга кода, до мульти-пользовательского режима и приглашений в проекты. Остановимся на основных:

    Регистрация и создание проектов

    Если у вас есть учетная запись Google, то регистрация нового домена займет не более 2-3 минут. Имя домена будет взято с ID гуглпочты. В случае, если вы не желаете использовать учетную запись Google, доступна и “ручная” регистрация с выбором желаемого имени домена. Никаких загрузок, плагинов, конфигураций. Это все на чистой Linux, Windows или Mac OS, под Chrome, Firefox или Safari (IE не поддерживается).

    Создание проектов происходит под руководством специального визарда. У вас не будет шансов выбрать не поддерживаемый PaaS или ввести недопустимое имя проекта. Codenvy по умолчанию предлагает использовать свои темплейты, однако, импорт собственных приложений никто не отменял. Клонирование репозиториев с GitHub или BitBucket через графический интерфейс интуитивно понятно и не занимает много времени. Также присутствует загрузка локальных файлов и архивов с проектами.

    Поддерживаемые языки и PaaS-ы

    На данный момент Codenvy поддерживает Java, Java Script, PHP, Python, Ruby, HTML и CSS. Приложения, написанные на этих языках, могут развертываться на AWS Elastic Beanstalk, AppFog, Cloud Foundry, CloudBees, Google App Engine, Heroku и OpenShift. Такой набор технологий и PaaS-ов не означает, что любое приложение можно развернуть на любом PaaS-е. Так, например, PHP приложение можно “задеплоить” только на OpenShift или AppFog. Стоит ли говорить, что список доступных языков программирования и PaaS-ов постоянно увеличивается. Кстати, пользователи сами голосуют за те фишки, которые они хотели бы увидеть.

    Редактор

    Codenvy изначально заточены под Java. Но, это не значит, что другие языки обделены функционалом редактора. Все же, Java программисты найдут для себя большее количество фишек — автозаполнение кода, синтаксическая подсветка, редактор ошибок с подсказками по их устранению, схема кода и рефакторинг кода (на сегодняшний день поддерживается переименование классов, полей и переменных; смотрите видео).

    Тулбар и горячие клавиши легко поддаются кастомизации, поэтому, всего за несколько минут возможно настроить домен Codenvy под себя, например, поместив на главную панель самые часто используемые команды.

    Билды, запуск и дебаг приложений

    Перед развертыванием приложения на выбранном PaaS пользователи имеют возможность собрать и опубликовать проект, запустить его на локальном сервере Codenvy или же запустить приложение в режиме отладки. И это все в облаке! В качестве сборщика проектов используется Maven. Для Java приложений доступен JRebel плагин, способный обновлять приложение прямо в рантайме.

    Система контроля версий

    Codenvy использует Git в качестве системы контроля версий. Git-операции доступны как из GUI, так и из Shell. Само собой, предусмотрена работа с удаленными репозиториями. Планируется ли поддержка SVN или Mercurial — вопрос открытый. Возможно, такая поддержка появится в будущем. Впрочем, и нейтив Git — вполне юзабельный вариант.

    Приглашения в проекты/совместное программирование

    Codenvy уже работает над полноценным collaboration режимом, который в чем-то будет напоминать совместное редактирование документов в Google Docs. Пользователи, работающие в данный момент над файлом будут обозначаться разноцветными курсорами, а их правки также будут иметь цветовые отличия. Бета-проект уже находится в стадии тестирования, и его появление ожидается в ближайшем будущем.

    Из того, что уже доступно — приглашение пользователей в ваше виртуальное рабочее место (импорт контактов Google или же адресное приглашение), а также приглашение GitHub соавторов.

    Стоимость

    На данный момент пользоваться Codenvy можно абсолютно бесплатно. В ближайшем будущем планируется переход на модель GitHub: публичные проекты — бесплатно, приватные — за деньги. Тарифные пакеты стартуют от 9$/месяц, однака пока что не вступили в силу.

    Итоги

    Не будем спорить и размышлять о целесообразности развития облачных IDE. Критиков и сторонников “покодить в облаке” хватает. С другой стороны, прятать голову в песок как минимум глупо — рынок онлайн IDE развивается, и развивается динамично. А тот факт, что на рынке появляется конкуренция, свидетельствует о том, что обычные IDE будут и дальше прогрессировать. По оценкам экспертов, к 2015 году облачная индустрия принесет компаниям доходы в размере $1.1 триллиона и создаст 14 миллионов рабочих мест по всему миру. Уж точно, какую-то часть этого рынка и будут занимать cloud IDE проекты. Ну, и ко всему прочему, сейчас в мире создается все больше и больше приложений, в то время как количество людей, задействованных в разработке ПО, не успевает за ростом количества приложений и веб-сервисов. Это значит, что программистам просто необходимо становиться более продуктивными. Именно на это и нацелены online IDE проекты. Цель любого облачного IDE проекта — облегчить жизнь девелопера или команды разработчиков.

    В качестве итогов, приведу сводную таблицу-сравнение Cloud9 и Codenvy. Регистрируйтесь, пробуйте и высказывайтесь!

    image

    Only registered users can participate in poll. Log in, please.

    Облачные IDE

    Share post

    Similar posts

    Comments 41

      +2
      Есть еще Koding, правда он пока в бете, но выглядит неплохо. А вообще облачные IDE неплохи, хотя я по привычке юзаю офлайн-IDE, а проекты храню на гитхабе, чтоб отовсюду доступ иметь.
        0
        да, есть Koding, Orion, и другие… надеюсь появится время написать и про них
          0
          Cloud9 лагает как бета. Частая ситуация — файл правят два человека, но они друг друга не видят. Или опять же с файлом работают 2 человека, но неправильно мержится их вклад — тот, кто пришел позже, может случайно сохранением удалить уже сохраненных вклад первого.
          +3
          Мне кажется, что в выбор пунктов для голосования надо добавить «Будут сосуществовать с оффлайн IDE, заняв собственную нишу.»
            0
            спасибо, добавил )
            +2
            А почему в сравнении только языки веб-программирования и нет даже C и C++?
              0
              Ну ведь код на Си надо будет запускать у вас на машине что бы проверить его работу, и что его качать все время?
                0
                А в чем проблема запускать его на сервере?
                  0
                  Ну у него же может быть гуй, а как етот гуй показывать? р-декстоп?
                  Ну и ето ж апасна, давать запускать шото у себя на сервере чужому кодеру, наверна прийдется делать какие-то виртуалки.
                  Какая-то получается сложная инфраструктура с сомнительным профитом.
                    +3
                    Разумеется виртуалки. И gui не проблема.

                    Хотя, это сложно, конечно (мало ли, под что пишет). Но принципиальных проблем не вижу.
                      0
                      «Сложно» и «проблем не вижу» очень плохо уживаются в одном предложении.
                        +2
                        «проблем не вижу» и «принципиальных проблем не вижу» — разные фразы
                    –1
                    Сложно. С одной стороны, коду на сервере нужно организовать окружение, в котором он не сможет навредить серверу, т.е. окружение должно быть изолированным аж до сингулярности. Во-вторых, коду ж нужны какие-то библиотеки? Соответственно их придется грузить туда же. Но библиотекам тоже нужно свое окружение (особенно если они бинарники). А если не бинарники, то их придется там пересобирать.
                    Кроме того, в том окружении не будет того, с чем, возможно приложению нужно работать у вас: драйвера, оборудование, сервисы и т.д.
                    Ну и даже сам ввод-вывод неконсольного приложения через web реализуется весьма нетривиальным и достаточно дорогим способом.
                      +1
                      В чем проблема виртуалку поставить? Она решает все вопросы, которые вы затронули. Но сложно, да.
                        –1
                        Ресурсов сервера не напасешься — виртуалку на каждого пользователя запускать. Конечно, если пользователи будут платить 100 долларов за рабочее место в месяц, то можно и железа накупить, и софта соответствующего. А если подешевле, то дЕбет с крЕдитом не сходится.
                          0
                          Погодите, а в чем, собственно, проблема? Разве сейчас многие компании не так работают с вебом?
                          У нас под проекты часто выделяются отдельные виртуальные сервера.
                          <<пользователи будут платить 100 долларов за рабочее место в месяц
                          Откуда такое дикое число? И почему нельзя для фирмы один сервер использовать?
                            –1
                            Посмотрите, сколько всего всякого разного требуется для работы средненького бизнес-приложения. И все это нужно будет запихнуть «туда», добиться его устойчивой, предсказуемой работы, идентичной работе на реальном железе. Каковы будут аппаратные потребности этого приложения? А черт его знает.

                            Одно дело вебсерверочки, которые все под копирку и окно памяти им для работы требуется 16м.
                            А совсем другое дело, какой-нибудь настольный монстр, который хочет 512М памяти (и окружение неизвестно сколько хочет).

                            Число 100 взято с потолка.
                            Для фирмы нельзя использовать один сервер, т.к. нагрузку нельзя предсказать. Если будет пробный запуск одного экземпляра продукта — нужно 512мб. Если 10 тестеров будут тестрировать — 5Г.
                              0
                              Приложения разные бывают. Для некоторых web-приложений такое тоже не подойдет.
                          0
                          Я видел «онлайн-демонстрацию» одного бухгалтерского продукта. Выглядело это так:
                          Ты запускаешь браузер.
                          В браузере запускается JAVA-апплет клиента службы терминалов.
                          У них там Citrix'ом запускается под тебя новый сеанс, из дефаулт юзера. Создается «чистенькая» копия демонстрируемого продукта. И вот так вот работаешь.
                          Но там продукт был такой, что одна его продажа озолотит дистрибьюторов и окупит все затраты на ПО и софт для всего этого техночуда.
                  +9
                  Для бОльшей части разработчиков никакого плюса в них нет, а минусов уйма — невозможность работы в офлайне, более убогие средства
                    +5
                    Зато ж модно.
                      +1
                      Невозможность работы в оффлайне я бы пережил, как бы там ни было, количество вайфай хот-спотов растет и доступность интернета на некоторую единицу площади постепенно повышается. А вот удобство работы в веб-интерфейсе и общую функциональность облачных IDE еще есть куда улучшать.
                        0
                        Работать в офлайне с онлайн проектом будет не просто ))

                        Для меня ценность этого всего, не быть привязанным к конкретному рабочему месту.
                        0
                        Пока не будет толкового оффлайн режима — это все игрушки.
                          0
                          Но учитывая что большинство этих IDE рассчитано на веб разработку, наличия интернета мне кажется само собой разумеющимся. Даже я, занимаюсь, совсем не веб-разработкой с самым, что ни на есть оффлайновом редактором и компилятором, практически не представляю себе работы без интернета, так как документацию я обычно читаю онлайн, а гугль, StackOverflow, профессиональные форумы, рассылки и тому подобные ресурсы — неотъемлемая часть рабочего процесса (я даже не говорю про рабочую переписку и документацию в Google Docs).
                            0
                            Ну я согласен, что отсутствие сети — это крайний случай. Но зачастую в командировках нужно куда-то лететь (до НЮ, например, 8 часов). Тут без оффлайновой иде вообще никак — и к таким поездкам нужные доки качаются для оффлайна.
                              0
                              оффлайн режим в cloud IDE — одно из направлений, в котором ожидается развитие. Cloud9 вроде даже поддерживают оффлайн режим, но насколько он полноценный в плане юзабельности и полезности — вопрос.
                                0
                                Согласен, бывает нужно иногда. Но согласитесь, что работа в самолете — это относительно редкий сценарий, и не повод считать любой инструмент, который этого не умеет, «игрушкой».
                                  0
                                  Я предпочту настроить раз и навсегда оффлайновую IDE и пользоваться ей всегда, чем настроить две разных, заточенных под онлайн и оффлайн и мучиться с миграцией, когда прижмет.
                            0
                            > А вот идея иметь все средства разработки, а также сервисы для запуска, тестирования и развертывания приложений в облаке, весьма и весьма прельщает.

                            И много фирм согласятся отдать свой код посторонним? Хотя пусть это будет риторическим вопросом, а вот ответ на «какую ответственность несут данные IDE при потере данных?» хотелось бы услышать.
                              +2
                              Спросите это у компаний, которые хранят сорцы своих коммерческих проектов на GitHub
                                0
                                По-моему, мало таких компаний: обычно у себя хостят. Хотя интересно было бы посмотреть статистику.
                                  +1
                                  А по-моему, много — в Киеве, по крайней мере. Проект на Гитхабе, Багтреккер — в облаке, почта в Гугле, сервера в Амазоне, платежи в Пейпал, в качестве инструментов общения — скайп. Не вижу, чем такой сетап как-то принципиально отличается от того, чтобы иметь свои сервера. Да, дороже, но если бюджет позволяет, то почему нет?
                                0
                                Во времена DCVS о таких вещах как «потеря данных» еще кто-то задумывается разве?
                                Как минимум, по копии у каждого разработчика будет в случае чего.
                                  0
                                  Если есть локальная копия репозитория (с которой мы работаем), то зачем они вообще нужны?

                                  ЗЫ: случай выше habrahabr.ru/post/170085/#comment_5905581 довольно забавный и не решается никакими копиями.
                                    0
                                    Это я к тому, что потерянные данные это проблема самого пользователя. Наверняка не каждый будет хранить в облаке что-то важное, не имея при этом копии. К тому же, вышеперечисленные сервисы, как минимум git, поддерживают.
                                    Мне кажется, это нормально писать код в таком редакторе, но не забывать периодически пушить\пулить на другой бэкап хостинг (опять же, если это какой-то важный проект).
                              • UFO just landed and posted this here
                                  0
                                  Суть одно и то же

                                  47% — будут развиваться, но не составят конкуренции оффлайн средам разработки
                                  48% — будут сосуществовать с оффлайн IDE, заняв собственную нишу

                                  Поэтому и процент одинаковый.
                                    0
                                    HTML, Node.js, PHP, Python и Ruby…
                                    ...Java, Java Script, PHP, Python...

                                    ЯП Node.js, Java Script — WTF? Сам присматриваю себе cloudIDE под проект на Node.js, но это же не ЯП, это платформа. Автор, проведите себе ликбез по теме javascript. (И это явно вариант автора, на выше означенных сайтах написано всё корректно)
                                      0
                                      слабоват обзор. например, недавно видел обзор 13 cloud ide.
                                        0
                                        Ну так посту уже год стукнул.

                                      Only users with full accounts can post comments. Log in, please.