Эта статья поможет новичкам в программировании (и, может быть, не только им) понять законы логики и почему они важны при создании приложений, а также в повседневной жизни. В статье приведены примеры того, как эти законы могут нарушаться в реальных приложениях и в нашей жизни. Также есть ссылки на видеоверсию статьи и бесплатный онлайн курс по теме.
«Хочешь заценить какую-нибудь новую игру? Ну так скачай её по радио!»
Звучит как бред сумасшедшего, не так ли? Но ещё почти полвека назад это было реальностью!
В начале 1980-х годов, когда интернет был лишь мечтой, а компьютеры только начинали появляться в домах, энтузиасты нашли удивительный способ распространять программы и игры — через радиоволны. Вместо привычных сегодня загрузок из интернета, пользователи записывали информацию на кассеты, которые затем загружались в компьютеры. Да, в те годы жёсткие диски были ещё не столь повсеместны из-за своей дороговизны, отчего именно аудиокассеты были основным видом хранения данных.
Представьте: вы геймплейный программист, к вам приходит левелдизайнер и говорит что ему нужно чтобы наши мобы умели патрулировать, да к тому же не просто ходить по прямой между точками, а уметь двигаться по кривой, например, вокруг какого-то важного объекта на карте. Вспоминая как работает мувмент вы спрашиваете:
— А по точкам вот прям вообще не подойдет?
— Не, ну, конечно, на крайняк подойдет, но хочу чтобы было по кривой. Да и на прошлой игре где я работал такое было, почему у нас нет?
И вот вы одновременно рады за его предыдущую команду, но в то же время и сами понимаете, что по кривой будет и красивее и гибче, но с какой стороны подойти к задаче — вопрос не праздный. Если вы оказались в такой или подобной ситуации, то эта статья для вас.
Всем привет! Меня зовут Женя, я руководитель отдела разработки «Аккаунт» в мобильном приложении для продавцов платформы Ozon Seller. Поделюсь нашим опытом работы над улучшением скорости сборки Android-проекта.
Скорость сборки проекта напрямую влияет на time to market продукта и (внезапно) удовольствие от процесса разработки. Если каких-то 50 лет назад время компиляции могло доходить до нескольких дней, и это считалось нормальным, то сейчас даже лишняя пара минут сборки проекта в Android Studio может заставить понервничать. Чтобы сберечь здоровье себе и CI, скорости сборки проекта нужно уделять внимание. Нетерпеливые читатели могут сразу посмотреть итоговую таблицу с результатами в конце статьи.
『Совесть — не ослик: и не такое вывезет.』
_(с) Р. Суржиков, Полари_
『Халдер, проверь, что умеет сир Поросёнок.』
_(с) Д. Мартин, ПЛИО_
Статья будет особенно интересна филологам, которые знают, что научных материалов в Интернете по измерению лексического разнообразия текста не так много, а в Рунете единицы и часто поверхностные.
Преамбула
Видел некоторые баталии в комментариях от читателей на профильных ресурсах: частое сравнение между собой двух высокооценённых циклов в жанре эпическое фэнтези/средневековье — «ПЛИО» VS «Полари». Сходства и различия сводились к тематике, эпохе, локациям, чертам действующих лиц, слогу и другим очевидным и/или нетривиальным литературным приёмам и ходам. В этой статье добавлю контраста на художку и с математической точки зрения.
Как преподаватель, могу сказать, что студентам непросто бывает привести базу данных к какому‑то осмысленному виду (не говоря уже про третью нормальную форму). Во‑первых, нередко «всё связано со всем», во‑вторых, в мало‑мальски сложной (в смысле, комплексной) задаче бывает трудно правильно спроектировать таблицы (то есть определить, какие таблицы должны быть в базе, как они должны быть связаны друг с другом, где и какая информация должна в них храниться). Помогает ли им в этом теория? И да, и нет. Дело в том, что нормализация данных говорит о желаемом виде каждой таблицы, и, преобразуя отдельно взятую таблицу к нормальной форме, мы также что‑то делаем со всей базой данных (добавляем новые таблицы, перемещаем между ними поля, и так далее) — это как сборка кубика Рубика. Второй проблемой здесь является то, что даже база данных, состоящая из единственной таблицы, не приведенной к первой нормальной форме, внезапно, тоже будет работать — криво‑косо, но будет! Теория — штука хорошая, но кое‑чего ей не хватает, а именно — задания точки отсчёта. Ведь для того, чтобы пройти к библиотеке третьей нормальной форме, для начала нужно понимать, где мы находимся.
Помните, как в Корпорации Монстров страшилы добывали энергию из криков детей? Они готовились, чтобы быть пострашнее и собирать побольше энергии: репетировали жуткие звуки, подбирали реквизит, узнавали страхи ребёнка. В общем, настраивали параметры запугивания :) В мире баз данных у параметров конфигурации аналогичная роль: чем точнее настройка, тем выше производительность системы. Однако не все параметры везде работают с одинаковым эффектом (как не все монстры одинаково страшны для всех детей): какой-нибудь параметр идеален для одного профиля нагрузки, но не даёт того же результата для другого.
Администраторы БД часто ломают голову, как подобрать оптимальные настройки под задачи СУБД. И чтобы помочь им разобраться, мы обратились к опыту Майка Вазовски — тренера легендарного монстра Салли. Вдохновились секретами его тренировок и разработали утилиту Pangolin Tuner — аналог Вазовски для настройки параметров конфигурации.
Я Кристина Демидович, DevOps-инженер в СберТехе, занимаюсь автоматизацией в команде СУБД Pangolin — это целевая СУБД в Сбере и не только. В этой статье покажу на примерах, как всё работает. Прошу под кат.
Наверняка у вас тоже было такое, что сервис работает себе спокойно, радует пользователей своей стабильностью и производительностью, а вас зелёным мониторингом. А в следующий момент хлоп - и нет его. Вы на панике смотрите в логи ошибок, а там или невнятный сегфолт, или просто ничего. Что делать – непонятно, и вообще надо прод спасать, поэтому вы поднимаете его обратно и всё работает как и раньше. Вы ещё пытаетесь разобраться в причинах случившегося, но со временем переключаетесь на другие задачи, а этот случай отходит на дальний план или вообще забывается.
Но это всё хорошо когда вы один, а вот если у вас много клиентов, то рано или поздно у вас возникает ощущение что что-то не так и надо разобраться с этими всплесками энтропии, чтобы найти первопричину подобных событий.
В этой статье описано наше исследование длиною в год, из которого вы узнаете, почему PostgreSQL(и любое другое приложение) может падать из-за бага в ядре Linux, причём тут XFS и почему очистка памяти может быть не так полезна, как вы о ней думали.
Надругательство над C#, C++ и HLSL, игрища с булками и буферами, тройная полиглотность, SIMD, пепекторы, DirectX, экономия 800 Тб ОЗУ, новая парадигма программирования, многопроцессность, быстрая степень и многое другое.
В этой части я расскажу, как делал софт на собственном фреймворке, который управляет ядерной подсветкой и механической видеостеной.
Представляем наш синтез для языков России и СНГ. В этот раз получилось покрыть 20 языков, всего 95 голосов. От старой демки этот релиз отличается следующим:
Модель поддерживает SSML;
Модель стала быстрее ещё на 20-25% (она и так была супер быстрой);
С живыми дикторами были подписаны договоры на запись их голоса;
Запись велась в максимально высоком из практически доступного качестве;
Для ряда языков опубликованы модели простановки ударений и / или словари с ударениями в рамках silero-stress;
К модели синтеза применены все оптимизации, как к нашей прошлой публичной модели;
Для демки мы брали шумные публичные данные низкого качества. В этот раз всё хорошо - как следствие существенно выросло качество синтеза.
Люди с самых древних времён интересовались тремя главными вопросами мироздания: почему горит огонь, какой формы земля и мёртв ли Хабр. На последний я постараюсь ответить. И если коротко - я понятия не имею. Быстрый сбор статистики и интерпретация результатов растянулась в несколько раз, ведь чем дальше тем становится всё больше и больше вопросов. А искать ответы - вообще и близко не моё любимое занятие, поэтому все данные будут опубликованы для открытого доступа и возможно кто-то сможет уменьшить количество этих чертовски важных вопросов.
Всем привет! Последние несколько месяцев я работаю над пет-проектом — интерактивной образовательной платформой для изучения Web Audio API и принципов обработки и синтеза цифрового звука. На платформе пользователи смогут решать задачи, программируя на JavaScript прямо в браузере. Эти программы выполняются в изолированной среде — песочнице, где пользовательский код не может повлиять на работу самой платформы.
Когда я начал реализовывать песочницу для своего проекта, я быстро понял, что это куда сложнее, чем кажется на первый взгляд. Я перепробовал разные подходы и убедился, что тема изоляции кода в браузере далека от очевидной, а большинство материалов в сети рассматривают её лишь поверхностно. Из моих исследований и экспериментов выросла эта статья — подробный разбор того, как устроены песочницы в браузере и какие архитектурные принципы и нюансы безопасности лежат в их основе.
Альберт Эйнштейн, критикуя принцип неопределённости Гейзенберга, произносит знаменитую фразу: «Бог не играет в кости!». На что Нильс Бор, участник дискуссии, с юмором отвечает: «Эйнштейн, не учите Бога, что ему делать».
Я в IT довольно давно, как в том меме — мне этот мир абсолютно понятен. Но сейчас происходит какая‑то ерунда, учитывая разные обстоятельства в мире, считаю так делать крайне тупо. Не то, что бы я хотел пожаловаться, и увольнения, «оптимизации», «трансформации» были всегда. Это все бизнес и к нему нечего предъявить. Разные ситуевины бывают. Но я бы хотел как‑то вставить свое мнение по теме.
Годами, если вы хотите попасть в какую‑то крутую компанию, вам нужно было и до сих пор это «нормальная» практика устраивать десятки этапов собеседований. Без проблем я принимаю эту игру. Нам же важно найти того самого рок звезду, который будет решать поставленные перед ним задачи. Типо как в магазине выбираем принтер, правда сдать его обратно через 3 месяца нельзя. Листик с него вышел — значит все, поиспользовал, живи с ним дальше.
Я давно пользуюсь кодогенерацией. Ещё во времена Yii фреймворка мне нравилось, что одним кликом мышки можно было сгенерировать CRUD с бэкендом, таблицами и формами. Backbone.js сразу из коробки обеспечивал REST API запросы и другие фичи. Между тем временем и нынешним днём — целый пласт инструментов для автоматизации, бутстрапинга и шаблонизации разработки. Приходилось и хрюкать, и глотать. То, что всё это, мягко говоря, так себе — уже отдельная история. Местами стало даже хуже. Хуже, чем когда вы неделю возились с конфигом Webpack.
В этой статье мы рассмотрим вайбкодинг. В чистом виде так сказать.
Привет, Хабр!
В детстве портовый кран представлялся мне исполинским жирафом. Длинные ноги его портала стояли на пирсе. А под ними сновали, невероятным образом ставшие крохотными, железнодорожные вагоны. Свою вытянутую желтую шею-стрелу, покрытую темными пятнами ферм, неспешно склонял он над раскрывшейся пастью трюма рыболовного судна-кашалота, отнимая его богатый улов. Жилы стальных канатов звенели от напряжения, настолько тяжела была его работа. Жираф издавал электрический вой, сражаясь за свою добычу.
И вот, спустя многие годы меня продолжают восхищать конструкции советских машин. Но вижу теперь я за ними не те фантазии из детства, а гений человеческой инженерной мысли. И в этой статье я предлагаю вам насладиться технической эстетикой архивных чертежей и конструкторских решений инженеров прошлого.
Проиндексируем фото-видео архив для поиска на человеческом языке простыми фразами. Фраза: «новогодний праздник» найдет все фото и видео связанные с новым годом. В этом нам поможет Qwen3-VL и Qdrant.
...А заодно добавим поиск по лицу.
Продолжая развивать свою синтезируемую систему-на-кристалле для ПЛИС, о которой я уже написал несколько статей, столкнулся с необходимостью подключать устройства ввода типа клавиатура, манипулятор мышь или джойстик. Если обратиться к тому, чем занимаются ретро-фаны, то проблем особых нет — старый добрый интерфейс PS/2 очень прост в реализации, он позволяет легко взаимодействовать с клавиатурой и мышью с минимальными ресурсами. Фактически PS/2 это последовательный синхронный порт работающий на низких скоростях, реализовать его можно программно. С ретро-джойстиками тоже проблем нет - положение джойстика это всего лишь замыкание контактов, что легко обрабатывается программно. Проблема в том, что всё это «ретро» постепенно уходит из нашей жизни, клавиатуры и мыши с интерфейсом PS/2 всё еще можно приобрести на маркетплейсах, но всё же редкость. И от джойстика хочется чего-то большего чем просто замыкания пяти контактов, а именно — градации положения стика. Такая фича доступна либо на очень старых аналоговых джойстиках, либо на современных геймпадах с USB интерфейсом. В конце концов я разрабатывают хоть и минималистичную, но современную систему с современной архитектурой (RISC-V) предназначенную для современного промышленного применения, а не для ретро-гейминга. ;-) В общем, встал вопрос как подключать простые HID устройства ввода через USB к своей синтезируемой ЭВМ.
Интерфейс шины USB на столько широко вошел в обиход, что мы даже не задумываемся что там внутри: сколько сигнальных проводов в USB кабеле, как они подключены, как передаются по ним данные, на каких скоростях и какие могут быть ограничения. Всё что мы знаем это то, что USB бывает разных версий: 2.0 — медленный и 3.0 — очень быстрый; и что USB устройства бывают с разными видами разъемов: USB type A и, с недавних пор, USB type C. Для большинства пользователей и программистов USB это такая штука, которую «вставил и работает». А если нет, то нужно вынуть, перевернуть устройство два раза вокруг его оси и вставить в компьютер еще раз. Если и так не заработало, то искушенный пользователь возможно вспомнит команду lsusb чтобы выяснить какие сейчас устройства присутствуют в системе или даже заглянет в dmesg чтобы выяснить наличие ошибок при детектировании устройства. Но что означают эти сообщения ? Еще меньшее число пользователей понимает результат вывода команды lsusb -v. Не многим лучше обстоят дела с пониманием USB у разработчиков электроники. Обычно на их уровне USB это четыре провода: GND, VBUS, D+ и D-, при этом каждый электронщик знает что D+ и D- это дифференциальная пара которую требуется трассировать на печатной плате соответствующим образом. Но так ли это на самом деле ?
Раз уж возникла необходимость, то надо погружаться в тему если не по уши, то хотя бы по пояс и выяснить, а на сколько сложно реализовать свой собственный минималистичный USB контроллер. Ведь задача то очень простая — считать пару байт с USB клавиатуры, и, как мне казалось, осилить её можно за пару-тройку ночных сейшнов.
В Deckhouse Prom++ мы переписали ядро хранения и обработки горячих данных на C++, при этом вся оркестрация и периферия остались в Prometheus на Go, что позволило сохранить полную совместимость с Prometheus. Для частых вызовов кода C++ мы использовали механизм CGo, однако первые тесты показали, что производительность CPU практически не улучшилась из-за его медлительности. В итоге мы переписали CGo, создав собственный механизм вызова.
В статье разберём, что такое CGo и почему он такой медленный, сделаем простейший собственный механизм CGo-вызова и доведём этот механизм до полноценного решения.
Эта заключительная часть данной серии (ссылка на первую часть) должна быть выйти раньше, но из-за многих факторов (об этом будет в конце статьи, если кому интересно) этого не произошло. Но звёзды сошлись и результаты экспериментов собраны здесь.
В данной статье поясню, как я разбирался в работе файловой лицензии, как новая версия программы не поддалась мне с первого раза (поэтому в этот раз патч сделан по иной схеме, но лучше с моей точки зрения), а так же поговорим о экспериментах с живым HASP ключом.
Disclaimer: Данная заметка написана в ознакомительных целях и не является руководством к действиям. Статья в этот раз написана таким образом, что в ней описываются мои мысли и шаги, как я к этому пришёл. Мне кажется, что это интереснее и позволяет перенять логику решения подобных задач.