Для большинства разработчиков использование expression tree ограничивается лямбда-выражениями в LINQ. Зачастую мы вообще не придаем значения тому, как технология работает «под капотом».

В этой статье я продемонстрирую вам продвинутые техники работы с деревьями выражений: устранение дублирования кода в LINQ, кодогенерация, метапрограммирование, транспиляция, автоматизация тестирования.

Вы узнаете, как пользоваться expression tree напрямую, какие подводные камни приготовила технология и как их обойти.



Под катом — видео и текстовая расшифровка моего доклада с DotNext 2018 Piter.

Привет, Хабр! Сегодня мы отобрали 9 самых интересных лайфхаков для работы с Visual Studio Code. Среди них полезные сочетания клавиш и функциональные виджеты. Подробности под катом!

Привет Хабр.

Raspberry Pi наверное есть дома почти у каждого, и рискну предположить, что у многих она валяется без дела. А ведь Raspberry это не только ценный мех, но и вполне мощный fanless-компьютер с Linux. Сегодня мы рассмотрим полезные возможности Raspberry Pi, для использования которых код писать не придется совсем.

Для тех кому интересно, подробности под катом. Статья рассчитана для начинающих.

Платформа .NET предоставляет множество готовых примитивов синхронизации и потокобезопасных коллекций. Если при разработке приложения нужно реализовать, например, потокобезопасный кэш или очередь запросов — обычно используются эти готовые решения, иногда сразу несколько. В отдельных случаях это приводит к проблемам с производительностью: долгим ожиданием на блокировках, избыточному потреблению памяти и долгим сборкам мусора.

Эти проблемы можно решить, если учесть, что стандартные решения сделаны достаточно общими — они могут иметь избыточный в наших сценариях оверхед. Соответственно, можно написать, например, собственную эффективную потокобезопасную коллекцию для конкретного случая.

Под катом — видео и расшифровка моего доклада с конференции DotNext, где я разбираю несколько примеров, когда использование средств из стандартной библиотеки .NET (Task.Delay, SemaphoreSlim, ConcurrentDictionary) привело к просадкам производительности, и предлагаю решения, заточенные под конкретные задачи и лишённые этих недостатков.

Несмотря на желтый заголовок, дальше будет не желтая статья. Всех нас (я надеюсь именно здесь я наконец-таки смогу сказать от всего сообщества) уже достали действия Роскомнадзора. А также его постоянное появление в рекомендованном на хабре. Поэтому эта новость вам понравится. Хоть что-то важное. Новость кстати еще от декабря 2018.

​

Вступление

Идентификация по JWT (JSON Web Token) — это довольно единообразный, согласованный механизм авторизации и аутентификации между сервером и клиентами. Преимущества JWT в том, что он позволяет нам меньше управлять состоянием и хорошо масштабируется. Неудивительно, что авторизация и аутентификация с его помощью все чаще используется в современных веб-приложениях.

Автор статьи, перевод которой мы сегодня публикуем, говорит, что React — это её любимая библиотека для создания интерактивных интерфейсов. React одновременно и лёгок в использовании, и достаточно хорошо защищён. Однако это не значит, что React-приложения совершенно неуязвимы. Очень легко впасть в неоправданное спокойствие, решив, что о XSS-атаках можно не волноваться из-за того, что в проекте используется React.

Уязвимости React чаще всего проявляются тогда, когда разработчик думает, что он использует защитные механизмы этой библиотеки, хотя на самом деле оказывается, что это не так. Поэтому важно правильно оценивать возможности React, и знать о том, какие задачи программисту нужно решать своими силами.



Сегодня мы поговорим о типичных уязвимостях React, о том, как находить их во время код-ревью, и о том, как от них защищаться.

.NET – управляемая среда выполнения. Это означает, что в ней представлены высокоуровневые функции, которые управляют вашей программой за вас (из Introduction to the Common Language Runtime (CLR), 2007 г.):

Среда выполнения предусматривает множество функций, поэтому их удобно разделить по следующим категориям:

1. Основные функции, которые влияют на устройство других. К ним относятся:
   1. сборка мусора;
   2. обеспечение безопасности доступа к памяти и безопасности системы типов;
   3. высокоуровневая поддержка языков программирования.
