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

Сегодня я предлагаю вспомнить один старый и простой алгоритм, рисующий красивые картинки, который когда-то вовлёк меня в программирование и увлёк математикой. А заодно мы немного разберёмся в том почему картинки получаются именно такими.

Эта текст покрывает ответы на некоторые совсем базовые вопросы и вместе с тем сразу погружает в проблематику получения ответа на вопрос: "как работать лучше? однопоточно, многопоточно или многопоточно, но на ThreadPool?". Ответ на этот вопрос может изначально показаться очень простым и понятным, однако реальность совершенно иная: всё как и везде сильно зависит от ситуации: от типа задачи, от её размера, от прочих условий, которые так просто в голову сами собой не придут.

А потому мы пройдёмся в первую очередь по IO-/CPU-bound операциям, стоимости создания потока, базовым основам работы пула потоков (но только основы), а далее -- углубимся в анализ чёрного ящика: от чего зависит производительность пула потоков? Каков объём работы приемлим для того чтобы в него планировать?

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

Также отмечу, что материал постепенно переходит от начального уровня сложности ? через ⚠️ средний уровень к ☠️ высокому, о чём вы сможете узнать по пиктограммам.

TL;DR:
— в Rust намного больше достоинств, чем просто скорость и безопасность
— в Rust по умолчанию CDD (compiler-driven development, разработка через компилирование). Это как TDD, только CDD
— Rust — не сложный язык, особенно если не гнаться за максимальной производительностью

В этой статье я бы хотел рассказать:
— почему взгляд на Rust как на "memory safe C" очень сильно сужает область его возможного применения
— почему я смотрю на Rust как на очень удобный в разработке язык высокого уровня, которому просто случайно повезло оказаться невероятно быстрым
— почему разработка на Rust быстрее, чем многие думают
— почему Rust — это один из лучших языков общего назначения

Привет, Хабр!

Рад поделиться с уважаемым сообществом своей любовью к популярной науке, в первую очередь, к космологии. Эта статья открывает небольшую серию, основанную на моём курсе лекций, который я читаю школьникам в летней школе Химера.
И который до сих пор был кипой листов А4, исписанных от руки буквально в лесу под деревом.

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

Неприступных крепостей не бывает. Опасную брешь, то есть бэкдор, недавно обнаружили в шифрованном стандарте радиосвязи TETRA. А ведь он вот уже 25 лет используется военными, экстренными службами и объектами критической инфраструктуры по всему миру. Самое интересное, что на технические детали и контекст этой истории почти никто не обратил внимания.

Мы изучили статьи и доклады исследователей и собрали всю суть. Перед вами — подробная история взлома TETRA.

Каждый год выходит новая версия .NET. Это событие не только предоставляет нам возможность познакомиться с последними улучшениями в самом .NET и нововведениями в языке, но и даёт повод исследовать исходный код .NET. Нужно воспользоваться этим шансом!

За 2023 год разработчиками PVS-Studio было написано немало статей о проверке Open Source C#-проектов. По традиции мы делимся с вами 10-ю самыми интересными ошибками, найденными за этот год. Приятного чтения!

test.o: In function `MyClass':
test.cc:3: undefined reference to `VTT for MyClass'

В C и C++ есть особенности, о которых вас вряд ли спросят на собеседовании (вернее, не спросили бы до этого момента). Почему не спросят? Потому что такие аспекты имеют мало практического значения в повседневной работе или попросту малоизвестны.

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

Если вы, как и я, любите и интересуетесь C/C++, и эти языки являются неотъемлемой частью вашей жизни, в том числе и его углубленного изучения, то эта статья для вас. По большей части я надеюсь, что эта статья сможет развлечь и заставить поработать головой. И если получится, рассказать что-то, чего вы, возможно, еще не знали.

Эта статья выросла из ответа на комментарии к статье Основные отличия PascalABC.NET, где возник традиционный спор про то, есть ли смысл в 2023 году изучать Pascal. Для комментов мой ответ слишком большой, так что оформлю в виде такого спонтанного поста.

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

