Будни разработчика

#фишка дня CSS anchor positioning aka якоря могут реально поменять то, как мы с вами реализуем интерфейсы, требующие графового представления: CJM, майндмапы, блок-схемы, пайплайны... Темани Афиф недавно сделал пример, соединив круги стрелками и набросив немного JS для drag&drop: https://css-tip.com/connected-circles/ Потом немного улучшил: https://css-tip.com/connected-circles-2/ И пару дней назад пошёл ва-банк и представил буквально реализацию поиска кратчайшего пути в графе: https://css-tip.com/graph-theory/ Выглядит, конечно, весьма сложно. Но следующим шагом, видимо, будет транспиляция Mermaid в CSS... Зато самому алгоритм стрелок реализовывать не придётся! 😂️️️️️️ #css #anchor #graph

Backend реальности или скрытые механизмы этого мира Любой разработчик знает, что за каждым интерфейсом, плавной анимацией или кнопкой, на которую хочется нажать, стоят тысячи строк кода. Кода, который долго оттачивали, рефакторили и дебажили. Пользователь видит картинку — мы видим архитектуру, логику и зависимости. В жизни всё устроено точно так же. За каждым крупным событием, культовым брендом или социальным трендом стоит своя «кодовая база» — смыслы и механизмы, которые не видны при беглом взгляде. Если вам привычнее мыслить системами, а не картинками, загляните в канал «Рабочая философия». Там занимаются деконструкцией реальности. Это разборы того, как на самом деле устроено поведение людей, на какие «скрытые спецификации» опирается наш мозг при принятии решений и как конструируются смыслы, управляющие миллионами. Советую к прочтению: → Как Нетфликс конструирует реальность? → Как один ритуал превратил стартап в систему за $730 млн (кейс Ironman) → Баги восприятия. Как реклама обходит наши фильтры и заставляет покупать ненужное → Как человек превратился в «символическое животное» и почему мы живем в мире знаков Полезно читать, чтобы понимать правила игры, в которую мы все вовлечены. Даже если вы не собираетесь «строить бизнес», знание того, как устроены социальные механизмы, дает огромное преимущество в критическом мышлении — @journey_liceum

#заметка дня В чат прилетел вопрос: "Как добавить иконку в поле ввода так, чтобы она была видна только когда виден плейсхолдер и исчезла при вводе текста?" Отвечаем: конечно же добавить её в контейнер label, а потом использовать псевдо-класс :placeholder-shown на поле ввода! Он очень давно и хорошо поддерживается, так что почему бы и нет. Оставим за пределами этого обсуждения тот факт, что плейсхолдеры не должны заменять реальные метки. Это всё равно уже стало де-факто стандартом индустрии... но постарайтесь так не делать. И, конечно, пример: https://codepen.io/alinaki/pen/xxMpgLK?editors=1100 Там заодно используются SVG-спрайты, потому что мне лениво подключать профессиональный аккаунт на кодпене и грузить туда картинки. Так что заодно можно посмотреть, как работать со спрайтами. Пригодится! Всем бу, котаны! #css #placeholder #svg #sprite #бородач

#ссылка дня Каждый из нас при взгляде на кодовую базу когда-нибудь ловит себя на мысли "есть ли вариант элегантнее и проще, может спецификацию обновили". Особенно это актуально в контексте стилизации (к счастью сейчас развитие спецификации можно назвать стремительным). Но чтение разрозненных статей/заметок, попытки получить внятный ответ ИИ зачастую вносят лишь сумятицу. Ведь хорошо когда можно найти готовые примеры современных решений частых (и не очень) задач в сравнении до/после. Еще лучше когда для каждого примера указана поддержка браузерами использованных свойств спецификации. https://modern-css.com содержит пока небольшое количество примеров, но с понятным описанием и ченжлогом