2. Дополнительные функции– работают на базе основных. Многие полезные программы обходятся без них. К таким функциям относятся:
   1. изолирование приложений с помощью AppDomains;
   2. защита приложений и изолирование в песочнице.
3. Другие функции – нужны всем средам выполнения, но при этом они не используют основные функции CLR. Такие функции отражают стремление создать полноценную среду программирования. К ним относятся:
   
   1. управление версиями;
   2. отладка/профилирование;
   3. обеспечение взаимодействия.

Видно, что хотя отладка и профилирование не являются основными или дополнительными функциями, они находятся в списке из-за ‘стремления создать полноценную среду программирования’.

Предыстория

У меня есть убогий дешевый планшет на Windows 10 с одним гигабайтом оперативной памяти и 16 гигабайтами места, в пределах которого установлен Windows 10. Чтобы Windows 10 мог хоть как-то скачивать и устанавливать обновления — я скрутил размер файла подкачки в ноль и файл pagefile.sys перестал занимать драгоценные гигабайты.

После этого я с удивлением обнаружил, что для просмотра более-менее крупных сайтов на этом планшете невозможно использовать ни Chrome, ни Internet Explorer, ни даже старую Opera 12. Все они пытаются пару раз показать сайт, перезагружают его снова (он, по видимости, не влезает в настоящую оперативную память без файла подкачки) и выдают после второй попытки загрузки сообщение о неудаче.

Почему при размере исходного HTML-кода сайта в несколько сотен килобайт — компьютер с гигабайтом оперативной памяти не может его отрисовать?

Предыстория

Есть у меня маленький и уютный pet-project, который позволяет качать файлы из интернета. Файлы при этом группируются и пользователю отображается не каждый файл, а некоторая группировка. И весь процесс скачивания (и отображение этого процесса) сильно зависел от данных. Данные при этом получались на лету, т.е. пользователь запускает на скачивание и нет никакой информации, сколько придётся качать в реальности.

Наивная реализация хоть какого-то информирования сделана простой — отображается прогресс скачивания как отношение количества скачанных к общему количеству. Информации для пользователя не много — просто ползущая полоска, но это уже лучше чем ничего, и это заметно лучше чем популярный нынче механизм загрузки без индикации прогресса.

И тут появляется пользователь с логичной проблемой — на большой группировке непонятно, почему прогресс еле ползёт — много файлов надо скачать или низкая скорость? Как я упоминал выше — количество файлов заранее неизвестно. Поэтому, я принял решение добавить счетчик скорости.

Анализ

Хорошая практика — посмотреть тех, кто уже решал аналогичную задачу, чтобы не изобретать велосипед. Разный софт закрывает этим разные задачи, но выглядит отображение довольно одинаково:

Ключевой момент, который я выделил для себя — в первую отображение скорости нужно на текущий момент времени. Не какая скорость была средней, не какая скорость в целом средняя с момента начала, а именно какова эта цифра на текущий момент. На самом деле это важно, когда дойду до кода — поясню отдельно.

Итак, нам нужна простая цифра вида 10 MB/s или что-то подобное. Как же нам её посчитать?

Эта шпаргалка поможет вам подготовиться к техническому собеседованию, чтобы вы могли освежить в памяти ключевые вещи. По сути, это содержание курса по информатике безо всяких подробностей.

Предисловие к переводу

В отличие от научных статей, статьи данного типа сложно переводить "близко к тексту", приходится проводить довольно сильную адаптацию. По этой причине приношу свои извинения, за некоторую вольность, с моей стороны, в обращении с текстом исходной статьи. Я руководствуюсь лишь одной целью — сделать перевод понятным, даже если он, местами, сильно отклоняется от исходной статьи. Буду благодарен за конструктивную критику и правки / дополнения к переводу.

Введение

Пространство имен System.Threading.Tasks и класс Task впервые были представлены в .NET Framework 4. С тех пор, этот тип, и его производный класс Task<TResult>, прочно вошли в практику программирования на .NET, стали ключевыми аспектами асинхронной модели, реализованной в C# 5, с его async/await. В этой статье я расскажу о новых типах ValueTask/ValueTask<TResult>, которые были введены с целью повышения производительность асинхронного кода, в тех случаях, когда ключевую роль играют накладные расходов при работе с памятью.

