hahacker
Давным-давно программный код хранился на перфокартах, но эти времена прошли и теперь мы храним код в текстовых файлах, что конечно же лучше. Но, может быть, пора сделать еще один шаг и начать использовать другой формат, более удобный?
Моим первым языком программирования был ActionScript. Написание кода для Macromedia Flash максимально далеко от голого железа, и эта специфика работы глубоко засела в моём сознании. В результате меня интересовали преимущественно высокоуровневые языки для веб-программирования. Низкоуровневые же казались непостижимыми. Со временем я постепенно из разных источников узнавал о них всё больше, но это моё убеждение оставалось прежним. Низкоуровневые языки пугают, и машинный код подтверждал это наглядно. Когда я обращался к Google с запросом «понятный машинный код», то результат выдачи чаще представлял нечто пугающее и отталкивающее, нежели полезное для обучения.
В конечном итоге я решил, что для достижения поставленных целей мне этот страх необходимо преодолеть. И результат приложенных усилий оказался для меня неожиданным.
Машинный код вовсе не страшен. Если вы можете обеспечить, чтобы документ JSON соответствовал схеме JSON, то без проблем сможете писать машинный код.
Никто давно не пытается выводить теорий о том как правильно писать код.
Старые теории и способы об этом думать в общественной дискуссии давно свелись к спору о синтаксическом сахаре да и теории те были попыткой выделения каких-то математических свойств кода. Потом как известно была доказана невозможность этого.
Сейчас всё изменилось - мы должны рассуждать о проекте как о том, что постоянно изменяется большими группами людей, какая-то часть и кода и людей может быть неправильной, никто из модифицирующих не знает проекта целиком, нужны новые идеи и способы рассуждения.
Цикл продуктовой разработки часто напоминает весы: с одной стороны, системное проектирование, подбор основополагающих инструментов, масштабные рефакторинги. С другой — совокупность локальных решений, принимаемых для точечных улучшений в системе. И самое сложное тут: соблюдать баланс. Как понять, когда имеет смысл вмешаться «хирургически», а когда — предпочесть вместо конкретной проблемы решить (или предотвратить) целый класс проблем?
Иногда нащупать границу между «масштабом» и «целесообразностью» получается почти что случайно. Однажды мы в Сравни подступились к переделке чата в нашем мобильном приложении, и на старте расценивали задачу как «ещё один рядовой продуктовый кейс». Но планы по модификации фичи быстро переросли в создание универсального инструмента: конструктора сценариев на базе Backend Driven UI.
В итоге мы не просто заменили чат более удобной альтернативой, а в целом научились гибко управлять фронтендом приложения. Со всеми сопутствующими плюсами как для бизнеса, так и для самих разработчиков (теперь, чтобы реализовать некоторые изменения на экранах, даже не обязательно быть фронтендером или мобильным разработчиком!).
Подробности о нашем сценарном BDUI-движке — этапах его создания, вариантах использования и нюансах технического устройства — читайте под катом.
Привет, Хабр!
Сегодня рассмотрим почему DataFrame.apply() — это так себе инструмент в 2025 году, чем его заменять и как писать dataframe-логику так, чтобы она летала вместо того, чтобы жечь CPU и бюджет.
Привет, Хабр!
В этой статье рассмотрим, почему безобидная строчка await fetch() неожиданно превращается в тормоз, где именно она зарывает драгоценные миллисекунды — и что можно сделать с этим.
С 2022 года я разрабатываю методику предсказания IT‑карьеры для новичков.
Равно год назад она стала общедоступной в виде бесплатного курса‑профориентации для всех желающих. За прошедшие 12 месяцев свои IT‑перспективы успели оценить 795 человек. Увы, подавляющее большинство из них (87%) получили отрицательный ответ.
В этой статье — типичные ошибки ищущих себя в новой профессии.
Когда я ищу информацию о принципе KISS в Интернете, я натыкаюсь на множество сайтов, определяющих его в паре строк: важна простота, давайте быть простыми, конец. Они часто не объясняют, что такое простота, почему простота важна и как ее достичь.
Простота - это одна из ведущих идей, которую мы должны помнить всегда, проектируя систему. Проблема: ее действительно трудно достичь.
Вы угадали: мы погрузимся в простоту (и сложность) в этой статье. Я не буду писать обо всех различных способах, которыми сложность может проникнуть в ваш код, но, вместо этого, я постараюсь дать вам краткий обзор различных масок, которые сложность может носить, с множеством примеров. Мы перейдем от самого бизнес-домена, через мелочи (реализацию), чтобы закончить сложностью архитектуры программного обеспечения.
Мне недавно встретился код вывода количества FPS на экран, написанный начинающим программистом, и в этом коде был базовый класс, класс-потомок, виртуальные функции, конструктор с множеством параметров, variant. Код позволял выводить любое количество счетчиков FPS на экран разными шрифтами, но все, что было на самом деле нужно, это простая функция на 3 строки, считающая количество FPS и выводящая его на экран.
Всем привет! Меня зовут Артем Валевич, я тимлид в AGIMA. Хочу рассказать о нашем опыте работы с джуниор-разработчиками. Вообще на рынке к ним принято относиться с опаской. Есть стереотип, что они приносят мало пользы, зато требуют много вложений. Что ж, это отчасти правда, спорить бессмысленно. Но мы ребята рисковые, решили пробовать — и в итоге остались довольны. В этой статье объясню нашу логику и немного расскажу о том, как мы готовим джунов к великим свершениям.
Эпиграф:
Приходит чувак к музыкантам, в группу просится. Те у него и спрашивают:
- А ты на гитаре играть умеешь?
- Нет.
- А на барабанах?
- Тоже не умею.
- Может ты поешь?
- Не пою.
- Зачем ты нам тогда нужен?
- Знаете, я просто офигенный друг!
Рано или поздно любой хороший продакт начинает покрывать метриками свою команду. В одной из продуктовых групп так и случилось: продакт ввел метрики, постепенно вычислил самого неэффективного сотрудника — назовем его Петя — и уже готовил бумаги на увольнение. Но во время этого веселого процесса вдруг выяснилось, что общие высокие показатели команды, это заслуга совсем не продакта (опаньки!), а именно «неэффективного» Пети. Потому что Петя оказался «человек-клей». Тот самый парень (или девушка), ради общения с которым собирается команда, который умеет поддержать, вдохновить, снять негатив и вообще настроить команду на продуктивный лад. При этом он вполне может быть распоследним раздолбаем.
Эта статья — краткая заметка о двух связанных друг с другом эмпирических правилах.
Поднимайте If вверх
Если внутри функции есть условие if, то подумайте, нельзя ли его переместить в вызывающую сторону:
// ХОРОШО
fn frobnicate(walrus: Walrus) {
... }
// ПЛОХО
fn frobnicate(walrus: Option<Walrus>) {
let walrus = match walrus {
Some(it) => it,
None => return,
};
...
}
В подобных примерах часто существуют предварительные условия: функция может проверять предусловие внутри и «ничего не делать», если оно не выполняется, или же может передать задачу проверки предварительного условия вызывающей её стороне, а при помощи типов (или assert) принудительно удовлетворить этому условию. Подъём проверок вверх, особенно в случае предварительных условий, может иметь лавинообразный эффект и привести к уменьшению общего количества проверок. Именно поэтому и возникло это правило.
Привер, Хабр!
В копилку статей про DeepSeek, которых здесь уже великое множество, хочу забросить ещё пять копеек в виде практического отчёта о инсталляции на Xeon, о котором меня попросили в комментариях к посту «Мануал по запуску полной модели DeepSeek-R1 локально...». Кому любопытно — может заглянуть под кат, ну а тем, кто уже выполнил упражнение по установке — вероятно будет совершенно неинтересно.
Давеча наткнулся в экс-Твиттере на интересный тред (https://x.com/carrigmat/status/1884244369907278106?s=52) о том, как запустить самую мощную (на сегодня) ИИ reasoning модель DeepSeek-R1 прямо у себя под столом.
DeepSeek-R1 — это одна из топовых моделей (из Китая), наделавших много шума (и не только), для задач логики, математики и программирования. Она настолько умная, что может (с некоторыми оговорками) "конкурировать" с решениями от OpenAI, но при этом её можно запустить локально, без интернета, без смс и полностью контролировать весь процесс.
Почему это круто?
* все данные остаются с вами, никакие сторонние сервисы не получат доступ к вашим запросам.
* запуск на своём железе избавляет от затрат на облачные сервисы.
* модель способна решать сложные задачи и выдавать результаты на уровне профессионалов.
В статье я расскажу:
* какое оборудование нужно для запуска DeepSeek-R1.
* чем локальный запуск отличается от серверного.
* какие возможности открывает эта модель и как она может быть полезна.
* как сохранить безопасность и приватность при работе с ИИ.
В этом мануале описано, как настроить локальный запуск модели DeepSeek-R1 Q8, сохраняя максимальное качество и производительность без дистилляции или уменьшенной квантизации. Общая стоимость сборки составит около ~$6,000, и ниже приведены все необходимые ссылки на компоненты и инструкции.
Бро, если ты хоть раз руководил командой — ты это проходил. На стендапе всё звучит красиво: «делаю задачу, осталось чуть‑чуть», «почти готово», «просто баг странный». А потом проходит неделя, ты заглядываешь в код — и там либо ничего, либо половина сделано, либо вообще не туда копали.
Нет, это не обязательно саботаж. Иногда это банальная прокрастинация, страх ошибиться, потеря мотивации, или просто неумение сказать: «я застрял». Но проблема‑то реальная. Если не ловить и не разруливать — команда тонет в самообмане, а ты — в вечных переносах.
Разберёмся, почему разработчики врут (осознанно и не очень), какие признаки надо замечать раньше, и как перевести разговор из «всё нормально» в «честно, я залип». С кейсами, приёмами и без розовых очков.
Picturephone навел шороху в СМИ не меньше, чем первый iPhone, но так и не дождался своего звездного часа. Его история началась задолго до первой презентации в 1964-м, а дизайн воплощал фантазии кинематографистов о связи будущего. Вот только когда будущее наступило, люди оказались к нему не готовы. Пресса называла Picturephone проявлением «инженерного высокомерия» и чем-то «слишком опередившим свое время».
В этом тексте обсудим, чем так манила и пугала людей сама идея видеосвязи и как ее воплощали в реальность по обе стороны Атлантики начиная с 1920-х.
Сначала представлюсь: меня зовут Нина, я дочь физика, редактор техноблогов, а еще пишу для команды спецпроектов в МТС. Надеюсь, вам понравится читать этот текст так же, как мне понравилось над ним работать — в том числе искать старые газеты и фотографии. Если будут вопросы, пишите в комментариях, постараюсь на все ответить. Начнем!
В прошлых частях мы подключились к Godot, обсудили адаптацию к API и разобрались с устройством тела функции. Дальше в планах было перейти к входным и выходным данным, от них к общей архитектуре и далее снова к особенностям API. Если бы я отстрелялся быстрее, то так бы и было, но я возился слишком долго (об этом чуть ниже), из-за чего до моей телеги успел доползти читатель с типовым набором набивших оскомину вопросов. Допускаю, что я собрал всю коллекцию практикующих читателей, но мне хочется верить, что где-то прячется «молчаливое большинство» с аналогичными проблемами. Поэтому я решил передвинуть некоторые рассуждения из конца цикла в середину.
Это задержит кульминацию, но не критично, так как финальные части цикла я планировал запостить без длительных пауз. Поэтому эта глава пролежит в ожидании до тех пор, пока не будет готов черновик всего цикла. Если этот текст появился на Хабре, то остальные главы уже на подходе.