Как стать автором
Обновить
13
0

Пользователь

Отправить сообщение

Задумка с этим blazor-ом была интересная, но как дело подошло к релизу все больше похоже, что что-то с ним не так.

1) Получился новый фреймворк сильно отличающийся и от WinForms и от Razor-a. Такой React на C#. Т.е. толку от предыдущего опыта разработки UI на C# мало, нужно изучать все заново.

2) WebAssembly версия получилась медленной. Изначально там не было ahead of time компиляции, грешили на это. В .NET 6 ее вроде завезут, но это сильно увеличит время компиляции и размер бинарников. И возможно все равно будет медленно. С нативными приложениями (например, WinForms) по восприятию не сравнить.

3) WebAssembly получилась огромной. Размер сжатых бинарников, загружаемых клиенту, под 4 Мб. А при включенной ahead of time компиляции - под 8 Мб. И это для hello world проекта. Это будет постоянной головной болью при разработке и сопровождении. Как уменьшить размер начальной загрузки, как уменьшить объем потребляемой памяти и т.п. Оно нам надо?

4) Серверный режим работает на веб сокетах. Постоянно нужно сетевое соединение. Весь рендеринг идет на сервере. Очень-очень-очень на любителя.

5) Взаимодействие с существующими js библиотеками, скажем так, будет непростым.

6) Ну и традиционно для Microsoft все закончится тем, что новая версия фреймворка будет требовать новую версию Visual Studio, какую-нибудь новую версию браузера или работать только на Windows 12. Или вообще забьют на него в пользу другого решения. Не забываем Silverlight.

Oracle конечно виноват, но не виноват… Баг то в коде DbCommand. И только в полном .net framework. В .net 5 это, например, уже исправлено.
Опущен момент, а зачем вообще нужен AOT? Ответ прост — на сегодняшний момент в webassembly нельзя использовать jit компиляцию байт кода .net. И непонятно, когда это будет можно. Из-за этого хоть сама среда .net работает в браузере «нативно», но она может только интерпретировать байт код вашего blazor приложения. Что приводит к существенной просадке в производительности.
AOT пробует эту проблему решить, но у нее тоже будут свои накладные расходы — увеличение размера файла приложения (в несколько раз), увеличение времени компиляции (в несколько раз).
Очень не нравится, что новый интерфейс, начиная еще с 8-ки использует свой особый алгоритм сглаживания шрифтов (вроде бы grayscale) — отличный от старого интерфейса. Так, например, полностью отключить сглаживание шрифтов уже нельзя — это сработает только для старого ui, а новый — так и останется сглаженным. На retina экранах может это и не столь важно, но на стандартных 96dpi разница весьма заметна.
Есть проект CoreWCF, пока «pre-release» и «not production ready» к сожалению, но многое из классического WCF он уже поддерживает.
У Ричарда Хикки (создателя Clojure) есть отличное видео на эту тему — «Hammock Driven Development».
Legacy кстати может отлично стать и любой «шаблонный на сегодня» код. Причем поддерживать его может быть даже труднее, т.к. документация к используемым фреймворкам или библиотекам может просто в будущем оказаться недоступной. Сама же Microsoft этим часто грешит в отношении своих разработок. Так что здесь нет какого-то универсального подхода.
Мне очень нравятся простые примеры какой-то новой фичи, когда наглядно показывается, как раньше было всё плохо, а с новым нововведением стало всё хорошо. Пример с суммой чисел — это не то, чтобы я хотел видеть для асинхронных потоков.
Исправляем ситуацию… Допустим, у вас есть следующий метод
IEnumerable<FileResult> ReadFiles(string[] fileNames)
{
  foreach(var name in fileNames)
  {
    yield return ReadFile(name);
  }
}

