Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 56
У меня есть страх, что ВЕСЬ мой код в таком случае передается третьим лицам(Хозяевам облака). А так, в принципе это удобно.
Как покодить в самолете?
И не только, брательник как раз месяц назад в командировку в Китай летал, и решил в Google Docs все нужные документы сохранить, типа ж модно, всё в облаке, доступно по всему миру. В итоге ждал его жесткий облом, ввиду недоступности Google и его сервисов в Китае.
Так, что имхо, облачные IDE — баловство.
Так, что имхо, облачные IDE — баловство.
дык и гуглдоки третьим лицам доступны. гуглу вообще много чего доступно, и что, теперь не пользоваться гмейлом?
Через годик другой так и будет, а пока это все тормозно для реальной работы, не все готовы мириться со скоростью работы локально запущенных Eclipse/Idea/Netbeans написанных на java, что уж говорить об облачных решениях схожего уровня.
Это ничего. По мере тупения общества скорость восприятия будет уравниваться со скоростью воспроизведения и пользователя будет устраивать любой тормозизм.
Точно так же, как раньше пользователи легко осваивали сложные, насыщенные разнообразными элементами управления интерфейсы и радовались многообразию возможностей. Сейчас же большинство пользователей в таких интерфейсах теряются и больше склонны доверять интерфейсам в двумя далеко стоящими друг от друга полупрозрачными рельефными карамельными голубенькими кнопочками: «Пыщ» и «Не пыщ».
А такое вполне можно реализовать и в вэбе.
Если раньше сабмит формы, продолжительностью более 1 секунды уже успевал взволновать пользователя: «ох, неужели сервер затупил при обработке запроса? Успел он внести данные, или не успел?», то сейчас даже внезапно вырубившийся компьютер не обеспокоит пользователя вопросом, а сохранилось ли то огроменное письмо, что он последние 2 часа двумя пальцами набирал в окне браузера?
Точно так же, как раньше пользователи легко осваивали сложные, насыщенные разнообразными элементами управления интерфейсы и радовались многообразию возможностей. Сейчас же большинство пользователей в таких интерфейсах теряются и больше склонны доверять интерфейсам в двумя далеко стоящими друг от друга полупрозрачными рельефными карамельными голубенькими кнопочками: «Пыщ» и «Не пыщ».
А такое вполне можно реализовать и в вэбе.
Если раньше сабмит формы, продолжительностью более 1 секунды уже успевал взволновать пользователя: «ох, неужели сервер затупил при обработке запроса? Успел он внести данные, или не успел?», то сейчас даже внезапно вырубившийся компьютер не обеспокоит пользователя вопросом, а сохранилось ли то огроменное письмо, что он последние 2 часа двумя пальцами набирал в окне браузера?
Бесплатный Eclipse против заведомо платного облака?
Наиболее отталкивает от онлайн IDE излишняя монетизация — ограничение на количество проектов или требований опен-сорса для бесплатного использования.
Плюс не забывайте, что скорость работы с плохим интернетом несоизмеримо ниже.
Поэтому сейчас cloud IDE скорее одна из альтернатив, чем полноценная замена.
Плюс не забывайте, что скорость работы с плохим интернетом несоизмеримо ниже.
Поэтому сейчас cloud IDE скорее одна из альтернатив, чем полноценная замена.
Не решён вопрос с дебагером.
Ясно, что Windows (Android, iOS) приложение в облаке только на эмуляторе можно запустить, что сильно неудобно.
Даже с веб-приложениями непонятно, как дебажить серверную часть.
Кроме кода самого приложения, нужно дать облаку доступ ко всем базам данных (тестовых баз часто недостаточно, чтобы разобраться в каком-нибудь сложном глюке, повторяемом только в рабочей базе). Кроме баз данных сложные корпоративные приложения могут обращаться к внутренним веб-сервисам (1с, сторонние решения и т.п.), к контроллеру домена и почтовому серверу. В принципе, если сделать всё в одном облаке от одного проавйдера, это решаемо: все идём на Microsoft Azure, например. В Azure — SQL-сервера, почта, контроллеры доменов и до кучи пусть и IDE там будет. Но не слишком ли мы начинаем зависеть от одной конторы?
Ясно, что Windows (Android, iOS) приложение в облаке только на эмуляторе можно запустить, что сильно неудобно.
Даже с веб-приложениями непонятно, как дебажить серверную часть.
Кроме кода самого приложения, нужно дать облаку доступ ко всем базам данных (тестовых баз часто недостаточно, чтобы разобраться в каком-нибудь сложном глюке, повторяемом только в рабочей базе). Кроме баз данных сложные корпоративные приложения могут обращаться к внутренним веб-сервисам (1с, сторонние решения и т.п.), к контроллеру домена и почтовому серверу. В принципе, если сделать всё в одном облаке от одного проавйдера, это решаемо: все идём на Microsoft Azure, например. В Azure — SQL-сервера, почта, контроллеры доменов и до кучи пусть и IDE там будет. Но не слишком ли мы начинаем зависеть от одной конторы?
Подумалось… Если мы переносим в облако железо и операционные системы (вместе с прилагаемыми к ним админами), а также базы данных и приложения, то логично к двум последним переносить и программистов.
Будущее — не IDE в облаке, а облачные программисты, которые работают так, как им удобнее. Заказчику должно быть безразлично, какие у них IDE.
Будущее — не IDE в облаке, а облачные программисты, которые работают так, как им удобнее. Заказчику должно быть безразлично, какие у них IDE.
Cloud IDE поставит огромный жирный, невероятно суровый вопрос о стабильности и сохранности.
В эпоху git'а заботиться о высокой надёжности центрального репозитория не нужно — всегда есть несколько десятков копий кода на локальных машинах. Которые
а) Имеют разные корни администрирования (имеется в виду, нет единого root'а на все машины)
б) Физически изолированы и разнесены
в) Некоторая их часть не имеет открытого интерфейса администрирования (ssh)
г) Запущены на различных ОС
И всё это предлагается похерить и тщательно вложить яйца в одну яйцезакручивающую корзинку.
А смысл?
В эпоху git'а заботиться о высокой надёжности центрального репозитория не нужно — всегда есть несколько десятков копий кода на локальных машинах. Которые
а) Имеют разные корни администрирования (имеется в виду, нет единого root'а на все машины)
б) Физически изолированы и разнесены
в) Некоторая их часть не имеет открытого интерфейса администрирования (ssh)
г) Запущены на различных ОС
И всё это предлагается похерить и тщательно вложить яйца в одну яйцезакручивающую корзинку.
А смысл?
Чтобы онлайн-IDE потеснили настольные версии, необходимо, чтобы они предоставляли лучшие по сравнению с настольными продуктами условия работы — функциональность, быстродействие и т.д. Пока же, как мне кажется, основной их плюс — то, что клауд это модно. А с таким подходом сложно добиться успеха.
В облака можно успешно выносить программное обеспечение общего назначения, то есть то, чем пользуется много людей и что подразумевает относительно простые сценарии использования. Например, офисный редактор в облаке — это хорошо, потому что он позволяет открывать рабочие договора и таблицы и кое-как их редактировать из любого места. Очень многие пользуются текстовыми документами и таблицами, и доступ к ним может быть нужен из разных мест, в разное время и с разными целями. Если хранить их в облаке и в любой момент иметь к ним доступ со всего мира и с любого пылесоса — это хорошо, нужно и самое главное востребованно.
В отличие от обычных текстов и таблиц, программный код как правило пишут профессионалы (опустим здесь скрипты на три строчки, для которых не нужна IDE). Соответственно, требования к инструментарию для написания кода должны быть не как к софту общего назначения, а как к софту для профессионалов. Примерами подобного софта кроме IDE могут быть например CAD'ы и профессиональные графические редакторы (Photoshop/Illustrator/Corel и т.д.). Для программного обеспечения этого класса более важны другие характеристики, например функциональность и быстродействие. В то время как софту общего назначения нужен максимально простой интуитивный интерфейс, пусть иногда и в ущерб функциональности, интерфейсы профессионального ПО могут подразумевать более высокий порог входа, но в итоге способствовать более высокой производительности.
Контент, который создается в профессиональных программах, как правило сам по себе не предназначен для потребления. Скорее, в этих программах создаются промежуточный контент, используемый далее для создания потребительского контента. Это опять же подразумевает различные сценарии использования. Например, если я пишу в Гугл Докс книгу о том, как захватить власть над миром и не обратить на себя внимание санитаров, то результат моего труда — это уже готовый к употреблению массами продукт. Я даю на текст ссылку, и эту ссылку может открыть другой человек любой профессии, имеющий только базовые представления об Интернете. Он может прочитать мой текст и (если я разрешаю) внести в него правки с минимальными затратами прямо в том же редакторе. А в облачной IDE я не смогу создать законченный потребительский продукт напрямую. Я могу написать код программы, но пользователю нужен не код. Ему нужна сама программа, доступная после компиляции или интерпретации. Он не будет открывать IDE, чтобы получить пользу от моего труда. А мой программный код интересен только другим программистам, да и то как правило только тем, которые работают со мной в команде.
То есть, промежуточные продукты, создаваемые при помощи профессионального софта используются не так, как законченные продукты, создаваемые софтом общего назначения. Над сложными программами, макетами или чертежами нужно долго работать, причем этот процесс интересен только ограниченному кругу создателей этих конкретных продуктов. Соответственно, как правило этот процесс не спонтанен, работа идет постепенно, в офисе, с 9 до 6. И изменения как правило вносятся кем-то из команды. А для внесения изменений человеком со стороны требуется определенное время на понимание текущего состояния продукта. Если для исправления опечатки в википедии мне обычно достаточно знать русский язык и не нужно понимать контекста статьи, то для внесения изменений в чужой код мне мало того, что нужно сначала зачем-то этот код найти и открыть, затем найти проблему и потом еще убедиться, что я все правильно понял и ничего не испортил. То есть, это не минутное дело.
Соответственно, для работы с продуктами, создаваемыми при помощи профессионального ПО, облачные версии редакторов как мне кажется не особенно и нужны, поскольку не предоставляют добавленной ценности по сравнению с настольными программами. А вот плюсы настольного ПО по сравнению с облачным на текущем этапе очевидны. Если же облачные программы сравняются по качеству с настольными, то их облачное размещение может быть и будет плюсом, но небольшим. Да и нескоро это произойдет.
В облака можно успешно выносить программное обеспечение общего назначения, то есть то, чем пользуется много людей и что подразумевает относительно простые сценарии использования. Например, офисный редактор в облаке — это хорошо, потому что он позволяет открывать рабочие договора и таблицы и кое-как их редактировать из любого места. Очень многие пользуются текстовыми документами и таблицами, и доступ к ним может быть нужен из разных мест, в разное время и с разными целями. Если хранить их в облаке и в любой момент иметь к ним доступ со всего мира и с любого пылесоса — это хорошо, нужно и самое главное востребованно.
В отличие от обычных текстов и таблиц, программный код как правило пишут профессионалы (опустим здесь скрипты на три строчки, для которых не нужна IDE). Соответственно, требования к инструментарию для написания кода должны быть не как к софту общего назначения, а как к софту для профессионалов. Примерами подобного софта кроме IDE могут быть например CAD'ы и профессиональные графические редакторы (Photoshop/Illustrator/Corel и т.д.). Для программного обеспечения этого класса более важны другие характеристики, например функциональность и быстродействие. В то время как софту общего назначения нужен максимально простой интуитивный интерфейс, пусть иногда и в ущерб функциональности, интерфейсы профессионального ПО могут подразумевать более высокий порог входа, но в итоге способствовать более высокой производительности.
Контент, который создается в профессиональных программах, как правило сам по себе не предназначен для потребления. Скорее, в этих программах создаются промежуточный контент, используемый далее для создания потребительского контента. Это опять же подразумевает различные сценарии использования. Например, если я пишу в Гугл Докс книгу о том, как захватить власть над миром и не обратить на себя внимание санитаров, то результат моего труда — это уже готовый к употреблению массами продукт. Я даю на текст ссылку, и эту ссылку может открыть другой человек любой профессии, имеющий только базовые представления об Интернете. Он может прочитать мой текст и (если я разрешаю) внести в него правки с минимальными затратами прямо в том же редакторе. А в облачной IDE я не смогу создать законченный потребительский продукт напрямую. Я могу написать код программы, но пользователю нужен не код. Ему нужна сама программа, доступная после компиляции или интерпретации. Он не будет открывать IDE, чтобы получить пользу от моего труда. А мой программный код интересен только другим программистам, да и то как правило только тем, которые работают со мной в команде.
То есть, промежуточные продукты, создаваемые при помощи профессионального софта используются не так, как законченные продукты, создаваемые софтом общего назначения. Над сложными программами, макетами или чертежами нужно долго работать, причем этот процесс интересен только ограниченному кругу создателей этих конкретных продуктов. Соответственно, как правило этот процесс не спонтанен, работа идет постепенно, в офисе, с 9 до 6. И изменения как правило вносятся кем-то из команды. А для внесения изменений человеком со стороны требуется определенное время на понимание текущего состояния продукта. Если для исправления опечатки в википедии мне обычно достаточно знать русский язык и не нужно понимать контекста статьи, то для внесения изменений в чужой код мне мало того, что нужно сначала зачем-то этот код найти и открыть, затем найти проблему и потом еще убедиться, что я все правильно понял и ничего не испортил. То есть, это не минутное дело.
Соответственно, для работы с продуктами, создаваемыми при помощи профессионального ПО, облачные версии редакторов как мне кажется не особенно и нужны, поскольку не предоставляют добавленной ценности по сравнению с настольными программами. А вот плюсы настольного ПО по сравнению с облачным на текущем этапе очевидны. Если же облачные программы сравняются по качеству с настольными, то их облачное размещение может быть и будет плюсом, но небольшим. Да и нескоро это произойдет.
Преимущества облачных IDE становятся очевидными, если поработать над хромом. Компиляция в облаке на много быстрее компиляции на локальном компьютере. Обновление проекта занимает существенное время, которое могло бы быть сведено к нулю, если исходники хранились бы в облаке. Запуск тестов — опять облако ибо браузер нужно проверить на множестве разных версий разных операционных систем да и работа тестов занимает часы (к сожалению, даже с учетом облачности). Поиск кода в облаке в десятки раз быстрее, чем поиск на локальном винчестере. Любое изменение настроек проекта в Eclipse — и нужно ждать переиндексации хрома несколько часов, чтобы увидеть нормальную подсветку ошибок. В облаке это могло бы занимать минуты (Eclipse здесь тоже виноват, но реализации параллельной индексации от его разработчиков не дождешься).
Если появится облачная IDE, которая объединит все это в одном месте, то никто из разработчиков хрома не будет оглядываться назад.
Если появится облачная IDE, которая объединит все это в одном месте, то никто из разработчиков хрома не будет оглядываться назад.
пока что это определённо игрушки.
Предполагаю, что разработчикам онлайн-IDE просто в кайф разрабатывать такую «клёвую штуковину, которой ещё не было».
О реальном использовании этого класса программ даже говорить рано.
Попользуют сначала фанатики-энтузиасты, поймут, что в этих начинаниях хорошо, а что плохо. Разработчики (кто поумнее) прислушаются к ним, перепишут несколько новых версий.
Предпервые пользователи (фактически альфа-тестеры) оценят, в каких случаях использование онлайн-IDE оправдано, а менеджеры (кто поумнее) прислушаются и правильно спозиционируют свою продукцию.
Google Docs ведь нашёл своих пользователей, значит и онлайн-IDE найдут.
Предполагаю, что разработчикам онлайн-IDE просто в кайф разрабатывать такую «клёвую штуковину, которой ещё не было».
О реальном использовании этого класса программ даже говорить рано.
Попользуют сначала фанатики-энтузиасты, поймут, что в этих начинаниях хорошо, а что плохо. Разработчики (кто поумнее) прислушаются к ним, перепишут несколько новых версий.
Предпервые пользователи (фактически альфа-тестеры) оценят, в каких случаях использование онлайн-IDE оправдано, а менеджеры (кто поумнее) прислушаются и правильно спозиционируют свою продукцию.
Google Docs ведь нашёл своих пользователей, значит и онлайн-IDE найдут.
«И если большинство вменяемых пользователей благополучно забыли о вордовских документах в сообщениях электронной почты, давно и навсегда перейдя на Google Docs»
Позвольте уцепиться за вот эту ваше высказывание. Я уверен, что вы написали это на полном серьезе, даже не задумываясь, на автомате, потому что вы верите в вами же сказанное.
Я всегда придерживался противоположного мнения. И мне всегда приходилось объяснять «вменяемым пользователям» с какого цвета и температуры огнем они на самом деле играют. Но век же 21, общие рассуждения никто не слушает, перейдем сразу к конкретным примерам.
Однажды группа молодых людей, увлекающихся общественной деятельностью, собрали в одном месте с три десятка человек, чтобы сделать доклад, сопровождающийся презентацией. Собрали, ясное дело, в общественном месте, т.к. дома столько гостей не примешь.
Как всякие прогрессивные молодые люди, без колебаний отправляющие на свалку истории всякие технические атавизмы,
презентация их была сохранена в гуглдоках.
И был у них экран. И был у них проектор. И было у них на троих четыре ноутбука. И было в том общественном месте целых две файфай точки. Но почему-то именно в этот момент на полчаса пропал доступ к интернет. В итоге тщательно спланированное и подготовленное мероприятие модно-стильно-молодежно накрылось медным тазом.
По-моему отличный пример-аргумент в пользу утверждения о том, что в онлайн должно выноситься только то, что без вынесения в онлайн впринципе не может работать, или теряет значительную часть функций и возможностей.
Аргумент номер два: после предпоследнего обновления моего любимого браузера, он начал довольно часто вылетать (а после последнего — перестал). Т.е. во время вылетания браузера, мне и не попрограммировать что ли было?
Если все в системе делается «через одно место» (в данном случае браузер), то этот компонент становится критическим ресурсом, нарушения в работе которого ломают нам всю жизнь.
Я полностью согласен с вашим знакомым девелопером с 15-летним стажем, потому что он понимает, о чем говорит он и о чем говорите вы. Вы же не понимаете ни того ни другого. Вы слишком устали от критики и слишком увлечены поиском позитива.
Позвольте уцепиться за вот эту ваше высказывание. Я уверен, что вы написали это на полном серьезе, даже не задумываясь, на автомате, потому что вы верите в вами же сказанное.
Я всегда придерживался противоположного мнения. И мне всегда приходилось объяснять «вменяемым пользователям» с какого цвета и температуры огнем они на самом деле играют. Но век же 21, общие рассуждения никто не слушает, перейдем сразу к конкретным примерам.
Однажды группа молодых людей, увлекающихся общественной деятельностью, собрали в одном месте с три десятка человек, чтобы сделать доклад, сопровождающийся презентацией. Собрали, ясное дело, в общественном месте, т.к. дома столько гостей не примешь.
Как всякие прогрессивные молодые люди, без колебаний отправляющие на свалку истории всякие технические атавизмы,
презентация их была сохранена в гуглдоках.
И был у них экран. И был у них проектор. И было у них на троих четыре ноутбука. И было в том общественном месте целых две файфай точки. Но почему-то именно в этот момент на полчаса пропал доступ к интернет. В итоге тщательно спланированное и подготовленное мероприятие модно-стильно-молодежно накрылось медным тазом.
По-моему отличный пример-аргумент в пользу утверждения о том, что в онлайн должно выноситься только то, что без вынесения в онлайн впринципе не может работать, или теряет значительную часть функций и возможностей.
Аргумент номер два: после предпоследнего обновления моего любимого браузера, он начал довольно часто вылетать (а после последнего — перестал). Т.е. во время вылетания браузера, мне и не попрограммировать что ли было?
Если все в системе делается «через одно место» (в данном случае браузер), то этот компонент становится критическим ресурсом, нарушения в работе которого ломают нам всю жизнь.
Я полностью согласен с вашим знакомым девелопером с 15-летним стажем, потому что он понимает, о чем говорит он и о чем говорите вы. Вы же не понимаете ни того ни другого. Вы слишком устали от критики и слишком увлечены поиском позитива.
перегибы любые плохи.
Про ребят, которые сохранили презентацию в гуглдоках, а потом не смогли её показать, неправы в основном в том, что вместо мозга использовали актуальные тренды. Во-первых, гуглдоки могут работать оффлайново, но для этого надо было заранее сделать пару движений. Во-вторых, если пропал местный вайфай, то можно было воспользоваться собственным айфоном для коннекта. Какой пользователь интернета не знает, что коннект имеет обыкновение теряться в самый ответственный момент? Можно же было такое предусмотреть.
Тут не гугл с его доксами виноват, и не местный провайдер. В другой раз у этих же ребят таким образом будет виноват майкрософт с его кривой виндой, падающей от вирусов (а не они сами, когда согласились на просьбу инсталлятора скачанного на порноресурсе псевдокодека выключить антивирус), ну или яббл с его несовместимым с остальным миром оборудованием (а не пользователь, понадеявшийся на то, что в кукуевском сельском клубе найдётся переходник thunderbolt->vga на время презентации).
Разбираться же надо в своём инструменте, учиться его использовать правильно.
Про ребят, которые сохранили презентацию в гуглдоках, а потом не смогли её показать, неправы в основном в том, что вместо мозга использовали актуальные тренды. Во-первых, гуглдоки могут работать оффлайново, но для этого надо было заранее сделать пару движений. Во-вторых, если пропал местный вайфай, то можно было воспользоваться собственным айфоном для коннекта. Какой пользователь интернета не знает, что коннект имеет обыкновение теряться в самый ответственный момент? Можно же было такое предусмотреть.
Тут не гугл с его доксами виноват, и не местный провайдер. В другой раз у этих же ребят таким образом будет виноват майкрософт с его кривой виндой, падающей от вирусов (а не они сами, когда согласились на просьбу инсталлятора скачанного на порноресурсе псевдокодека выключить антивирус), ну или яббл с его несовместимым с остальным миром оборудованием (а не пользователь, понадеявшийся на то, что в кукуевском сельском клубе найдётся переходник thunderbolt->vga на время презентации).
Разбираться же надо в своём инструменте, учиться его использовать правильно.
Кстати, да, эти онлайн ОС как-то очень незаметно все загнулись. Волна схлынуло и их унесло.
да потому что ОС — это не рабочий стол.
ОС — это прослойка между железом и приложениями.
И как-то так потихонечку, незаметно и ненавязчиво эту роль на себя берёт хром.
Вспоминаю, какой эпопеей ещё лет пять назад оборачивалась покупка нового компьютера или установка ОС.
А на днях покупаю себе нетбук, и вся эта эпопея уложилась по сути в одну строчку: sudo apt-get install google-chrome-stable.
И всё. Логинюсь — и все часто используемые приложения на месте. И большую часть времени хром в полноэкранном режиме, и никаких других программ не запущено.
Это ли не онлайн-ОС? Только жизнеспособная, а не все те имитаторы рабочих столов на javascript.
ОС — это прослойка между железом и приложениями.
И как-то так потихонечку, незаметно и ненавязчиво эту роль на себя берёт хром.
Вспоминаю, какой эпопеей ещё лет пять назад оборачивалась покупка нового компьютера или установка ОС.
А на днях покупаю себе нетбук, и вся эта эпопея уложилась по сути в одну строчку: sudo apt-get install google-chrome-stable.
И всё. Логинюсь — и все часто используемые приложения на месте. И большую часть времени хром в полноэкранном режиме, и никаких других программ не запущено.
Это ли не онлайн-ОС? Только жизнеспособная, а не все те имитаторы рабочих столов на javascript.
Этот разговор напомнил мне попытки девушки прокатиться на авто с ручной коробкой. «Не оно», — сразу сказала девушка. «Почему? Совсем не беспокоишься об экономии бензина или любишь, когда нет контроля над двигателем?» — спросил я. «Не-а! Я не привыкла дергать ручку».
Лично я для себя понял (C# разработчик), что онлайн IDE очень удобны, когда нужно быстро проверить как работает тот или иной код, при этом не создавая мусора у себя на машине.
мне как веб-разработчику сразу приходит на ум jsfiddle :)
А, ну что касается JavaScript, то понятно.
Но меня удивило, что такие инструменты есть и для других языков (compileonline.com например).
Но меня удивило, что такие инструменты есть и для других языков (compileonline.com например).
Делать просто IDE в облаке нет большого смысла, причины уже указали выше. Нужно делать полный комплекс для разработки, включая Issue Tracker, CI server, автоматизацию развертывания, организацию работы команды (что-то вроде PivotalTracker, например), ну и т.д.
Возможно, jetbrains когда-нибудь и займутся этим, у них многие компоненты присутствуют.
Возможно, jetbrains когда-нибудь и займутся этим, у них многие компоненты присутствуют.
Всё это и так уже вынесено в веб. Причем возможности именно облаков, то есть в первую очередь эластичность, с натяжкой нужны только серверу Continuous Integration. Приложения, решающие перечисленные вами задачи уже сейчас могут спокойно хоститься как в облаках, так и на обычных купленных или арендованных серверах. Зачем писать новый полный программный комплекс, если тот же стек Atlassian (Jira+Convolution+Bamboo) решает все задачи, полностью интегрирован друг с другом и вашей IDE?
Confluence, разумеется, а не Convolution.
Возможно и так, я лишь указал, что
насчет полноты интеграции с IDE как-то сомнительно, но я их продуктами не пользовался, так что ничего не могу сказать. В любом случае, не думаю, что наличие альтернатив что-то испортит.
Делать просто IDE в облаке нет большого смысла
насчет полноты интеграции с IDE как-то сомнительно, но я их продуктами не пользовался, так что ничего не могу сказать. В любом случае, не думаю, что наличие альтернатив что-то испортит.
Интересное развитие получилось. Вот что оказалось на почте у меня. Много букв и на инглише. Но, все по пунктам и подробно.
Hello, Community. This thread is from Tyler Jewell, who is leading the business related to Exo IDE. I have been reviewing the comments (at least as well as Google translate will allow for), and wanted to offer some additional perspective on the perceived value of such a solution.
We recognize that we are taking an incredible risk by building a cloud-based IDE, but have found that there are a couple of key pain points that cloud-based systems can address that are difficult to address with desktop-based IDEs. Below is a list of areas that we've heard from various developers as to the benefits, and why they are evaluating some offerings. I'd really like to continue the dialogue — and hope to get an invitation so that I can have write privileges directly here. Otherwise, you can reach me directly at tyler@codenvy.com.
We believe the biggest benefits come from productivity, compliance, and distribution.
These use cases aren't needed for everyone, but there are many developers who do experience these pains, and this is why I believe we are getting some decent traction.
PRODUCTIVITY
We are focused on exploiting use cases where cloud-based development improves the productivity of users. These are the use cases that seem to be most evident.
1) Incremental, differential build and deploy. We are working on algorithms where we use cloud's resources to continuous compile intermediate files while they are being edited. We will also do incremental deployments. We hope to achieve a model where many edits are compiled & deployed before the developer has requested the action.
2) We can do parallel builds, and break down some functions to take advantage of multi-core CPUs available to us on-demand. This offsets some drain off of a developer's laptop.
3) Onboarding is faster. For use cases related to evaluating new technologies, creating new projects, or viewing someone else's project, it's possible to create a tenant, load a sample project, compile it, and deploy it into a test VM quickly. The primary benefit is to eliminate some downloaded IDE failure rates. If you wanted to do a simple «Hello World» on GAE with Eclipse, it can take some developers 4 hours to download the IDE, get it configured, configure their GAE account, configure the plug-in, get the sample code, and make the build system work correctly. In a pure cloud world, we can dramatically reduce the time to configure all of these items, which gets developers who are in a trial-mindset to a moment of understanding quicker. We are working hand in hand with many PAAS vendors to do this sort of automatic onboarding. Also, this onboarding concept can apply to other project resources such as test, CI, project management — there is value in being able to create project spaces quickly. Finally, the project setup for a team can be improved. For an organization, with a team of multiple developers, there is a time cost associated with duplicating an environmental configuration across every computer. VDI helps some with this, but it is still a replication. In a cloud environment, the project can be configured once and then many people can be invited simultaneously.
4) Easier Sharing of code. Higher degrees of code sharing, leads to higher volume of sharing. And this means it is easier to get adoption of libraries.
5) Avoid SDK downloads. We have had some government clients who need to use SDKs that they cannot download at work. Having the cloud IDE download & configure these components automatically allows some people to continue working behind firewalls that would normally prevent such downloads.
6) Eliminate IDE boot time. Many developers do not have powerful machines yet. So the resources that the IDE consumes and the time it takes to boot can be significant. In the cloud, we can have project spaces always active so that people can instantly reconnect to their last stage at any time.
7) Shared resources. A single team, or tenant can have multiple projects being worked on, and they can share their editor, build, and test VM resources across those projects. The cloud IDE can handle the switching of these components.
COMPLIANCE
8) This is a corporate benefit. Some companies are having IP drift issues, where they cannot have code copied onto their developer's laptops. A private cloud version of this technology allows them to hvae centralized visibility on all code.
9) Some organizations want or need to push administrative controls of the desktop to their administrators.
DISTRIBUTION
10) These are benefits for ISVs. Project spaces can be represented as URLs. In fact, we have a CodeNow concept that allows a new tenant to be created on-demand with a single URL. This URL contains the IDE configuration and project that should be loaded, built, and deployed. This single URL concept is useful for ISVs who want to enable on-demand buildable projects. This is good for evaluation, support organizations, and pre-sales.
11) We can enable a better Eclipse plug-in ecosystem. Eclipse has 4000 plug-ins and that can be daunting for people to sort thorugh. Also, Eclipse doesn't help those companies make money for their efforts on creating the component. We think (and hope) that is a market for creating developer-plug ins, and monetizing them similar to the way that Heroku has done for production plug-ins.
Of course there is more work we have to do. And we are far from proving that this is a significant market. But we do see some interesting benefits here and are going to keep moving forward. We look forward to discussing further.
Tyler Jewell
CEO, Exo IDE (http://cloud-ide.com/)
Tyler Jewell
CEO
Codenvy, S.A.
c: 978-884-5355
Hello, Community. This thread is from Tyler Jewell, who is leading the business related to Exo IDE. I have been reviewing the comments (at least as well as Google translate will allow for), and wanted to offer some additional perspective on the perceived value of such a solution.
We recognize that we are taking an incredible risk by building a cloud-based IDE, but have found that there are a couple of key pain points that cloud-based systems can address that are difficult to address with desktop-based IDEs. Below is a list of areas that we've heard from various developers as to the benefits, and why they are evaluating some offerings. I'd really like to continue the dialogue — and hope to get an invitation so that I can have write privileges directly here. Otherwise, you can reach me directly at tyler@codenvy.com.
We believe the biggest benefits come from productivity, compliance, and distribution.
These use cases aren't needed for everyone, but there are many developers who do experience these pains, and this is why I believe we are getting some decent traction.
PRODUCTIVITY
We are focused on exploiting use cases where cloud-based development improves the productivity of users. These are the use cases that seem to be most evident.
1) Incremental, differential build and deploy. We are working on algorithms where we use cloud's resources to continuous compile intermediate files while they are being edited. We will also do incremental deployments. We hope to achieve a model where many edits are compiled & deployed before the developer has requested the action.
2) We can do parallel builds, and break down some functions to take advantage of multi-core CPUs available to us on-demand. This offsets some drain off of a developer's laptop.
3) Onboarding is faster. For use cases related to evaluating new technologies, creating new projects, or viewing someone else's project, it's possible to create a tenant, load a sample project, compile it, and deploy it into a test VM quickly. The primary benefit is to eliminate some downloaded IDE failure rates. If you wanted to do a simple «Hello World» on GAE with Eclipse, it can take some developers 4 hours to download the IDE, get it configured, configure their GAE account, configure the plug-in, get the sample code, and make the build system work correctly. In a pure cloud world, we can dramatically reduce the time to configure all of these items, which gets developers who are in a trial-mindset to a moment of understanding quicker. We are working hand in hand with many PAAS vendors to do this sort of automatic onboarding. Also, this onboarding concept can apply to other project resources such as test, CI, project management — there is value in being able to create project spaces quickly. Finally, the project setup for a team can be improved. For an organization, with a team of multiple developers, there is a time cost associated with duplicating an environmental configuration across every computer. VDI helps some with this, but it is still a replication. In a cloud environment, the project can be configured once and then many people can be invited simultaneously.
4) Easier Sharing of code. Higher degrees of code sharing, leads to higher volume of sharing. And this means it is easier to get adoption of libraries.
5) Avoid SDK downloads. We have had some government clients who need to use SDKs that they cannot download at work. Having the cloud IDE download & configure these components automatically allows some people to continue working behind firewalls that would normally prevent such downloads.
6) Eliminate IDE boot time. Many developers do not have powerful machines yet. So the resources that the IDE consumes and the time it takes to boot can be significant. In the cloud, we can have project spaces always active so that people can instantly reconnect to their last stage at any time.
7) Shared resources. A single team, or tenant can have multiple projects being worked on, and they can share their editor, build, and test VM resources across those projects. The cloud IDE can handle the switching of these components.
COMPLIANCE
8) This is a corporate benefit. Some companies are having IP drift issues, where they cannot have code copied onto their developer's laptops. A private cloud version of this technology allows them to hvae centralized visibility on all code.
9) Some organizations want or need to push administrative controls of the desktop to their administrators.
DISTRIBUTION
10) These are benefits for ISVs. Project spaces can be represented as URLs. In fact, we have a CodeNow concept that allows a new tenant to be created on-demand with a single URL. This URL contains the IDE configuration and project that should be loaded, built, and deployed. This single URL concept is useful for ISVs who want to enable on-demand buildable projects. This is good for evaluation, support organizations, and pre-sales.
11) We can enable a better Eclipse plug-in ecosystem. Eclipse has 4000 plug-ins and that can be daunting for people to sort thorugh. Also, Eclipse doesn't help those companies make money for their efforts on creating the component. We think (and hope) that is a market for creating developer-plug ins, and monetizing them similar to the way that Heroku has done for production plug-ins.
Of course there is more work we have to do. And we are far from proving that this is a significant market. But we do see some interesting benefits here and are going to keep moving forward. We look forward to discussing further.
Tyler Jewell
CEO, Exo IDE (http://cloud-ide.com/)
Tyler Jewell
CEO
Codenvy, S.A.
c: 978-884-5355
Благодаря этому сообщению, я начинаю понимать, каким организациям интересны облачные IDE.
Прежде всего тем, кто не доверяет своим разработчикам. Облако может препятствовать скачиванию исходных кодов проекта, может препятствовать использованию несанкционированных библиотек (чтобы в проект не попал GPL-код), в облаке легко следить, сколько времени каждый сотрудник потратил на работу в IDE.
Прежде всего тем, кто не доверяет своим разработчикам. Облако может препятствовать скачиванию исходных кодов проекта, может препятствовать использованию несанкционированных библиотек (чтобы в проект не попал GPL-код), в облаке легко следить, сколько времени каждый сотрудник потратил на работу в IDE.
«Не доверяет своим разработчикам» звучит плохо. А вот «не доверяет чужим разработчикам» звучит куда лучше. В мире, где всё и вся на аутсорсе, держать свой проект «при себе» — важное уменьшение рисков.
О каких рисках речь?
1. Потеря исходного кода. Так храните всё в git-репозитории и настройте ежечасную репликацию из основного репозитория на backup-сервер, к которому доступ только у одного админа.
2. Утечка исходников. А вы своих разработчиков не пустите в систему контроля версий? В лучших практиках наоборот все диффы каждого коммита летят на почту каждому девелоперу, и нередки случаи, когда посмотрев незамыленным глазом кто-то говорит товарищу: «на&*я такой велосипед, если я месяц назад сделал удобные функции для этой цели, давай переписывай этот страшный кусок на 1 строчку» или «Б&%ть, Вася ты опять закоммитил включение подробного логгирования всех операций с объектами. Подебажил — верни обратно, а то продукт тормозить будет». Даже если отбросить agile-практики и запретить полноценный доступ к VCS, кто будет решать конфликты коммитов разных разработчиков? Генеральный директор, что-ли )))
В-общем, невозможность получить полное дерево исходников проекта сильно ограничивает творческие возможности. Разработчика ставят в положение: копай от забора до обеда. А если что не так, он скажет: «я не знай, чо там глючить, я не виновать, я дальше своего носа не вижу». Потому что бывает нужно перепахать весь проект в своей локальной копии, чтобы дорыться до бага. Подключить исходники всех фреймворков (NHibernate + DB Provider, например), подебажить всё это в куче и тогда только будет понятен workaround.
1. Потеря исходного кода. Так храните всё в git-репозитории и настройте ежечасную репликацию из основного репозитория на backup-сервер, к которому доступ только у одного админа.
2. Утечка исходников. А вы своих разработчиков не пустите в систему контроля версий? В лучших практиках наоборот все диффы каждого коммита летят на почту каждому девелоперу, и нередки случаи, когда посмотрев незамыленным глазом кто-то говорит товарищу: «на&*я такой велосипед, если я месяц назад сделал удобные функции для этой цели, давай переписывай этот страшный кусок на 1 строчку» или «Б&%ть, Вася ты опять закоммитил включение подробного логгирования всех операций с объектами. Подебажил — верни обратно, а то продукт тормозить будет». Даже если отбросить agile-практики и запретить полноценный доступ к VCS, кто будет решать конфликты коммитов разных разработчиков? Генеральный директор, что-ли )))
В-общем, невозможность получить полное дерево исходников проекта сильно ограничивает творческие возможности. Разработчика ставят в положение: копай от забора до обеда. А если что не так, он скажет: «я не знай, чо там глючить, я не виновать, я дальше своего носа не вижу». Потому что бывает нужно перепахать весь проект в своей локальной копии, чтобы дорыться до бага. Подключить исходники всех фреймворков (NHibernate + DB Provider, например), подебажить всё это в куче и тогда только будет понятен workaround.
Позволю себе кратенько перевести:
1. Инкрементальные дифференциальные билды. Вы ещё кодите, а облако уже компилирует. При этом «вы» — это целая команда может быть.
2. Билды на мощных облачных серверах — быстрее, чем на вашем лаптопе.
3. Быстрый старт — не нужно 4 часа качать, деплоить и конфигурировать IDE, чтобы попробовать простой hello world. Всё готово сразу — и для разработчиков, и для ПМов, и для QA.
4. Легче делиться кодом.
5. Не нужно качать SDK.
6. Не нужно загружать IDE.
7. Легче делиться ресурсами. Даже целыми виртуальными машинами.
8. Безопасность. Не нужно хранить код на стороне разработчика.
9. Контроль над кодом.
10. Легко раздавать — можно сгенерить новое место разработчика по прямому линку. Клик — и ты в проекте.
11. Улучшенная экосистема плагинов к Eclipse. 4000 уже установленных и ждущих подключения плагинов, маркет плагинов, обсуждение, комментарии, карма плагинов, сливы, ресеты, pay to win.
1. Инкрементальные дифференциальные билды. Вы ещё кодите, а облако уже компилирует. При этом «вы» — это целая команда может быть.
2. Билды на мощных облачных серверах — быстрее, чем на вашем лаптопе.
3. Быстрый старт — не нужно 4 часа качать, деплоить и конфигурировать IDE, чтобы попробовать простой hello world. Всё готово сразу — и для разработчиков, и для ПМов, и для QA.
4. Легче делиться кодом.
5. Не нужно качать SDK.
6. Не нужно загружать IDE.
7. Легче делиться ресурсами. Даже целыми виртуальными машинами.
8. Безопасность. Не нужно хранить код на стороне разработчика.
9. Контроль над кодом.
10. Легко раздавать — можно сгенерить новое место разработчика по прямому линку. Клик — и ты в проекте.
11. Улучшенная экосистема плагинов к Eclipse. 4000 уже установленных и ждущих подключения плагинов, маркет плагинов, обсуждение, комментарии, карма плагинов, сливы, ресеты, pay to win.
Ну преимущества облачных IDE для разработчиков миниатюрных короткоживущих безответственных свистоперделок (см. «Курсовая работа») очевидны.
А что дает облачная IDE нормальным программистам и группам разработчиков такого, чего не дает необлачная?
А что дает облачная IDE нормальным программистам и группам разработчиков такого, чего не дает необлачная?
1. «Вы ещё кодите, а облако уже компилирует». Компилировать во время кодирования можно и локально, благо код пишется явно медленнее. А вот писать неудобно. У меня куча хоткеев в IDE, которые бы сожрал браузер (F1-F12, Ctrl+буквы). Облачной IDE остаются Shift- и Alt-модификаторы. Случайные нажатия браузерных хоткеев (например, Alt-F4) приведут к непредвиденным результатам
2. «Билды на мощных облачных серверах» — билды на CI-серверах уже везде используются, перенести в облако элементарно, никакой облачной IDE для этого не нужно.
3,4,5,6,7,10,11 — как написано выше, актуально для проектов типа сайт-визитка. Если проект ведётся два года, настройкой IDE новому разработчику можно пренебречь в общих затратах
8,9 — не убедили, отписал выше.
2. «Билды на мощных облачных серверах» — билды на CI-серверах уже везде используются, перенести в облако элементарно, никакой облачной IDE для этого не нужно.
3,4,5,6,7,10,11 — как написано выше, актуально для проектов типа сайт-визитка. Если проект ведётся два года, настройкой IDE новому разработчику можно пренебречь в общих затратах
8,9 — не убедили, отписал выше.
4. Легче делиться кодом
Вряд ли облачная IDE избавит от необходимости ведения репов. А если всё равно используется что-то вроде git, то как может быть легче делиться кодом? То на то и выходит.
5. Не нужно качать SDK.
Как же меня бесит скорость работы этой онлайновой документации! Вроде и на канал не жалуюсь, а всё равно от нажатия кнопки до прогрузки страницы MSDN ждать нужно 2-3 сек. минимум, хотя во времена Pentium MMX и win32sdk.hlp справка открывалась одновременно с кликом, без задержек вообще.
6. Не нужно загружать IDE
Нужно, просто грузится оно не целиком и в фоне. Тот же Google Docs требует прилично времени во время начальной загрузки. Почему-то OpenOffice стартует с SSD быстрее, чем открывается в браузере GD-документ.
8. Безопасность. Не нужно хранить код на стороне разработчика
Зато нужно хранить на стороне облачного провайдера. Повышается ли при этом безопасность? Сомнительно, особенно если учесть, что репы точно с тем же эффектом можно хранить на удалённом сервере или даже в том же облаке.
11. Улучшенная экосистема плагинов к Eclipse. 4000 уже установленных и ждущих подключения плагинов, маркет плагинов, обсуждение, комментарии, карма плагинов, сливы, ресеты, pay to win.
Вот лучше бы те ресурсы, которые сейчас тратят на создание «облачного Эклипса», пустили на улучшение экосистемы плагинов. Пользы было бы больше.
Но, вообще говоря, облака будут наступать и дальше. Тут чисто экономические эффекты сработают. Как только выяснится, что организация, поддержка и ведение «облачного» проекта обходится в 3-4 раза дешевле, чем проекта оффлайнового, то разработчики очень-очень быстро забудут про все недостатки облаков…
>1. Инкрементальные дифференциальные билды. Вы ещё кодите, а облако уже компилирует. При этом «вы» — это целая команда может быть.
При засилии скриптовых языков не слишком актуально. Даже если язык компилируемый — то скорее всего уже есть билд-сервер, который уже делает ровно то же самое.
>2. Билды на мощных облачных серверах — быстрее, чем на вашем лаптопе.
См. выше.
>3. Быстрый старт — не нужно 4 часа качать, деплоить и конфигурировать IDE, чтобы попробовать простой hello world. Всё готово сразу — и для разработчиков, и для ПМов, и для QA.
Нормально настроенная (за 4 часа) IDE работает месяцами, если не годами. 4 часа — это доли процента, за это у вас отберут моментальный отклик и полный контроль окружения. Ну если стоит задача быстро писать hello world'ы, тогда конечно. Интересно — а сколько на быстром написании hello world можно заработать?
>4. Легче делиться кодом.
Для этого придуманы и успешно используются VCS.
>5. Не нужно качать SDK.
Выигрывам те же доли процента, только вместо 4 часов — десятки минут.
>6. Не нужно загружать IDE.
А в браузере облачная IDE конечно сразу полностью с момента старта загружено.
> 7. Легче делиться ресурсами. Даже целыми виртуальными машинами.
Не вижу проблем делиться ими сейчас, безо всяких облаков.
>8. Безопасность. Не нужно хранить код на стороне разработчика.
А в чем проблема хранить код на стороне разработчика? Если уж мы подумываем о том, чтобы доверить свой код компании с непонятным TOS?
А как вам такая картинка — релиз нужно выпускать еще вчера, в приёмной уже юрист заказчика с исковым заявлением, код не хранится на стороне разработчика, а облако третий день как лежит? Да, такое бывает, даже у Amazon.
>9. Контроль над кодом.
Когда код у меня локально — я его контролирую лучше всего. В самолёте, в поезде, В Китае…
>10. Легко раздавать — можно сгенерить новое место разработчика по прямому линку. Клик — и ты в проекте.
Снова экономим доли процентов. Минимальное время, за который новый разработчик будет въезжать в более-менее сложный проект, займёт на порядки больше времени, чем разворачивание рабочего окружения.
>11. Улучшенная экосистема плагинов к Eclipse. 4000 уже установленных и ждущих подключения плагинов, маркет плагинов, обсуждение, комментарии, карма плагинов, сливы, ресеты, pay to win.
И все, теперь толко Eclipse? А если я его ненавижу и использую продукты JetBrains или вообще vim?
При засилии скриптовых языков не слишком актуально. Даже если язык компилируемый — то скорее всего уже есть билд-сервер, который уже делает ровно то же самое.
>2. Билды на мощных облачных серверах — быстрее, чем на вашем лаптопе.
См. выше.
>3. Быстрый старт — не нужно 4 часа качать, деплоить и конфигурировать IDE, чтобы попробовать простой hello world. Всё готово сразу — и для разработчиков, и для ПМов, и для QA.
Нормально настроенная (за 4 часа) IDE работает месяцами, если не годами. 4 часа — это доли процента, за это у вас отберут моментальный отклик и полный контроль окружения. Ну если стоит задача быстро писать hello world'ы, тогда конечно. Интересно — а сколько на быстром написании hello world можно заработать?
>4. Легче делиться кодом.
Для этого придуманы и успешно используются VCS.
>5. Не нужно качать SDK.
Выигрывам те же доли процента, только вместо 4 часов — десятки минут.
>6. Не нужно загружать IDE.
А в браузере облачная IDE конечно сразу полностью с момента старта загружено.
> 7. Легче делиться ресурсами. Даже целыми виртуальными машинами.
Не вижу проблем делиться ими сейчас, безо всяких облаков.
>8. Безопасность. Не нужно хранить код на стороне разработчика.
А в чем проблема хранить код на стороне разработчика? Если уж мы подумываем о том, чтобы доверить свой код компании с непонятным TOS?
А как вам такая картинка — релиз нужно выпускать еще вчера, в приёмной уже юрист заказчика с исковым заявлением, код не хранится на стороне разработчика, а облако третий день как лежит? Да, такое бывает, даже у Amazon.
>9. Контроль над кодом.
Когда код у меня локально — я его контролирую лучше всего. В самолёте, в поезде, В Китае…
>10. Легко раздавать — можно сгенерить новое место разработчика по прямому линку. Клик — и ты в проекте.
Снова экономим доли процентов. Минимальное время, за который новый разработчик будет въезжать в более-менее сложный проект, займёт на порядки больше времени, чем разворачивание рабочего окружения.
>11. Улучшенная экосистема плагинов к Eclipse. 4000 уже установленных и ждущих подключения плагинов, маркет плагинов, обсуждение, комментарии, карма плагинов, сливы, ресеты, pay to win.
И все, теперь толко Eclipse? А если я его ненавижу и использую продукты JetBrains или вообще vim?
Думаю, облачные IDE имеют право на жизнь, но вряд ли будут особо популярны до того как станут популярными облачные ОС, в которых можно будет полностью развернуть всё окружение разработки. Ведь мало кто, по-моему, пользуется только IDE при разработке, обычно используются и другие инструменты, начиная от узкоспециализованных самописных и заканчивая всей мощью консоли. Пока же то, что я видел полноценного окружения разработки мне создать не может, предлагая свои инструменты а, главное, сценарии использования.
В целом, я уверен, что за cloud IDE будущее, но пока быстрый интернет не стал таким же распространенным как и электричество, решение должно быть гибридным, поддерживающим оффлайн-работу и последующую синхронизацию наработанного, вроде дропбокса или гитхаба.
Да распространен быстрый интернет даже более, чем электричество. Например беспроводного электричества нет, а беспроводной интернет есть.
Но у интернета аптайм ниже, чем у электроснабжения. И если электричество можно запасти, то «запас интернета» иметь невозможно.
Но у интернета аптайм ниже, чем у электроснабжения. И если электричество можно запасти, то «запас интернета» иметь невозможно.
Ваш скептический настрой мне понятен, поэтому я воздержусь от пустой дискуссии по этому и другим комментариям.
Например беспроводного электричества нет
Наверное после этого комментария появились беспроводные зарядные устройства )
Наверное после этого комментария появились беспроводные зарядные устройства )
Дальность «беспроводного электричества» о котором вы говорите, составляющая максимум несколько сантиметров, фактически лишает смысла называть его беспроводным. Не смотря на то, что у меня дома есть «беспроводная зарядка», я не могу заряжать телефон (или иное устройство) в любой точке квартиры. А по-настоящему беспроводным интернетом пользоваться в любой точке квартиры могу.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Онлайн IDE — дань облачной моде или неизбежность среды разработки?