либо я путаю, либо вы:) для меня всегда «мама» — это гнездо, «папа» — штекер (молчать господа гусары). Там стоит «мама» в моём понимании (принимающая часть), а «папа» воткнут в пишку
P.S. для GPIO я всё же использовал бы папу а не маму, тогда можно было бы втыкать незамисимые штырьки (а так надо обязательно подключать ещё один шлейф чтобы не погнуть пины)
Практически в каждом Groovy проекте используются трансформации. ToString, EqualsAndHashCode, Delegate, Category, Mixin и так далее. Всё это AST трансформации, если вы вдруг не знали.
1) MOP — это лишь одна из немногих фич языка, без которой спокойно живётся
2) AST transfomations — вчера появившаяся фича? Расскажите это всем поклонникам AOP например:)
3) опять же, это делалось мягко говоря не только ради дсл, точнее совсем не для них
4) инструмент был выбран под свою конкретную задачу и с ней он справляется на отлично:)
так что могу сделать вывод что вы тупо тролль:) А то, что тролль не умный — подтверждает ваша карма;)
Мы используем Groovy с @CompileStatic, это даёт высокую производительность, при этом фичи типа MOP и динамичного программирования мы итак не используем.
Как понятно из статьи, даже DSL у нас статичные (но при этом не лишены своей краткости, гибкости и красоты:))
1) Groovy тоже компилируемый
2) Groovy тоже мягко говоря имеет кучу продвинутых фреймворков
3) AIR для IDE убог чуть более чем полностью. Поясню:
3.1) Нет наработанной базы кода для таких вещей как у JVM.
3.2) Сам язык (а пишу я на AS уже давно и много:)) очень слабый для таких вещей, отсутствие Generic-ов, типизированных лямбд, enum-ов, грамотных коллекций и ещё кучи всего
3.3) Работать будет очень медленно при таком объёме кода
3.4) Весь IO в AIR реализован на несколько порядков хуже JVM
4) по поводу Scala. Groovy — это better Java, можно писать старый добрый Java код, и периодически начинать использовать фишки Groovy. В Scala тебя сразу же с ходу заставляют писать монстра на непривычном синтаксисе. AFAIK в Scala такая конструкция не пройдёт (поправьте если я не прав):
onAction: { t ->
ProjectDialogs.newAsProjectDialog(scene, false)
} as EventHandler<ActionEvent>
установка Chef на сервере осуществляется через Opscode Installer, у которого есть проблемы с установкой некоторых gem-пакетов (эта проблема решается указанием своего скрипта установки).
А по поводу второго предложения — я не говорю, что Puppet лучше и у него есть то, чего нет у Chef-а, просто он мне удобней и в итоге сделал выбор в именно сторону Puppet-а. Ну и среди знакомых больше кукловодов, чем шефов:)
Имхо переход с однострочника на многострочный код это не личное поражение, а победа команды людей в которой закрался такой вот любитель писать что-то вроде этого:)
А в итоге всё равно получился Android-планшет
</сарказм>
P.S. см. батарейку
2) AST transfomations — вчера появившаяся фича? Расскажите это всем поклонникам AOP например:)
3) опять же, это делалось мягко говоря не только ради дсл, точнее совсем не для них
4) инструмент был выбран под свою конкретную задачу и с ней он справляется на отлично:)
так что могу сделать вывод что вы тупо тролль:) А то, что тролль не умный — подтверждает ваша карма;)
Как понятно из статьи, даже DSL у нас статичные (но при этом не лишены своей краткости, гибкости и красоты:))
А как вы решали проблему репликации кеша БД на бизнеслогике? EHCache?
2) Groovy тоже мягко говоря имеет кучу продвинутых фреймворков
3) AIR для IDE убог чуть более чем полностью. Поясню:
3.1) Нет наработанной базы кода для таких вещей как у JVM.
3.2) Сам язык (а пишу я на AS уже давно и много:)) очень слабый для таких вещей, отсутствие Generic-ов, типизированных лямбд, enum-ов, грамотных коллекций и ещё кучи всего
3.3) Работать будет очень медленно при таком объёме кода
3.4) Весь IO в AIR реализован на несколько порядков хуже JVM
4) по поводу Scala. Groovy — это better Java, можно писать старый добрый Java код, и периодически начинать использовать фишки Groovy. В Scala тебя сразу же с ходу заставляют писать монстра на непривычном синтаксисе. AFAIK в Scala такая конструкция не пройдёт (поправьте если я не прав):
А по поводу второго предложения — я не говорю, что Puppet лучше и у него есть то, чего нет у Chef-а, просто он мне удобней и в итоге сделал выбор в именно сторону Puppet-а. Ну и среди знакомых больше кукловодов, чем шефов:)
И, что самое главное, не требует написания каких-то .sh скриптов и не имеет проблем с установкой.
Ума не приложу как я это запомнил, но думаю поможет таким же как и я, кто не помнит комбинации в OS X для скриншотов:)
P.S. думаю вот эта ссылка лучше покажет все его преимущества: owner.aeonbits.org/docs/usage/
Ведущий аналитик Mobile Research Groupавторитетный Flash-разработчик пропал с Хабра то?Имхо переход с однострочника на многострочный код это не личное поражение, а победа команды людей в которой закрался такой вот любитель писать что-то вроде этого:)