Видите ключевое слово yield? В нем все дело.
Теперь вы узнали о чудесной конструкции async await и хотели бы применить ее к данному методу. И у вас даже есть новый метод ReadFileAsync.
Вы хотели бы, конечно, написать что-то такое
async IAsyncEnumerable<FileResult> ReadFilesAsync(string[] fileNames)
{
  foreach(var name in fileNames)
  {
    yield return await ReadFileAsync(name);
  }
}

Так вот! Раньше так нельзя было написать. А в C# 8 можно.
Задумываться над чем, простите? Может ли объект быть null? Может, т.к. это reference type. А вот сейчас мы будем смотреть, есть ли у него «знак вопроса» или нет. Но самое ужасное пока в этом новшестве то, что runtime не гарантирует, что если вы объявите свой тип без «знака вопроса», то в нем не будет null.
Т.е. вот у нас функция принимает строковый параметр (без ?). Нужно ли проверять его на null? В текущей парадигме — да, в новой — нет. Хотя null потенциально может быть и там и там.
Текущее решение — не доделано, это костыль, чтобы улучшить проверки кода на потенциальные NullReferenceException. Но оно может привести к тому, что многие начинающие или низкоквалифицированные разработчики (коих хватает) будут считать, что в таких типах null не может быть никогда и это может привести не к уменьшению, а к увеличению этих самых NullReferenceException-ов, которые как известно, мы получаем в самый неожиданный и непредсказуемый момент (иначе бы мы их выловили бы еще на стадии тестирования).
Здесь проблема, что теперь над каждым полем, свойством, параметром надо дополнительно думать, может ли оно потенциально быть null. Раньше мы думали только об Nullable значимых типах, а теперь нужно вообще обо всех типах. Причем, эта настройка только проверяет, что вы сами в вашем коде не можете присвоить null, но есть огромное число фреймворков (тот же MVC), где объекты создаются им самим из, например, http запроса. Что должно быть, если свойство не null, но в запросе его нет — exception или все-таки значение null? Сейчас это будет null. Т.е. потенциально возможно, что даже nonnullable reference type все равно будет равен null. И теперь в каждом месте программы я должен об этом думать…
Появление var, lambda функций, linq, nullable VALUE types, tuples, nameof, async await, $"..." — как же это все было круто! Благодаря этим и многим другим фичам C# сегодня — это, на мой взгляд, лучший язык программирования.
Но Nullable Reference Types — это какой-то перебор и шаг не туда.
Это очень странное решение, которое выливается в множество неочевидных нюансов, включая обратную совместимость с существующим кодом, отсутствие поддержки в runtime (хоть это и обещают сделать в следующих версиях, интересно как?) и многое другое. Уже сейчас, когда новой версией языка по сути еще никто не пользовался, это нововведение уже вызвало некий раскол среди разработчиков, т.к. плюсов и минусов у этого решения хватает.
Интересно, что Nullable Value Types (int?) такой реакции не вызывали, они очень органично «зашли» в язык.
Урок MetroUI на десктопе похоже ничему не научил. Зачем так радикально менять интерфейс, обрезать по максимуму настройки и всех пользователей силой переводить на это? Их же возненавидят. Причем, реально. В мире миллионы людей используют Skype для связи с родными в других странах и городах. Если связь в ноябре отрубится у миллионов пользователей старых версий, Microsoft быстро все вернет назад. Иначе, это так отразится на репутации их компании, что мало им не покажется. Они реально идут на очень большой риск.
Я пользуюсь Skype уже много лет. Почти каждый день — и сообщения и видео звонки. Все работает как часы. Звук и качество видео отличные, сообщения доходят мгновенно. На android телефон поставил Skype Lite — тоже очень хорошо и стабильно работает (при входящем звонке у меня телефон и десктоп звонят одновременно и синхронно играют одну и ту же мелодию — это же круто!). Итак, я большой фанат данной программы и поэтому новую десктопную 8-ку мне было особенно больно видеть. Эти странные смайлики в сообщениях, эти странные кислотные цвета, невозможность настройки шрифта. Минимум настроек. Вообщем, снес и поставил назад последнюю 7 версию. И стал счастлив снова!
Отношение к Microsoft после 8 версии Skype сильно ухудшилось. Видимо, 8-ые версии продуктов им не очень удаются (привет, Windows 8 :))
Где-то слышал, что они вроде бы отказались от планов отключить 7-ую классическую версию в этом сентябре, как планировалось — и эта версия еще будет работать достаточно долго. Хотелось бы в это верить.
Для примера, возьмем букву e. Для сглаживания могут использоваться как минимум 2 алгоритма — grayscale (в центре) и cleartype (справа). Они выглядят по разному. Вариант слева (несглаженный) выглядит всегда именно так (для такого же размера этого шрифта) и является самым четким.

