Forwarded from Node.js Ukraine Community
Пруф возможности состояния гонки в асинхронном программировании на JavaScript https://github.com/HowProgrammingWorks/RaceCondition/tree/master/JavaScript
Forwarded from Валя читает ишью
Say Goodbye to dotenv
И вот, начиная с 20.6.0, в ноду встроена поддержка dotenv конфигов.
Конфиг явно передаётся через флаг --env-file:
До этого всегда приходилось использовать motdotla/dotenv.
И вот, начиная с 20.6.0, в ноду встроена поддержка dotenv конфигов.
Конфиг явно передаётся через флаг --env-file:
node --env-file=config.env index.jsДо этого всегда приходилось использовать motdotla/dotenv.
👍3
Forwarded from Flutter Talks
🔥 Flutter Talks #1
42 Meetups и наши друзья из DAR University рады пригласить вас на наш первый митап по направлению Dart/Flutter.
Встречаемся 23-го сентября в 11:00, слушаем доклады, общаемся и кушаем пиццу.
Адрес: Байзакова 280, пространство SmartPoint, зал Freedom.
Список спикеров будет доступен уже в ближайшее время. Темы вас точно заинтересуют.
Участие бесплатное, регистрация доступна по ссылке — Google Forms.
Важно: количество мест ограничено, не откладывайте регистрацию в долгий ящик.
@flutter_talks
42 Meetups и наши друзья из DAR University рады пригласить вас на наш первый митап по направлению Dart/Flutter.
Встречаемся 23-го сентября в 11:00, слушаем доклады, общаемся и кушаем пиццу.
Адрес: Байзакова 280, пространство SmartPoint, зал Freedom.
Список спикеров будет доступен уже в ближайшее время. Темы вас точно заинтересуют.
Участие бесплатное, регистрация доступна по ссылке — Google Forms.
Важно: количество мест ограничено, не откладывайте регистрацию в долгий ящик.
@flutter_talks
🔥1
Forwarded from Node.js Ukraine Community
⭐️ Тут сведены идеи применения AI, точнее LLMок в разработке программного обеспечения. Что они делают хорошо 🟢, что удовлетворительно 🟧, а что вообще плохо 🛑
🟢 Анализ больших объемов данных, которые человеку сложно внимательно обработать
∙ логов и стектрейсов
∙ memory dumps
∙ dependency trees
∙ git blame
🟢 Портирование:
∙ с одной версии фреймворка или библиотеки на другую
∙ с одного языка на другой
∙ с одной СУБД на другую
∙ с одной OS на другую или поддержка нескольких
🟢 Боты и тулинг для автоматизации обработки кодовой базы и репозиториев:
∙ применение стиля
∙ применение чеклиста изменений
∙ поиск уязвимостей в кодовой базе
∙ маркировка commits, pull requests, issues
∙ расстановка тегов по коммитам и т.д.
∙ автоматизация закрытия тасков, майлстоунов
∙ поиск дубликатов кода, тасков, или перелинковка связанных
∙ аудит объемов работы, качества, сбор статистики
∙ предложения для рефакторинга
∙ поддержание консистентности кодовой базы и стиля
∙ создание спеки стиля кода по примерам кода или кодовой базе проекта
∙ предложение метрик для оценки кода и вычисление этих метрик
🟢 Написание текстов:
∙ подготовка CHANGELOG, HOW TO, Q&A
∙ генерация документации по коду
∙ реверс-инжиниринг кода в ТЗ
∙ поиск отличий между ТЗ, кодом, доками
∙ преобразование между форматами данных, например json, csv, pdf, sql, txt
🟢 Управление проектами
∙ оценка трудоемкости разработки, времени и денег
∙ оценка возможности распараллеливания разработки
∙ поиск слабых мест и выявление проблем в сметах, планах, ТЗ
∙ предложения по оптимизации бизнес-процессов
∙ сбор данных для подготовки принятия решений
🟢 Программирование
∙ алгоритмические задачи, подбор и реализация алгоритмов
∙ портирование, перевод и транспиляция между языками программирования
∙ преобразование между class и prototype в JavaScript
∙ оптимизация по заданному критерию: cpu, ram, i/o, lines, читаемость, сложность, etc.
∙ объяснение кода
∙ генерация примеров использования библиотек или абстракций
∙ ревью пул реквестов
∙ генерация юниттестов, системных тестов
∙ генерация конфигураций
∙ настройка CI/CD
∙ генерация SQL запросов
∙ генерация API, CRUD, формочек
∙ генерация моделей, структур, DTO, схем данных, классов, jsdoc
∙ преобразование моделей между разными синтаксисами
∙ синхронизаций структуры базы данных, схем, моделей, форочек
∙ генерация тайпингов и заголовочных файлов как .h, .d.ts
∙ подготовка контрактов и описание интерфейсов для интеграции систем
∙ генерация парсеров, конвертеров, по примерам входных и выходных форматов данных
∙ генерация валидаторов данных и валидаторов контрактов
🟧 Задачи, которые LLMки делают, но не всегда качественно и с проблемами
∙ терпимо конвертирует код между парадигмами: ООП, процедурное и структурное программирование
∙ гораздо хуже конвертирует между ООП и ФП
∙ асинхронное программирование и задачи с доступом к состоянию из разных мест
∙ олимпиадное программирование
∙ подготовка шаблонов и примеров приложений/проектов
∙ выбор зависимостей
∙ выбор СУБД, языков программирования, платформ, тулинга
∙ концептуальный код, демонстрирующий идею и делающий ее понятнее для многих
🛑 Что плохо решается при помощи LLMок
∙ системное программирование
∙ платформенный код, код библиотек, фреймворков
∙ новые и прорывные технологические решения, которые негде подсмотреть
∙ большинство новых нетипичных задач, когда в интернете мало примеров кода
∙ архитектура систем и структура приложений, даже при наличии множества примеров
🟢 Анализ больших объемов данных, которые человеку сложно внимательно обработать
∙ логов и стектрейсов
∙ memory dumps
∙ dependency trees
∙ git blame
🟢 Портирование:
∙ с одной версии фреймворка или библиотеки на другую
∙ с одного языка на другой
∙ с одной СУБД на другую
∙ с одной OS на другую или поддержка нескольких
🟢 Боты и тулинг для автоматизации обработки кодовой базы и репозиториев:
∙ применение стиля
∙ применение чеклиста изменений
∙ поиск уязвимостей в кодовой базе
∙ маркировка commits, pull requests, issues
∙ расстановка тегов по коммитам и т.д.
∙ автоматизация закрытия тасков, майлстоунов
∙ поиск дубликатов кода, тасков, или перелинковка связанных
∙ аудит объемов работы, качества, сбор статистики
∙ предложения для рефакторинга
∙ поддержание консистентности кодовой базы и стиля
∙ создание спеки стиля кода по примерам кода или кодовой базе проекта
∙ предложение метрик для оценки кода и вычисление этих метрик
🟢 Написание текстов:
∙ подготовка CHANGELOG, HOW TO, Q&A
∙ генерация документации по коду
∙ реверс-инжиниринг кода в ТЗ
∙ поиск отличий между ТЗ, кодом, доками
∙ преобразование между форматами данных, например json, csv, pdf, sql, txt
🟢 Управление проектами
∙ оценка трудоемкости разработки, времени и денег
∙ оценка возможности распараллеливания разработки
∙ поиск слабых мест и выявление проблем в сметах, планах, ТЗ
∙ предложения по оптимизации бизнес-процессов
∙ сбор данных для подготовки принятия решений
🟢 Программирование
∙ алгоритмические задачи, подбор и реализация алгоритмов
∙ портирование, перевод и транспиляция между языками программирования
∙ преобразование между class и prototype в JavaScript
∙ оптимизация по заданному критерию: cpu, ram, i/o, lines, читаемость, сложность, etc.
∙ объяснение кода
∙ генерация примеров использования библиотек или абстракций
∙ ревью пул реквестов
∙ генерация юниттестов, системных тестов
∙ генерация конфигураций
∙ настройка CI/CD
∙ генерация SQL запросов
∙ генерация API, CRUD, формочек
∙ генерация моделей, структур, DTO, схем данных, классов, jsdoc
∙ преобразование моделей между разными синтаксисами
∙ синхронизаций структуры базы данных, схем, моделей, форочек
∙ генерация тайпингов и заголовочных файлов как .h, .d.ts
∙ подготовка контрактов и описание интерфейсов для интеграции систем
∙ генерация парсеров, конвертеров, по примерам входных и выходных форматов данных
∙ генерация валидаторов данных и валидаторов контрактов
🟧 Задачи, которые LLMки делают, но не всегда качественно и с проблемами
∙ терпимо конвертирует код между парадигмами: ООП, процедурное и структурное программирование
∙ гораздо хуже конвертирует между ООП и ФП
∙ асинхронное программирование и задачи с доступом к состоянию из разных мест
∙ олимпиадное программирование
∙ подготовка шаблонов и примеров приложений/проектов
∙ выбор зависимостей
∙ выбор СУБД, языков программирования, платформ, тулинга
∙ концептуальный код, демонстрирующий идею и делающий ее понятнее для многих
🛑 Что плохо решается при помощи LLMок
∙ системное программирование
∙ платформенный код, код библиотек, фреймворков
∙ новые и прорывные технологические решения, которые негде подсмотреть
∙ большинство новых нетипичных задач, когда в интернете мало примеров кода
∙ архитектура систем и структура приложений, даже при наличии множества примеров
🚀 Состоялся релиз Lit 3.0.
В посте детали. Интересен тем что из лабс вышла интеграция с реактом. И конечно же сигналы в качестве эксперимента.
В посте детали. Интересен тем что из лабс вышла интеграция с реактом. И конечно же сигналы в качестве эксперимента.
X (formerly Twitter)
Lit on X
It's Lit Launch Day!
Say “Bye bye” to Internet Explorer, and “Ay up 👋” to a new major release of Lit and some brand new toys for you to try 🧸!
We can’t fit everything into a single tweet, so check out the 🧵and release post: https://t.co/psbihMN06d
Say “Bye bye” to Internet Explorer, and “Ay up 👋” to a new major release of Lit and some brand new toys for you to try 🧸!
We can’t fit everything into a single tweet, so check out the 🧵and release post: https://t.co/psbihMN06d
Forwarded from Валя читает ишью
Safari class fields implementation is buggy: part two, Tt edition
Я уже рассказывал о том, как сафари не очень хорошо (мягко говоря) дружит с замыканиями в class fields. И вот, спустя полгода, мы снова здесь. Long time no see как говорится!
В прошлый четверг я закончил миграцю с Jest на Vitest в последнем нашем проекте (про наш опыт можно почитать тут), всё протестил и выкатил в прод. На следующей день пришла жалоба от пользователя «форма поиска исчезает в сафари 15 — ничего не работает». При этом я форму эту не трогал даже близко. Весело!
Для начала пошли в BrowserStack чтобы посмотреть что ж там в 15 сафари происходит (какая же гениальная система обновлений у сафари, боже, я никогда это не пойму). В 15 сафари мы ничего не могли воспроизвести около часа, хотя у тестировщика разок получилось. Решили ради интереса попробовать сафари 14, который мы не поддерживаем — и сразу же воспроизвелось, причём стабильно. Увидели «ReferenceError: Tt is not defined». В этот раз проблемное место нашли сразу же, т.к. такая переменная была одна на весь бандл. Ну в общем всё тоже самое: class field, замыкание, вспомнили что в 15 сафари проблема иногда воспроизводилась, а иногда не особо.
Но как так вышло, что мы чиним ту же проблему, что и полгода назад? А всё просто — проблема та же, но в другом проекте! Понятно, что это чинится использованием babel/plugin-proposal-class-properties, но почему всё сломалось?
Если поменялся результат билда, то очевидно, что обновилась какая-то транизитивная зависимость (зависимость зависимости зависимости зависимости, ну вы знаете). В yarn.lock смотреть было бесполезно, т.к. дифф очень большой.
Решил сравнить мастер с веткой через yarn info.
и т.д.
В дифе помимо кучи других пакетов, я увидел
Начиная с 7.22.6 в @babel/compat-data указано, что class properties поддерживаются в iOS 14.5, а до этого было указано что в iOS 15, т.е. с Safari 15 сдаунгрейдили поддержку до Safari 14.1. Напомню, без багов эта фича работает начиная с Safari/iOS 16.
Что ж, тут вроде всё понятно. А что с caniuse-lite? Его использует browserslist, чтобы получить браузеры, которые мы хотим поддерживать. В конфиге у нас было указано defaults, last 2 years, not ie > 0, not ie_mob > 0, chrome >= 94. Сравнил вывод
Получается, что к проблеме мог привести апдейт babel/compat-data и caniuse-lite в любых комбинациях: по отдельности и вместе.
А кто их обновил? Ну, в общем-то я, когда устанавливал vitest и пару зависимостей к нему. Мы используем yarn dedupe, чтобы в рамках SemVer использовалась только одна библиотека. При установке и babel/compat-data, и caniuse-lite зарезолвились на последнюю версию и всё сломалось! Этой проблемы можно было бы избежать, если yarn dedupe умел бы в другие стратегии, но пока что только latest.
Ну и напоследок: что сделали, чтобы такого больше не случалось?
1. Явно включили babel/plugin-proposal-class-properties.
2. Посмотрели, что пользователи 14 сафари приносят нам 1% деняк и явно указали safari >= 14 в конфиге браузерслиста.
3. Через resolutions явно установили browserslist и caniuse-lite в единственных экземплярах, чтоб прозрачно контролировать процесс обновления.
А что там с ишью? А ишью в бабеле так и висит без изменений…
Я уже рассказывал о том, как сафари не очень хорошо (мягко говоря) дружит с замыканиями в class fields. И вот, спустя полгода, мы снова здесь. Long time no see как говорится!
В прошлый четверг я закончил миграцю с Jest на Vitest в последнем нашем проекте (про наш опыт можно почитать тут), всё протестил и выкатил в прод. На следующей день пришла жалоба от пользователя «форма поиска исчезает в сафари 15 — ничего не работает». При этом я форму эту не трогал даже близко. Весело!
Для начала пошли в BrowserStack чтобы посмотреть что ж там в 15 сафари происходит (какая же гениальная система обновлений у сафари, боже, я никогда это не пойму). В 15 сафари мы ничего не могли воспроизвести около часа, хотя у тестировщика разок получилось. Решили ради интереса попробовать сафари 14, который мы не поддерживаем — и сразу же воспроизвелось, причём стабильно. Увидели «ReferenceError: Tt is not defined». В этот раз проблемное место нашли сразу же, т.к. такая переменная была одна на весь бандл. Ну в общем всё тоже самое: class field, замыкание, вспомнили что в 15 сафари проблема иногда воспроизводилась, а иногда не особо.
Но как так вышло, что мы чиним ту же проблему, что и полгода назад? А всё просто — проблема та же, но в другом проекте! Понятно, что это чинится использованием babel/plugin-proposal-class-properties, но почему всё сломалось?
Если поменялся результат билда, то очевидно, что обновилась какая-то транизитивная зависимость (зависимость зависимости зависимости зависимости, ну вы знаете). В yarn.lock смотреть было бесполезно, т.к. дифф очень большой.
Решил сравнить мастер с веткой через yarn info.
yarn info --recursive --name-only выводит плоский список зависимостей с их версиями:├─ @adobe/css-tools@npm:4.3.1
├─ @ampproject/remapping@npm:2.2.1
├─ @aviasales/analytics@npm:4.0.7и т.д.
В дифе помимо кучи других пакетов, я увидел
caniuse-lite и @babel/compat-data, а именно их использует @babel/preset-env, чтобы решить нужно трансформировать ту или иную фичу.Начиная с 7.22.6 в @babel/compat-data указано, что class properties поддерживаются в iOS 14.5, а до этого было указано что в iOS 15, т.е. с Safari 15 сдаунгрейдили поддержку до Safari 14.1. Напомню, без багов эта фича работает начиная с Safari/iOS 16.
Что ж, тут вроде всё понятно. А что с caniuse-lite? Его использует browserslist, чтобы получить браузеры, которые мы хотим поддерживать. В конфиге у нас было указано defaults, last 2 years, not ie > 0, not ie_mob > 0, chrome >= 94. Сравнил вывод
yarn dlx browserslist и увидел, что из поддерживаемых браузеров исчез сафари 14, т.к. ему исполнилось больше двух лет.Получается, что к проблеме мог привести апдейт babel/compat-data и caniuse-lite в любых комбинациях: по отдельности и вместе.
А кто их обновил? Ну, в общем-то я, когда устанавливал vitest и пару зависимостей к нему. Мы используем yarn dedupe, чтобы в рамках SemVer использовалась только одна библиотека. При установке и babel/compat-data, и caniuse-lite зарезолвились на последнюю версию и всё сломалось! Этой проблемы можно было бы избежать, если yarn dedupe умел бы в другие стратегии, но пока что только latest.
Ну и напоследок: что сделали, чтобы такого больше не случалось?
1. Явно включили babel/plugin-proposal-class-properties.
2. Посмотрели, что пользователи 14 сафари приносят нам 1% деняк и явно указали safari >= 14 в конфиге браузерслиста.
3. Через resolutions явно установили browserslist и caniuse-lite в единственных экземплярах, чтоб прозрачно контролировать процесс обновления.
А что там с ишью? А ишью в бабеле так и висит без изменений…
Forwarded from Валя читает ишью
DefinitelyTyped is a monorepo!
DefinitelyTyped только что стал полноценным монорепозиторием на основое pnpm!
В DefinitelyTyped хранятся все пакеты в
Масштаб впечатляет — 8710 пакетов в одном репозитории!
Это миграции посвящены аж три поста:
1. What is DefinitelyTyped, and is it a monorepo? — как был устроен репозиторий и какие проблемы были до миграции.
2. Speeding up pnpm — название говорит само за себя. Естественно, при таком объёме всплывают не очень эффективные алгоритмы. Особенно круто, что показан процесс профилирования.
3. DefinitelyTyped is a monorepo! — как теперь всё устроено, какие проблемы сохранились (или появились) и что дальше.
Монументальная работа и огромный, в том числе и маркетинговый, успех для pnpm!
DefinitelyTyped только что стал полноценным монорепозиторием на основое pnpm!
В DefinitelyTyped хранятся все пакеты в
@types организации. Если пакет не поставляет типы сам, то всегда можно прислать пул-реквест в этот репозиторий и установить пакет отдельно (так делает, например, react с его @types/react).Масштаб впечатляет — 8710 пакетов в одном репозитории!
Это миграции посвящены аж три поста:
1. What is DefinitelyTyped, and is it a monorepo? — как был устроен репозиторий и какие проблемы были до миграции.
2. Speeding up pnpm — название говорит само за себя. Естественно, при таком объёме всплывают не очень эффективные алгоритмы. Особенно круто, что показан процесс профилирования.
3. DefinitelyTyped is a monorepo! — как теперь всё устроено, какие проблемы сохранились (или появились) и что дальше.
Монументальная работа и огромный, в том числе и маркетинговый, успех для pnpm!
Вышел ReactQuery 5.
Не то чтобы я рад этому, на мой взгляд есть SWR. Просто информация.
https://twitter.com/TkDodo/status/1714262102305632643
Не то чтобы я рад этому, на мой взгляд есть SWR. Просто информация.
https://twitter.com/TkDodo/status/1714262102305632643
В последнее время нравится использовать Warp Terminal вместо iTerm/Alacrity.
Написан на Rust. AI ассистент. Интерфейс похожий на чат.
https://www.youtube.com/watch?v=1YZLPJ5X18k&t=2s
Написан на Rust. AI ассистент. Интерфейс похожий на чат.
https://www.youtube.com/watch?v=1YZLPJ5X18k&t=2s
www.warp.dev
Warp: The Agentic Development Environment
The fastest way to build with multiple AI agents, from writing code to deploying it. Trusted by over half a million engineers, Warp gives developers speed, privacy, and control to ship faster.
❤1
Forwarded from Валя читает ишью
React Forget Status Update
React Forget презентовали почти 2 года назад , но с тех пор про него ничего не было слышно.
На столько ничего, что на реддите даже появился пост Did the React team forget the React Forget compiler? в который пришёл один из разработчиков и рассказал в чём сложность разработки и почему это занимает столько времени.
Он же выступил пару недель назад на React India с докладом Statically analysing react components for fun and profit, в котором чуть подробней рассказал тоже самое, что и на реддите.
А два дня назад ещё двое ребят выступили на React Advanced. И вот этот доклад прям интересный!
Во-первых, показали как выглядит внутренний playground для разработки (что-то в духе бабеля и тайпскрипта). Т.е. React Forget действительно существует и работает.
Во-вторых, поделились опытом использования в Quest Store (приложение для VR-шлема):
— смена табов стала работать на 150% быстрее
— загрузка страницы на 4-12% быстрее
— показали на сколько ре-рендер приложения становится эффективне (см. скрины)
В-третьих, рассказали, что react forget обкатывают и в инстаграме. Т.к. это веб, то здесь появлется вопросы производительности, на которые сейчас ищут ответы:
— в результате компиляции кода становится больше, как это сказывается на старте приложения? Как сильно? На сколько этим можно пожертвовать?
— из-за повсеместной мемоизации увеличивается потребление памяти. Как с этим справляются дешевые андроид смартфоны?
В-четвёртых, немного прояснили таймлайн разработки:
1. Proof of concept
2. Работающий компайлер (в большинстве случаев)
3. Тестирование в нескольких продуктах — мы сейчас находимся здесь
4. Релиз во всех продуктах Meta
5. Публичный релиз
В-пятых, подтвердили что ультимативная цель — избавиться от всех API с мемоизацией: useMemo, memo, useCallback.
В-шестых, рассказали, что сейчас React Forget существует в качестве Babel плагина, но потенциально его будет легко (или не очень) перенести на другие инструменты.
P.S. Fun fact: пост про React Forget самый популярный в канале, 11к просмотров.
React Forget презентовали почти 2 года назад , но с тех пор про него ничего не было слышно.
На столько ничего, что на реддите даже появился пост Did the React team forget the React Forget compiler? в который пришёл один из разработчиков и рассказал в чём сложность разработки и почему это занимает столько времени.
Он же выступил пару недель назад на React India с докладом Statically analysing react components for fun and profit, в котором чуть подробней рассказал тоже самое, что и на реддите.
А два дня назад ещё двое ребят выступили на React Advanced. И вот этот доклад прям интересный!
Во-первых, показали как выглядит внутренний playground для разработки (что-то в духе бабеля и тайпскрипта). Т.е. React Forget действительно существует и работает.
Во-вторых, поделились опытом использования в Quest Store (приложение для VR-шлема):
— смена табов стала работать на 150% быстрее
— загрузка страницы на 4-12% быстрее
— показали на сколько ре-рендер приложения становится эффективне (см. скрины)
В-третьих, рассказали, что react forget обкатывают и в инстаграме. Т.к. это веб, то здесь появлется вопросы производительности, на которые сейчас ищут ответы:
— в результате компиляции кода становится больше, как это сказывается на старте приложения? Как сильно? На сколько этим можно пожертвовать?
— из-за повсеместной мемоизации увеличивается потребление памяти. Как с этим справляются дешевые андроид смартфоны?
В-четвёртых, немного прояснили таймлайн разработки:
1. Proof of concept
2. Работающий компайлер (в большинстве случаев)
3. Тестирование в нескольких продуктах — мы сейчас находимся здесь
4. Релиз во всех продуктах Meta
5. Публичный релиз
В-пятых, подтвердили что ультимативная цель — избавиться от всех API с мемоизацией: useMemo, memo, useCallback.
В-шестых, рассказали, что сейчас React Forget существует в качестве Babel плагина, но потенциально его будет легко (или не очень) перенести на другие инструменты.
P.S. Fun fact: пост про React Forget самый популярный в канале, 11к просмотров.
👍1
Forwarded from Road to FAANG
Rob Pike's 5 Rules of Programming
Rule 1. You can't tell where a program is going to spend its time. Bottlenecks occur in surprising places, so don't try to second guess and put in a speed hack until you've proven that's where the bottleneck is.
Rule 2. Measure. Don't tune for speed until you've measured, and even then don't unless one part of the code overwhelms the rest.
Rule 3. Fancy algorithms are slow when n is small, and n is usually small. Fancy algorithms have big constants. Until you know that n is frequently going to be big, don't get fancy. (Even if n does get big, use Rule 2 first.)
Rule 4. Fancy algorithms are buggier than simple ones, and they're much harder to implement. Use simple algorithms as well as simple data structures.
Rule 5. Data dominates. If you've chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programming.
Pike's rules 1 and 2 restate Tony Hoare's famous maxim "Premature optimization is the root of all evil." Ken Thompson rephrased Pike's rules 3 and 4 as "When in doubt, use brute force.". Rules 3 and 4 are instances of the design philosophy KISS. Rule 5 was previously stated by Fred Brooks in The Mythical Man-Month. Rule 5 is often shortened to "write stupid code that uses smart objects".
Rule 1. You can't tell where a program is going to spend its time. Bottlenecks occur in surprising places, so don't try to second guess and put in a speed hack until you've proven that's where the bottleneck is.
Rule 2. Measure. Don't tune for speed until you've measured, and even then don't unless one part of the code overwhelms the rest.
Rule 3. Fancy algorithms are slow when n is small, and n is usually small. Fancy algorithms have big constants. Until you know that n is frequently going to be big, don't get fancy. (Even if n does get big, use Rule 2 first.)
Rule 4. Fancy algorithms are buggier than simple ones, and they're much harder to implement. Use simple algorithms as well as simple data structures.
Rule 5. Data dominates. If you've chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programming.
Pike's rules 1 and 2 restate Tony Hoare's famous maxim "Premature optimization is the root of all evil." Ken Thompson rephrased Pike's rules 3 and 4 as "When in doubt, use brute force.". Rules 3 and 4 are instances of the design philosophy KISS. Rule 5 was previously stated by Fred Brooks in The Mythical Man-Month. Rule 5 is often shortened to "write stupid code that uses smart objects".
В последнее время, уставший от очередной настройки сборки, вспомнал Rome
Forwarded from Валя читает ишью
Rome is Biome now
Well, вот и продолжение сериала.
Т.к. истории уже больше двух лет, то небольшая ретроспектива:
1. https://t.me/valya_reads_issue/141 — Себастьян и Джейми поднимают инвестиций, чтобы сделать ультимативный тулинг, который будет делать всё-всё-всё (бандлер, линтер, тесты, whatever).
2. https://t.me/valya_reads_issue/164 — Rometools аплаятся в TC39, чтобы развивать язык и экосистему вокруг него.
3. https://t.me/valya_reads_issue/237 — через 7 месяцев Джейми уходит из компании.
4. https://t.me/valya_reads_issue/296 — в конце января 2023 года у компании кончились деньги, статус проекта не ясен, все разработчики ушли/уволены.
???
5. «Rome won't be maintained anymore by the same people that maintained it so far. Biome will provide new features and fixes» красуется в ридми github.com/rome/tools.
Biome является «официальным» форком Rome. Под «официальным» подразумеватся, что форкнули его те же люди, что и работали над Rome. Одна из причин форка — Себастьян просто всех заигнорил, а у команды не было доступа к организации, хостингу и т.д.
Ну и вот сам блогпост Announcing Biome.
P.S. К сожалению, всё это было очень предсказуемо… Посмотрим, что получится у этих ребят дальше.
Well, вот и продолжение сериала.
Т.к. истории уже больше двух лет, то небольшая ретроспектива:
1. https://t.me/valya_reads_issue/141 — Себастьян и Джейми поднимают инвестиций, чтобы сделать ультимативный тулинг, который будет делать всё-всё-всё (бандлер, линтер, тесты, whatever).
2. https://t.me/valya_reads_issue/164 — Rometools аплаятся в TC39, чтобы развивать язык и экосистему вокруг него.
3. https://t.me/valya_reads_issue/237 — через 7 месяцев Джейми уходит из компании.
4. https://t.me/valya_reads_issue/296 — в конце января 2023 года у компании кончились деньги, статус проекта не ясен, все разработчики ушли/уволены.
???
5. «Rome won't be maintained anymore by the same people that maintained it so far. Biome will provide new features and fixes» красуется в ридми github.com/rome/tools.
Biome является «официальным» форком Rome. Под «официальным» подразумеватся, что форкнули его те же люди, что и работали над Rome. Одна из причин форка — Себастьян просто всех заигнорил, а у команды не было доступа к организации, хостингу и т.д.
Ну и вот сам блогпост Announcing Biome.
P.S. К сожалению, всё это было очень предсказуемо… Посмотрим, что получится у этих ребят дальше.
Понадобилось сравнить два коммита в гитхабе. Помню что в гитлабе это было. Погуглил чуть-чуть.
Если коротко, то вот так
Если коротко, то вот так
github.com/<username>/<repo_name>/compare/<commit1>...<commit2>Stack Overflow
How to compare two different commits on the same branch in github?
Comparing histories on the same branch is very confusing for me on GitHub. I struggle with this regularly:
If I use compare/master in the URL after the GitHub repo name, I can compare against other
If I use compare/master in the URL after the GitHub repo name, I can compare against other