Комментарии 94
Skrillex – не группа, а один человек. Проверяйте информацию.
Гилс знатно вбросил говна, эту статью бурно обсуждали на HN и дофига где еще. Впрочем, в чем-то он, наверное, прав. Как минимум порог вхождения в рельсы сильно повысился за последние годы.
Я это видел уже столько раз, что кажется могу вывести закон который в точности предскажет время, через которое отличный проект превращается в разжиревшего неповоротливого монстра, которого поедает более современный и быстрый конкурент.
(5 year — ( 1 year * team_of_developers ) — (0,1 day * community_size)) /
[if huge_corporation_involved true then 2 else 1]
Netscape — IE — Firefox — Crome — ?
Joomla — Drupal — Wordpress
ACDsee — Faststone — Bridge — ACDsee pro
(5 year — ( 1 year * team_of_developers ) — (0,1 day * community_size)) /
[if huge_corporation_involved true then 2 else 1]
Netscape — IE — Firefox — Crome — ?
Joomla — Drupal — Wordpress
ACDsee — Faststone — Bridge — ACDsee pro
Bowkett испытывает горячую приязнь к кофескрипту, однако я её не разделяю: CoffeeScript даёт резкое увеличение быстроты написания кода, зато опечатки в нём гораздо трудноуловимее. В обычном джаваскрипте я не могу облажаться, перепутав размер отступа; а если я потеряю фигурную скобку, то интерпретатор поймает меня за руку, зато не станет ничего за меня некорректно додумывать.
Вот насчёт будущего Node.js (которое выглядит получезарнее, чем будущее рельсов) он прав, кажется.
Вот насчёт будущего Node.js (которое выглядит получезарнее, чем будущее рельсов) он прав, кажется.
Просто CoffeeScript — это не панацея. Он исправляет проблемы JS, добавляя пачку собственных проблем. Зато теперь у каждого есть выбор, с какими из проблем ему проще мириться :)
Большинство проблем CoffeeScript возникают из-за отсутствие нормальных редакторов (хотя бы на уровне JS), но в этом плане со временем ситуация может улучшиться.
Большинство проблем CoffeeScript возникают из-за отсутствие нормальных редакторов (хотя бы на уровне JS), но в этом плане со временем ситуация может улучшиться.
А какие у JavaScript проблемы?
Видел я это видео, ничего нового нового не узнал. Для тех кто-то более или менее знаком с языком такие вещи не кажутся сюрпризами.
А сравнивать CoffeeScript и JavaScript по этому видео вообще не корректно, потому что +[] и там и там транзитивно нулю.
А сравнивать CoffeeScript и JavaScript по этому видео вообще не корректно, потому что +[] и там и там транзитивно нулю.
В тихоря минусонуть карму герои, обосновать хватит знаний?
Я не минусовал, но я скажу. Я не пишу на джаваскрипте, но могу (как правило) его читать и понимать. Я пишу на джаве. И вот я считаю, что то, что описано в этом видео _не_должно_быть_так_как_оно_есть_.
Это именно то, о чем сказал LaggyLuke — каждый сам решает, с чем ему приятнее мириться. Вы решили, что с этими багофичами вам мириться приятнее. Я пишу на джаве, и такие штуки меня убивают.
Это именно то, о чем сказал LaggyLuke — каждый сам решает, с чем ему приятнее мириться. Вы решили, что с этими багофичами вам мириться приятнее. Я пишу на джаве, и такие штуки меня убивают.
Это не «багофича», а неявное приведение типа из объектного к элементарному.
А происходит это из-за неявного вызова метода valueOf().
Такую ситуацию можно самому смоделировать:
Обо всем этом написано в спецификации, просто большинство людей считают что ее можно читать, мол язык простой и так все понятно, а что не понятно списывают на глюки языка.
А происходит это из-за неявного вызова метода valueOf().
Такую ситуацию можно самому смоделировать:
var object = {
a: 1,
b: 2,
valueOf: function () {
return this.a + this.b;
}
};
alert(+object) //3
Обо всем этом написано в спецификации, просто большинство людей считают что ее можно читать, мол язык простой и так все понятно, а что не понятно списывают на глюки языка.
Для тех, кто более-менее знаком с $ANY_LANGUAGE, ни одна из вещей, которые преподносятся как «проблемы», не кажется сюрпризом. И что? От этого проблемы не перестают быть проблемами.
По поводу редакторов для CoffeeScript, в корне не согласен.
Во всех продуктах jetBrains c недавних пор реализована полная поддержка, точно такая же как и для JavaScript. Причем полностью совместима с API Node.
Во всех продуктах jetBrains c недавних пор реализована полная поддержка, точно такая же как и для JavaScript. Причем полностью совместима с API Node.
Уф, кто-то таки написал эту статью. Наконец-то явно это все высказано.
«Коммьюнити Рельс превратилось во всё то, что само высмеивало.»
«Эта ссылка иронична, она ведёт на гигантскую страницу со списком вещей, которые нужно сделать, прежде чем можно начать писать своё приложение.»
И еще, конечно, говнеца в Rails сообщество добавил «синдром Раяна Бэйтса», когда народ тупо лепит в проект gems, не думая, нужен ли вообще gem для решения этой задачи, нужен ли именно этот новый gem из railscasts, а просто потому что «ну вышло в Railscasts — теперь модно это, юзаем»
«Коммьюнити Рельс превратилось во всё то, что само высмеивало.»
«Эта ссылка иронична, она ведёт на гигантскую страницу со списком вещей, которые нужно сделать, прежде чем можно начать писать своё приложение.»
И еще, конечно, говнеца в Rails сообщество добавил «синдром Раяна Бэйтса», когда народ тупо лепит в проект gems, не думая, нужен ли вообще gem для решения этой задачи, нужен ли именно этот новый gem из railscasts, а просто потому что «ну вышло в Railscasts — теперь модно это, юзаем»
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Блин, а писать bundle exec это такая проблема? Ну если так автору трудно… есть решение
Очень оригинальная статья. Ни в коей мере не согласен, что рельсы — мертвы. Это абсолютный бред. Но программистам следует внимательнее присмотреться на NodeJS, потому что некоторые задачи он сейчас решает лучше всего. Например, обработка WebSocket на NodeJS через socket.io работает очень здорово.
За фреймворками типа Backbone или GWT безусловно будет будущее интернет-разработки. Для конечного пользователя оно приятнее, но сейчас оно затратнее для бизнеса. Разрабатывать на них сейчас дольше и сложнее (это я говорю, как человек, которые написал на Backbone.js достаточно сложное приложение).
Я думаю, что появится какой-то фреймворк, который свяжет серверную и клиентскую сторону при помощи подхода, применяемого в Backbone. Возможно, что он будет как раз частью Ruby on Rails, а возможно он будет написан на NodeJS. Может быть это будет просто следующий этап развития Backbone или другого аналогичного фреймворка. Поживем — увидим.
За фреймворками типа Backbone или GWT безусловно будет будущее интернет-разработки. Для конечного пользователя оно приятнее, но сейчас оно затратнее для бизнеса. Разрабатывать на них сейчас дольше и сложнее (это я говорю, как человек, которые написал на Backbone.js достаточно сложное приложение).
Я думаю, что появится какой-то фреймворк, который свяжет серверную и клиентскую сторону при помощи подхода, применяемого в Backbone. Возможно, что он будет как раз частью Ruby on Rails, а возможно он будет написан на NodeJS. Может быть это будет просто следующий этап развития Backbone или другого аналогичного фреймворка. Поживем — увидим.
Я думаю, когда появится фреймворк, как минимум, предоставляющий единые модели для клиентской и серверной стороны (или хотя бы авто-генерацию для начала). А то сейчас уж очень неудобно получается c клиентскими js-фреймворками bd -> server-side model -> client-side model.
А CouchDB?
Что конкретно вы имеете в виду? Доступ к данным напрямую из клиентской части?
Практически да.
Ну так такое API выстраивается и над любой БД, будь она SQL или NoSQL или еще какое. Но все равно останутся задачи, которые перенести на клиентскую сторону нельзя. Самый первый и важный пример – валидация данных. И такого еще очень много – предварительная генерация отчетов, данных и т.д. и т.п.
Ну для валидации на клиент-сайде в рельсах есть такой гем А насчет нельзя перенести совсем… Может быть в будущем будут чаще использоваться штуки типа WebStorage с периодической синхронизацией с серверной БД, кто знает…
вебсервисы(soap, rest...) и их алгоритмы вам в помощь. Для тонких клиентов в том числе на js без «клиентской серверной прокладки» наверное идеально. В том числе нет и проблем с валидацией серверной+клиентской.
nowjs?
Рельсы не мертвы, они просто становятся большим, неповоротливым УГ с немалым порогом вхождения и кучей «нюансов»
Я тут недавно портировал 1.x проект на 3.x ветку и офигел как все быстро и просто. А добавили… Да ничего особо прям нужного не добавили…
Я тут недавно портировал 1.x проект на 3.x ветку и офигел как все быстро и просто. А добавили… Да ничего особо прям нужного не добавили…
Собственно время запуска меня и оттолкнуло от изучение рейлс. Думал это я такой слабак и не могу понять всех этих соглашений. Однако видимо не я один…
Уже пол года успешно учу ноду и вполне нравится. Есть удобные вещи из мира руби, но нет неповоротливости. Лично для меня.
Уже пол года успешно учу ноду и вполне нравится. Есть удобные вещи из мира руби, но нет неповоротливости. Лично для меня.
rvm install 1.9.3 --patch falcon
Стоить отметить, так же, что разрабатываю я на Windows
не знаю что на виндоус. Я собрал образ для virtualbox/vagrant и раздаю его ребятам, которые начинают программить. Для меня там все есть. Под виндой сам использую эту коробку, на маке все итак нормально работает.
С одним в этой статье я согласен — порог вхождения в рельсу сильно повысился. НО, это не делает рельсу технологией прошлого. И пока нода/экспресс не будут давать такого же разнообразия джемов и удобства создания вебприложений, как рельса, за нодой останется ниша вебсокетов и апи.
С одним в этой статье я согласен — порог вхождения в рельсу сильно повысился. НО, это не делает рельсу технологией прошлого. И пока нода/экспресс не будут давать такого же разнообразия джемов и удобства создания вебприложений, как рельса, за нодой останется ниша вебсокетов и апи.
В каком мире вы живете? Не забывайте про python с кучей пакетов, джангу ничем не уступающие ruby/rails, и реалйтайм на питоне — twisted, tornado(tornadio) а так-же есть в плане реальтайма сильные языки — Erlang и реализация сокетов на нем очень хороша — github.com/yrashk/socket.io-erlang а еще есть и отличный фреймворк для Erlang github.com/evanmiller/ChicagoBoss. Ты решаешь что же лучше нода или рельсы когда рельса еще ничем не доказала что она лучше питона или чего-то другого.
Я не забываю про питон, и про джангу и про твистед (кстати, на руби есть эвентмашина). И про эрланг я слышал. В свое время я перешел с джанги на рельсы. С тех пор не думал переходить обратно.
Вы поймите, если бы был «лучший» фреймворк, остальные бы просто умерли. А так — есть питон, есть руби, есть еще много языков, которые можно использовать для веба. У каких-то из них есть удобная инфраструктура. Есть еще набор фич, которые реализуются этой самой инфраструктурой.
Например, насколько я знаю, в джаге нет рельсового asset pipeline. Это единичный пример, наверняка он решается какими-нибудь скриптами/сторонними танцами с бубном, но в коробке его нет.
В большинстве случаев сейчас рельса больше подходит для создания среднестатистических приложений для веба. Если вы говорите про каттин эдж, то стек для такого приложения будет сборной солянкой. Если появится решение, которое сможет с удобством реализовать все это в «одном месте» — получит интерес сообщества. Нода пока таким решением не является.
Что будет через некоторое время — я не знаю. Знаю, что для меня сейчас рельса удобнее ноды в большинстве случаев. Поэтому я использую рельсу.
Вы поймите, если бы был «лучший» фреймворк, остальные бы просто умерли. А так — есть питон, есть руби, есть еще много языков, которые можно использовать для веба. У каких-то из них есть удобная инфраструктура. Есть еще набор фич, которые реализуются этой самой инфраструктурой.
Например, насколько я знаю, в джаге нет рельсового asset pipeline. Это единичный пример, наверняка он решается какими-нибудь скриптами/сторонними танцами с бубном, но в коробке его нет.
В большинстве случаев сейчас рельса больше подходит для создания среднестатистических приложений для веба. Если вы говорите про каттин эдж, то стек для такого приложения будет сборной солянкой. Если появится решение, которое сможет с удобством реализовать все это в «одном месте» — получит интерес сообщества. Нода пока таким решением не является.
Что будет через некоторое время — я не знаю. Знаю, что для меня сейчас рельса удобнее ноды в большинстве случаев. Поэтому я использую рельсу.
В джанго есть куча реализаций работы со статическими файлами например вплоть до использования картинок из директории и создания из них спрайтов и стилей, или склеивание всех скриптов или стилей, предварительно их скомпилив из coffeescript или less итд итп еще они умеют положить все в облако на амазоне например итд. Много всяких решений. Но зачем их в коробку пихать? Каждый использует то которое ему нравится. В коробке есть staticfiles который просто собирает статику из всех использованных пакетов, сжимает её если надо а больше от него ничего и не требуется.
> В большинстве случаев сейчас рельса больше подходит для создания среднестатистических приложений для веба.
Например? и почему? И еще почему питон так не умеет по вашему?
> В большинстве случаев сейчас рельса больше подходит для создания среднестатистических приложений для веба.
Например? и почему? И еще почему питон так не умеет по вашему?
Тут довольно доходчиво написали о таком барахле как asset pipeline — реализовать можно по-разному и нафига это в коробку пихать я не понимаю.
Точно такими же словами можно сказать про встроенную админку в джанго.
В Django тоже есть много лишнего я же не говорю что Django идеален. Я бы вообще выдернул GIS обратно в отдельное приложение. Мало кто его реально использует а занимает места он много. Но кичиться тем что есть в руби из коробки на фоне коммента по ссылке в комменте моем выше это как-то смешно.
Я просто не понял претензии конкретно к к assets pipeline. Хорошо что они есть из коробки, их много кто использует. Но если Вам они не нужны — нет ничего проще их отключить:
rails new myapp --skip-sprocketsАдминка в джанге вообще по умолчанию отключена при генерировании нового проекта и ее даже отключать не нужно))
>Например? и почему? И еще почему питон так не умеет по вашему?
сравниваю с нодой. Про питон вообще ничего не говорю.
Вы бы стали писать приложение на ноде вместо джанги? Я именно об этом. Я НЕ СРАВНИВАЮ ПИТОН И РУБИ. Идите ругайтесь в другой топик
сравниваю с нодой. Про питон вообще ничего не говорю.
Вы бы стали писать приложение на ноде вместо джанги? Я именно об этом. Я НЕ СРАВНИВАЮ ПИТОН И РУБИ. Идите ругайтесь в другой топик
>Я собрал образ для virtualbox/vagrant и раздаю его ребятам, которые начинают программить.
А можете поделиться? Тоже есть люди котроые только начинают изучать Ruby / Rails и готовый образ был бы кстати.
А можете поделиться? Тоже есть люди котроые только начинают изучать Ruby / Rails и готовый образ был бы кстати.
в этом и дело кстати, сам замучался и поставил в вмваре убунту — в виртуалке рельсы летают
RoR это модно и стильно :) А т.к. дабстеп я слушал до Skrillex, то продолжу использовать python.
Интересно где находиться php во всей этой кутерьме модно/немодно
Когда начинается спор о Django/Rails/NodeJS, php уже никто и не вспоминает =) Нет его.
спрятался за водопадом :-)
Слава богу я далек от этих споров… Пишу себе на старом добром пхп. Использую только те фичи которые мне действительно нужны. Надо мне минифай js и css сделать — нет проблем, скачал yui compressor, пару строк на баше и все. Надо ОРМ — скачал поставил. Ничего не надо — создал голый файл и пиши что дуще угодно. Не люблю когда фреймворки и технологии начинают диктовать и навязывать что и как делать
На мой взгляд, у каждого успешного инструмента есть две фазы:
1) Когда пачками добавляются новые фичи, и это всем весело… именно эту фазу педалирует автор статьи.
2) Когда инструмент используется для зарабатывания денег на коммерческих проектах. На этой фазе мало кому весело от появления новых фич, изменений в API и прочем. В этой фазе превалирует девиз «новые фичи — для новых проектов», а для существующих проектов должны быть очень весомые аргументы, чтобы затевать апгрейд. К примеру, в крупном проекте менять Jammit на Asset Pipeline и переписывать весь JavaScript на CoffeeScript практически никто не будет, т.к. во-первых это не несёт существенного профита, а во-вторых ни фига не весело…
В итоге кол-во существующих крупных проектов со временем достигает критического размера и те, кто раньше активно вводил новые фичи, становятся противниками дальнейших изменений. Грубо говоря, элитарная часть сообщества успокаивается, порог допуска к принятию решений повышается, а процедура введения новых фич максимально бюрократизируется. Это относится к любому ЯП, фреймворку и т.д.
P.S. Студентам, конечно, интереснее и полезнее возиться с проектами, у которых есть шашечки… Что не отменяет изучение и проверенных временем инструментов. Практикующим программистам сложнее находить время и желание для освоения каждого нового инструмента, поэтому и возникают разрывы и пропасти на последовательности принятия инноваций.
1) Когда пачками добавляются новые фичи, и это всем весело… именно эту фазу педалирует автор статьи.
2) Когда инструмент используется для зарабатывания денег на коммерческих проектах. На этой фазе мало кому весело от появления новых фич, изменений в API и прочем. В этой фазе превалирует девиз «новые фичи — для новых проектов», а для существующих проектов должны быть очень весомые аргументы, чтобы затевать апгрейд. К примеру, в крупном проекте менять Jammit на Asset Pipeline и переписывать весь JavaScript на CoffeeScript практически никто не будет, т.к. во-первых это не несёт существенного профита, а во-вторых ни фига не весело…
В итоге кол-во существующих крупных проектов со временем достигает критического размера и те, кто раньше активно вводил новые фичи, становятся противниками дальнейших изменений. Грубо говоря, элитарная часть сообщества успокаивается, порог допуска к принятию решений повышается, а процедура введения новых фич максимально бюрократизируется. Это относится к любому ЯП, фреймворку и т.д.
P.S. Студентам, конечно, интереснее и полезнее возиться с проектами, у которых есть шашечки… Что не отменяет изучение и проверенных временем инструментов. Практикующим программистам сложнее находить время и желание для освоения каждого нового инструмента, поэтому и возникают разрывы и пропасти на последовательности принятия инноваций.
Появилось зверское желание купить електруху и научиться играть Skrillex)))
Меня всегда умиляют сравнения фреймворка и языка.
Ну вроде сравнивали node.js и Rails…
Причем сравнение, конечно не совсем корректное — я бы не сказал что node.js хоть как-то революционно упрощает веб-разработку, как это сделал Rails в свое время, скорее он хорошо решает некий класс задач.
Но епрш, так стало мутнее это все конфигурить и настраивать…
Причем сравнение, конечно не совсем корректное — я бы не сказал что node.js хоть как-то революционно упрощает веб-разработку, как это сделал Rails в свое время, скорее он хорошо решает некий класс задач.
Но епрш, так стало мутнее это все конфигурить и настраивать…
Не особо знаком с рельсами, и не увлекаюсь нодом, но параллель с яйцами была проведена просто блестяще.
Статья интересная с точки зрения провокационности и скандальности.
Не имеет смысла сравнивать Ноду и Рельсы, потому что никогда ими не взаимозаменить друг друга.
Попробуйте написать интернетный магазин и Ноде и исплюётесь.
Рельсы — мамонт, который не нужен.
Это моё мнение.
Нода не заменит.
Нужно что-то другое, но нормальное.
Явовский стиль — вообще треш.
Не имеет смысла сравнивать Ноду и Рельсы, потому что никогда ими не взаимозаменить друг друга.
Попробуйте написать интернетный магазин и Ноде и исплюётесь.
Рельсы — мамонт, который не нужен.
Это моё мнение.
Нода не заменит.
Нужно что-то другое, но нормальное.
Явовский стиль — вообще треш.
ололо рельсы стали слишком сложными ололо буду писать на голых ноджс испытывать сырые баги на себе самом. ололо строчка source :rubygems мешает(а как без нее — вдруг надо её исключить и юзать другой сорс) и это мой главный аргумент.
а с do end вообще атас. они нужны когда хочется в декларативном стиле вызывать с блоком, юзать можно {}. удивлен что он не обругал class и def ведь можно было бы их называть %% и &&
в итоге имеем бугурт диванного кукаретика который не пробывал(точнее попробывал но сил не хватило) рельсы в Rails way стиле и за весь спор он так и не оспорил тот факт что рельсы самый удобный фреймворк для прототипирования и для разработки и ему не нужны транскомпайлеры(кофе) чтобы писать на нем и не плеваться.
модульность rails 3 лучше чем отсутствие модульности вообще. сейчас это сложный для новичка механизм но рельсы уже переросли этап когда надо удивлять 5и минутными блогами.
впрочим, тесты медленные — тут он прав.
а с do end вообще атас. они нужны когда хочется в декларативном стиле вызывать с блоком, юзать можно {}. удивлен что он не обругал class и def ведь можно было бы их называть %% и &&
в итоге имеем бугурт диванного кукаретика который не пробывал(точнее попробывал но сил не хватило) рельсы в Rails way стиле и за весь спор он так и не оспорил тот факт что рельсы самый удобный фреймворк для прототипирования и для разработки и ему не нужны транскомпайлеры(кофе) чтобы писать на нем и не плеваться.
модульность rails 3 лучше чем отсутствие модульности вообще. сейчас это сложный для новичка механизм но рельсы уже переросли этап когда надо удивлять 5и минутными блогами.
впрочим, тесты медленные — тут он прав.
> IBM Smalltalk — один из самых безвкусных корпоративных документов, который я видел в своей жизни; к тому же, хороший контр-аргумент крикам рубистов из культа под названием «Smalltalk был самой классной штукой на свете».
Документация из IBM — как недостаток языка? Парень явно шарит. (Впрочем, Smalltalk действительно не был самой классной штукой на свете, как и любой другой отдельно взятый язык)
> По многим вакансиям требуется знание Рельс, но вроде бы Нода планирует откусить приличный кусок пирога веб разработки в ближайшем будущем.
Человек думает что учить основываясь на лёгкости поиска работы, за еду, видимо. Зачем ему писать об этом статьи?
Это и постоянная реклама какого-то муз. ансамбля остановила меня от чтения дальше второго видео.
Документация из IBM — как недостаток языка? Парень явно шарит. (Впрочем, Smalltalk действительно не был самой классной штукой на свете, как и любой другой отдельно взятый язык)
> По многим вакансиям требуется знание Рельс, но вроде бы Нода планирует откусить приличный кусок пирога веб разработки в ближайшем будущем.
Человек думает что учить основываясь на лёгкости поиска работы, за еду, видимо. Зачем ему писать об этом статьи?
Это и постоянная реклама какого-то муз. ансамбля остановила меня от чтения дальше второго видео.
Пацаны, я придумал клёвое вебдванольное название: rubyroid (рубероид).
Понятия не имею, что это такое, но им можно было бы назвать какой-нибудь модный вебдванольный блог о руби.
Понятия не имею, что это такое, но им можно было бы назвать какой-нибудь модный вебдванольный блог о руби.
Давно таких статей не было.
На половине фраз — можно громко смеяться.
На вторую — забить.
НО посыл пойман. Думаем.
зы. Открыл для себя Skrillex ))
На половине фраз — можно громко смеяться.
На вторую — забить.
НО посыл пойман. Думаем.
зы. Открыл для себя Skrillex ))
Может кто-нибудь в двух словах объяснить, почему Рельсы больше не рулят и не педалят? Я статью честно прочитал, написано прикольно, но разумного зерна так и не увидел. Как были простыми и понятными, так и остались. И стартуют они адекватно быстро. И писать на них приятно. Зачем мне на ноду то перепрыгивать, почему работодателям я вскоре стану не нужен?
Когда-то у него брали интервью как у успешного рубиста :) habrahabr.ru/post/95197/
ага, я транслатил. а у тебя куда серия вся пропала кстати? ) Он болтун, глянул на его бложек gilesbowkett.blogspot.com/2010/03/programmers-what-to-do-if-you-get-fired.html
Да, собсно, никуда — допереводил и выложил на rubflow (http://rubyflow.ru/items/1051)… Просто здесь не выкладывал, думаю поезд уже прошел :)
Опа, там ссылки не рабочие уже… Лучше тут смотреть rezvanov.info/tags/7
Кстати, не сразу понял последний кусок кода, который ему Иегуда Катц прислал… Теперь я точно знаю, что команда bundle возращает корректные коды возврата :D
чувствую butheart за два любимых языка(
Giles Bowkett истеричка)))
А насчет Node — для веба то оно может еще приемлемо, но если нужно что-то посерьезнее, то тут уже Erlang рулит.
А насчет Node — для веба то оно может еще приемлемо, но если нужно что-то посерьезнее, то тут уже Erlang рулит.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Рельсы сошли с рельс: Почему я переписываю Archaeopteryx на CoffeeScript