image
Возьмем 2 компьютера с Windows, отключим сглаживание шрифтов, откроем блокнот и наберем в нем шрифтом Arial 12 размера один и тот же текст. Так вот этот текст будет выглядеть пиксел в пиксел одинаково и четко. Точно так же, как он выглядел в Windows 98, XP и т.д. Независимо от версии Windows, разрешения монитора и видеодрайвера.
Если же используется сглаживание шрифтов, то тот же Arial одного и того же размера, в Windows 7, Windows 10, IE 11 и MetroUI может выглядеть немного по разному, т.к. используются разные алгоритмы и параметры сглаживания.
Когда-то попадалось статья с интернете, что сглаженные шрифты некомфортны для работы определенному не очень большому проценту людей, причем это не сильно коррелирует с их остротой зрения. Это как-то связано с тем, как мозг воспринимает текст. Для кого-то важна четкость текста, а для кого-то — форма, очертания.
Мне вот тоже очень не нравится, как выглядит сглаживание шрифтов в Windows на моем 24 дюймовом FullHD мониторе — текст немного замыленный и нечеткий — и никакие настройки сглаживания ситуацию кардинально не меняют. А на телефоне с огромным ppi сглаженный текст смотрится отлично, т.к. он очень четкий.
Вообще, главное достоинство несглаженных шрифтов — что они четкие и на любых мониторах выглядят одинаково. Сглаженный же текст на каждом мониторе выглядит немного по-разному.
Поэтому в Windows приходится отключать это сглаживание всеми возможными средствами. И тут с каждой новой редакцией этой ОС ситуация все печальнее и печальнее. Если в Windows 7 сглаживание шрифтов можно отключить полностью, то в Windows 10 — уже нет. Для меня это, например, является сильным сдерживающим фактором по переходу на эту ОС.
Опять же, начиная с IE 9 Microsoft решил использовать в своем браузере только сглаженное отображение текста. А некоторые программы, например, Visual Studio 2017 используют движок IE11 для работы своих компонентов — и получаем софт, где часть текста несглажено, а часть сглажено.
MetroUI приложения в Windows 10 используют только сглаженный текст.
Проблема еще в самих шрифтах. Если вы отключите сглаживание в Windows, то можете заметить, что одни шрифты (Tahoma, Arial) выглядят лучше, чем другие (Roboto). Дело в том, что в Windows всегда была специальная оптимизация для адаптации некоторыхо шрифтов к пиксельной сетке. Плюс, сами эти шрифты были разработаны так, чтобы они хорошо смотрелись именно на дисплее. Современные шрифты уже под пиксельную сетку никто не адаптирует — поэтому они смотрятся с отключенным сглаживанием просто ужасно.

