Очень похожую проблему наблюдаю в NodeJS сообществе. Огромный плюс ноды, по моему мнение, в возможности писать как сложный код с применением кучи патернов так и супер простой минимальный код без единого класс на 3-4 функции. Тем не менее разработчики упорно тащат непонятно кому нужные паттерны и псевдо best practices из-за чего одна функция разрастается на добрый десяток классов.
Моя главная претензия к экосистеме ruby и RoR в сложившейся традиции mokey patching и неявного внедрения в чужие классы. Вот только на днях потратил кучу времени чтобы понять, что гемы rollify (для ролей) и geocode не дружат т.к. оба пытаются заинжектить в базовый класс метод adapter. Да, *иногда* иметь такую возможность круто, но когда это становится нормой то начинает мне напоминать спагети php код эпохи до фреймворков. Это не значит, что я в ближайшее время откажусь от RoR, он позволяет мне решать поставленные задачи быстро и конечный результат всех устраивает, да и спрос на рынке труда падать не собирается. Но проблема есть, и вылечить ее просто так не получится.
Идея в том, что аутентификация и проверка токена это не есть непосредственная задача микросервиса. Пускай этим занимается промежуточный сервис. Кроме того конкретному микросервису как правило нужно очень мало информации о клиенте, ID в принципе для большинства задач хватит, но не хочется это все в токене хранить, не всегда это нужно пользователю знать. и на каждый чих пых дергать auth сервис тоже не здорово.
Да, nginx в отдельном контейнере, попасть снаружи в контейнер с приложением невозможно просто потому что туда нет рутинга (порты приложения не экспортируются в хост машину).
Насчет асиметричного шифрования пожалуй соглашусь. А вот с утверждением "в этой схеме при компрометации любого компонента появляется возможность генерировать токены в любом количестве" смею поспорить. Для генерации токенов нужно скомпроментировать один из сервисов имеющих доступ к кэшу redis. Т.е. или auth или nginx.
Т.е. ни тебе USB-C никаких других иноваций? Ведь приняв закон они не буду менять его десятилетиями. Подобная стандартизация губительна в условиях бурно развивающихся технологий. Представьте себе что какая-нибудь «светлая» голова решила бы стандартизировать разъем десять лет назад, чтобы мы сейчас имели? Смартфон с зарядок через штекер и отдельный кабель для данных.
На самом деле идологически ruby и objective c достаточно близки. В обоих языках методы это все го лишь функции и вызов осуществляется отправкой сообщения, что позволяет в рантайме добавлять методы или даже подменять существующие.
Типов нет, это язык динамический этапа присвоения (т.е. тип прозрачно назначается в момент присвоения значения). Нельзя сказать что это плохо, это просто другой подход, дающий очень очень большую свободу но и несущий определнный риск.
Протоколов в самом руби нет, т.к. они просто не нужны. Вместо того чтобы говорит «дай мне объект реализующий такой то протокол», в руби всегда можно проверить «а вот эта балалайка поймет если я позову у нее метод :abc? нет? ну значит кинем exception».
В общем rubymotion позволяет писать приложение намного быстрее (особенно если вы хорошо знаете ruby) благодаря огромной гибкости языка и наличию большого количества библиотек, которые скрывают за собой сложности Cocoa в тех случая когда они не нужны.
в rubymotion можно использовать все то же, что и в cocoa touch, включая xib и storyboard (которые конечно придется рисовать в xcode), есть даже несколько гемов облегчающих жизнь с ними. но по моим ощущениям они особой популярностью не пользуются, может быть потому, что нет интеграции с редактором кода и связи IBOutlet приходится руками создавать.
Каждая моя попытка использовать Storyboard или XIB заканчивается тем что весь дизайн в нем все равно не настроишь и все равно приходится часть делать в коде, получаем на выходе кашу, часть значений настроена тут, часть тут. Для себя я остановился на ручной верстке с использование autolayout там где это оправдано и autosizing там где важен перформанс. Благо при разработке на rubymotion есть множество библиотек облегчающих именно такой подход и предоставляющих очень элегантные обертки.
Позвольте не согласиться. Офис влегкую вытянет эту фичу, т.к. для очень большого количества людей это самый главный и почти единственный рабочий инструмент.
А вы спеки сравните и сразу понятно станет. Там проц весьма устаревший, места кот наплакал. Смысл им оптимизировать ось под старое железо, идти на компромисы, при том что апгрейд ну совсем не дорогой выходит.
В принципе хвалят (я слышал, сам не пользовался) Dell XPS. Но стоит они столько же сколько macbook. А что с Thinkpad'ами стало? Вроде они страшненькие, но бодрые весьма.
Про CDMA я сильно в подробности не вдавался, т.к. совсем не актуально, но то что вы написали совпадает с моим понимаем. однако ж, автор поста специально указал на факт что только T-Mobile подойдет. хотелось бы знать причину.
очень поддерживаю. и даже не потому что я пойду покупать, а чтобы была конкуренция у apple серьезная. сейчас покупка ХОРОШЕГО виндового ноута выглядит примерно как археологические раскопки, которые сводятся к «а если вы не хотите во всем этом копаться, купите себе макбук».
Типов нет, это язык динамический этапа присвоения (т.е. тип прозрачно назначается в момент присвоения значения). Нельзя сказать что это плохо, это просто другой подход, дающий очень очень большую свободу но и несущий определнный риск.
Протоколов в самом руби нет, т.к. они просто не нужны. Вместо того чтобы говорит «дай мне объект реализующий такой то протокол», в руби всегда можно проверить «а вот эта балалайка поймет если я позову у нее метод :abc? нет? ну значит кинем exception».
В общем rubymotion позволяет писать приложение намного быстрее (особенно если вы хорошо знаете ruby) благодаря огромной гибкости языка и наличию большого количества библиотек, которые скрывают за собой сложности Cocoa в тех случая когда они не нужны.