Мне кажется, что "умные дома" страдают не от отсутствия стандартов, а от отсутствия "стандартов".
Как только появится "ЗверУмныйДом на одном ДВД" — все сразу будут представлять себе "умный дом" именно так.
Если вы написали собственный механизм миграций — то и edeliver у надо будет рассказать как мигрировать.
Если вы используете ecto — то он и сам знает.
Вот что значит "на автомате"
По-моему, нигде в проекте на хранятся пользовательские данные. Если это картинки и файлы — в отдельной папочке, которая даже не обрабатывается beamом, а сервится прямо нгинксом.
Я может быть сейчас от незнания сморожу, но можно ли писать под эту ОС на Rust?
Мне кажется, что аналогичная статья про Rust (если можно конечно), была бы очень интересна (благодаря хайпу), и возможно я (и даже куча других людей) бы даже попробовал свои силы в написании каких нибудь программ под эту ОС.
Статья просто потрясная! Очень коррелирует с моими мыслями по поводу Rails.
Показушная "простота" работает хорошо только до тех пор, пока не надо чуток выйти за рамки. В тот момент когда это происходит, совершенно теряется понимание "что делать", код превращается в макароны из грязных хаков и теряет полностью свою простоту и привлекательность.
ЗА адептами Рельсов очень интересно наблюдать тогда, когда они пытаются написать что-то на… Ruby! ActiveSupport — это по сути новый язык программирования.
По моим ощущениям, создание rails приложения — это сборка камней/гемов — как в лего, только вся сложность начинается в тот момент, когда эти кубики надо собрать вместе. Когда гем подключается одной строчкой и делает кучу вещей — я его просто боюсь! А такие "батарейки" — везде.
Самое главное, API Рельсов не очевидное, не однозначное, и разработчика на Рельсах по сути ничего не заставляет его как то изучать и понимать. Можно создать десяток сайтов на Рельсах и так и не узнать, что скрывается за волшебным словом Rack, и чем middleware гемы отличаются от "не middleware"!
Ничего не имею против ActiveRecord, если чувствовать пределы, его использовать очень удобно. Но когда можно забрать модель из формы через :params и сохранить как есть одной строчкой как в статье — это рождает миллионы вопросов на SO — "Почему сохраняет пустую модель/не сохраняет ничего" которые просто нереально чинить — там всего одна строка!)
Очень бы хотелось обсудить предыдущую статью автора, в которой он осуждает monkey patching: если не ActiveSupport, то как? Если многим это удобно, то писать RFC к самому Руби? 10.years.ago — возможно это должно быть в стандартной библиотеке?
А что касается проблем ООП — мне кажется Руби — не показатель плохости такой парадигмы. Monkey patching и вся рефлексия — это по сути нарушение инкапсуляции. И это то, что самое крутое в руби, с его method_missing, символами и открытиями классов в любом месте вашего кода. А ведь именно на этом строится такая "классная" ActiveRecord, роутинг, ActiveSupport. Оставь в Рельсах "чистое" ООП — и от всей прелести Релься ничего не останется.
Мне кажется, вы всё же немного путаете Реакт с его инфраструктурой. На сегодняшний день webpack-ом собирается react вместе с css в файл мой_апупенный_апп.js, который подключается в тег script и может "хостится на гитхабе". Туда же можно подключить и react-router (хотя это не обязательно). Туда же можно подключить flux библиотеку (хотя это тоже не обязательно). Конечно, этот js и весить будет опупенно, но разговор же не об этом.
Впрочем, что касается бэкэнда, то большинство js spa фреймворков его не требуют. Или Angular, Backbone, Knockout не могут работать только на чужих апи?.
Я честно, не вижу принципиальной разницы между тем и этим. Подходы похожи, функции похожи, выбор определяется только вкусом и модой — кого-то бесит jsx, а меня, например, знак $.
react-router не имеет отношения к react в плане UI. Вы можете использовать react без роутеров. Или использовать react-router вместе с webcomponents. Или использовать react с любым роутером, который вы планируете использовать с webcomponents.
Да и в принципе, если использовать какой-нибудь redux можно не использовать роутинг вообще.
Мне почему-то казалось, что Реакт вот прям так как вы написали здесь и работает.
И отдельно, что касается "raw html"… Мне почему-то кажется, что html вообще должен умереть. С развитием SPA js всё теснее будет интегрироваться с html, и в какой то момент html превратится в xaml — этакое чудо, лежащее только в исходниках. И в этот момент с jsx переехать в новые реалии будет очень просто.
Мне почему-то кажется, что рефлексия сильно замедляет процесс работы кода. Можно, конечно же, накрутить через неё всяких крутых штук, но тогда Вы получите что-то равно по скорости Руби, а ничего круче Руби с такой же скоростью придумать нереально.
Вывод — Го может принимать только не замедляющие его работу фичи, а значит рефлексия это то, что Пайк будет советовать не использовать.
Сравните эти идеи с идеями zero cost abstractions в рантайме — и получите, что Go это плохо спроектированный для функциональщины язык.
Согласен полностью. Отсутствие generics превращает рутину в… рутину. Можно набрать в проект много мяса, и быстро начать разрабатывать, только вот похоже, что БЕЗ мяса на Го не очень то и попишешь…
Если я правильно понимаю, власти не того уровня, чтобы разбираться с архитектурой. Им легче, утрированно, ввести смертную казнь за наличие Telegram на телефоне, чем разбираться, как там что заблокировать. И, как мне кажется, никому рисковать не захочется…
А закон простой — классифицировать Telegram, к примеру, как инструмент терроризма, благо существует прецедент использования Telegram террористами.
Да, можно. "так же" относилось непосредственно к факту продажи собственного оборудования, а не всех перечисленных характеристик, но видимо я запутался в причастных или каких-то там оборотах. Что касается VR — может быть тоже будет совместим. А может вообще его не будет. Это просто фантазии, которые, как мне кажется, похожи на правду.
Как ни крути, но на сегодняшний день VR для работы не очень пригоден. А среди геймеров «яблочная» продукция не котируется.
А в тот момент, когда VR «крепко войдёт в нашу жизнь» в плане пользы, Эппл выпустит свой iOculus, который будет продавать за +$один нолик в конце по сравнению с остальными VR, с самым закрытым протоколом и совместимым только со своей продукцией, так же как сейчас продаёт свои мышки и клавиатуры для маков.
Имеется ввиду, чтобы у всех рутин был один и тот же таймер. Ну, даже может быть не таймер, а к примеру такой "генератор синхронизации", который при тике запускает сразу все подписанные на него рутины
Если вы решите делать такое в реальном коде — функция
newне приветствуется.Мне кажется, что "умные дома" страдают не от отсутствия стандартов, а от отсутствия "стандартов".
Как только появится "ЗверУмныйДом на одном ДВД" — все сразу будут представлять себе "умный дом" именно так.
Если вы написали собственный механизм миграций — то и edeliver у надо будет рассказать как мигрировать.
Если вы используете ecto — то он и сам знает.
Вот что значит "на автомате"
По-моему, нигде в проекте на хранятся пользовательские данные. Если это картинки и файлы — в отдельной папочке, которая даже не обрабатывается beamом, а сервится прямо нгинксом.
mix edeliver migrate
Если экто — то на автомате
А если не пользоваться релизами, тогда как? Каждый раз git pull?
Что насчёт
System.get_envв конфиге?Все непонятные параметры — это синтаксический сахар к понятным параметрам.
Все очень хорошо описано на сайте elixir в разделе basic types
Я может быть сейчас от незнания сморожу, но можно ли писать под эту ОС на Rust?
Мне кажется, что аналогичная статья про Rust (если можно конечно), была бы очень интересна (благодаря хайпу), и возможно я (и даже куча других людей) бы даже попробовал свои силы в написании каких нибудь программ под эту ОС.
Ну а если нет — тогда ждём....
Статья просто потрясная! Очень коррелирует с моими мыслями по поводу Rails.
Показушная "простота" работает хорошо только до тех пор, пока не надо чуток выйти за рамки. В тот момент когда это происходит, совершенно теряется понимание "что делать", код превращается в макароны из грязных хаков и теряет полностью свою простоту и привлекательность.
ЗА адептами Рельсов очень интересно наблюдать тогда, когда они пытаются написать что-то на… Ruby! ActiveSupport — это по сути новый язык программирования.
По моим ощущениям, создание rails приложения — это сборка камней/гемов — как в лего, только вся сложность начинается в тот момент, когда эти кубики надо собрать вместе. Когда гем подключается одной строчкой и делает кучу вещей — я его просто боюсь! А такие "батарейки" — везде.
Самое главное, API Рельсов не очевидное, не однозначное, и разработчика на Рельсах по сути ничего не заставляет его как то изучать и понимать. Можно создать десяток сайтов на Рельсах и так и не узнать, что скрывается за волшебным словом Rack, и чем middleware гемы отличаются от "не middleware"!
Ничего не имею против ActiveRecord, если чувствовать пределы, его использовать очень удобно. Но когда можно забрать модель из формы через :params и сохранить как есть одной строчкой как в статье — это рождает миллионы вопросов на SO — "Почему сохраняет пустую модель/не сохраняет ничего" которые просто нереально чинить — там всего одна строка!)
Очень бы хотелось обсудить предыдущую статью автора, в которой он осуждает monkey patching: если не ActiveSupport, то как? Если многим это удобно, то писать RFC к самому Руби? 10.years.ago — возможно это должно быть в стандартной библиотеке?
А что касается проблем ООП — мне кажется Руби — не показатель плохости такой парадигмы. Monkey patching и вся рефлексия — это по сути нарушение инкапсуляции. И это то, что самое крутое в руби, с его method_missing, символами и открытиями классов в любом месте вашего кода. А ведь именно на этом строится такая "классная" ActiveRecord, роутинг, ActiveSupport. Оставь в Рельсах "чистое" ООП — и от всей прелести Релься ничего не останется.
Мне кажется, вы всё же немного путаете Реакт с его инфраструктурой. На сегодняшний день webpack-ом собирается react вместе с css в файл
мой_апупенный_апп.js, который подключается в тег script и может "хостится на гитхабе". Туда же можно подключить и react-router (хотя это не обязательно). Туда же можно подключить flux библиотеку (хотя это тоже не обязательно). Конечно, этот js и весить будет опупенно, но разговор же не об этом.Впрочем, что касается бэкэнда, то большинство js spa фреймворков его не требуют. Или Angular, Backbone, Knockout не могут работать только на чужих апи?.
Я честно, не вижу принципиальной разницы между тем и этим. Подходы похожи, функции похожи, выбор определяется только вкусом и модой — кого-то бесит jsx, а меня, например, знак
$.react-router не имеет отношения к react в плане UI. Вы можете использовать react без роутеров. Или использовать react-router вместе с webcomponents. Или использовать react с любым роутером, который вы планируете использовать с webcomponents.
Да и в принципе, если использовать какой-нибудь redux можно не использовать роутинг вообще.
Мне почему-то казалось, что Реакт вот прям так как вы написали здесь и работает.
И отдельно, что касается "raw html"… Мне почему-то кажется, что html вообще должен умереть. С развитием SPA js всё теснее будет интегрироваться с html, и в какой то момент html превратится в xaml — этакое чудо, лежащее только в исходниках. И в этот момент с jsx переехать в новые реалии будет очень просто.
Вы точно уверены, что это Go код? В Go лямбды обозначаются не так:
Да и на Ruby это не похоже.
Но, если вы взяли код из C#, то какое это отношение имеет к моему комментарию?
Мне почему-то кажется, что рефлексия сильно замедляет процесс работы кода. Можно, конечно же, накрутить через неё всяких крутых штук, но тогда Вы получите что-то равно по скорости Руби, а ничего круче Руби с такой же скоростью придумать нереально.
Вывод — Го может принимать только не замедляющие его работу фичи, а значит рефлексия это то, что Пайк будет советовать не использовать.
Сравните эти идеи с идеями zero cost abstractions в рантайме — и получите, что Go это плохо спроектированный для функциональщины язык.
А закон простой — классифицировать Telegram, к примеру, как инструмент терроризма, благо существует прецедент использования Telegram террористами.
А в тот момент, когда VR «крепко войдёт в нашу жизнь» в плане пользы, Эппл выпустит свой iOculus, который будет продавать за +$один нолик в конце по сравнению с остальными VR, с самым закрытым протоколом и совместимым только со своей продукцией, так же как сейчас продаёт свои мышки и клавиатуры для маков.