Замечания:
1. В предыдущей заметке "time zone" я перевёл как «временнАя зона», поскольку речь шла о часовых поясах США, имеющих специфическое название. В данном случае корректнее использовать "часовой пояс". Здесь используется более корректный перевод.

2. Небольшая врезка из Википедии даст вам понимание что такое UTC и чем оно отличается от GMT —

Всеми́рное координи́рованное вре́мя (UTC) — стандарт, по которому общество регулирует часы и время. Отличается на целое количество секунд от атомного времени и на дробное количество секунд от всемирного времени UT1.

UTC было введено вместо устаревшего среднего времени по Гринвичу (GMT). Новая шкала времени UTC была введена, поскольку шкала GMT является неравномерной шкалой и связана с суточным вращением Земли. Шкала UTC основана на равномерной шкале атомного времени (TAI) и является более удобной для гражданского использования.

Часовые пояса вокруг земного шара выражаются как положительное и отрицательное смещение от UTC.

Следует помнить, что время по UTC не переводится ни зимой, ни летом. Поэтому для тех мест, где есть переход на летнее время, меняется смещение относительно UTC.


Теперь продолжим разбираться со структурами, обслуживающими такие сущности, как дата и время.

Через некоторое время после публикации твита о Noda Time, меня начали спрашивать, какой смысл в использовании Noda Time — люди верили, что поддержка дат и времени в .NET вполне хороша. Я конечно не видел их код, но подозреваю, что практически любая кодовая база, имеющая дело с датами, станет яснее, если будет использовать Noda Time, а также, вполне возможно, станет более корректной благодаря подходу, с помощью которого Noda Time заставляет вас принимать некоторые, не очевидные в .NET, решения. В этой заметке мы обсудим недостатки .NET API, обеспечивающего работу с датами и временем. Моё отношение к этой теме выглядит несколько предвзятым, но я надеюсь, что эта заметка не выглядит неуважительно по отношению к команде, работающей над BCL (Base Class Library — прим. переводчика) — поскольку, кроме всего прочего, они работают в условиях, заставляющих их принимать во внимание взаимодействие с COM и т.п.

Как-то раз моему коллеге в беклог упала задача «хотим организовать взаимодействие с внутренним REST-api так, чтобы любое изменение контракта сразу приводило к ошибке компиляции». Что может быть проще? – подумал я, однако работа с получившимся кактусом вынудила заняться многочасовым курениям документации, спуску от привычных концепций оверинжинеринга «налепим побольше интерфейсов, добавим максимум косвенности, и приправим всё это DI» до переезда на .Net Core, ручной кодогенерации промежуточного ассемблера и изучения нового компилятора C#. Лично я для себя открыл много интересного как в рантайме, так и в структуре самого компилятора. Думаю, некоторые вещи хабровчане уже знают, а некоторые станут полезной пищей для размышления.

Компания Apple активно внедряет в массы идею о том, что теперь-то с приватностью данных пользователей их продукции всё в порядке. Но исследователи из Hexway выяснили, что стандартный и активно используемый механизм Bluetooth LE (BLE) позволяет узнать довольно много о твоем айфончике.

Если Bluetooth включен, то любой человек в радиусе действия сигнала может узнать:

• состояние устройства;
• информацию о заряде;
• имя устройства;
• состояние Wi-Fi;
• доступность буфера;
• версию iOS;
• номер телефона.

Иногда это является полной неожиданностью и даже потрясает — то, как близкие по мироощущению люди, близкие по возрасту, образованию, окружению, фильмам, которые смотрели, книгам, которые читали, могут по-разному интерпретировать одни и те же события. На основе одних и тех же источников информации, обладая хорошими IQ, непредвзято, они приходят ровно к противоположным выводам.

Очевидно, что как минимум кто-то в этой ситуации находится в состоянии иллюзии.
Как так получается, что ни хорошее образование, ни доступность информации, ни развитая способность логически мыслить не защищают нас от концептуальных ошибок в восприятии и интерпретации, как получается так, что мы не распознаем манипуляцию и ложь? Споры, наблюдения и размышления в конце концов привели меня к образу мыслей, изложенному в этой статье.

