Заявление в стиле «зачем вам MS если есть Linux» или vice versa.
Для интеграции кроме упомянутых вами Camel и Spring есть еще куча проприетарных (MS, IBM, Oracle etc), опенсоурсных и промежуточных (типа MulrSoft) решений. Зачем они все казалось бы?
Дипломаты и институты ООН имеют особый статус. Так, северокорейцы и кубинцы имеют возможность выступать с трибуны ООН, а США обязана их впускать не смотря на все возможные санкции и даже состояние войны.
Короче говоря, есть поле международного законодательства и некоторые организации существуют исключительно в нем.
По всей видимости, порочна сама практика привязки свободной лицензий к законодательству одной страны.
Интересно, есть ли версия линкуса, поддерживаемая/распространяемая какой нибудь из структур ООН или Юнеско? Т.е. чтобы эта структура обладала иммунитетом от местного законодательства?
Вот очередная статья из серии «hello word» на котлин, которые регулярно появляются на хабре не первый год.
Когда уже можно будет почитать на хабре уже и что нибудь более серьезное? -Написать хелло ворд уже все успели.
Хотелось бы более критической, профессиональной и независимой оценки, что в котлине хорошо, что — не очень. Идеальных языков не бывает. А щенячий восторг статей намекает на недостаток опыта и профессионализма у авторов.
Вот как живет котлин в больших проектах, какие фремворки используются, библиотеки?
Общие утверждения типа «все как и в джава» бесполезны, т.к. во-первых для этого надо знать java, а во-вторых, там далеко не все так очевидно, как утверждают всякие «популяризаторы» котлина, весь опыт которых заключается в прочтении базовой документации по языку.
Дело не в том, как это назвать. Дело в том, что имеется две лицензии на продукт и один полноправный владелец заинтересованный в том, чтобы клиенты платили.
Нет, почему-же? Как раз таки Mule остается открытым в комьюнити эдишн.
Так же, старый вариант коннектора все еще открыт.
Вообщем, я не вижу причину, по которой владелец ПО не сможет в определенный момент сказать, что вот эта вот функциональность будет доступна только в платной версии и начнет отвергать коммиты с аналогичной функциональностью в публичную версию.
Ну и важнейшим моментом тут является именно мотивация. Понятно, что владелец заинтересован в том, чтобы пользователи переходили с бесплатной на платную версию.
И полный контроль над кодом дает ему в руки хороший рычаг для стимуляции пользователей двигаться в этом направлении. У мulesoft это напоминает выкручивание рук.
Столкнулись с двойным лицензированием на Mule. Это чистый ад и трэш. В один прекрасный момент mulesoft говорит: «а с версии такой-то, этот коннектор становится проприетарным». Усе.
Так что теперь, когда я слышу про двойное лицензирование, то жду подвоха.
На мой взгляд, часто достаточно изучить какой-то фреймворк или библиотеку, чтобы найти работу в АйТи. «Гениев», готовых освоить, то дофига. А когда проекту срочно нужен человек просто владеющий чем-то специфическим, то могут быть сложности с поиском и есть шанс получить работу без всякого другого опыта или высшего образования.
Я не уверен, что вы поняли о чем речь. Речь о JSON схеме. А она как раз позволяет описывать данные гораздо более точно. Скажем, для Int задавать граничные значения. Ну и конечно существуют библиотеки, чтобы генерить классы из схемы или и json.
А JSON схема чем плоха? Но дело даже не в этом. Я не понимаю мотивации в описании схемы БД в терминах протобуф IDL. Может есть какой-то годный фреймворк, позволющий удобно все эти описания переводить в DDL?
Ну так этот язык ведь заточен под конкретную цель — эффективно упаковывать-распаковывать данные.
При чем тут схемы, индексы? О таких сущностях протобуф не знает.
Они что, свои метаданные в протобуф пакуют?
Автор еще упоминает какие-то анотации. Что интересно под этим подразумевается?
И главное, зачем городить?
"Мы используем Protocol Buffers для схем данных (и правил изменения схем) чтобы держать все слои распределённой системы синхронизированными, включая мобильные приложения, веб-сервисы и хранилище данных. Мы аннотируем схемы деталями конфигурации, такими как имена талиц и индексов, правилами валидации записей, такими как максимальная длина строк или допустимые диапазоны значений чисел."
Не совсем представляю, а как это можно делать. Они схему БД на протобуфе пишут?
… и код покрывается красным. Причем, по причинам, далеко не всегда очевидным тем, кто начинает разбираеться с языком.
Вообще, есть хороший доклад на эту тему. Полностью согласен со всеми замечаниями Антона, а вот ответы из зала, мол все так и задумано, выглядят не всегда убедительно.
Но я бы добавил еще и отсутствие фреймворка.
В докладе говорится о том, что с котлином не заработал mockito и пришлось писать довесок, причем все равно криво.
Вообще, мне весело читать теоретические рассуждения на тему того, что Play нефик делать подружить с Kotlin. Пример работающего проектика можно?
Отличная новость! Расскажите пожалуйста, как использовать Play с Kotlin?
Судя по вашему комментарию, все проблемы там решаются за пару часов.
Ну и исходя и популярности фреймворка, уже все давно решено, не так ли?
С удовольствием почитаю подробную инструкцию по имплементации.
Ну и если вас не затруднит, примеры успешных проектов в такой связке.
Заранее спасибо.
Чей-то как-то так себе. Выбор между Spring и проектами с непонятной перспективой куда комитят пару человек для серьезного проекта и не выбор вовсе. Помнится давно были разговоры о Play. Теперь, я так понимаю, эта тема заглохла окончательно. Может тогда все же пора заняться серьезно вопросом фреймворка, а не упавать на авсь мол что-то такое само взрастет? Уже сколько лет ведь…
«И это был один из немногих моментов, когда мой принцип «программы надо писать хорошо» меня подвел.»
Меня этот принцип подводит постоянно. Когда то, что ты пишешь, работает сразу и надежно, у принимающей стороны создается впечатление, что это от простоты задачи и вообще, не слишком ли много тебе платят. При этом рядом «косячит» деятель, которого вообще в профессию нельзя пускать. Но поскольку там «все сложно», баги так и лезут и все критические, их героически надо править и постоянные доклады о «победах» идут на самый верх — то вот кто и есть главный герой, получатель ништяков, бонусов и благодарностей.
Поскольку я давно далеко за пределами Родины, то иллюзий насчет столиц и больших городов не испытываю. Работал и в самых больших мировых IT компаниях — и на три буквы которая, и на две, и в не таких больших — везде примерно так. Ну может в гугле по-другому…
Для интеграции кроме упомянутых вами Camel и Spring есть еще куча проприетарных (MS, IBM, Oracle etc), опенсоурсных и промежуточных (типа MulrSoft) решений. Зачем они все казалось бы?
Короче говоря, есть поле международного законодательства и некоторые организации существуют исключительно в нем.
Интересно, есть ли версия линкуса, поддерживаемая/распространяемая какой нибудь из структур ООН или Юнеско? Т.е. чтобы эта структура обладала иммунитетом от местного законодательства?
Когда уже можно будет почитать на хабре уже и что нибудь более серьезное? -Написать хелло ворд уже все успели.
Хотелось бы более критической, профессиональной и независимой оценки, что в котлине хорошо, что — не очень. Идеальных языков не бывает. А щенячий восторг статей намекает на недостаток опыта и профессионализма у авторов.
Вот как живет котлин в больших проектах, какие фремворки используются, библиотеки?
Общие утверждения типа «все как и в джава» бесполезны, т.к. во-первых для этого надо знать java, а во-вторых, там далеко не все так очевидно, как утверждают всякие «популяризаторы» котлина, весь опыт которых заключается в прочтении базовой документации по языку.
Так же, старый вариант коннектора все еще открыт.
Вообщем, я не вижу причину, по которой владелец ПО не сможет в определенный момент сказать, что вот эта вот функциональность будет доступна только в платной версии и начнет отвергать коммиты с аналогичной функциональностью в публичную версию.
Ну и важнейшим моментом тут является именно мотивация. Понятно, что владелец заинтересован в том, чтобы пользователи переходили с бесплатной на платную версию.
И полный контроль над кодом дает ему в руки хороший рычаг для стимуляции пользователей двигаться в этом направлении. У мulesoft это напоминает выкручивание рук.
Так что теперь, когда я слышу про двойное лицензирование, то жду подвоха.
При чем тут схемы, индексы? О таких сущностях протобуф не знает.
Они что, свои метаданные в протобуф пакуют?
Автор еще упоминает какие-то анотации. Что интересно под этим подразумевается?
И главное, зачем городить?
Не совсем представляю, а как это можно делать. Они схему БД на протобуфе пишут?
Вообще, есть хороший доклад на эту тему. Полностью согласен со всеми замечаниями Антона, а вот ответы из зала, мол все так и задумано, выглядят не всегда убедительно.
Но я бы добавил еще и отсутствие фреймворка.
В докладе говорится о том, что с котлином не заработал mockito и пришлось писать довесок, причем все равно криво.
Вообще, мне весело читать теоретические рассуждения на тему того, что Play нефик делать подружить с Kotlin. Пример работающего проектика можно?
Судя по вашему комментарию, все проблемы там решаются за пару часов.
Ну и исходя и популярности фреймворка, уже все давно решено, не так ли?
С удовольствием почитаю подробную инструкцию по имплементации.
Ну и если вас не затруднит, примеры успешных проектов в такой связке.
Заранее спасибо.
Меня этот принцип подводит постоянно. Когда то, что ты пишешь, работает сразу и надежно, у принимающей стороны создается впечатление, что это от простоты задачи и вообще, не слишком ли много тебе платят. При этом рядом «косячит» деятель, которого вообще в профессию нельзя пускать. Но поскольку там «все сложно», баги так и лезут и все критические, их героически надо править и постоянные доклады о «победах» идут на самый верх — то вот кто и есть главный герой, получатель ништяков, бонусов и благодарностей.
Поскольку я давно далеко за пределами Родины, то иллюзий насчет столиц и больших городов не испытываю. Работал и в самых больших мировых IT компаниях — и на три буквы которая, и на две, и в не таких больших — везде примерно так. Ну может в гугле по-другому…