Логические операции играют важную роль в программировании. Они используются для создания условных конструкций и составления сложных алгоритмов. В Python для проведения логических операций используются логические операторы:
not — логическое отрицание
and — логическое умножение
or — логическое сложение
В этой статье мы поговорим о неочевидных деталях и скрытых особенностях работы логических операторов в Python.
В этом году я окончил бакалавриат “Прикладная информатика: в экономике”. Поэтому пока память свежая, хотел предоставить небольшую выжимку из 4 лет моего обучения.
Недавно я реализовал очень необычную задумку — демонстрацию Minecraft-подобного движка с игровой логикой, выполняющейся полностью на GPU.
Как и зачем я это сделал, и как дошёл до жизни такой, я поведаю в этой статье.
Внимание, в статье есть много скриншотов!
Прошлая наша статья, где мы задали несколько вопросов блогеру IMAXAI (он же Максим Горшенин) почему-то была им оставлена без должного внимания. Мы предположили, что Максима опять все обманули, и его лучшие друзья, которые "все разработали сами", на самом деле не такие уж и "все сами", а всего лишь в шелкографии китайской платы нарисовали свой бренд. Так как Максим почему-то не захотел во имя "импортозамещения" задать наши неудобные вопросы своим друзьям, то у нас появились теперь вопросы к самому Максиму. Является ли целью его деятельности действительное импортозамещение, или же просто из меркантильных целей, на волне хайпа и эпатажа, он продвигает тех кто с ним сотрудничает и топит других, кто отказался от его предложений? И что будет если те кого он так истово возносит на пьедестал импортозамещения окажутся обычными продвинутыми "переклейщиками шильдиков"? Интересно? Ну что же, сегодня мы поближе рассмотрим очередного друга блогера - компанию GS Group, чьей продукцией наш подопечный, кстати, приторговывает на своем сайте.
Мою первую статью я желаю посвятить истории о том, как я решил заняться исследованием часто встречающихся в модулях PlayStation Portable непонятных байтовых строк. Никакой документации в Homebrew коммьюнити найти не удалось, так что я взялся за дело сам.
Когда я был юн, я ненавидел архитектурное проектирование и документацию, и считал единым источником правды код. Если вы знакомы с мемом в заголовке статьи, то конечно же знаете, к чему это привело меня в конечном счете.
Эта история про то, как я пришел к необходимости процесса обязательного технического анализа по задачам для программистов.
Иногда, изучая Python, можно наткнуться на вещи, которые позволяют решать задачи довольно неожиданным способом. К одной из таких вещей можно отнести унарный оператор ~, с помощью которого можно осуществить симметричную индексацию последовательности. Под симметричной индексацией последовательности будем подразумевать ее одновременный обход от начала и конца.
Сегодня я хотел бы обсудить тему, с которой так или иначе сталкивался почти каждый программист встраиваемых устройств без использования настоящих операционных систем, а именно прямое управление периферийными узлами микроконтроллера. A конкретнее, я хотел бы обсудить повышение безопасности при управлении периферийными модулями без потери эффективности, гибкости и читаемости.
Статья предполагает, что читатель имеет базовые знания программирования bare-metal систем и языка С++, в том числе и современных стандартов. Это означает, что совсем базовые пояснения выходят за рамки этой статьи.
В этой статье мы расскажем про базовые техники работы с Docker, а также погрузим читателя в основы докеризации приложений.
Предполагается, что читатель что-то слышал про Docker и хотел бы начать знакомство с технологией. Мы постараемся упростить этот процесс.
В статье выясним, можно ли с точки зрения стандарта языка C++ тривиальным вызовом push_back продублировать элемент std::vector. Отвечая на простой вопрос, столкнемся с более интересными: что собой представляет внутренний мир вектора, как "протухают" итераторы при реаллокации, какие ограничения добавляют гарантии безопасности относительно исключений...
Как говорится, «не будите во мне ботана». Иногда кто-нибудь беспечно задаст мне, казалось бы, невинный вопрос — и я убиваю следующие несколько часов (в описываемом случае — дней), чтобы полноценно сформулировать ответ. Обычно всё это заканчивается с моей стороны очередной филиппикой на mastodon или в каком-нибудь приватном чате. Но на сей раз не буду этим ограничиваться и напишу целый пост.
Вот с какого невинного вопроса всё началось:
А почему UID начинаются с 0, но PID начинаются с 1?
Если совсем коротко: в Unix PID (идентификаторы процессов) начинаются именно с 0! PID 0 просто не отображаются в пользовательском пространстве через традиционные API. PID 0 запускает ядро, а затем практически уходит на покой, только немного участвует в работе планировщика процессов и в управлении питанием. Кроме того, на просторах Интернета доминирует заблуждение о PID 0, всё из-за одного ошибочного утверждения в Википедии, которому уже 16 лет.
В заключении к посту я дам несколько расширенную версию этого короткого ответа, но если хотите до него дойти вместе со мной — давайте разберём достаточно длинную среднюю часть.
Но, конечно же, любой желающий может просто загуглить, что такое PID 0, верно? Зачем мне вообще всё это писать?
КДПВ за авторством ＠uncleinuyasha
У каждого из нас помимо хобби есть ещё и "времяпрепровождение" — как раз для тех случаев, когда времени на руках оказывается слишком много и надо бы его проводить куда подальше.
В моём случае таким занятием ещё со времён актуальности PSP стала ритм-игра под названием "Project DIVA". Базовая концепция максимально простая — на экране появляются мишени, к которым летят иконки клавиш, оные и нужно нажимать в ритм песни.
Вскоре после переезда в Японию я узнал, что есть куда более серьёзная версия этой игры — Project DIVA Arcade. Однако и некоторые игровые механики в ней существенно отличаются от её карманного прородителя. Именно они среди прочего и делают эту игру уникальной — возможно, единственной ритм-игрой "с открытой концовкой".
Давайте же разберём правила игры, создадим имитационную модель игрового процесса и посмотрим, можно ли получить преимущество в игре путём вычислений, или же уже всё посчитано до нас :-)
Решил я, значит, изучить, как работают компьютеры на самом низком уровне. Это тот уровень, где работают всякие железяки, транзисторы, логические элементы и так далее. Чтобы полностью закрепить материал, я решил построить простенькую ЭВМ на редстоуне в Minecraft. Эта статья о том, как работают ЭВМ на уровне логических элементов и о том, как я построил прототип такой ЭВМ в Minecraft. В конце я оставил ссылку на GitHub-репозиторий с проектом.
По мнению Артема Закируллина*, одна из фундаментальных проблем, с которой сталкиваются разработчики при анализе кода – высокая когнитивная нагрузка. Это не абстрактное, а реальное ограничение возможностей, которое стоит времени и денег. На чтение и понимание кода, тратится больше времени, чем на его написание. Поэтому, разработчику нужно постоянно задаваться вопросом: не пишет ли он код, чтение которого создает чрезмерную когнитивную нагрузку?
Подробнее о том, с какими проблемами от высокой когнитивной нагрузки сталкиваются разработчики и какие решения помогут упростить понимание кода для последующей работы с ним читайте под катом.
*Обращаем ваше внимание, что позиция автора может не всегда совпадать с мнением МойОфис.
У одной задачи может быть несколько способов решения. Возьмем классическую задачу программирования — задачу подсчета, в которой мы считаем, сколько раз каждый элемент списка встречается в нем. Способ решения этой задачи на Python менялся по мере развития языка. Именно об этом мы будем говорить в этой статье.
Большинство из нас присоединилось к программированию на Python с его третьей версии. Однако мы начнем с Python 1.4. Пристегните ремни, отправляемся в далекое прошлое — в 1997 год!