Если цель обучения — получать удовольствие от просмотра сериалов и фильмов на языке оригинала, то можно смотреть хоть с субтитрами, хоть без. Это случай, когда в переводе вам фильм смотреть менее комфортно, чем в оригинале, даже если вы не все понимаете.
Если цель — научиться понимать иностранную речь, то лучше сначала посмотреть без субтитров. Если вы не поняли больше половины слов, то посмотреть второй раз — с субтитрами, паузами, повторами и т.п. Вы точно должны знать, какие фразы сказали герои. На этом же шаге можно посмотреть в словаре значения неизвестных слов или оборотов. А после этого — посмотреть третий раз опять без субтитров. Если опять много не поняли — повторить всю процедуру :) Стоит ли это затраченного времени? Возможно. В реальном общении и по ТВ за границей субтитров же нет…
Сериалы (как и фильмы, как и аудиокниги, как и live tv) серьезно улучшают навыки аудирования.
Главное, чтобы сериал нравился. Если субтитры — то желательно английские, т.к. большинству действительно сложно воспринимать информацию на 2-х языках.
Смотреть или не смотреть с субтитрами — это все индивидуально и зависит от уровня знания языка. Я бы отключил субтитры в тот момент, когда они начинают вам мешать. Когда у вас включены субтитры, вы невольно стараетесь их читать, даже если и так понимаете, что говорят герои. С некоторого момента это начинает отвлекать и тогда субтитры можно и отключить.
Сериал сериалу рознь. В каком-то речь простая, герои говорят отчетливо и громко (обычно, это ситкомы). В другом — говорят приглушенно, жуя слова и нужно очень прислушаться, чтобы разобрать их речь. В каких-то сериалах важно действие, в каких-то важны фразы.
Я сам очень люблю смотреть американские сериалы именно в оригинальной озвучке.
Вот мой небольшой рейтинг:
1) Seinfeld — очень юморной сериал с достаточно простой речью. Сериал выдержал 9 сезонов и был одной из жемчужин NBC наравне с «Friends». У нас он мало известен.
2) Friends — речь очень беглая, во фразах много смыслов, я бы рекомендовал его смотреть с субтитрами
3) 30 Rock — тоже довольно смешной сериал с достаточно простой речью. В нем блистают Tina Fey и Alec Baldwin. Можно смотреть и без субтитров.
4) Boston Legal — интересный комедийный сериал про юридическую фирму в Бостоне. Речь довольно простая, можно смотреть без субтитров.
5) Homeland — интересный сериал на тематику спец. служб. Речь средняя по уровню, но ближе к простой. Вполне нормально смотрится без субтитров.
6) House Of Cards — очень интересный сериал о политической системе США, желательны субтитры
7) Westworld — средняя по сложности речь, но сериал интересный.
8) House M.D. — интересный сериал на медицинскую тематику. можно без субтитров
9) Desperate Housewives — довольно простая речь, можно смотреть без субтитров.
10) It Crowd — смешной британский сериал про службу техподдержки. Речь хоть и британская, но довольно простая.
Можно еще предложить сериал Rectify. Я, например, просто не могу смотреть его без субтитров, т.к. не слышу часть слов, настолько быстро и бегло говорят персонажи, хоть и не на сленге. Или, например, Дживс и Вустер или сериал про Эрклюля Пуаро — там такая британская речь, что даже с субтитрами ее сложно понять :)
Цены может сильно и не скокнули, но дефицит уже появился.
Например, на мебель, на все товары, связанные с ремонтом — стройматериалы, двери и т.п. Цены повысились на них уже сейчас на 10 и более %, при этом наблюдается очень сильный ажиотаж.
Во многих мебельных магазинах вся мебель (даже выставочные образцы) уже продана.
Для полноты картины — если название в кавычках (например, «myBigTable»), то использовать его можно только именно так и никак иначе — попытки использовать «mybigtable», myBigTable (без кавычек) или mybigtable будут приводить к ошибкам. Поэтому, наверное, такой стиль совсем не популярен.
В MySql, кстати, тоже названия таблиц приводятся к нижнему регистру во многих ОС (например, Windows). Но в нем есть настройка — lower_case_table_names, которую можно изменить и в названии можно станет использовать большие буквы.
1

Информация

В рейтинге
Не участвует
Зарегистрирован
Активность