Просидев на одном предприятии несколько лет, я решил поискать альтернативы. Специально не привожу детали по моей должности, квалификации и стажу, чтобы не создавать предвзятое впечатление и не влиять на объективность оценки выполнения тестового задания. По моему профилю вакансий оказалось довольно много. Откликнулся на первую попавшуюся вакансию очень близко к дому. Перезвонили в течении нескольких часов, обрисовали буквально в двух словах чем занимается контора (обмен данными между системами разных уровней) и предложили сделать тестовое задание. Выполнив задание примерно за сутки, я его отправил и через пару часов получил ответ: «задание Вы выполнили действительно отвратительно, халтурно» и отказ от дальнейших комментариев. По месту своей основной работы я много раз выполнял очень разные задания от очень разных людей, но такого ответа никогда не было даже близко. Что же тут произошло?
Сергей Пономарев @novar
Программист
Инфраструктура команд для вызова пользователем действий в шаблоне MVVM
10 min
10KПредставим типичный пользовательский интерфейс. Есть несколько элементов управления, которые запускают некоторые повторяемые (за время жизни приложения) действия разной сложности. Чтобы сложные действия, такие как обращение к различным носителям, обращение к сети или сложное вычисление, не снижали отзывчивость интерфейса, они должны быть асинхронными. Дополнительно могут быть элементы управления, отменяющие асинхронно запущенное действие. Действие имеет свойство состояния (неактивно, запущено, завершено успешно, завершено с ошибкой, отменено), которое тем или иным образом отображается пользователю. Принятый в WPF, Silverlight и WinPhone шаблон проектирования MVVM диктует, чтобы такое «действие» было частью модели представления, давая возможность вызывать сервисы модели из пользовательского интерфейса без создания между ними жёсткой связи. К сожалению, такое «действие» в базовой библиотеке классов не реализовано. Ближайшие имеющиеся в библиотеке сущности, такие как задачи System.Threading.Tasks.Task, команды System.Windows.Input.ICommand и делегаты System.Delegate, не подходят: задачи всегда одноразовые и не могут представлять повторяемое действие, делегаты и команды не поддерживают отмену и не содержат свойств состояния, а команды вообще не могут быть асинхронными. Далее я предлагаю решение в виде небольшой библиотеки классов, дающей возможность легко использовать описанные «действия» в ваших приложениях.
+12
Улучшаем LINQ для работы с IReadOnly-коллекциями
7 min
16KКак известно, при использовании интерфейса IEnumerable<> там, где подразумевается коллекция, могут случаться проблемы (см. например Проблемы использования IEnumerable и LINQ против LSP). К счастью, в .NET v4.5 в 2012-м году (немного поздновато, но лучше поздно, чем никогда), появились интерфейсы IReadOnlyCollection<>, IReadOnlyList<>, IReadOnlyDictionary<> (далее буду их обобщённо называть IReadOnly-интерфейсы). В отличие от IEnumerable<>, IReadOnly-интерфейсы дают возможность достаточно и без лишних требований обозначать функциональность коллекции, что и позволяет их рекомендовать для использования вместо IEnumerable<> везде, где подразумевается чтение коллекции. Но тут встречается одно затруднение. Одним из важных компонентов, потребляющим и создающим коллекции, является LINQ и, особенно, его часть «LINQ к объектам». К сожалению, IReadOnly-интерфейсы появились через 5 лет после LINQ, и в нём не используются. Все входные и выходные коллекции LINQ-операций имеют базовый тип IEnumerable<>, исходя из ограниченных возможностей которого, многие операции подразумевают лишние затраты: полный последовательный перебор или даже создание промежуточных копий входных коллекций. Более того, возвращая из операций тот же IEnumerable<>, LINQ требует при дальнейшем использовании результата опять использовать полный перебор и создание промежуточных копий. В связи с этим, у меня давно зрела мысль «подружить» LINQ с IReadOnly-интерфейсами.
+13
Удобный двоичный источник данных взамен Stream
9 min
8.4KКак обычно получают двоичные данные ваши .NET-компоненты? Если отбросить примитивный случай когда все данные уже в байтовом массиве, то уверен что в виде System.IO.Stream. В общем случае он позволяет собственно только одну операцию — считать в указанный байтовый массив (буфер) указанное количество байтов. При выполнении чтения с помощью этой операции возникают два вида затруднений и одно нерациональное использование ресурсов.
Затруднение номер один: если данные одного и того же источника нужны в нескольких компонентах, то после того как один компонент считал какие то данные из Stream, то он их «потребил», и другим компонентам они уже никак не достанутся. Затруднение номер два: данные нам нужны в виде некоторых блоков, а в результате чтения блок может оказаться в буфере лишь частично (только три байта 32-х битного числа, только половина букв слова и т.д.). Нерациональное использование ресурсов возникает из-за того, что каждый читающий данные компонент должен создавать свой собственный буфер для чтения. Далее я предлагаю простое в использовании решение указанных затруднений, которое позволит очистить ваш код, получить высокую производительность чтения и получать универсальные компоненты.
Затруднение номер один: если данные одного и того же источника нужны в нескольких компонентах, то после того как один компонент считал какие то данные из Stream, то он их «потребил», и другим компонентам они уже никак не достанутся. Затруднение номер два: данные нам нужны в виде некоторых блоков, а в результате чтения блок может оказаться в буфере лишь частично (только три байта 32-х битного числа, только половина букв слова и т.д.). Нерациональное использование ресурсов возникает из-за того, что каждый читающий данные компонент должен создавать свой собственный буфер для чтения. Далее я предлагаю простое в использовании решение указанных затруднений, которое позволит очистить ваш код, получить высокую производительность чтения и получать универсальные компоненты.
+3
Information
- Rating
- Does not participate
- Registered
- Activity