В таком варианте — да. Но, многие скрипты и картинки грузятся асинхронно, и не очень влияют на впечатление о сайте.
Просто как абстрактный пример. У нас есть интернет магазин, у которого фактически 2 страницы для пользователя: список товаров и карточка товара. После первого захода может приехать куча скриптов и стилей. Но человек ходит по сайту, смотрит разные товары и по факту он получает только информацию о товаре и его фотографии. Т.е. в случае условного SPA — у него только данные придут, у него всё уже загружено. Вот в данном случае, насколько важно время первой и время последующих?
А я видел, как люди упарывались именно ради первой загрузки. Сайт открывался быстро, но потом всё дёргалось и моргало, т.к. люди обманывали тесты и роботов, чтобы сайт в выдаче был красивый, но на людей было наплевать.
Почему-то все любят мерять скорость загрузки главной страницы (с картинками, стилями, резолвингом DNS, установлением SSL и прочим). Но при этом забывают, что ресурсы кешируются. Т.е. первая загрузка долгая, но дальше всё будет хорошо и быстро. А вот это уже никому не интересно.
> Кстати, идея насчёт того, что QR сам по себе ведёт на информационный ресурс, а для приложения это маркер — классная.
IZI Travel так работает. Мы как-то в Калининграде оказались в псевдо замке (новодел для туристов со всякими шоу и едой), и там был музей пыток. В общем, собирались просто посмотреть, но увидели куркоды и с помощью колонки устроили себе аудиогида. Ещё пару раз потом подобное в других городах повторяли.
Прочтение письма никто не гарантирует. Его можно проверять или заголовком, и почтовый клиент сам письмо отправит (обычно отключают все). Или трекинговым кодом. Но загрузка внешних изображений может быть отключена в целях безопасности или проксироваться (как делают всякие гуглы и яндексы). А когда они решат попросить картинку — в целом не очень известно.
Баунсы и комплейнты приходят с аццкой задержкой, которую можно использовать для отключения доставки на этот ящик (пользователь не хочет), но не как гарантию доставки/недоставки.
Я тоже не сильно слежу за EF, так что может они что-то и реализовали уже. Да и в linq2db мы используем не все возможности. В качестве идей:
1. linq2db — лёгкий ORM, который делает то, что сказано без всякой магии с трекингом изменений и волшебным сохранением непойми чего, непойми когда (context.SaveChanges())
2. Простые и понятные Insert/Update/Delete. Булки, которые могут работать по-разному в зависимости от провайдера
3. Интуитивные массовые операции (тот же апдейт по критерию)
4. Простые Poco классы для таблиц
5. Быстрый селект (некоторые используют Dapper для селекта, потому что EF медленный, тут не надо).
6. Понятные запросы в базу данных — т.е. они соответствуют тому, что написано, EF любит монстрячить жёсткости с вложенными селектами
7. Всякие оптимизации, типа CROSS APPLY и прочих, если потребовалось
8. Всякие хелперы, типа .LeftJoin, чтобы не писать станадартную linq магию с DefaultIfEmpty
9. Оптимизации под версии баз данных (не знаю, есть ли это у EF)
Если не вдаваться в подробности, то однопроцессорные Xeon'ы, это те же i7, и раньше могли быть взаимозаменяемы (серверный проц в десктопную мамку или наоборот). Потом интел подкрутила гайки. А вот двухпроцессорные и более — имеют гораздо более низкую частоту, чтобы уложиться в пакет и нормально синхронизированно работать в паре. А ядро в целом — то же. Т.е. для числодробилок разница в результатах ровно такая же как и разница в частоте. Т.е. десктопный i7 порвёт ксеоны на грелки и ещё успеет кофе налить (у него же Турбобуст есть).
Начните хотя бы просто с обзорной статьи и чем вы отличаетесь от Entity Framework.
Я про вас узнал на какой-то конференции, когда был рассказ про BLToolkit, а потом попробовал и затянуло. Думаю, многие просто не знают про то, что есть такой офигенный ORM.
Последний раз, когда я увидел CTE в проекте, я заменил его на два джойна. Так что у меня также мнение, если вы начали их использовать, то скорее всего что-то не так :)
Просто если разработчики начинают использовать CTE, то им всё видится гвоздём.
Зато у неё встроенный аккум и зарядка от Micro USB, которая не мешает работать. А так — поиграйтесь с настройками в Bloody, уменьшите рефреш и прочее, и будет дольше.
При этом, те же а4теховые обычные унылые мыши работают месяцами от батарейки. Так что они умеют делать как надо.
> Я вообще не понимаю, почему они должны делать доступ бесплатным.
Я не сторонник того, чтобы они сделали доступ бесплатным, но какие аргументы могут быть:
* Эппл каждый год доит разработчиков на $100 за возможность публиковать. Вполне себе нормальная сумма для поддержания функционирования инфраструктуры
* Одна из причин покупки телефонов эппл — возможность пользоваться магазином. Т.е. его наличие позволяет продавать телефоны, а от продажи телефонов как раз могут идти деньги и на его поддержку
И у многих требование даже не про бесплатный магазин, а то, чтобы они могли продавать самостоятельно. Сейчас, нельзя для пользователя Эппл сделать цену $10, а для пользователя браузера — $7. Это многих злит.
Нет, в 98-ой убрали эту фразу, потому что некоторые пользователи сидели на табуретках и падали с них, когда пытались откинуться. Байка из того времени.
У нас была подобная история. В выходные выключали свет, соответственно вырубили всё что можно, в понедельник, первый пришедший должен был включить всё, что надо.
Всё нормально, всё работает, но люди жалуются, что пропала работа за 2 месяца. Мысли про какой-то аварийный откат файловой системы, потерю данных, всё такое. Сведения разрозненные. Всё работает, но что-то не то.
По итогу оказалось, 2 месяца назад мигрировали сервер на новое железо, старый выдернули из сети и оставили разборки с ним до лучших времён. При включении сотрудник решил, что не порядок, что в сервер не воткнуто питание (ага, провод выбило вместе с пробками) и воткнул старый, который и захватил власть.
Потому что как и дефрагментация в винде. Плохо работает, если мало свободного места. Т.е. контроллеру негде разгуляться для выравнивания. При этом стоит понимать, что эти советы очень эвристические, в зависимости от модели SSD числа могут быть совершенно разные.
Кроме того, не ясно что делает контроллер с резервированным местом. Варианты могут быть следующие:
1. Использует для информации об адресации. Т.е. фактически место занято служебными данными
2. Использует для SLC кеша (который делается не отдельным кешем а просто использованием MLC/TLC ячеек для хранения одного бита).
3. Просто холодные блоки в резерв. Которые подменяются, когда другие начинают плохо себя вести
4. Просто холодные блоки для компенсации брака. Т.е. производится SSD с запасом, но из не очень качественных чипов. При начальном тестировании бракованные просто отключаются. Если все оказались живы, то лишние блоки лежат просто мёртвым грузом (ну не выпускать же одинаковые модели с ёмкостями 240, 250, 256GB). Но думаю, всё-таки по факту пункт 3 используется, хотя от китайцев всего можно ожидать.
Эта хитрость для HDD, для SSD и флешек как я понимаю, используют «лишние» байты на служебные цели. Просто потому, что память для них делают всё-таки «круглого» двоичного размера.
Фильтр Блума так и не понял, куда тут применить. Он для оптмизиации подходит, но не для хранения.
Поможет ли тут BWT — тоже не ясно, т.е. так-то он поможет, но потом дожимать надо опять, и он очень медленный. Проще уж сразу в bzip2 сжимать :)
Естественно 90% кода лучше писать красиво, а не эффективно, но есть 10%… которые сейчас работают хорошо, а потом стреляют. Через год, в другом проекте, через утёкшую абстракцию. Когда уже никто ничего не помнит.
Несколько раз ходить по IEnumerable — это отличный способ выстрелить себе в ногу. Почему? А потому что сегодня это коллекция, а завтра это поток сообщений с удалённого сервера, который не остановить, и перемотка назад повторит все операции.
Да, это крайние случаи, и в статье про подобное сказано, но могу добавить следующее:
1. Когда пишется неоптимальный код, сразу надо думать — а есть ли возможность сделать его потом оптимально, если потребуется? Или мы в погоне за красотой должны всё переписать
2. Будет ли этот код кто-то поддерживать, или он уйдёт в библиотеку Common, которой пользуются все, но никто не помнит, что там есть и как работает
3. А может оптимальный но некрасивый код будет лучше читать? Всякие цепочки вида .Where.Select.GroupBy.Select.Where.Distinct.Any через некоторое время становятся совершенно непонятными, а тупой цикл for можно разметить комментариями и крутить в голове
4. Знаю ли я, как работает абстракция? Сколько она стоит? Возьмём Distinct — что там внутри? Какая сложность алгоритма? Не взорву ли я мир через 2 месяца?
Опять же, подчеркну, большинству кода это не надо. Но я неоднократно был свидетелем, когда вылезали жёсткие перфоманс проблемы на продакшен сервере (там данных больше и пользователи щаче ходят), которые было уже не пофиксить без серьёзного вникания в логику и переписывания больших кусков. И это времени занимало больше, чем подумать заранее и преждевременно оптимизировать.
Просто как абстрактный пример. У нас есть интернет магазин, у которого фактически 2 страницы для пользователя: список товаров и карточка товара. После первого захода может приехать куча скриптов и стилей. Но человек ходит по сайту, смотрит разные товары и по факту он получает только информацию о товаре и его фотографии. Т.е. в случае условного SPA — у него только данные придут, у него всё уже загружено. Вот в данном случае, насколько важно время первой и время последующих?
А я видел, как люди упарывались именно ради первой загрузки. Сайт открывался быстро, но потом всё дёргалось и моргало, т.к. люди обманывали тесты и роботов, чтобы сайт в выдаче был красивый, но на людей было наплевать.
IZI Travel так работает. Мы как-то в Калининграде оказались в псевдо замке (новодел для туристов со всякими шоу и едой), и там был музей пыток. В общем, собирались просто посмотреть, но увидели куркоды и с помощью колонки устроили себе аудиогида. Ещё пару раз потом подобное в других городах повторяли.
Да. Скупали что можно, наращивая складские запасы.
Баунсы и комплейнты приходят с аццкой задержкой, которую можно использовать для отключения доставки на этот ящик (пользователь не хочет), но не как гарантию доставки/недоставки.
1. linq2db — лёгкий ORM, который делает то, что сказано без всякой магии с трекингом изменений и волшебным сохранением непойми чего, непойми когда (context.SaveChanges())
2. Простые и понятные Insert/Update/Delete. Булки, которые могут работать по-разному в зависимости от провайдера
3. Интуитивные массовые операции (тот же апдейт по критерию)
4. Простые Poco классы для таблиц
5. Быстрый селект (некоторые используют Dapper для селекта, потому что EF медленный, тут не надо).
6. Понятные запросы в базу данных — т.е. они соответствуют тому, что написано, EF любит монстрячить жёсткости с вложенными селектами
7. Всякие оптимизации, типа CROSS APPLY и прочих, если потребовалось
8. Всякие хелперы, типа .LeftJoin, чтобы не писать станадартную linq магию с DefaultIfEmpty
9. Оптимизации под версии баз данных (не знаю, есть ли это у EF)
Я про вас узнал на какой-то конференции, когда был рассказ про BLToolkit, а потом попробовал и затянуло. Думаю, многие просто не знают про то, что есть такой офигенный ORM.
Просто если разработчики начинают использовать CTE, то им всё видится гвоздём.
При этом, те же а4теховые обычные унылые мыши работают месяцами от батарейки. Так что они умеют делать как надо.
Я не сторонник того, чтобы они сделали доступ бесплатным, но какие аргументы могут быть:
* Эппл каждый год доит разработчиков на $100 за возможность публиковать. Вполне себе нормальная сумма для поддержания функционирования инфраструктуры
* Одна из причин покупки телефонов эппл — возможность пользоваться магазином. Т.е. его наличие позволяет продавать телефоны, а от продажи телефонов как раз могут идти деньги и на его поддержку
И у многих требование даже не про бесплатный магазин, а то, чтобы они могли продавать самостоятельно. Сейчас, нельзя для пользователя Эппл сделать цену $10, а для пользователя браузера — $7. Это многих злит.
В целях отладки или вырубания кусков кода без ворнингов про то, что выражение всегда истинно и всё такое.
Всё нормально, всё работает, но люди жалуются, что пропала работа за 2 месяца. Мысли про какой-то аварийный откат файловой системы, потерю данных, всё такое. Сведения разрозненные. Всё работает, но что-то не то.
По итогу оказалось, 2 месяца назад мигрировали сервер на новое железо, старый выдернули из сети и оставили разборки с ним до лучших времён. При включении сотрудник решил, что не порядок, что в сервер не воткнуто питание (ага, провод выбило вместе с пробками) и воткнул старый, который и захватил власть.
Кроме того, не ясно что делает контроллер с резервированным местом. Варианты могут быть следующие:
1. Использует для информации об адресации. Т.е. фактически место занято служебными данными
2. Использует для SLC кеша (который делается не отдельным кешем а просто использованием MLC/TLC ячеек для хранения одного бита).
3. Просто холодные блоки в резерв. Которые подменяются, когда другие начинают плохо себя вести
4. Просто холодные блоки для компенсации брака. Т.е. производится SSD с запасом, но из не очень качественных чипов. При начальном тестировании бракованные просто отключаются. Если все оказались живы, то лишние блоки лежат просто мёртвым грузом (ну не выпускать же одинаковые модели с ёмкостями 240, 250, 256GB). Но думаю, всё-таки по факту пункт 3 используется, хотя от китайцев всего можно ожидать.
Поможет ли тут BWT — тоже не ясно, т.е. так-то он поможет, но потом дожимать надо опять, и он очень медленный. Проще уж сразу в bzip2 сжимать :)
Несколько раз ходить по IEnumerable — это отличный способ выстрелить себе в ногу. Почему? А потому что сегодня это коллекция, а завтра это поток сообщений с удалённого сервера, который не остановить, и перемотка назад повторит все операции.
Да, это крайние случаи, и в статье про подобное сказано, но могу добавить следующее:
1. Когда пишется неоптимальный код, сразу надо думать — а есть ли возможность сделать его потом оптимально, если потребуется? Или мы в погоне за красотой должны всё переписать
2. Будет ли этот код кто-то поддерживать, или он уйдёт в библиотеку Common, которой пользуются все, но никто не помнит, что там есть и как работает
3. А может оптимальный но некрасивый код будет лучше читать? Всякие цепочки вида .Where.Select.GroupBy.Select.Where.Distinct.Any через некоторое время становятся совершенно непонятными, а тупой цикл for можно разметить комментариями и крутить в голове
4. Знаю ли я, как работает абстракция? Сколько она стоит? Возьмём Distinct — что там внутри? Какая сложность алгоритма? Не взорву ли я мир через 2 месяца?
Опять же, подчеркну, большинству кода это не надо. Но я неоднократно был свидетелем, когда вылезали жёсткие перфоманс проблемы на продакшен сервере (там данных больше и пользователи щаче ходят), которые было уже не пофиксить без серьёзного вникания в логику и переписывания больших кусков. И это времени занимало больше, чем подумать заранее и преждевременно оптимизировать.