#тред дня Давно я не пользовал этот тег. Что мы делаем с тредами дня из X/Твиттера (Мастодона и так далее)? Правильно, воруем! В этот раз воруем тред Антона C++ про компилятор, который был написан ИИ. Ссылку тоже прилагаем. На прошлой неделе показали компилятор Си, собирающий ядро linux, ffmpeg и много другое + проходящий 99% GCC тестов, а сам компилятор написан полностью ИИ. Оператор этой мультиагентной системы только задавал направление. За 2 недели сожгли 20к$ и получили вот такой результат. ИИ-инфлюенсеры и позитивисты высрались в очередной раз, что скоро будет эпоха одиночек, корпорации и команды не нужны, через 2 года все программисты пойдут искать работу в ноготочках или где там ещё машина не заменит человека. Почитайте @platoff в качестве такого примера. В этом плане они совершенно правы, мир меняется и скоро изменится ещё сильнее. Если вы уже сейчас не изучаете, или, что ещё лучше, не ищите подходы к разработке с помощью/через ИИ, то скоро вы будете профнепригодны. ИИ это новый git и IDE, некоторые уже спрашивают на собеседованиях, но через 3 года уже будет стыдно не уметь, а через 5 стыдно спрашивать (git и IDE на это потребовалось лет 10-15). А теперь самое важное, на что ИИ позитивисты закрывают глаза, но что полностью и подчистую разматывает их позицию о том, что программисты останутся без работы: компилятор Си на нейрослопе - неоптимизирующий. Да, он производит код, способный работать на парочке платформ, но даже при прохождении 99% тестов это не 1% того, что требуется от компилятора. От компилятора требуется не производить код, но производить эффективный код. И эффективный код нужен для сотен разных чипов, со своими наборами расширений, десятка операционных систем и ещё вороха стандартов, каждый из которых хочет решить свою проблему. И всё это работа инженеров и программистов, которая длится 40 лет. Машина может написать код, но не может найти и описать проблему реального мира. Если вы активно пользуетесь ИИ, то вы знаете, что дать описание проблемы не значит получить решение, скорее всего вы получите нейрослоп, который удовлетворит поверхностное любопытство, но не более. Плохие новости в том, что если найти правильный подход к использованию ИИ, мы и правда будем лучше и эффективнее как программисты, а значит нам придётся это сделать. Машины отбирают наше любимое занятие - писать код, но с другой стороны, может быть, они дадут нам расти дальше, куда нам не давала расти постоянная необходимость писать код. Жаль, конечно, что нас не спросили, но что уже теперь поделать, будущее яркое и нам всё ещё есть в нём место, но только мы в этом будущем уже не будем прежними. То есть ничего нового не произошло, осталось только это принять. /thread А теперь от автора канала: если хотите здорово посмеяться, вот вам ссылка на issues это компилятора, где у людей не собирается Hello World: https://github.com/anthropics/claudes-c-compiler/issues/1 Дивный новый мир. #ai #llm #future

#статья дня Оказывается, `ignore`-файлы — это не только .gitignore. Почти каждый инструмент в экосистеме тащит свою версию формата, и хотя все говорят «поддерживаем синтаксис gitignore», нюансы часто отличаются. Хороший пример — .npmignore. Если его нет, npm ориентируется на .gitignore. Но как только вы добавляете .npmignore, он полностью заменяет правила из .gitignore. В итоге можно случайно опубликовать в пакет то, что в Git было исключено, или наоборот — не опубликовать нужные файлы. Поведение похоже, но не идентично, и легко запутаться. В статье перечисляется целый зоопарк `ignore`-файлов: .gitignore — Git .dockerignore — Docker .npmignore — npm .prettierignore — Prettier .eslintignore — ESLint .stylelintignore — Stylelint .hgignore — Mercurial .containerignore — Podman/Buildah .gcloudignore — Google Cloud CLI .vercelignore — Vercel .slugignore — Heroku .cfignore — Cloud Foundry .helmignore — Helm и т. д. и т. п. Вывод простой: одинаковое название не гарантирует одинаковое поведение. Если инструмент что-то «внезапно» включает или исключает — почти всегда дело в деталях реализации ignore-логики. Собственно, ссылка: https://nesbitt.io/2026/02/12/the-many-flavors-of-ignore-files.html #gitignore #ignore