Сразу уточню: речь, прежде всего, идёт о среднем звене "среднестатистических" школ, где информатика изучается строго по ФГОС - только с 7-9 классы, по 1 часу (уроку в 40-45 минут) в неделю. Если хотите изучить "единую министерскую" программу, можете скачать её с официального сайта Минпроса.

Конкретно на программирование эта программа отводит порядка 30 часов . По 1 часу в неделю, растянутых на конец 8 - начало 9 классов (с перерывом в 3 месяца, ага).

За это время авторы ФГОС предлагают с нуля (!) объяснить детям (которые только-только поверхностно изучили строение компьютера и принципы работы с мышино-клавиатурным интерфейсом (а нынешние дети реально от мыши тупят, т.к. с пелёнок привыкли к тачскринам!) ):

Наверное, уже все слышали о нехватке айтишников в России. Последние полтора-два года СМИ и чиновники активно муссируют эту тему. Давайте разберёмся, реален ли этот дефицит, насколько сложно войти в IT в 2023 году, как наш социально-ответственный и безусловно-патриотичный бизнес отвечает на вызовы времени, а также что предлагают уехавшим в случае возвращения.

В понятие «айтишник» каждый «эксперт» включает разные группы работников, критерии и методики оценки редко публикуются, представители ведомств и компаний заинтересованы в необъективных оценках. Поэтому понять положение в отрасли сложно. Но всё-таки попробуем оценить, сколько в России IT-специалистов.

Я рискну все таки продолжить изложение своего понимания Поста: How Async/Await Really Works in C#, которое в предыдущей статье получило название “ортогональный взгляд”. Также, недавно мы познакомились (возможно несколько преждевременно) с изначальным определением концепции SynchronizationContext на которую ссылается автор этого Поста.

Это не перевод. Это изложение содержания Поста на разных уровнях раскрытия сущностей и их взаимодействия по мере развития (эволюции) моего понимания тех мыслей и идей, которые, как мне кажется, хотел донести до читателя автор Поста Stephen Toub.

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

В этот раз попробуем сформулировать задачу, которую решает компилятор, то есть те разработчики, которые разрешили нам пользоваться конструкциями Async/Await в C#.

Всем привет. Сегодня я расскажу об инструментах, которые существуют в .NET для параллельной работы с какими-то внешними ресурсами и приведу примеры, где и как их можно применить.

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

Тяжелый старт

В связи с тем, что у меня не так много времени для ресерча каких-то новых штук и написания статей о них, я решил перевести серию уроков по Vulkan. Надеюсь, что мои переводы будут кому-то полезны и не очень плохого качества. Для начала обучения — прошу под кат.

Автор оригинала дал свое согласие на перевод. Также, когда я доперевожу все статьи и у меня будет время отформатировать их для github, он добавит русский перевод на свой сайт.

В этой статье я хочу описать (часть) моего опыта взаимодействия со структурой, именуемой в дальнейшем «яндекс», с точки зрения работника. Опишу собеседования и этап «входа».

Да, уже были статьи про собеседование и даже в эту же структуру, некоторые из них я видел, но не во всём с ними согласен, к тому же конкретно С++ разработчиков я там не видел.

Хочу вас огорчить, программисты не делают игры - их делают дизайнеры и арт. Можно уволить программиста и на его место придет другой и через условные месяц-два-полгода начнет закрывать таски не хуже. Если увольняется дизайнер, его монстр, пушка или контент повисает без хозяина и без "видения". Если её не перехватил сосед (а у соседа свой монстр), то в большинстве случаев его работа просто уходит в стол и монстра пишут заново на тех же ассетах и принципах, но заново.

Если увольняется арт-директор, который несет "видение" проекта, то проекту становится очень плохо, в большинстве случаев визуально он изменится до неузнаваемости, хотя ассеты могут быть те же самые. Программисты делают всё, кроме самой игры: рендер, звук, физику, сеть, AI, инверсную кинематику, поиск пути и т.д. Можем подискутировать в комментариях.