← All posts tagged programming

k0st1x

попалась мне книжка "Fluent C#"
для меня она сейчас ну прям совсем "hello world", но жаль, что в начале моего пути таких книг не нашел.
она рассказывает о том, как надо делать приложения, а не только программировать.
да еще и СТИМПАНКОВСКИЕ иллюстрации!
books.google.ru
рекомендую новичкам

k0st1x

MS анонсировали ".NET Standard 2.0"
Looking at the various flavors of .NET there is a lot of common BCL code that is not tied to App Models (WinForms, WPF, ASP.NET, etc). These APIs will be part of .NET Standard 2.0, which will be released at the same time, resulting in APIs being consistent across .NET Framework, .NET Core and Xamarin. It will be much easier to write portable code that can run on all the major .NET platforms, targeting .NET Standard 2.0.
blogs.msdn.microsoft.com

k0st1x

пробежался по статье "Сравниваем Swift и Rust"
habrahabr.ru
делаю вывод, что писать на "свифте" явное проще, понятнее, код пишется адекватнее, работает предсказуемее, по сравнению с "растом".
"раст" прям таки написан чужими для хищников.

k0st1x

не юзайте, люди, wcf duplex, ибо это зло бажное.

вот что у меня было:

если при классическом вызове (с клиента на сервер), происходит ошибка, то клиент получает Fault, который катит вместо Exception'а.

а в сценарии с Дуплексом и Callback'ом, если случается ошибка на клиенте при ответе серверу, то пипец. ошибка никуда не едет, сервер получает timeout, у channel'ов (с обоих сторон) State видится, как Open (т.е. все окей, работать можно), но общаться они больше не могут.
про ошибку можно узнать только под дебагером либо из логов.

вот пара нюаснсов:
— если пакет оказался больше чем мог бы быть (ограничение на maxReceivedMessageSize/maxArrayLength) то сервер получает timeout, но канал остается работоспособнымж
— если пакет не смог сериализоваться (KnownType не прописан), то наступает ад — сервер получает timeout exception, каналы думают, что они открыты, работать больше не могут, ивенты типа Faulted/Closed не вызываются.

я тут подумал, раз в логах видно, то можно кастомного WCF FaultHandler'а написать, навесить его через IEndpointBehavior. но и тут жопа — fault handler срабатывает только при классических ошибках — при запросе от клиента к серверу. при работе с коллбэком (FaultHandler я навесил на все каналы, на в том числе и на Callback-channel, причем на обоих сторонах — на клиенте и на сервере) он тупо не срабатывает.

гугл ответа не подсказал, на стек-оверфлоу ничего толкового не нашел.
писать самим MS как-то влом (хотя периодически это делаем на msconnect и на форумах), потому что уже запланировали переписать архитектуру, чтобы было без коллбеков.

k0st1x

только что узнал, что C#5 не умеет вот такой код

public async Task> GetItemsAsync() {
string item1 = await GetSomethingAsync();
yield return item1;

string item2 = await GetSomethingElseAsync();
yield return item2;
}

таки async/await не везде языком поддерживается

k0st1x

день открытий.
сегодня узнал, что для того, чтобы объект жил в виде ключа для Dictionary
правильнее реализовать не метод Equals()
а интерфейс IEquatable
это и рекомендуемый подход (msdn), и не придется переопределять метод GetHashCode()