Для ангуляра есть еще вариант ngc + closure compiler, причем если в коде не будет левых зависимостей можно включить advanced оптимизации. Интересно какой будет результат.
Не совсем понял, что мешает залить в базу тот же OpenStreetMap, придется конечно немного поразбиратся, куда без этого. Сейчас многие БД предоставляют возможности работать с гео данными, даже SQLite можно поднять в памяти с соотв. расширением. Вопрос сводится к следующему, будет ли реализация реверс геокодинга на хадупе/спарке, быстрее/проще/лучше, чем аналогичная (и уже готовая) реализация в одной из таких БД? Причем сама БД статическая, скопировал на вторую машину запустил и получил гарантированный х2 перформанс.
ArcGIS судя по всему просто использует модуль PostGIS, т.е. можно было бы просто загнать данные карт в локальный постгрес и потом выбирать напрямую из него по координатам с помощью ST_Intersects, ST_CoveredBy, ST_Within и тд. Эта схема относительно легко масштабируется.
Я имел ввиду, что может быть маппить и не нужно это поле вообще, а в месте использования просто использовать экстеншен метод: myLabel.Text = foo.Enum.ToDisplayName(). По скорости это будет не хуже (если использовать кэш имен), по удобству — терпимо.
Есть интересная статья (и единственная за тоннами хайпа) — Kotlin vs Java The Whole Story. Там сделана попытка обьективно оценить целесообразность перехода на Котлин.
Тоже думал написать что-то похожее, но потом отказался от идеи, слишком много сил надо чтобы написать полноценное решение и будущее декораторов выглядело смутно. Самая неприятная проблема — работа с датами, но ее можно решить по-другому.
Сейчас есть интересная альтернатива — TypeScript Custom Transformers, что позволяет делать кодогенерацию во время компиляции, еще не все сделано, но уже можно пробовать. По идее можно будет обойтись без кучи декораторов. Еще один способ — кодогенерация по моделям бэкенда или свагеру.
Flash для десктопа был уже 10 лет назад и есть до сих пор, называется Adobe Air. Причем писать можно было и на js, точно так же как на электроне сейчас.
С фрагентами конечно проще, но в целом писать одно мучение.
Будем реалистами, зайдем на гитлаб GitFox и посмотрим статистику, сотни комитов, несколько авторов. Установим приложение (на первом же экране кнопка back ведет на пустое место, ошибка в токене никак не сообщается юзеру, просто слетает форма и все), по сути это клиент для части гитлабовского рест апи. На каком-нибудь реакте или ионике или том же новом флаттере это все заняло бы максимум неделю времени: сделать апи клиент, закодить n экранов/списков, без лишних размышлений о потоках, активити, лайфсайклах, листвью, темах, стилях и тп.
Это неудачный пример, у вас могут быть две разные сущности, которые имеют тип {id:number, name:string} и два соотв. сервиса чтобы их сохранять на бэкенде, компилятор разрешит вам сохранить любую сущность любым сервисом, что будет ошибкой. Люди не знакомые с тайпскриптом пытаются использовать маркерные (пустые) интерфейсы, что тоже приводит к похожим ошибкам.
Действительно, в чем проблема если мы можем передать в функцию что угодно, что совпадает по структуре? Очевидно, что надо проявлять бдительность, чтобы не проморгать такую ситуацию.
Если команда выполняется через npm run то будут использованы локальный протрактор и драйвер менеджер сложит драйвера локально. Глобальный протрактор будет работать только если указать явно в конфиге пути к соотв. драйверам, например, chromeDriver: '...'. По непонятной причине простого способа заставить протрактор использовать глобальный конфиг нельзя, но если хочется, то можно находить и парсить update-config.json.
Честно говоря, в первый же раз когда мне понадобилось несколько простых списков (тогда еще RV только только выходил) в приложении (и просто массивы и данные из sqlite) я подумал, что так просто нельзя писать, количество приседаний зашкаливало + огромные портянки кода, который не делает ничего полезного для бизнес логики. В итоге не совсем чисто, но загнал весь этот бойлерплейт в абстракные классы, фабрики и интрефейсы, после чего любой список добавлялся тривиально, он определяется адаптером, типом элементов и представлением элемента (для sqlite нужно присесть дополнительный раз), все проверяется на этапе компиляции. Если просто представить себе сколько написали люди всяких ViewHolder-ов, становится темно в глазах.
Для ангуляра есть еще вариант ngc + closure compiler, причем если в коде не будет левых зависимостей можно включить advanced оптимизации. Интересно какой будет результат.
Не совсем понял, что мешает залить в базу тот же OpenStreetMap, придется конечно немного поразбиратся, куда без этого. Сейчас многие БД предоставляют возможности работать с гео данными, даже SQLite можно поднять в памяти с соотв. расширением. Вопрос сводится к следующему, будет ли реализация реверс геокодинга на хадупе/спарке, быстрее/проще/лучше, чем аналогичная (и уже готовая) реализация в одной из таких БД? Причем сама БД статическая, скопировал на вторую машину запустил и получил гарантированный х2 перформанс.
ArcGIS судя по всему просто использует модуль PostGIS, т.е. можно было бы просто загнать данные карт в локальный постгрес и потом выбирать напрямую из него по координатам с помощью ST_Intersects, ST_CoveredBy, ST_Within и тд. Эта схема относительно легко масштабируется.
Я имел ввиду, что может быть маппить и не нужно это поле вообще, а в месте использования просто использовать экстеншен метод:
myLabel.Text = foo.Enum.ToDisplayName(). По скорости это будет не хуже (если использовать кэш имен), по удобству — терпимо.Неплохой вариант, но с другой стороны возникает вопрос, не лучше ли написать экстеншен метод т.е.
foo.Enum.ToDisplayName()?Один из насущных примеров это генераторы.
Есть интересная статья (и единственная за тоннами хайпа) — Kotlin vs Java The Whole Story. Там сделана попытка обьективно оценить целесообразность перехода на Котлин.
Салют! Вижу дело живет. В чем отличие WX от прошлых мышей? Теперь сенсор пиксаровский?
Тоже думал написать что-то похожее, но потом отказался от идеи, слишком много сил надо чтобы написать полноценное решение и будущее декораторов выглядело смутно. Самая неприятная проблема — работа с датами, но ее можно решить по-другому.
Сейчас есть интересная альтернатива — TypeScript Custom Transformers, что позволяет делать кодогенерацию во время компиляции, еще не все сделано, но уже можно пробовать. По идее можно будет обойтись без кучи декораторов. Еще один способ — кодогенерация по моделям бэкенда или свагеру.
Flash для десктопа был уже 10 лет назад и есть до сих пор, называется Adobe Air. Причем писать можно было и на js, точно так же как на электроне сейчас.
Вы неправильно меня поняли, я не критикую ваш труд, я говорю о том, что разработка под андроид нативным способом требует слишком много времени.
С фрагентами конечно проще, но в целом писать одно мучение.
Будем реалистами, зайдем на гитлаб GitFox и посмотрим статистику, сотни комитов, несколько авторов. Установим приложение (на первом же экране кнопка back ведет на пустое место, ошибка в токене никак не сообщается юзеру, просто слетает форма и все), по сути это клиент для части гитлабовского рест апи. На каком-нибудь реакте или ионике или том же новом флаттере это все заняло бы максимум неделю времени: сделать апи клиент, закодить n экранов/списков, без лишних размышлений о потоках, активити, лайфсайклах, листвью, темах, стилях и тп.
Это неудачный пример, у вас могут быть две разные сущности, которые имеют тип
{id:number, name:string}и два соотв. сервиса чтобы их сохранять на бэкенде, компилятор разрешит вам сохранить любую сущность любым сервисом, что будет ошибкой. Люди не знакомые с тайпскриптом пытаются использовать маркерные (пустые) интерфейсы, что тоже приводит к похожим ошибкам.альтернатива это
browser.wait, фактически тот же самый слип, только можно выйти из него раньше.Действительно, в чем проблема если мы можем передать в функцию что угодно, что совпадает по структуре? Очевидно, что надо проявлять бдительность, чтобы не проморгать такую ситуацию.
Если команда выполняется через
npm runто будут использованы локальный протрактор и драйвер менеджер сложит драйвера локально. Глобальный протрактор будет работать только если указать явно в конфиге пути к соотв. драйверам, например,chromeDriver: '...'. По непонятной причине простого способа заставить протрактор использовать глобальный конфиг нельзя, но если хочется, то можно находить и парситьupdate-config.json.Это конечно хорошо, что они почистят старый код, хотя и немного непривычно после долгих лет обратной совместимости.
Честно говоря, в первый же раз когда мне понадобилось несколько простых списков (тогда еще RV только только выходил) в приложении (и просто массивы и данные из sqlite) я подумал, что так просто нельзя писать, количество приседаний зашкаливало + огромные портянки кода, который не делает ничего полезного для бизнес логики. В итоге не совсем чисто, но загнал весь этот бойлерплейт в абстракные классы, фабрики и интрефейсы, после чего любой список добавлялся тривиально, он определяется адаптером, типом элементов и представлением элемента (для sqlite нужно присесть дополнительный раз), все проверяется на этапе компиляции. Если просто представить себе сколько написали люди всяких ViewHolder-ов, становится темно в глазах.
А вы не смотрели, может имеет смысл купить готовое решение, типа TP-Link NC200? Выбор достаточно большой.
Всегда полезно посмотреть на вещи с другой стороны.