Forwarded from Web Stack
Александр Моргунов — Разбираемся в Feature-Sliced Design
Посмотрим, что из себя представляет архитектурная методология Feature-Sliced Design и ее основные концепты.
https://www.youtube.com/watch?v=H_rJ0zB8rqc
Посмотрим, что из себя представляет архитектурная методология Feature-Sliced Design и ее основные концепты.
https://www.youtube.com/watch?v=H_rJ0zB8rqc
Что случилось с легковесными десктопными приложениями? История Electron / Хабр
https://habr.com/ru/companies/ruvds/articles/873714/
https://habr.com/ru/companies/ruvds/articles/873714/
🔥1
Forwarded from FrontEndDev
AI ассистент прямо в DevTools
С недавнего времени в Chrome появился свой асистент, который помогает с вопросами по отладке. Вот небольшой обзор и краткое руководство от разработчиков Chrome.
https://developer.chrome.com/docs/devtools/ai-assistance?hl=ru
С недавнего времени в Chrome появился свой асистент, который помогает с вопросами по отладке. Вот небольшой обзор и краткое руководство от разработчиков Chrome.
https://developer.chrome.com/docs/devtools/ai-assistance?hl=ru
Forwarded from FrontEndDev
RegexpGarden
Игровое обучение регулярным выражениям. 42 задания от просто к сложному раскрывают аспекты работы с регулярками.
👉 Внимание, чтобы перейти к описанию урока нажмите на крестик в сайдбаре (рядом с Select Lesson)
https://regexp-garden.madewith.fun/
Игровое обучение регулярным выражениям. 42 задания от просто к сложному раскрывают аспекты работы с регулярками.
👉 Внимание, чтобы перейти к описанию урока нажмите на крестик в сайдбаре (рядом с Select Lesson)
https://regexp-garden.madewith.fun/
🔥1
В этой заметке мы рассмотрим, как с помощью типов ts и предикатов можно упростить обработку результатов Promise.allSettled, выделяя значения успешных промисов и причины ошибок.
Please open Telegram to view this post
VIEW IN TELEGRAM
JetBrains анонсировала Junie – нейросетевого агента для программирования
https://habr.com/p/876162/
https://habr.com/p/876162/
Habr
JetBrains анонсировала Junie – нейросетевого агента для программирования
В блоге JetBrains анонсировали Junie — автономного нейросетевого агента-программиста, которому можно поручать небольшие рабочие задачи. Компания уже запустила программу раннего доступа. Отмечается,...
Forwarded from mefody.dev
Шаблонные литералы в TypeScript
У доктора Акселя Раушмайера вышел очень хороший гайд по тому, как можно полезно применять шаблонные литералы в TS. Это когда вы пишете что-то вроде
Видел, как при помощи таких «умных» типов делали супер-мощные проверки контрактов с бекендом, прокачивали типы внешних библиотек и в целом сильно улучшали DX (автокомплит — одно удовольствие).
https://2ality.com/2025/01/template-literal-types.html
У доктора Акселя Раушмайера вышел очень хороший гайд по тому, как можно полезно применять шаблонные литералы в TS. Это когда вы пишете что-то вроде
type TailwindColor = `${BaseColor}-${Variant}`;, а внутри уточняете допустимые типы-значения.Видел, как при помощи таких «умных» типов делали супер-мощные проверки контрактов с бекендом, прокачивали типы внешних библиотек и в целом сильно улучшали DX (автокомплит — одно удовольствие).
https://2ality.com/2025/01/template-literal-types.html
2Ality
Template literal types in TypeScript: parsing during type checking and more
In this blog post, we take a closer look at template literal types in TypeScript: While their syntax is similar to JavaScript’s template literals, they operate at the type level. Their use cases include: Static syntax checking for string literals Transforming…
Forwarded from 🧊 siberiacancode x IT-ХОЗЯЕВА
Тяжело быть перфекционистом в бигтехе ☎️
Об этом действительно можно написать книгу, чем больше вы работает, тем больше вы создаете, чем больше вы создаете, тем больше будет легаси. Бесконечный круг производства. А самое главное, что не все легаси вам дадут переписать, некоторое легаси вы будете тащить из проекта в проект, какой то проект вы просто удалите и попрощаетесь с ним.
Звучит грустно, но важно понимать, что это реальная жизнь и такой цикл — это норма. Невозможно все сделать идеальным, невозможно просто взять и зарефакторить сразу весь проект, а где-то это и не нужно.
Тяжело быть перфекционистом в бигтехе, все что мы напишем станет легаси, мы это или перепишем или выбросим🗑
Об этом действительно можно написать книгу, чем больше вы работает, тем больше вы создаете, чем больше вы создаете, тем больше будет легаси. Бесконечный круг производства. А самое главное, что не все легаси вам дадут переписать, некоторое легаси вы будете тащить из проекта в проект, какой то проект вы просто удалите и попрощаетесь с ним.
Звучит грустно, но важно понимать, что это реальная жизнь и такой цикл — это норма. Невозможно все сделать идеальным, невозможно просто взять и зарефакторить сразу весь проект, а где-то это и не нужно.
Тяжело быть перфекционистом в бигтехе, все что мы напишем станет легаси, мы это или перепишем или выбросим
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from artalog (artalar)
Я как-то работал с челом, который каждые полгода-год переписывал бэкенд полностью. Но делал это по-умному.
У него в разработке постоянно было две версии бэка: текущая с самыми страшными костылями новых фич и будущая (не зарелиженная), в которой он внедрял новые фичи, ломая всё, что под руку попадется.
Т.е. обычно внедрение кода тормозится о две вещи: нужно сделать нормально для будущей поддержки, и при этом нужно не сломать обратную совместимость. Ведя параллельно живую ветку, которую ты точно скоро выбросишь и в которой можно писать любой хардкод, и неродившуюся ветку, в которой можно постоянно ломать совместимость, появляется возможность раз в какой-то срок делать большой релиз с любыми техническими и функциональными обновлениями за небольшую цену.
Конечно, обе ветки должны жить в богатом тестовом окружении при этом.
(по мотивам https://t.me/siberiacancode/1654)
У него в разработке постоянно было две версии бэка: текущая с самыми страшными костылями новых фич и будущая (не зарелиженная), в которой он внедрял новые фичи, ломая всё, что под руку попадется.
Т.е. обычно внедрение кода тормозится о две вещи: нужно сделать нормально для будущей поддержки, и при этом нужно не сломать обратную совместимость. Ведя параллельно живую ветку, которую ты точно скоро выбросишь и в которой можно писать любой хардкод, и неродившуюся ветку, в которой можно постоянно ломать совместимость, появляется возможность раз в какой-то срок делать большой релиз с любыми техническими и функциональными обновлениями за небольшую цену.
Конечно, обе ветки должны жить в богатом тестовом окружении при этом.
(по мотивам https://t.me/siberiacancode/1654)
🔥1
Forwarded from Open Source
This media is not supported in your browser
VIEW IN TELEGRAM
File Converter
File Converter — это удобный инструмент для конвертации и сжатия файлов, доступный через контекстное меню проводника Windows.
Начавшись в 2014 году как проект с открытым исходным кодом, он направлен на упрощение процесса конвертации для пользователей и поддерживает множество языков благодаря усилиям локализаторов.
Программа использует ffmpeg для конвертации, ImageMagick для изображений и Ghostscript для редактирования PDF.
https://github.com/Tichau/FileConverter
================
👁 News | 👁 Software | 👁 Hardware
File Converter — это удобный инструмент для конвертации и сжатия файлов, доступный через контекстное меню проводника Windows.
Начавшись в 2014 году как проект с открытым исходным кодом, он направлен на упрощение процесса конвертации для пользователей и поддерживает множество языков благодаря усилиям локализаторов.
Программа использует ffmpeg для конвертации, ImageMagick для изображений и Ghostscript для редактирования PDF.
https://github.com/Tichau/FileConverter
================
Please open Telegram to view this post
VIEW IN TELEGRAM
Как разбирать логи в Linux: journalctl, grep, awk и sed / Хабр
https://habr.com/ru/companies/otus/articles/879032/
https://habr.com/ru/companies/otus/articles/879032/
Docker Compose: Фичи, которые ускорят вашу разработку / Хабр
https://habr.com/ru/companies/barsgroup/articles/879132/
https://habr.com/ru/companies/barsgroup/articles/879132/
🔥1
Forwarded from mefody.dev
Кнопка «Вверх» с индикатором прогресса
Мануэль Матузович собирает популярную на различных сайтах кнопку «Scroll to top» на HTML и CSS. Кнопка из коробки доступная (потому что ссылка), заодно показывает, сколько процентов страницы уже прочитано пользователем. «2-в-1, только сейчас в нашем онлайн-магазине, ещё и бесплатно!»
Заранее предупрежу, что использует она под капотом современные возможности браузеров вроде Scroll Timeline API и
https://matuzo.at/blog/2025/scroll-to-top-button
Мануэль Матузович собирает популярную на различных сайтах кнопку «Scroll to top» на HTML и CSS. Кнопка из коробки доступная (потому что ссылка), заодно показывает, сколько процентов страницы уже прочитано пользователем. «2-в-1, только сейчас в нашем онлайн-магазине, ещё и бесплатно!»
Заранее предупрежу, что использует она под капотом современные возможности браузеров вроде Scroll Timeline API и
@property, но это не мешает прогрессбар прикручивать как прогрессивное улучшение.https://matuzo.at/blog/2025/scroll-to-top-button
Manuel Matuzovic
Building a progress-indicating scroll-to-top button in HTML and CSS
I'm a frontend developer in Graz, specialized in HTML, accessibility, and CSS layout and architecture.
Forwarded from Уставший техдир
Кто такой Individual Contributor?
Многие считают, что единственный путь карьерного роста в IT — это менеджмент. Тимлид, руководитель разработки, технический директор… Но что, если ты не хочешь управлять людьми, а хочешь расти как инженер?
Вот тут и появляется IC-ветка — путь для тех, кто создает ценность через экспертизу, а не управление. В российских реалиях ей соответствуют ведущий инженер, инженер-эксперт, главный специалист, а в международной терминологии — Staff Engineer, Principal Engineer, Distinguished Engineer.
IC — это про:
- Глубину: архитектура, исследования, сложные технические вызовы.
- Влияние: через код, архитектуру, решения, а не через управление людьми.
- Фокус: на самых нетривиальных и масштабных задачах.
- Лидерство: через менторство, ревью, стандарты и лучшие практики.
Без IC тяжело построить сложную и успешную систему. Они, зачастую, влияют на бизнес не меньше, чем руководители. Но, в наших компаниях очень часто это происходит неявно: просто крутой разраб, сидит в какой-нибудь команде и тихо шаманить свою тему. И все знают к кому прийти на советом)
Отсюда и ощущение, что менеджмент — единственный рост. Но это не так
Многие считают, что единственный путь карьерного роста в IT — это менеджмент. Тимлид, руководитель разработки, технический директор… Но что, если ты не хочешь управлять людьми, а хочешь расти как инженер?
Вот тут и появляется IC-ветка — путь для тех, кто создает ценность через экспертизу, а не управление. В российских реалиях ей соответствуют ведущий инженер, инженер-эксперт, главный специалист, а в международной терминологии — Staff Engineer, Principal Engineer, Distinguished Engineer.
IC — это про:
- Глубину: архитектура, исследования, сложные технические вызовы.
- Влияние: через код, архитектуру, решения, а не через управление людьми.
- Фокус: на самых нетривиальных и масштабных задачах.
- Лидерство: через менторство, ревью, стандарты и лучшие практики.
Без IC тяжело построить сложную и успешную систему. Они, зачастую, влияют на бизнес не меньше, чем руководители. Но, в наших компаниях очень часто это происходит неявно: просто крутой разраб, сидит в какой-нибудь команде и тихо шаманить свою тему. И все знают к кому прийти на советом)
Отсюда и ощущение, что менеджмент — единственный рост. Но это не так
🔥1
Forwarded from katsuba.dev (Igor Katsuba)
🔥 Вышла документалка про Angular! 🔥
На YouTube вышел документальный фильм про историю Angular! 🎬 Если вам интересно, как фреймворк прошел путь от внутреннего эксперимента Google до одного из самых обсуждаемых инструментов в мире JavaScript, этот фильм для вас!
🔹 Как Gmail и Google Maps отказались от AngularJS?
🔹 Почему команда решила полностью переделать фреймворк?
🔹 Какие вызовы стояли перед Angular 2, Ivy и Signals?
🔹 Как Angular снова становится важным для Google?
📺 Смотрим: YouTube
#Angular #JavaScript #WebDev #Frontend #Google
На YouTube вышел документальный фильм про историю Angular! 🎬 Если вам интересно, как фреймворк прошел путь от внутреннего эксперимента Google до одного из самых обсуждаемых инструментов в мире JavaScript, этот фильм для вас!
🔹 Как Gmail и Google Maps отказались от AngularJS?
🔹 Почему команда решила полностью переделать фреймворк?
🔹 Какие вызовы стояли перед Angular 2, Ivy и Signals?
🔹 Как Angular снова становится важным для Google?
📺 Смотрим: YouTube
#Angular #JavaScript #WebDev #Frontend #Google
YouTube
Angular: The Documentary | An origin story
Born as an internal Google experiment - and initially brushed off by Gmail and Google Maps - AngularJS soon became a JavaScript sensation. But when internal pressures pushed the team towards a radical overhaul of the framework, the community felt left behind.…
Промпты для ChatGPT, которые могут повысить качество ответов ChatGPT / Хабр
https://habr.com/ru/articles/880708/
https://habr.com/ru/articles/880708/
Forwarded from Уставший техдир
Притча про три конверта
Старый Head of Engineering уходит из компании и передаёт дела молодому преемнику. Напоследок вручает ему три конверта и говорит:
— Когда начнутся серьёзные проблемы, вскрой первый конверт.
Сначала всё идёт отлично: команда продуктивна, CI/CD работает как часы, релизы выходят вовремя. Но в какой-то момент начинаются проблемы: технический долг, дедлайны срываются, продакшен падает. Руководитель в панике, но вспоминает про конверты. Открывает первый:
— "Вали всё на предыдущую команду!"
Он так и делает: рассказывает CTO, как унаследованный код ужасен, архитектура устарела, а процесс разработки давно пора переделать. Получает поддержку, выстраивает новые процессы, дела улучшаются.
Но через год ситуация снова ухудшается. Продукт растёт, скорость разработки падает, баги множатся. Вскрывает второй конверт:
— "Обещай всё исправить и делай красивые роадмапы!"
Он начинает рисовать графики, анонсирует рефакторинг, миграцию на новую архитектуру, внедрение best practices. Команда вдохновляется, менеджеры успокаиваются, и всё вроде бы налаживается.
Но проходит время, и проблемы возвращаются: рефакторинг затянулся, технический долг растёт, сроки срываются. Уже не получится свалить вину на предыдущих, и красивые планы больше не работают. Вскрывает последний конверт:
— "Готовь три конверта…"
П.С. Последнее время часто ее вспоминал, нашел и попроси GPT переделать под руководителя разработки, цитирую в оригинале. Вообще, конечно, да, можно долго удивлятьсякак быстро растут дети как быстро развивается искусственный интеллект. Еще 25 лет назад, компов ни у кого не было особо, а сейчас — вот это вот. Дела
П.П.С. Все персонажисгенерированы выдуманы, аналогии случайны. Если вы узнали себя, извините
Старый Head of Engineering уходит из компании и передаёт дела молодому преемнику. Напоследок вручает ему три конверта и говорит:
— Когда начнутся серьёзные проблемы, вскрой первый конверт.
Сначала всё идёт отлично: команда продуктивна, CI/CD работает как часы, релизы выходят вовремя. Но в какой-то момент начинаются проблемы: технический долг, дедлайны срываются, продакшен падает. Руководитель в панике, но вспоминает про конверты. Открывает первый:
— "Вали всё на предыдущую команду!"
Он так и делает: рассказывает CTO, как унаследованный код ужасен, архитектура устарела, а процесс разработки давно пора переделать. Получает поддержку, выстраивает новые процессы, дела улучшаются.
Но через год ситуация снова ухудшается. Продукт растёт, скорость разработки падает, баги множатся. Вскрывает второй конверт:
— "Обещай всё исправить и делай красивые роадмапы!"
Он начинает рисовать графики, анонсирует рефакторинг, миграцию на новую архитектуру, внедрение best practices. Команда вдохновляется, менеджеры успокаиваются, и всё вроде бы налаживается.
Но проходит время, и проблемы возвращаются: рефакторинг затянулся, технический долг растёт, сроки срываются. Уже не получится свалить вину на предыдущих, и красивые планы больше не работают. Вскрывает последний конверт:
— "Готовь три конверта…"
П.С. Последнее время часто ее вспоминал, нашел и попроси GPT переделать под руководителя разработки, цитирую в оригинале. Вообще, конечно, да, можно долго удивляться
П.П.С. Все персонажи
Forwarded from BEARlogin
FSD: дело было не в бобине...
Часто слышу критику FSD: "Слишком много папок, слишком много правил, это избыточно!".
Но хочу сказать, что FSD — это не про количество папок. Это про направление зависимостей и архитектурные границы.
Ты не обязан сразу строить многоэтажный небоскрёб, если у тебя пока маленький проект. Начать можно просто.
С чего начинать?
На старте достаточно трёх слоёв:
1. app/ — конфигурация приложения: роутинг, провайдеры, глобальные стили.
2. shared/ — переиспользуемые, не связанные с бизнесом компоненты, утилиты, стили и т.д.
3. pages/ — страницы приложения и используемые ими компоненты.
Сначала можно оставить всё в pages, если функциональность используется только там.
Но как только начинаешь дублировать код, либо твой слайс хочет что то импортировать у соседей, то логично вынести его в widgets.
А затем продолжаешь углублять структуру. Например, если два widget используют схожую логику или функциональность, то логично вынести её в features. Дальше это движение продолжается по мере необходимости.
Что касается entities и shared, то здесь есть определённая специфика. Об этом я расскажу в следующих постах.
Вынос в новый сегмент какого то функционала не является самоцелью. Я бы сказал, даже наоборот — если можно не выносить и остаться в рамках одного слайса — оставайтесь.
Таким образом FSD подходят для любых проектов на старте, позволяя сразу закладывать возможности для масштабирования и помогает соблюдать принципы низкой связанности и высокого зацепления.
Ставьте🔥 , если хотите больше практических примеров и советов по FSD.
BEARlogin dev — подпишись!
P.S. советую этот экстеншн для генерации слайсов https://marketplace.visualstudio.com/items?itemName=SbokyZahodi.fsd-slices
#архитектура #frontend #fsd
Подготовлю к собесам, помогу с рабочими задачами и росту хардов/софтов. Уперся в потолок с з/п, ответственностью?
Если необходимо менторство - пишите @bearlogin
Часто слышу критику FSD: "Слишком много папок, слишком много правил, это избыточно!".
Но хочу сказать, что FSD — это не про количество папок. Это про направление зависимостей и архитектурные границы.
Ты не обязан сразу строить многоэтажный небоскрёб, если у тебя пока маленький проект. Начать можно просто.
Кстати, само название FSD (Feature-Sliced Design), на мой взгляд, не совсем корректно. Это не "дизайн, разделенный на фичи". Скорее, это методология, которая помогает структурировать код, организуя его вокруг бизнес-функционала и уровней ответственности, позволяя соблюдать принципы Low coupling и High cohesion.
Можете в комментариях предложить своё название. Лично я бы назвал это Business-Sliced Design — чтобы невозможно было интерпретировать методологию упрощённо и требовалось изучение её сути.
С чего начинать?
На старте достаточно трёх слоёв:
1. app/ — конфигурация приложения: роутинг, провайдеры, глобальные стили.
2. shared/ — переиспользуемые, не связанные с бизнесом компоненты, утилиты, стили и т.д.
3. pages/ — страницы приложения и используемые ими компоненты.
src/
app/
App.tsx
routes.ts
shared/
ui/
Button/
index.tsx
pages/
catalog/
ui/
CatalogPage.tsx
ProductList.tsx //кандидат на вынос
index.ts
recommended/
ui/
RecommendedPage.tsx
ProductList.tsx
index.ts
Сначала можно оставить всё в pages, если функциональность используется только там.
Но как только начинаешь дублировать код, либо твой слайс хочет что то импортировать у соседей, то логично вынести его в widgets.
src/
app/
App.tsx
routes.ts
shared/
ui/
Button/
index.tsx
widgets/
product-list/
ui/
ProductList.tsx
model/
useProducts.ts
index.ts
pages/
catalog/
ui/
CatalogPage.tsx
index.ts
recommended/
ui/
RecommendedPage.tsx
index.ts
А затем продолжаешь углублять структуру. Например, если два widget используют схожую логику или функциональность, то логично вынести её в features. Дальше это движение продолжается по мере необходимости.
Что касается entities и shared, то здесь есть определённая специфика. Об этом я расскажу в следующих постах.
Вынос в новый сегмент какого то функционала не является самоцелью. Я бы сказал, даже наоборот — если можно не выносить и остаться в рамках одного слайса — оставайтесь.
Таким образом FSD подходят для любых проектов на старте, позволяя сразу закладывать возможности для масштабирования и помогает соблюдать принципы низкой связанности и высокого зацепления.
Ставьте
BEARlogin dev — подпишись!
P.S. советую этот экстеншн для генерации слайсов https://marketplace.visualstudio.com/items?itemName=SbokyZahodi.fsd-slices
#архитектура #frontend #fsd
Подготовлю к собесам, помогу с рабочими задачами и росту хардов/софтов. Уперся в потолок с з/п, ответственностью?
Если необходимо менторство - пишите @bearlogin
Please open Telegram to view this post
VIEW IN TELEGRAM
Занятная статья о сложностях перехода на другой яп при непрерывной разработке проекта.
https://habr.com/ru/companies/yandex/articles/871868/
Please open Telegram to view this post
VIEW IN TELEGRAM