С американскими компаниями ситуация аналогичная, у них просто регулирующие документы другие - Adobe, Autodesk, AWS, Hashicorp, Elastic, Mongo and the list goes on and on.
Упоминание басни Крылова, на мой взгляд, все объясняет. Перестаньте слушать и читать тех, у кого не получается выстроить BIM таким образом, чтобы получить экономический эффект. Обратите внимание на тех у кого получается, кто продолжает в этом развиваться и совершенствоваться. Кто ранее блистал, тот и продолжает блистать ещё ярче. Никакой отмены не происходит - ни у нас, ни в мире.
Предположим. Тогда методом от обратного возникают следующие вопросы.
Эксплуатация. Пассажирский или грузовой лифт требует наличия кабины для перемещения. Исходя из того что мы сейчас видим в пирамиде, она не содержит элементов которые могли бы использоваться для удобной погрузки и выгрузки из кабины.
Материалы. ЛАИ и Скляров пришли к очень логичному умозаключению, что условные колонизаторы не имеют возможности возить с собой материалы и возить нужно инструменты. Поэтому для любой планеты строить из камня является наиболее рациональным решением. Но космический лифт требует использования уже совсем других материалов, очень высокотехнологичных по производству. Возникает вопрос - зачем строить основание из камня, если вся остальная конструкция из высокотехнологичных производимых материалов?
Тогда более честным было бы сравнение базы sql server с колоночными таблицами и duckdb, или даже in-memory таблицы sql server с duckdb. Или сравнение duckdb с clickhouse. Сравнение in-memory таблицы sql server с clickhouse было бы интересным, не факт что clickhouse выйдет победителем 😀 Сейчас получается вы говорите - у нас есть платный движок, который все посчитал заранее, давайте посмотрим сможет ли бесплатный движок считать на лету так же быстро, как если бы все было посчитано заранее. Ответ на мой взгляд очевиден. И даже понятно, что если кто-нибудь сделает olap cube engine поверх duckdb, то движок этот будет платным 😀
Не понятно как вы сравниваете olap cube в ssas и колоночную rdbms. В кубе все агрегаты предпосчитаны при построении, в duckdb расчитываются налету при выполнении запроса. Функционала olap кубов в duckdb нет.
А есть у вас возможность расписать полностью конфигурацию серверов, на которой получилось 200 тыс запросов / мин достигнуть?
То есть — сколько вебов, сколько db серверов, сколько кешей приложения и кешей сессий — и на каких инстансах AWS каждый.
Стоимость в месяц всего вместе вы уже оценивали? :)
для Smart TV потребуется один метод:
— /catalog/{pageId} — возвращает html page
для Xbox/IE потребуется два метода:
— /api/catalog/{parameters set} — возвращает json для infinite scrolling
— /catalog — возвращает html page, нет input параметров
Вы предлагаете для обоих случаев пользоваться одним методом — - /catalog/{pageId}
Это возможно, но не правильно. Объясню почему.
Вы отдаете приложение на QA, они на xbox IE набирают /catalog/2 и выписывают дефект примерно следующего содержания: «как бы дитя не скролилло, любимых медведей не увидело». У Вас два пути решения проблемы:
— сделать для xbox метод без параметра
— сделать в контроллере условную логику основанную на том какой девайс/браузер используется, что является не верным решением. Именно от этого и следует уходить любыми средствами. Аналогичная условная логика во View также не желательна — поэтому MS и сделали View Modes в MVC 4.
Это спор аналогичный тому стоит ли пытаться на HTML 5 делать одно приложение работающее и на iOS, и на Android, и на Windows Phone 8. Ответ на него очень простой — если Вам нужен WoW результат и ресурсы позволяют, то нужно делать для каждой платформы нативное приложение.
С сайтом ситуация аналогичная. Если Вы хотите быть удобными для пользователей, если хотите чтобы пользователи открывали Ваш сайт пока сидят в туалете, дома перед выпуском новостей, пользовались вашим сайтом с нескольких устройств одновременно — то Вам придется делать сайт опираясь на возможности каждой из платформ. Сайт — это такое же приложение.
В то же время открывать большенство сайтов на мобильных устройствах, телевизорах и приставках практически бесполезно, т.к. меню разворачивается на mouse over, комбобоксы закрываются до того как вы проскроллите до нужного пункта и автоматически уходит пост-бек, чтобы добраться до кнопки ОК нужно 25 раз нажать на кнопку Вниз, а на link button никак не попасть с джойстика. И все эти сайты не парятся по этому поводу :)
Я бы всем посоветовал запарится, потому что другой возможности сейчас как-то выделится из десятков тысяч аналогов — нет.
В условиях конкуренции выигрывает тот, кто к лесу задом, а к пользователю передом.
Я бы сказал что различие в том, что
— для infinite scrolling у нас есть action method который принимает параметры и отдает JSON
— а для постраничного пейджинга у нас есть action method который отдает aspx/cshtml View, причем размер страницы в элементах фиксированный и не должен передаваться через параметры — у пытливого пользователя не должно быть возможности этим управлять.
Передавать параметр в метод управляя тем в каком формате отдавать результат или опираться на content-type запроса в данном случае не верно.
У Вас может использоватся одна и таже логика пейджинга, но методы контроллера — это presentation layer. Они будут разными и это правильно. Здесь не нужно стремиться делать универсальные механизмы.
Да, приведу пример на странице показывающей пользователю ассортимент товара — обычный browse list с картинками товаров.
Оптимальным подходом будет следующее:
Для XBOX мы показываем товар как обычно, ширина фиксирована, пейджинг нам не нужен — пользователь пролистывает страницу вниз и мы всевремя подгружаем вниз товар для показа (infinite scrolling). Страница может содержать виджеты социальных сетей, кнопки рейтинга товара и тому подобное.
Для SmartTV — ширина та же, но необходимо избавится от скроллинга, товар показывается постранично, все умещается на страницу без скроллинга, слева и справа страницы кнопки Влево/Вправо, в JavaScript обрабатываем key press events с кнопок пульта и делаем пост-беки для пейджинга. Никаких виджетов.
То есть и сама страница, ее функционал и внешний вид, а также server side для педжинга будут различными.
Совершенно верно! Я тоже сталкивался с тем, что валидация email адресов не пропускает домены .travel Нужно все регулярные выражения которыми производится валидация email-ов тестить на .travel
Я забыл уточнить, что разницы между ними нет с точки зрения продавца :)
Sales Tax в US, так же как и VAT (НДС у нас), перекладываестя на покупателя, увеличивая стоимость товара на опредененный процент. Если товар продается повторно (used goods), то Sales Tax взымается повторно — так же как и VAT.
Разница между ними только в том, что:
— размер VAT включен в retail price, а ценники в US не содержат Sales Tax; в России цены также могут не содержать в себе НДС.
— VAT (НДС) закладывается в цену начиная с производства и переклывается вверх по цепочке продажи по-очереди, пока не дойдет до покупателя, который его собственно и заплатит.
То есть VAT отличается от Sale Tax в методике расчета. Но для последнего звена — продавца — оба налога обслуживаются одинаково. Для покупателя оба налога также суть одно и тоже, так как ему приходится заплатить больше на определенный процент.
Есть еще разница в том куда идет сумма налога, но это с точки зрения продавца уже не важно :)
Visual Studio активируется как онлайн лицензией привязанной к аккаунту, так и вводом serial key, с вводом ключа все работает.
поставить teleport
в винде есть WSL, который предоставляет линукс консоль, зачем переезжать на Linux?
С американскими компаниями ситуация аналогичная, у них просто регулирующие документы другие - Adobe, Autodesk, AWS, Hashicorp, Elastic, Mongo and the list goes on and on.
Упоминание басни Крылова, на мой взгляд, все объясняет. Перестаньте слушать и читать тех, у кого не получается выстроить BIM таким образом, чтобы получить экономический эффект. Обратите внимание на тех у кого получается, кто продолжает в этом развиваться и совершенствоваться. Кто ранее блистал, тот и продолжает блистать ещё ярче. Никакой отмены не происходит - ни у нас, ни в мире.
Предположим. Тогда методом от обратного возникают следующие вопросы.
Эксплуатация. Пассажирский или грузовой лифт требует наличия кабины для перемещения. Исходя из того что мы сейчас видим в пирамиде, она не содержит элементов которые могли бы использоваться для удобной погрузки и выгрузки из кабины.
Материалы. ЛАИ и Скляров пришли к очень логичному умозаключению, что условные колонизаторы не имеют возможности возить с собой материалы и возить нужно инструменты. Поэтому для любой планеты строить из камня является наиболее рациональным решением. Но космический лифт требует использования уже совсем других материалов, очень высокотехнологичных по производству. Возникает вопрос - зачем строить основание из камня, если вся остальная конструкция из высокотехнологичных производимых материалов?
Тогда более честным было бы сравнение базы sql server с колоночными таблицами и duckdb, или даже in-memory таблицы sql server с duckdb. Или сравнение duckdb с clickhouse. Сравнение in-memory таблицы sql server с clickhouse было бы интересным, не факт что clickhouse выйдет победителем 😀 Сейчас получается вы говорите - у нас есть платный движок, который все посчитал заранее, давайте посмотрим сможет ли бесплатный движок считать на лету так же быстро, как если бы все было посчитано заранее. Ответ на мой взгляд очевиден. И даже понятно, что если кто-нибудь сделает olap cube engine поверх duckdb, то движок этот будет платным 😀
Не понятно как вы сравниваете olap cube в ssas и колоночную rdbms. В кубе все агрегаты предпосчитаны при построении, в duckdb расчитываются налету при выполнении запроса. Функционала olap кубов в duckdb нет.
То есть — сколько вебов, сколько db серверов, сколько кешей приложения и кешей сессий — и на каких инстансах AWS каждый.
Стоимость в месяц всего вместе вы уже оценивали? :)
для Smart TV потребуется один метод:
— /catalog/{pageId} — возвращает html page
для Xbox/IE потребуется два метода:
— /api/catalog/{parameters set} — возвращает json для infinite scrolling
— /catalog — возвращает html page, нет input параметров
Вы предлагаете для обоих случаев пользоваться одним методом — - /catalog/{pageId}
Это возможно, но не правильно. Объясню почему.
Вы отдаете приложение на QA, они на xbox IE набирают /catalog/2 и выписывают дефект примерно следующего содержания: «как бы дитя не скролилло, любимых медведей не увидело». У Вас два пути решения проблемы:
— сделать для xbox метод без параметра
— сделать в контроллере условную логику основанную на том какой девайс/браузер используется, что является не верным решением. Именно от этого и следует уходить любыми средствами. Аналогичная условная логика во View также не желательна — поэтому MS и сделали View Modes в MVC 4.
С сайтом ситуация аналогичная. Если Вы хотите быть удобными для пользователей, если хотите чтобы пользователи открывали Ваш сайт пока сидят в туалете, дома перед выпуском новостей, пользовались вашим сайтом с нескольких устройств одновременно — то Вам придется делать сайт опираясь на возможности каждой из платформ. Сайт — это такое же приложение.
В то же время открывать большенство сайтов на мобильных устройствах, телевизорах и приставках практически бесполезно, т.к. меню разворачивается на mouse over, комбобоксы закрываются до того как вы проскроллите до нужного пункта и автоматически уходит пост-бек, чтобы добраться до кнопки ОК нужно 25 раз нажать на кнопку Вниз, а на link button никак не попасть с джойстика. И все эти сайты не парятся по этому поводу :)
Я бы всем посоветовал запарится, потому что другой возможности сейчас как-то выделится из десятков тысяч аналогов — нет.
В условиях конкуренции выигрывает тот, кто к лесу задом, а к пользователю передом.
— для infinite scrolling у нас есть action method который принимает параметры и отдает JSON
— а для постраничного пейджинга у нас есть action method который отдает aspx/cshtml View, причем размер страницы в элементах фиксированный и не должен передаваться через параметры — у пытливого пользователя не должно быть возможности этим управлять.
Передавать параметр в метод управляя тем в каком формате отдавать результат или опираться на content-type запроса в данном случае не верно.
У Вас может использоватся одна и таже логика пейджинга, но методы контроллера — это presentation layer. Они будут разными и это правильно. Здесь не нужно стремиться делать универсальные механизмы.
Оптимальным подходом будет следующее:
Для XBOX мы показываем товар как обычно, ширина фиксирована, пейджинг нам не нужен — пользователь пролистывает страницу вниз и мы всевремя подгружаем вниз товар для показа (infinite scrolling). Страница может содержать виджеты социальных сетей, кнопки рейтинга товара и тому подобное.
Для SmartTV — ширина та же, но необходимо избавится от скроллинга, товар показывается постранично, все умещается на страницу без скроллинга, слева и справа страницы кнопки Влево/Вправо, в JavaScript обрабатываем key press events с кнопок пульта и делаем пост-беки для пейджинга. Никаких виджетов.
То есть и сама страница, ее функционал и внешний вид, а также server side для педжинга будут различными.
Sales Tax в US, так же как и VAT (НДС у нас), перекладываестя на покупателя, увеличивая стоимость товара на опредененный процент. Если товар продается повторно (used goods), то Sales Tax взымается повторно — так же как и VAT.
Разница между ними только в том, что:
— размер VAT включен в retail price, а ценники в US не содержат Sales Tax; в России цены также могут не содержать в себе НДС.
— VAT (НДС) закладывается в цену начиная с производства и переклывается вверх по цепочке продажи по-очереди, пока не дойдет до покупателя, который его собственно и заплатит.
То есть VAT отличается от Sale Tax в методике расчета. Но для последнего звена — продавца — оба налога обслуживаются одинаково. Для покупателя оба налога также суть одно и тоже, так как ему приходится заплатить больше на определенный процент.
Есть еще разница в том куда идет сумма налога, но это с точки зрения продавца уже не важно :)