Уже немного чуть более понятно. Недостаёт в каждом примере явного указания, кто есть кто. Но если дерзать, то можно понять.
С нетерпением жду рассказ про is4.
Ну так это целенаправленная политика, когда центры городов отдают туристам и исторической застройке, а бизнес-центры выносят на окраины и устраивают там крупные транспортные узлы.
Я вот работал в Amsterdam Zuid. На остановке все виды транспорта — автобусы, трамваи, метро, пригородные электрички, национальные и международные поезда.
Можно жить вообще в сотне километров от города и нормально добираться до работы за разумное время. И да, не во всех командировках я останавливался в местах, где до офиса можно добраться пешком или велосипедом. Пользовался ОТ и это занимало максимум 30-40 минут, через весь город, в утренний час пик.
И именно развитый ОТ приводит к тому, что города не превращаются в человейники, а люди не пытаются всеми средствами попасть жить в какой-то конкретный район.
Как личный пример — Амстердам. Машины есть. Но они не на каждый день. На работу и т.п. — ОТ или велосипед. В путешествие или за покупками — машина. И есть ещё такси. И качество жизни очень высоко.
В среднем, по различным источникам, минимальный объём чтения для получения этой абилки составляет примерно книгу в неделю в течении полугода, то есть достаточно просто читать Хабр каждое утро по дороге до работы.
Вот так, начитаются своего Хабра и давай грамотность причинять. Про запятые сказали ранее.
По существу статьи, корреляция грамотной письменной и складность устной речи с профессиональными навыками разработчика, крайне мала. Из моих 15 лет опыта в IT.
Именно поэтому и хочется какого-то однозначного алгоритма отнесения запусков на счёт того или иного государства. Всё-таки дух соперничества и всё-такое… ;)
Вы просто упомянули методику. И я думал, что это какой-то набор правил, следуя которым можно определить страну принадлежности РН. Например, в чьей юрисдикции находится компания, которая соединяет ракету с двигателем, той страны и запуск. Или, в чьей юрисдикции находится оператор запуска, тому и запуск.
А выходит, что единой методики нет и каждый считает, как хочет.
Гюнтер считает Электрон новозеландским.
Вики указывает, что юридически штаб-квартира (родительская компания) — американская.
На NSF был спор, но решили, что де-юре компания американская.
Получается странная ситуация (у всех, кроме Гюнтера).
— Союз для Куру производит РФ для Арианспейс. Заказы на услуги берёт Арианспейс. Оператором запуска выступает. И т.д. Но пуски засчитывают РФ, потому что ракета создана в РФ.
— Электрон для Rocket Lab USA производит новозеландская Rocket Lab Limited. Заказы на услуги берёт Rocket Lab USA. Пуски засчитывают Штатам, хотя ракета создана в НЗ.
Как раз ракету производят в НЗ. В США производят двигатели и авионику. Затем доставляют в Окленд и там собирают. И там же, пока что, запускают.
Если говорить о конечных владельцах, то да, это американский Rocket Lab USA, которому на 100% принадлежит новозеландский Rocket Lab Limited.
Если же говорить о стране, где производится ракета — то это всё-таки Новая Зеландия. Производит её новозеландская компания, пусть и на 100% принадлежащая американской.
Похожая ситуация с Союзами в Куру. Ракета российская, а запуск — европейский, Arianespace.
Потому что у программистов не маркетологи, а евангелисты и технолоджи-адвокаты. Они, в отличие от маркетологов, разбираются в том, что продвигают и сами это используют.
На Xamarin.Forms. Сейчас всё сильно стабильнее стало по сравнению с тем, что было ещё года два назад. Плюс, многие сторонние плагины для кроссплатформенной работы с аппаратной частью заменены реализацией в Essentials. И оно как-то стабильнее стало.
Пока единственные проблемы со стабильностью, с которыми сталкиваюсь, касаются фич в preview (experimental) статусе. Остальное очень даже работает.
Я вот гордый программист-одиночка. Фуллстек. Знаю C# и JavaScript. Поэтому пишу под мобильные платформы… На Xamarin. И потому некоторые ваши преимущества нативной по сравнению с кроссплатформенной звучат для меня странно. Обратиться к гироскопу? Да пожалуйста. Отпечаток пальца? Нате!
2. не понял вопроса, зачем хранить одну сущность в разных сабжектах.
Я это спросил, потому что не знаю вашей архитектуры. У меня просто были чисто практические затыки, которые приводили к появлению странных костылей. Наверно я просто не умею готовить сабжекты. Вот, допустим. Есть страница, где выводится список пользователей, постраничный. На бек уходит запрос с параметрами пейджинга, ответ помещается в сабжект. И есть ещё компонент, где выводится текущий пользователь. Что делать, если он не попал в сабжект? Хранить его в другом сабжекте? Дополнять текущий ещё и этим пользователем, но хранить настройки пейджинга, чтобы он не показывался на каждой странице? Это один из простых вопросов, с которыми сталкивался.
3. Точно так же все. Как напишете, так и будет.
И всё же? Если на странице в компоненте выводится таблица, где каждая строка — это данные пяти различных сущностей, где происходит их объединение? В коде компонента? В сервисе?
Я использую Akita. Меньше бойлерплейта, практически сервис на сабжектах, только с готовым апи.
Интересное решение, спасибо, гляну. Сейчас в ngrx бойлерплейта сильно меньше, чем было пару релизов назад.
Я специально указал, что state management обязателен для сложных бизнес приложений. А не вообще всегда. Это утверждение сделано на основании собственного опыта построения таких приложений, как без state management, так и с ним.
И да, я готов к предметному обсуждению вопроса.
Сервис с rxjs спокойно выступают в роли хранилища.
1. Каким именно образом хранить данные? В BehaviorSubject?
2. Есть single source of truth или одна и та же сущность может в разных экземплярах behavior subject?
3. А как быть с объектами, у которых много связей? Строить пайпы в ngOnInit на страницу текста?
Наличие стороннего стейта не обязательно, и ngrx их них не лучший.
Можно пример более лучшего state management решения под ангуляр? Сравнение?
Сторонний стейт удобен разве что поддержкой девтулзов и готовой документацией.
Сторонний стейт удобен тем, что даёт готовую архитектуру, которая определяет то, как будут взаимодействовать уровни приложения, храниться и передаваться данные.
С нетерпением жду рассказ про is4.
Я вот работал в Amsterdam Zuid. На остановке все виды транспорта — автобусы, трамваи, метро, пригородные электрички, национальные и международные поезда.
Можно жить вообще в сотне километров от города и нормально добираться до работы за разумное время. И да, не во всех командировках я останавливался в местах, где до офиса можно добраться пешком или велосипедом. Пользовался ОТ и это занимало максимум 30-40 минут, через весь город, в утренний час пик.
И именно развитый ОТ приводит к тому, что города не превращаются в человейники, а люди не пытаются всеми средствами попасть жить в какой-то конкретный район.
Вот так, начитаются своего Хабра и давай грамотность причинять. Про запятые сказали ранее.
По существу статьи, корреляция грамотной письменной и складность устной речи с профессиональными навыками разработчика, крайне мала. Из моих 15 лет опыта в IT.
А выходит, что единой методики нет и каждый считает, как хочет.
Вики указывает, что юридически штаб-квартира (родительская компания) — американская.
На NSF был спор, но решили, что де-юре компания американская.
Получается странная ситуация (у всех, кроме Гюнтера).
— Союз для Куру производит РФ для Арианспейс. Заказы на услуги берёт Арианспейс. Оператором запуска выступает. И т.д. Но пуски засчитывают РФ, потому что ракета создана в РФ.
— Электрон для Rocket Lab USA производит новозеландская Rocket Lab Limited. Заказы на услуги берёт Rocket Lab USA. Пуски засчитывают Штатам, хотя ракета создана в НЗ.
Если говорить о конечных владельцах, то да, это американский Rocket Lab USA, которому на 100% принадлежит новозеландский Rocket Lab Limited.
Если же говорить о стране, где производится ракета — то это всё-таки Новая Зеландия. Производит её новозеландская компания, пусть и на 100% принадлежащая американской.
Похожая ситуация с Союзами в Куру. Ракета российская, а запуск — европейский, Arianespace.
Пока единственные проблемы со стабильностью, с которыми сталкиваюсь, касаются фич в preview (experimental) статусе. Остальное очень даже работает.
Я это спросил, потому что не знаю вашей архитектуры. У меня просто были чисто практические затыки, которые приводили к появлению странных костылей. Наверно я просто не умею готовить сабжекты. Вот, допустим. Есть страница, где выводится список пользователей, постраничный. На бек уходит запрос с параметрами пейджинга, ответ помещается в сабжект. И есть ещё компонент, где выводится текущий пользователь. Что делать, если он не попал в сабжект? Хранить его в другом сабжекте? Дополнять текущий ещё и этим пользователем, но хранить настройки пейджинга, чтобы он не показывался на каждой странице? Это один из простых вопросов, с которыми сталкивался.
И всё же? Если на странице в компоненте выводится таблица, где каждая строка — это данные пяти различных сущностей, где происходит их объединение? В коде компонента? В сервисе?
Интересное решение, спасибо, гляну. Сейчас в ngrx бойлерплейта сильно меньше, чем было пару релизов назад.
А в чём нужда дестроить сторы?
И да, я готов к предметному обсуждению вопроса.
1. Каким именно образом хранить данные? В BehaviorSubject?
2. Есть single source of truth или одна и та же сущность может в разных экземплярах behavior subject?
3. А как быть с объектами, у которых много связей? Строить пайпы в ngOnInit на страницу текста?
Можно пример более лучшего state management решения под ангуляр? Сравнение?
Сторонний стейт удобен тем, что даёт готовую архитектуру, которая определяет то, как будут взаимодействовать уровни приложения, храниться и передаваться данные.