Короткий ответ: нет. Тем не менее, раз про это вновь и вновь спрашивают на Reddit, Stack Overflow и других сайтах, пришло время подробно разобрать эту тему. Оказывается, есть много интересного, о чём можно порассуждать.
В одной из предыдущих статей, посвященных анализу этого (все того же) Поста, я написал что «не возьмусь переписать всю эту хитрую логику, связанную с формированием последовательности вызовов сгенерированной функции на человеческом языке». Но подробно разбирая 5-ю главу того Поста у меня это вроде бы все-таки получилось сделать. Прошу вас оценить результаты этого труда.
Там где мне придется цитировать (назовем это так) содержание исходного текста в переводе, оно будет выделено подчеркнутым курсивом.В предыдущей статье я попробовал поэкспериментировать с особым форматированием, но это не всегда удобно читателю, на сколько я понимаю.
В статье «Ускоряем анализ данных в 180 000 раз с помощью Rust» показано, как неоптимизированный код на Python, после переписывания и оптимизации на Rust, ускоряется в 180 000 раз. Автор отмечает: «есть множество способов сделать код на Python быстрее, но смысл этого поста не в том, чтобы сравнить высокооптимизированный Python с высокооптимизированным Rust. Смысл в том, чтобы сравнить "стандартный-Jupyter-notebook" Python с высокооптимизированным Rust».
Возникает вопрос: какого ускорения мы могли бы достичь, если бы остановились на Python?
Под катом разработчик Сидни Рэдклифф* проходит путь профилирования и итеративного ускорения кода на Python, чтобы выяснить это.
*Обращаем ваше внимание, что позиция автора может не всегда совпадать с мнением МойОфис.
Этот пост посвящён памяти Никлауса Вирта, первопроходца в сфере вычислительных наук, ушедшего от нас 1 января этого года. В 1995 году он написал важную статью A Plea for Lean Software, и в своём посте я постараюсь воспроизвести её почти тридцать лет спустя, с учётом современных кошмаров разработки ПО.
Очень короткая версия поста: современные способы разработки/сборки ПО смехотворны, они приводят к созданию пакетов на 350 МБ для рисования графиков, а простые продукты импортируют 1600 зависимостей неизвестного происхождения. Уровень безопасности ПО ужасен, ведь он зависит и от качества кода, и от его объёма. Многие из нас понимают, что ситуация нерациональна. К сожалению, многие программисты (и их руководство) никогда не работали как-то иначе. А остальным редко выделяют время, чтобы выполнять работу качественно.
В этом посте я сделаю краткий обзор ужасного уровня безопасности современного ПО, а затем порассуждаю о том, почему он настолько плох. Также я упомяну нормативные/юридические аспекты, которые могли бы снова сделать качество ПО приоритетным. Наконец, я расскажу о написанном мной полезном ПО , позволяющем доказать, что сегодня по-прежнему можно разрабатывать минималистичное и простое ПО, остающееся современным.
Надеюсь, этот пост станет моральной поддержкой для страдающих программистов и технологов, стремящихся улучшить ситуацию. Дело не только в вас, и мы не просто страдаем от ностальгии: ПО сегодня действительно очень странное.
Привет, Хабр! Меня зовут Николай Пискунов, я ведущий разработчик в подразделении Big Data. В блоге beeline cloud мои коллеги уже знакомили вас с SOLID, заглядывали под капот Python. Я же расскажу о том, как с наименьшими затратами получить динамически изменяемый запрос к БД, используя Spring Data JPA и Hibernate.
Самый простой пример — реализация эндпоинта, который обрабатывает запросы фильтра интернет-магазина. Например, когда вы задаете характеристики, согласно которым возвращаются определенные товары.
К сожалению, баги - это неотъемлемая часть процесса разработки программного обеспечения. Но я обратил внимание, что одни команды допускают значительно меньше багов, чем другие.
Почему так происходит? - задался я вопросом.
Привет, Хабр!
Все знают, что SOLID и DRY делают код более чистым, гибким и, что немаловажно, понятным для других разрабов. Каждый компонент выполняет свою функцию и вместе они создают гармонию.
В этой статье рассмотрим как эти принципы применяются в golang.
В этот раз я достаточно внимательно прочитал перевод главы про задачи(Tasks) из этого Поста, чтобы выяснить, что он не очень точно передает смысл исходного текста. Я попробую пересказать содержание так, как я его понял, в том числе полагаясь на свой практический опыт программирования многопоточных приложений и embedded приложений с множеством прерываний.
Мне кажется, я придумал хороший формат, чтобы совместить свой пересказ содержания достаточно близко к смыслу исходного текста (надеюсь), с моими комментариями-разъяснениями-догадками.
Пару ссылок на предыдущие работы по этой теме вы тоже найдете под катом.
Go - один из немногих языков, в которых структуры можно передавать параметрами и возвращать из функций как по значению, так и по указателю. Это приводит к большей выразительности языка, но также разделяет общество разработчиков Go на два лагеря: сторонников указателей и сторонников значений.
В данной статье предлагается во многом субъективное сравнение обоих способов и делается попытка убедить читателей передавать и возвращать значения в тех случаях, где это возможно.
Насколько я понял из комментариев к своим предыдущим статьям по этой теме:
1. Часть 1. Проблемы модели асинхронного программирования (APM)
2. Уроки по асинхронному программированию из первой половины работы
3. Параллельные вычисления — Все дело в контексте-синхронизации (SynchronizationContext)
4. Async/Await из C#. Головоломка для разработчиков компилятора и для нас
и по количеству просмотров, тема все еще вызывает интерес, поэтому я хочу попробовать продолжить, но не просто перевод, а перевод С ПОЯСНЕНИЯМИ, хотя и сам перевод тоже должен отличаться от первоначального варианта, поскольку я его не читал, только по результатам, мельком, глянул пару абзацев. К тому же автор того первоначального перевода просил помощи с переводом, поэтому я надеюсь, мой вариант в чем-то сможет помочь в этом смысле или просто будет интересен с точки зрения сравнения.
Потом, мне кажется, что есть несколько читателей, которым будет интересен именно мой вариант перевода, вот для них, в первую очередь, я и продолжаю писать.
Я рискну все таки продолжить изложение своего понимания Поста: How Async/Await Really Works in C#, которое в предыдущей статье получило название “ортогональный взгляд”. Также, недавно мы познакомились (возможно несколько преждевременно) с изначальным определением концепции SynchronizationContext на которую ссылается автор этого Поста.
Это не перевод. Это изложение содержания Поста на разных уровнях раскрытия сущностей и их взаимодействия по мере развития (эволюции) моего понимания тех мыслей и идей, которые, как мне кажется, хотел донести до читателя автор Поста Stephen Toub.
То есть я пишу о том, что и как я понял из этого текста и стараюсь обосновать это свое понимание из найденного материала по теме, а вы одобряете или критикуете/уточняете то, что у меня получилось сформулировать. Таким образом мы самым естественным образом получим хорошую и полную интерпретацию содержания статьи на нашем родном языке, надеюсь, да еще и обогащенную критикой возможных заблуждений происходящих из недостаточности или неполноты изложения, например, по этой теме.
В этот раз попробуем сформулировать задачу, которую решает компилятор, то есть те разработчики, которые разрешили нам пользоваться конструкциями Async/Await в C#.
Всем привет! Недавно мне выпала возможность разработать шаблон сервиса, который можно было бы использовать как для монолитной, так и для микро‑сервисной архитектуры. Шаблон должен был придерживаться принципов Domain‑Driven Design (DDD). В этом процессе, я столкнулся с двумя интересными проблемами:
Проблема 1: Сложности обеспечения транзакционности базы данных
При разработке сервисов, часто возникает неотъемлемая потребность в использовании транзакций базы данных для обеспечения целостности данных. Однако, при попытке интегрировать транзакционную логику в традиционные подходы, столкнулся с трудностями. Связывание транзакционной логики с логикой слоя базы данных оказалось нетривиальным и привело к нарушению принципов разделения ответственности. Это, в свою очередь, сказалось на тестировании и поддержке кода.
Проблема 2: Нарушение изолированности слоя
В попытке решить первую проблему, некоторые разработчики переносят работу с транзакциями на уровень слоя приложения, чтобы избежать прямой зависимости от базы данных. Однако, такой подход, несмотря на его обоснование, может нарушить изолированность слоев и противоречить принципам DDD и чистой архитектуры. Это, в конечном итоге, затрудняет поддержку приложения и усложняет его масштабирование.
Эти две проблемы стали отправной точкой для исследования применения паттерна Unit of Work и его роли в обеспечении надежности и консистентности данных в контексте Golang и DDD.
В статье я расскажу о своем подходе к решению этих задач.
Чтобы до конца разобраться с содержанием Поста: How Async/Await Really Works in C#, который мы начали анализировать в предыдущей статье, неплохо бы познакомиться с изначальным определением концепции SynchronizationContext, на которую ссылается автор этого поста, без которой, по мнению того же автора, нельзя понять реализацию Async/Await.
Это перевод Поста: Parallel Computing - It's All About the SynchronizationContext
В этой статье мы познакомимся с бинарным поиском с примером на JavaScript, а так же сравним бинарный поиск и линейным.
Просматривая недавно соцсети, я наткнулся на этот скриншот. Разумеется, его сопровождало множество злобных комментариев, критикующих попытку этого новичка в программировании решить классическую задачу computer science: операцию деления с остатком.
В современном мире, где ИИ постепенно заменяет программистов, отнимая у них работу и совершая переворот в том, как мы подходим к рассуждениям о коде, нам, возможно, следует быть более открытыми к мыслям людей, недавно пришедших в нашу отрасль? На самом деле, показанный выше код — идеальный пример компромисса между временем и задействованной памятью. Мы жертвуем временем и в то же время памятью и временем компьютера! Поистине чудесный алгоритм!
Поэтому я решил изучить эту идею проверки чётности числа при помощи одних сравнений, чтобы понять, насколько хорошо она работает в реальных ситуациях. Я сторонник высокопроизводительного кода, поэтому решил реализовать это на языке программирования C, потому что он и сегодня остаётся самым быстрым языком в мире с большим отрывом от других (благодаря гению Денниса Ричи).
Несмотря на то, что с предыдущей статьей-переводом мы выяснили что перевод уже есть на Хабре я рискну продолжить анализ этой работы.
Теперь это НЕ перевод. Это моя интерпретация тех частей содержания первой половины Поста: Как на самом деле Async/Await работают в C#, которые мне показались заслуживающими внимания в этой работе, с моими пояснениями относительно того почему у меня возникла именно такая интерпретация материала.
Судя по количеству просмотров, работа вызывает интерес, но пробиться сквозь нагромождение терминов трудно даже для подготовленного читателя, как мне кажется. Я хочу попробовать перевести не с английского на русский, а с некоторого кулуарно-профессионального на какой-то более доступный язык. Не знаю, насколько доступный, надеюсь получить некоторый отклик, который поможет мне понять, насколько у меня это получилось. Заранее хочу сказать, что автор действительно изложил как или во что компилируются конструкции Async/Await и, соответственно, как они работают изнутри. Проблема в том, что автору пришлось написать большую подготовительную часть чтобы подвести к изложению этого внутреннего устройства Async/Await. И мне, волей неволей, придется пройтись по всему что предваряет, собственно, основную идею в реализации Async/Await. Поэтому запаситесь терпением либо начинайте читать сразу последнюю часть.
Это обзор только первой половины Поста, возможно по результатам анализа второй половины или по вашим замечаниям мне придётся пересмотреть какие-то мои выводы, я не претендую на абсолютное знание.
Дисклеймер 1
Я подозреваю что некоторых может шокировать, что я объясняю высокие проблемы, связанные с асинхронными вызовами самыми простыми или даже приземленными словами, поэтому не рекомендую читать эту статью слишком чувствительным натурам.
Сложность алгоритмов - это ключевой аспект при проектировании и создании веб-приложений, особенно при работе с большим объемом данных или выполнении вычислительно сложных операций. Понимание, как оценивать сложность алгоритмов, помогает принимать обоснованные решения в выборе алгоритмов и структур данных, а также оптимизировать производительность своих приложений.
Сейчас мы рассмотрим, почему знание сложности алгоритмов является важным навыком для разработчика, какие методы используются для оценки сложности, и какие практические применения можно найти для этого знания при создании веб-приложений. На тему сложности алгоритмов часто задаются вопросы на техническом собеседовании. Поэтому я настоятельно рекомендую не пропускать это видео.
Привет, Хабр!
Уже около четырех лет моя профессиональная деятельность тесно связана с энтерпрайз разработкой мобильных приложений на Flutter в компании TAGES. Сегодня мне бы хотелось поделиться некоторыми мыслями и практическими советами на тему, которая является актуальной и важной для всех разработчиков — рефакторинг кода.
Данный материал будет, в первую очередь, полезен новичкам. Мы рассмотрим различные аспекты рефакторинга кода, начиная от причин, по которым он необходим, до конкретных техник и инструментов, которые помогут его успешно проводить, а также разберем, почему рефакторинг — это не нечто, которого следует бояться, а наоборот, инструмент, помогающий стать более эффективным и успешным разработчиком.
Наливайте себе чай, берите плед и устраивайтесь поудобнее, дальше у нас большой разбор!
