Дано: ненужная ТВ-приставка + острая потребность в компьютере с низким энергопотреблением под Linux. Почему бы не превратить одно в другое?
Пользователь
Интересные приемы программирования на Bash
В данной статье они были пересмотрены и дополнены.
Создание API: в рамку и на стену
API — это большая сила и большая ответственность. У хорошего API будут благодарные пользователи; поддержка плохого превратится в кошмар.
Публичный API — не воробей, опубликуешь — не уберешь. Есть только одна попытка сделать все правильно, поэтому постарайся.
API должно быть легко использовать, но сложно использовать неправильно. Сделать что-то простое с помощью такого API должно быть просто; сложное — возможно; сделать что-то неправильно должно быть невозможно, или, по крайней мере, трудно.
API должен описывать сам себя. Изучение кода на таком API не вызывает желания читать комментарии. Вообще, комментарии редко нужны.
Перед разработкой API собери требования с долей здорового скептицизма. Осознай общие задачи и реши их.
Оформляй требования как шаблоны использования API. Сверяйся с ними в процессе проектирования.
Робот-не-пылесос с ножом или как мы делали смарт-ножницы на колесах
Эта история началась в октябре 2019 года. К нам пришел владелец крупного производства натяжных потолков и сказал: «Хочу максимально оптимизировать производство, избежать ошибок, вызванных человеческим фактором, повысить производительность и точность, не теряя качества готовой продукции». Подумав и оценив свои силы, мы решили попробовать создать робота-раскройщика. Мы - это тимлид, 3 программиста, инженер-конструктор и безопасник
Что может быть проще (сложнее), чем упорядочивание чисел?
Предположим, вы программист и у вас есть два числа. Вы хотите узнать, какое из чисел больше. Если оба числа имеют одинаковый тип, то почти в любом языке программирования решение будет тривиальным. Для этой операции обычно даже есть специальный оператор
<=
. Вот пример на Python:>>> "120" <= "1132"
False
Сравнение двух чисел на Brainfuck оставим в качестве упражнения для читателя.
Ой. Ну, строго говоря, это строки, а не числа, а строки обычно сортируются лексикографически. Но это всё-таки числа, хотя и представленные в виде строк. Это может показаться глупым, но такая проблема очень распространена в интерфейсах пользователя, например, в списках файлов. Именно поэтому нужно отбивать числовые имена файлов нулями (
frame-00001.png
) или использовать описания, сохраняющие лексикографический порядок, например, ISO 8601 для дат.Впрочем, я отклонился от темы. Предположим, числа действительно представлены числовыми типами. Тогда всё просто и
<=
отлично работает:>>> 120 <= 1132
True
Но так ли это?
Обучите YOLOv8 на пользовательском наборе данных
Ultralytics недавно выпустила семейство моделей обнаружения объектов YOLOv8. Эти модели превосходят предыдущие версии моделей YOLO как по скорости, так и по точности в наборе данных COCO. Но как насчет производительности на пользовательских наборах данных? Чтобы ответить на этот вопрос, мы будем обучать модели YOLOv8 на пользовательском наборе данных. В частности, мы будем обучать его на крупномасштабном наборе данных для обнаружения выбоин.
Электронный конструктор, не бьющий током
Дайте угадаю: вы в детстве заворожённо рассматривали печатные платы? Вам было любопытно узнать, как работает этот мини-город из разноцветных деталек? Возможно, у вас был опыт сборки электронных схем по книгам Борисова и Свореня? Советский сорокаваттный паяльник, кусочек канифоли в спичечном коробке? А ещё штаны с намертво влипшей в ткань каплей припоя?
Современные программные средства иллюстрируют процессы, происходящие в электрических цепях, с недосягаемыми для радиолюбителей недавнего прошлого наглядностью и интерактивностью. Они визуализируют протекающие по схеме токи и показывают напряжения в её различных частях. Это снижает порог понимания для людей, которым сложно даются абстрактные знания и язык формул.
Индексы в PostgreSQL — 5
В прошлые разы мы рассмотрели механизм индексирования PostgreSQL, интерфейс методов доступа, и два метода: хеш-индекс и B-дерево. В этой части займемся индексами GiST.
GiST
GiST — сокращение от «generalized search tree». Это сбалансированное дерево поиска, точно так же, как и рассмотренный ранее b-tree.
В чем же разница? Индекс b-tree жестко привязан к семантике сравнения: поддержка операторов «больше», «меньше», «равно» — это все, на что он способен (зато способен очень хорошо!). Но в современных базах хранятся и такие типы данных, для которых эти операторы просто не имеют смысла: геоданные, текстовые документы, картинки…
Тут на помощь и приходит индексный метод GiST. Он позволяет задать принцип распределения данных произвольного типа по сбалансированному дереву, и метод использования этого представления для доступа по некоторому оператору. Например, в GiST-индекс можно «уложить» R-дерево для пространственных данных с поддержкой операторов взаимного расположения (находится слева, справа; содержит и т. п.), или RD-дерево для множеств с поддержкой операторов пересечения или вхождения.
За счет расширяемости в PostgreSQL вполне можно создать совершенно новый метод доступа с нуля: для этого надо реализовать интерфейс с механизмом индексирования. Но это требует продумывания не только логики индексации, но и страничной структуры, эффективной реализации блокировок, поддержки журнала упреждающей записи — что подразумевает очень высокую квалификацию разработчика и большую трудоемкость. GiST упрощает задачу, беря на себя низкоуровневые проблемы и предоставляя свой собственный интерфейс: несколько функций, относящихся не к технической сфере, а к прикладной области. В этом смысле можно говорить о том, что GiST является каркасом для построения новых методов доступа.
Офисные джунгли (или особенности западной культуры общения на работе)
Это негласные правила этикета среди офисных белых воротничков. Об этом не расскажут ни в школе ни в университете. Как вести себя в офисах IT стартапа или корпорации?
Представлен обогащенный концентрат полезных подсказок, полученный в результате работы в трех западных организациях.
Эти правила написаны кровью!
Заражённый разум
Культурный код Запада тесно связан с идеей верховенства разума над бренной телесной оболочкой. Мы с вами привыкли отождествлять себя прежде всего с головным мозгом, закованным в скафандр из мяса и кожи. В костюм-экзоскелет, который можно прокачать в спортзале, украсить в салоне красоты, модифицировать на операционном столе, зарядить энергией за обеденным столом… И любые неисправности нашего скафандра вроде недомогания, слабости и боли мы воспринимаем словно как бы отдельно от себя: словно это не Я сам затронут болезнью, это затронуто болезнью мое транспортное средство, несущее меня по дорогам этого странного мира.
В целом, эта точка зрения вполне имеет право на существование. Однако что, если состояние нашего тела влияет на то, что мы считаем «самим собой»? Что, если существуют поразительные патогены, способные при заселении в тело манипулировать нами, а то и даже менять саму нашу психику, наше отношение к миру?
Земля круглая, вода мокрая, JPEG шакалит, небо голубое… Или нет?
Вы можете сказать, что один факт выбивается из этого ряда в заголовке, потому что он не так очевиден, как остальные. Еще лет 10-15 назад я бы никогда не подумал, что тут могут быть возражения, а сейчас уже и не удивляюсь, что приходится объяснять простые истины: дело в том, что планеты обладают очень большой массой, поэтому гравитация стремится придать им форму шара. Вот и все! Хотел бы на этом закончить статью и поблагодарить за внимание.
Заблуждения программистов относительно времени
Я постоянно удивлялся, как много ошибок в коде и тестов, и приложений происходят от неверного понимания и заблуждений насчёт времени. Под этим я имею в виду и компьютерный способ обработки времени, и фундаментальные ошибки, происходящие от несовершенной структуры календаря — летнее время тут лишь вершина айсберга.
На самом деле, я повидал так много заблуждений, которые оставляют след в чужих (и моих собственных) программах, что посчитал полезным составить список самых частых проблем.
Заблуждения программистов о времени
Музей-скансен эпохи Средневековья в Дании в режиме обычной работы (слева) ставит целью воссоздать повседневную жизнь города на стыке XIV и XV веков. Для съёмок фильма (справа) он «погрязнел»
Для киносъёмок в музей под открытым небом Middelaldercentret внесли несколько изменений. Вместо аккуратной каменной улицы развели неприятную кашицу из грязи, не самые роскошные стеклянные окна прикрыли досками и развесили везде выцветшее тряпьё. Здания как следует измазали чем-то коричневым, кое-где зачем-то перемешав субстанцию с соломой. В случайное здание воткнули факел, а не попытались изобразить лучину или фонарь.
Причина проста: кинозритель должен узнать на экране эпоху. Приходится снабжать снимаемое полным набором заблуждений про грязных неграмотных горожан, непрекращающиеся войны и еду без специй.
При проектировании информационных систем задача стоит ровно обратная: необходимо отразить реальность и не допустить в код собственные заблуждения. Ошибок восприятия много. По крайней мере, про карты и почтовые адреса получаются длинные списки.
Попытки собрать заблуждения про время и часовые пояса на Хабре уже были шесть и десять лет назад. Но без контрпримеров не так интересно.
Заблуждение 1. В сутках 24 часа или 86 400 секунд
Иногда и кое-где стрелки часов переводят, создавая сутки длиной в 23 и 25 часов — всё очевидно. Будет неплохо углубиться в случаи поэкзотичней.
Почему умножение матриц такое
Наверное, каждый задавался вопросом, почему умножение матриц такое. В этой статье мы разберём из каких соображений оно вводится именно так.
Введение в алгоритм A*
Для поиска этого пути можно использовать алгоритм поиска по графу, который применим, если карта представляет собой граф. A* часто используется в качестве алгоритма поиска по графу. Поиск в ширину — это простейший из алгоритмов поиска по графу, поэтому давайте начнём с него и постепенно перейдём к A*.
Что будет, если от разработчиков не отстать: умирающая команда
Источник
15 человек, из них — один руководитель проекта, три фронта, два бэка, три аналитика, девопс. Симптомы обычные: процессы всем не нравятся, соседи — козлы, потому что не то и не так делают, а как нужно — не знают, ответственности ни на ком толком нет ни за что.
Вроде бы когда-то это был настроенный конвейер, но теперь его куски — как будто в разных зданиях. Особо не заботятся о том, что было «до» и что будет «после». А если всё падает, то люди поднимают руки: «Я не виноват. Я не знаю, как поднять».
Проект — внутренний банка, он нужен для улучшения работы внутри компании. Традиционных решений в кровавом энерпрайзе — два: нанять новую команду (но вгружать мидла на проект такой сложности — три-четыре месяца) или же оставить проект на поддержке, через два года найти ему замену, а команду тихо похоронить в подвале. Точнее, не так: те, кто плывет по течению и не заботится о карьере, остаются тихо сидеть «на пенсии», то есть в бесконечной поддержке проекта. А самые проактивные тут же перейдут в другие команды или другие компании.
Почему процессы разваливались? На первый взгляд, потому, что была куча ненужных совещаний и встреч с теми, кого разработчики вообще не должны были видеть. Плюс местами странноватые KPI. Как это ни странно, но если психологически давить на разработчика пару лет, то ничем хорошим это не закончится. Руководство подразделения дало мне карт-бланш на исправления, и я начал разбираться, что же случилось.
Как НЕ надо строить надежные системы
При проектировании системы знание анти-паттернов и подвохов зачастую оказывается более полезным, чем знание самих паттернов. Отталкиваясь от этой идеи, я решил написать данную статью, чтобы рассказать о факторах, которые, на мой взгляд, приведут к созданию ненадёжных систем. В её основе лежит мой собственный опыт проектирования преимущественно распределённых корпоративных приложений. Будет здорово, если ниже вы поделитесь собственным опытом и полезными идеями по теме.
Простое понимание замыканий в Rust
У вас бывало такое, что вы никак не можете скомпилировать код с замыканиями в Rust? Уже и все варианты Fn
-трейтов перебрали, и move
написали везде, где можно, а borrow checker все равно не унимается? И тут оказывается, что просто нужно внутри замыкания клонировать переданную переменную окружения! Сложно и непонятно. Дурацкий привереда Rust.
На самом деле довольно просто понять, почему так происходит и на что влияет move
, а на что — клонирование. Но отсутствие подобного понимания я наблюдаю не только у начинающих программистов, но и у вполне зрелых. Хуже того, есть статьи, в которых это объясняется неправильно.
Что не так с китайским экономическим чудом, или почему оно закончилось?
Еще совсем недавно многие экономисты предрекали Китаю и китайской экономике большое будущее. Некоторые известные экономисты, такие как Рей Далио, вообще выпускали целые книги, объясняющие, что цикл верховенства США в мире закончен, и теперь пришло время Китаю вырваться вперед.
Этот рывок Китая вперед также часто называют «Китайским экономическим чудом», но сейчас, похоже, что эра этого «чуда» подходит к концу. В этой статье мы попробуем проанализировать некоторые факторы, являющиеся ключевыми для понимания общей картины, и попытаемся выяснить, что вообще происходит в экономике Китая сегодня.
Все данные взяты из открытых авторитетных источников, но так как я несколько лет прожил в Китае до пандемии, поэтому некоторые аспекты могут быть рассказаны в том числе и немного субъективно, с учетом моего опыта.
Опенсорс учёный: 15 полезных инструментов с искусственным интеллектом и машинным обучением
От создания дипфейков до обработки естественного языка — опенсорс-инструменты всегда находятся на переднем крае разработок с искусственным интеллектом и машинным обучением. Концепция открытого исходного кода и приложения для совместной работы упрощают обмен данными в командах и делают производственный цикл значительно короче.
Неудивительно, что open source с каждым годом завоевывает все большую популярность и начинает преобладать даже в корпоративном секторе, где традиционно доминировало проприетарное ПО. Согласно опросу, проведенному Red Hat среди почти 1300 ИТ-руководителей крупнейших компаний мира, свыше 80% предприятий планируют увеличить использование enterprise-технологий с открытым исходным кодом в ближайшие два года.
В этой статье рассмотрим 15 проектов с открытым исходным кодом, которые на наших глазах меняют мир искусственного интеллекта и машинного обучения. Некоторые из них — просто программные пакеты на основе AI/ML алгоритмов, другие — полнофункциональные фреймворки или платформы для машинного обучения. Но каждый из представленных ниже инструментов достоин внимания разработчика, интересующегося перспективными технологиями.
Информация
- В рейтинге
- Не участвует
- Зарегистрирован
- Активность