SupperMapping - это класс Python, который предоставляет удобный интерфейс для работы со словарями с возможностью обратного отображения.
Сопоставление шаблонов (pattern matching) и исчерпывающие переключатели (exhaustive switches) объединяются для создания функциональных моделей данных, которые легко сочетаются с объектно-ориентированным ядром Dart. ?
В этой статье мы создадим desktop-приложение, которое по нашему запросу будет сохранять на нашем диске заданное количество картинок. Так как картинок будет много, мы воспользуемся асинхронностью Python для конкурентной реализации операций ввода-вывода. Посмотрим, чем отличаются библиотеки requests и aiohttp. Также создадим два дополнительных потока приложения, чтобы обойти глобальную блокировку интерпретатора Python.
Руслан Гнатовский aka @Number55 в свой статье Когда ни туда, ни сюда, или в поисках оптимальной границы Domain слоя описал известную проблему протекания бизнес-логики из агрегата, в случае если эта логика зависит от данных которые находятся вне агрегата, и предложил несколько решений этой проблемы, каждое из которых не лишено недостатков. Многие из этих недостатков были описаны в статье а также в комментариях поэтому я не буду здесь дублировать эту информацию а попытаюсь предложить решение которое этих недостатков лишено.
Привет, Хаброжители!
Не секрет, что при формировании новой команды руководители (Team Leader, Tech Leader) сталкиваются с проблемой формирования единого стиля написания программ, так как все члены команды новые, и у каждого из них свой подход к организации кода и выбору используемой практики. Как правило, в большинстве случаев это приводит к длинным диспутам на ревью, которые в итоге перетекают в различные толкования известных практик, таких как SOLID, KISS, DRY, и т.д. Принципы использования этих практик довольно размыты и, при должном упорстве, легко найти парадокс, когда одна из них противоречит другой. Например, рассмотрим Single Responsibility и DRY.
Одна из вариаций определения принципа единой ответственности (Single Responsibility - буква S из аббревиатуры SOLID) гласит, что каждый объект должен иметь одну ответственность, и эта ответственность должна быть полностью инкапсулирована в класс. Принцип DRY (Don’t repeat yourself) предлагает избегать дублирования в коде. Однако, если у нас в коде есть один набор данных (DTO), который может использоваться в разных слоях/сервисах/модулях, какому из этих принципов нам следовать? Безусловно, во многих книгах по программированию разбираются похожие ситуации, как правило, в них говорится, что если речь идет о разных объектах/функциях с одинаковым набором свойств и логики, но принадлежащим разным доменным областям, то дублированием это не является. Но как доказать что эти объекты ДОЛЖНЫ принадлежать разным доменным областям, и, главное, готов (и уверен ли в своих силах) руководитель доказывать это утверждение?
Собственно говоря, зачем эта статья и для кого? Для тех, кто только начинают свой путь в изучении Java. В этой статье я не буду сильно углубляться в детали каждой коллекции в отдельности, ведь чтобы начать ими пользоваться достаточно хотя бы на базовом уровне понять, что это такое и с чем это «едят».
Чаще всего задачу можно решить интуитивно понятным процедурным способом. Однако самый простой вариант не всегда самый лучший. Предлагаю посмотреть на примере реальной задачи, как можно сделать решение объектно-ориентированным, и какую пользу это может принести.
В этой статье мы продолжим разбирать содержание работы Stephen Toub-а: «How Async/Await Really Works in C#». В этот раз, в след за автором исходного Поста мы рассмотрим код, который генерирует C# компилятор для реализации асинхронных вызовов и множество связанных с этим сущностей-понятий-приемов, таких как: контекст исполнения, боксинг, стейт машина, стек, потоки, … Эта 6-я часть, пожалуй, основная часть всей работы, которая непосредственно отвечает на вопрос: «Как на самом деле Async/Await работают (и компилируются) в C#»
Там, где мне придется цитировать содержание исходного текста в переводе (то есть более-менее дословно переводить), оно будет выделено подчеркнутым курсивом.
Возможно вам будет интересно сравнить эту мою работу с первоначальным переводом.
В 1978 году вышел третий том монографии Дональда Кнута «Искусство программирования», где автор рассматривает алгоритмы сортировки и поиска. Помимо самих алгоритмов описаны аппаратные характеристики компьютера и их влияние на производительность при работе с алгоритмами.
В 2024 году мы с вами возьмём классические алгоритмы сортировки и посмотрим, как работает современный многоядерный процессор при сортировке нескольких массивов на одном и нескольких логических ядрах. Мы напишем приложение с графическим интерфейсом (GUI) на фреймворке Qt, обойдем глобальную блокировку интерпретатора (GIL), воспользуемся несколькими потоками, на один из которых переложим выполнение асинхронного цикла событий, и распараллелим этот поток для реализации параллельных вычислений.
«ООП для меня означает лишь обмен сообщениями, локальные ограничения и защиту, сокрытие состояния процесса и крайне позднее привязывание», — Алан Кэй (человек, придумавший термин «объектно-ориентированное программирование»)1
Возможно 11 подписчиков моего блога обратили внимание на тот факт, что все мои статьи касаются языка Wolfram, а несколько последних статей вышли довольно громоздкими. Одна из последних статей была помечена Хабром как требующая в среднем 32 минуты на прочтение. Я посчитал, что это может отпугнуть пользователей (все 11 человек и не факт, что все они до сих пор читают Хабр) и решил попробовать писать более короткие статьи. Плюс я сам перестану теряться в большом количестве текста.
Данная статья является полностью самостоятельной и ценна для меня сама по себе, но она так же является подготовительной частью к другой статье, которая связана с одной несложной алгоритмической задачей и пока что находится в черновиках. Пока я писал ее - я понял, что выйдет много текста и кода, поэтому я решил разбить ее на несколько частей.
Ниже реализация структуры данных LinkedList на Wolfram Language.
Привет!
Сегодня я хочу поговорить про GRASP. В то время как многие знакомы с SOLID, GRASP, хотя и известен, мало кто в геймдеве воспринимает его всерьёз (или хотя бы знают о нем). GRASP расшифровывается как общие шаблоны распределения ответственностей. Самые часто упоминаемые принципы GRASP известны гораздо шире, чем сам список, в который они включены. Это знаменитые слова про низкую связность и высокое зацепление.
В этой статье представлены такие паттерны, как Abstract Document, Monad, Object Mother, Object Pool, Step Builder. Примеры приведены на .NET 7 и C#. Приятного чтения.
Продолжение в статье "Сто паттернов для разработки корпоративных программ. Часть 2.2".
В этой статье рассмотрены все паттерны проектирования из "Банды четырёх" с примерами на языке программирования C#. Для самых терпеливых имеются дополнительные паттерны.
Это первая статья из серии "Сто паттернов для разработки корпоративных программ". Следующие статьи будут посвящены паттернам из книг Мартина Фаулера и Роберта Нистрема.
Привет всем. Меня зовут Артурас, я пишу на Javascript. Полтора года назад я уволился из оффшорной компании и решил написать свой движок для браузерных 2d игр. Сегодня - делюсь результатами.
И снова всем привет! Продолжение к переводу второй части книги Patterns.dev
В ней речь идет про паттерны производительности. Узнайте, как оптимизировать последовательность загрузки, чтобы повысить скорость использования вашего приложения и др.
Напомню, что авторы Patterns.dev:
Лидия Холли — штатный консультант и преподаватель по разработке программного обеспечения, которая в основном работает с JavaScript, React, Node, GraphQL. Она также занимается наставничеством и проводит личные тренинги.
Эдди Османи — технический менеджер, работающий над Google Chrome. Его команды работают над такими проектами, как Lighthouse, PageSpeed Insights, Chrome User Experience Report и другими.
Материал книги будет полезен не только React‑разработчикам, но и всем, кто так или иначе интересуется или сталкивается с frontend‑разработкой. Это ознакомительная часть перевода учебника https://www.patterns.dev/. Перевод всей третьей части учебника можно найти здесь.
P. P. S.: Третья часть взята из книги: https://www.patterns.dev/, переведена на русский язык. Книга находится под лицензией CC BY-NC 4.0
Данный адаптированный материал распространяется на условиях лицензии Creative Commons Attribution-NonCommercial 4.0 International (CC BY-NC 4.0)
