Алоха всем.
Ни для кого не секрет, что алгоритмические задачи уже стали/становятся обыденными на техническом интервью. Кто то может любить это, кто то ненавидеть, но факт остается фактом, что бы пройти собеседование нужно научится решать алгоритмы.
А как быть интервьюерам? Какую задачу дать кандидату? Как понять сигналы, что кандидат "шарит"?
Я наткнулся на интересную статью по интервью на Senior инженера C++. Там у парня спрашивают базовую задачу FizzBuzz.
В этой статье мы рассмотрим бенчмарки различных решений на Java, начиная от простых вариантов и заканчивая многопоточными реализациями. Давайте разбираться вместе!
Каждый программист однажды получает по голове необходимостью парсить аргументы командной строки и вот это наконец случилось со мной - так почему бы не использовать это как возможность (написать какую-то дичь) (CLI парсер)? Скажу сразу - мы тут чтобы развлекаться, потому требования к парсеру будут... Интересные
Пару недель назад, на меня вышла HR "светлячков" и пригласила поговорить о позиции AI программера в их новую старую игру. Я был несколько удивлен, потому что знаком с парой ребят из студии и знаю, что найм у них сейчас остановлен. Но всегда интересно пообщаться с умными людьми, поэтому отказываться не стал. Первый созвон с HR вышел стандартный, где над чем работал, какие игры шипнул. Не очень понимаю зачем все это было спрашивать, если все это есть на линкедине подробно и с датами. Ну да ладно - видно такая их эйчарская доля по тридцать три раза переспрашивать. Или HR дальше второй страницы просто поленилась почитать.
Забукали время технического интервью. В полдень четверга на встречу приходит сотрудник студии и начинает просматривать резюмешку дальше второй страницы, где натыкается на скрин опенсорсного проекта StoneKingdoms, в который я некоторое время активно комитил. Проект, если что, получил благословение самого Simon Bradbury, так что проблем с правами на использование ресурсов из Stronghold нет. Посыпались вопросы, а что за проект? а как делаете? и что все на lua? а как же плюсы? Где-то на середине разговора к нам подключился другой разработчик "светлячков", с которым мое знакомство началось еще в 2010, когда он помогал восстанавливать исходники Caesar III и просто давал консультации как реализована игровая симуляция. Мы и сейчас иногда общаемся на форуме по ремейкам старых игр.
Редкая птица долетит до середины Днепра, не каждый разработчик осилит все паттерны в WL. Нет ему равных языков в паттерн-матчинге. Чуден и необычен язык этот. Изобилует он точками, подчеркиваниями, да запятыми так, что в глазах рябит, да разум мутнеет.
В этой статье я постараюсь сделать как можно более подробный обзор на механизм сопоставления с образцом в Wolfram Language (WL) и покажу реальные примеры, где я сам и мои товарищи его активно используют. А также я поделюсь всеми неочевидными тонкостями работы с шаблонами, с которыми лично я столкнулся в процессе написания кода на WL. По возможности я буду приводить примеры на других языках программирования - на Python и C#. Это позволит всем, кто не знаком с WL лучше понять код и сравнить синтаксис.
В шейдере мы можем написать vec3 v0 = v1.xxy * 2 и любую другую комбинацию x, y, z и w в зависимости от длины вектора. Я рассматриваю только размеры вектора до 4, как самые распространенные для использования. Полученный вектор может не иметь той же самой размерности, как в меньшую так и в большую сторону и его компоненты могут быть скопированы в произвольном порядке. Это операция называется "swizzle" и это чертовски удобно для различных операций с малоразмерными векторами, особенно если они представляют игровые сущности в виде позиций, размера или цветов. Вектора используются повсюду в игровых проектах (да и не только в игровых), и не только в шейдерах. В какой-то момент swizzle было решено затащить и в наш игровой движок в базовые классы vec2, vec3 и vec4. Возникли вопросы: как добиться такого же синтаксического и семантического поведения в C++ коде, при этом минимизируя потери производительности.
Среди нововведений C# 12 было достаточно больше количество по-настоящему качественных и крутых фич (например дефолтные параметры лямбд).
Но речь сегодня пойдет о ложке дёгтя в бочке мёда - Primary Constructors.
Вот казалось бы, как здесь можно было напортачить? Идея взята прямиком из Kotlin, все что надо было сделать это перенести известную, успешно работающую функциональность из одного языка в другой. Всё.
Как говорится, воруй как художник? Думаю, что это не про Primary Constructors, потому что насколько плохо своровать фичу это надо было постараться.
Почему же в Kotlin эта фича имеет смысл, а в C# нет? Давайте разбираться.
Конкурс для C++ программистов и их любимых багов
Привет всем крутым C и С++ разработчикам! Команда PVS-Studio на связи. Новый год не за горами, поэтому мы подготовили вам новый конкурс с призами!
BASHUI - это BASH + UI, а не то что вы подумали.
Начиная работать над sshto я решил не переизобретать велосипед, вернее не переизобретать велосипед целиком а только некоторые его части и в качестве "рамы с педалями" использовал dialog. Это значительно ускорило разработку, но идея написать свой UI на баше с блекджеком и всем остальным ни на секунду не покидала мой воспалённый мозг. Звёзды сошлись, и я решил воплотить этот проект в жизнь(в bash). Втречайте BASHUI!
В комментариях к мой статье пользователь @Refridgeratorв ответ на мой вопрос написал, что в Wolfram Language (WL) не хватает следующего:
"ООП, перегрузки операторов, строгой типизации, событийно-ориентированного
программирования, дата-ориентированного программирования, параллельного программирования с примитивами синхронизации, средств отладки, скорости исполнения." (с) @Refridgerator
Я отлично понимаю, что вокруг Mathematica сложились некоторые исторические стереотипы. В них обычно WL представляется как калькулятор на стероидах или просто игрушка, или больше язык запросов, которым можно дополнительно решать уравнения и строить графики. Сегодня я попытаюсь показать, что в языке есть не только лишь графики, уравнения и интегралы. Вряд ли у меня хватит сил написать подробно касательно каждого пункта списка, но я постараюсь объяснить хотя бы часть.
В прошлом году я написал программу, вычисляющую 255 цифр числа π на самом первом микропроцессоре от Intel - 4004. В той статье я упоминал рекорд ENIAC'a - 2035 цифр [^1], но побить его не смог. Настало время закрыть гештальт. В этот раз возьмём одного из преемников от Intel - 4040.
Кликбейтный заголовок, риторический вопрос и обещание раскрыть тайну! Не самый лучший набор, но нормального названия для статьи мне в голову не пришло. Что же здесь все таки будет? Речь пойдет о реализации символьного программирования в Wolfram Language (WL). Я не буду рассказывать про отличия от других парадигм. А также здесь точно не будет общих определений. Вместо этого я попытаюсь ответить на несколько вопросов исходя из своего личного опыта и наблюдений.
Внимание! Я не математик и не знаю haskell и lisp! И буду рад если меня поправят настоящие математики, которые с ними знакомы.
Функциональное программирование одной из целей ставит отражение логики программы в типах входных/выходных значений функций. Типы аргументов и результатов накладывают существенные ограничения на то, как может быть реализована функция. Тем самым, позволяют делать разумные выводы о работе функции, ориентируясь только на её сигнатуру. Такое явление называется "параметричность". Замечательным примером параметричности служит такая сигнатура:
val f: [A] => A => AЭту сигнатуру можно прочитать так: для любого типа, получив значение этого типа, вернуть какое-то значение того же типа. Исходя из того, что тип может быть любым, и никаких операций над этим типом мы не определили, единственной продуктивно завершающейся реализацией является identity. Здесь и далее мы исключаем непродуктивные решения вида f(a) = f(a) (зависание/отсутствие завершения) или f(a) = throw Exception() (исключение).
Для представления эффектов часто используется конструкция IO[A]. Значение из этого объекта можно получить, только выполнив код, содержащийся внутри. Довольно часто можно столкнуться с ситуацией, когда само значение нам не настолько интересно, как факт выполнения определённой операции. Обычно используется тип возвращаемого значения IO[Unit]. В этой заметке предлагается воспользоваться параметричностью, чтобы получить определённые гарантии.
Нетрадиционный способ вычисления медианы массива значений с плавающей точкой при помощи нескольких проходов по исходному массиву по словам, начиная с более значащих, с использованием целочисленной арифметики, что даёт возможность в некоторых случаях несколько обогнать по скорости "традиционные" классические алгоритмы.
Эта статья вторая в цикле по созданию crackme под linux amd64. В этой части мы создадим исполняемый файл, в котором каждая функция будет зашифрована собственным ключом, и будет расшифровываться только на время исполнения. Процесс создания будет полностью автоматизирован, то есть при добавлении нового кода или изменении старого никаких дополнительных действий делать будет не нужно. Код всего проекта находится в репозитории на github.
Средство обработки унифицированных по назначению данных (Sound – system for operating with unified data) разрабатывается для внятного программирования, обеспечивающего соответствие результатов вычислений назначениям. Под назначением данных понимается формальная спецификация вычислений, приводящих к этим данным. Язык программирования Sound нужен как универсальный инструмент, позволяющий транслировать вычислительную логику в любой язык программирования.
Эта статья первая из цикла, в котором мы будем создавать crackme для linux amd64. В crackme будут реализованы шифрование каждой функции отдельным ключём и наномиты для противодействия отладке. В данной статье мы рассмотрим алгоритм встраивания ключа шифрования в код для усложнения расшифровки функций пользователем. Если стало интересно, прошу под кат.
Что такое Dendy? Что так любит детвора? Это электронная игра! Ооо, дендиии...
В этой статье я вам расскажу о своем первом опыте разработки игры для NES/Famicom консоли. Постараюсь рассказать о инструментах, которые использовал и о интересных особенностях разработки игр для Dendy с которыми столкнулся во время создания игры.
На написание этой статьи, меня натолкнул разбор результата изменения полей объекта, лежащего в HashSet. Я развил идею и привнёс альтернативную математику в Java.
Хабр - не жалобная книга, я знаю. Но тут история про код, с примерами, разбором антипаттернов и всё такое, поэтому я рискну.
Всё началось, когда я узнал про конкурс красоты кода от Сбера. Я как раз хотел поучаствовать в каком-нибудь эпичным конкурсе, а тут как раз он мне и подвернулся, тем более что я - тот человек, которому есть что рассказать про красивый код. Я даже целую статью запилил о том, как писать красивый и понятный код. Так что что я решил, что в данном случае мои шансы на победу - в отличие от остальных конкурсов - всё же больше 0%. Кроме того, я хотел выступить на конференции PiterPy (спойлер: хрен мне), чтобы рассказать там про красивый код и всё такое, поэтому участие в конкурсе и сравнение результатов было бы классным подспорьем.