Здесь приведено 14 распространенных манипуляций. Анализируя свою жизнь, я могу сказать, что ощущал в разное время воздействия каждой из них, а некоторые методы «промывки мозгов» по отношению ко мне были по-настоящему эффективны. Думаю, это всем хорошо знакомые атаки. Я упорядочил их в некий список и попытался описать механизмы и причины, почему они, несмотря на тривиальность, являются довольно эффективными.

Я не рассматриваю элементарные воздействия такие, как подкуп, шантаж и запугивание. В этой статье меня интересуют лишь атаки, заставляющие нас жить в иллюзии.

В конце статьи я также попытаюсь дать ответ на вопрос, почему ложь может легко обмануть наш интеллект и, более того, использовать его себе на благо, почему наше образование и доступность информации не помогают нам.

Это не статья по психологии и не статья по философии, хотя бы потому, что в этой статье не будет приведено ни одной ссылки.

В своей практике я часто встречаю, в различном окружении, код вроде того, что приведен ниже:

[1] var x = FooWithResultAsync(/*...*/).Result;

//или
[2] FooAsync(/*...*/).Wait();

//или
[3] FooAsync(/*...*/).GetAwaiter().GetResult();

//или
[4] FooAsync(/*...*/)
    .ConfigureAwait(false)
    .GetAwaiter()
    .GetResult();

//или
[5] await FooAsync(/*...*/).ConfigureAwait(false)

//или просто
[6] await FooAsync(/*...*/)

Из общения с авторами таких строк, стало ясно, что все они делятся на три группы:

• Первая группа, это те, кому ничего не известно о возможных проблемах с вызовом Result/Wait/GetResult. Примеры (1-3) и, иногда, (6), типичны для программистов из этой группы;
• Ко второй группе относятся программисты, которым известно о возможных проблемах, но они не знают причин их возникновения. Разработчики из этой группы, с одной стороны, стараются избегать строк вроде (1-3 и 6), но, с другой, злоупотребляют кодом вроде (4-5);
• Третья группа, по моему опыту самая малочисленная, это те программисты, которые знают о том, как код (1-6) работает, и, поэтому, могут сделать осознанный выбор.

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

В коде самых разных проектов нередко приходится оперировать временем — например, чтобы завязать логику работы приложения на текущее время у пользователя. Старший разработчик интерфейсов Виктор Хомяков victor-homyakov описал типичные ошибки, которые встречались ему в проектах на языках Java, C# и JavaScript от разных авторов. Перед ними вставали одни и те же задачи: получить текущую дату и время, измерить интервалы или выполнить код асинхронно.



— До Яндекса я работал в других продуктовых компаниях. Это не как фрилансер — написал, сдал и забыл. Приходится очень долго работать с одной кодовой базой. И я, собственно, смотрел, читал, писал много кода на разных языках и увидел много чего интересного. В итоге у меня родилась тема этого рассказа.

Пару месяцев назад я наткнулся на интересный вопрос на stackoverflow, там, если вкратце, человек хотел создать пустую матрицу 5х5, и, используя один способ у него получилось, а используя другой — нет. В развернувшейся дискуссии на этот счёт были приведены интересные мысли.

Правда, задавший вопрос, так же как и те кто ему отвечал, не обратили внимания, на то, что фактически матрицу не получилось создать, а приведенный результат вычислений некорректен. Всё это меня заинтересовало, и, я решил копнуть чуть глубже, чтобы затем прийти к интересным умозаключениям, с которыми сейчас с вами и поделюсь.

Написать данную заметку меня сподвигло прочтение статьи на Хабре «Var, let или const? Проблемы областей видимости переменных и ES6» и комментариев к ней, а также соответствующей части книги Закаса Н. «Understanding of ECMAScript 6». Исходя из прочитанного я вынес, что не всё так однозначно в оценке использования var или let. Авторы и комментаторы склоняются к тому, что при отсутствии необходимости поддержки старых версий браузеров имеет смысл полностью отказаться от использования var, а также использовать некоторые упрощенные конструкции, заместо старых, по умолчанию.

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