А вы знали, что теоретически spread-синтаксис в JS можно применять почти к любому типу.
Вот пример "обычного" использования:

// Массив спредится
console.log([...[1, 2, 3]]); // [1, 2, 3]
// Строка спредится
console.log([...'Famabara']); // ['F', 'a', 'm', 'a', 'b', 'a', 'r', 'a'] 

Но если попытаться заспредить number, то будет ошибка:

console.log([...555]); // Uncaught TypeError: 555 is not iterable

Не является iterable.
Так давайте сделаем iterable!

Number.prototype[Symbol.iterator] = function * () {
  yield 'Фамабара';
  yield 'лучше';
  yield 'всех';
}

console.log([...555]); // ['Фамабара', 'лучше', 'всех']

Мы успешно заспредили number! Толку от этого никакого, на сам факт забавен.
Можно джунов за собесах мучить :)

В русском языке не очень хороший код, который решает задачу некачественно, но всё же решает, принято называть костылём. Часто костыли делают как бы временным решением, но в большинстве случаев они остаются навсегда. В любой крупной кодовой базе всегда куча костылей, можете мне поверить.

В английском языке принято говорит "workaround", т.е. обходной путь. Но этот термин не несёт смысловой нагрузки, которую в русском языке означает костыль. Костыль - это значит код можно заменить нормальным кодом, это значит, что разрабу даже немного стыдно за код, но поделать пока ничего нельзя. А workaround - это более мягкий термин, этакий хак для достижения цели.

Так вот на английском языке есть аналогичное слово - kludge (кладж). Смело используйте его в своих слаках и гугл-митингах, когда общаетесь на английском. Никаких больше workaround, теперь только честный kludge!

Представим вы несколько дней работали, писали код и наконец-то сделали коммит:

git commit -m "#715 changed color of button from red to green"
git push

И тут вы понимаете, что забыли убрать какой-нибудь console.log() или fmt.Println().
Можно добавить ещё один коммит поверх, что-то вроде:

git commit -m "#715 clean unnecessary code"

Но в некоторых командах это могут посчитать мусорным коммитом. Что делать?

Вместо второго коммита "правим" первый коммит, дописывая amend:

git commit --amend -m "#715 changed color of button from red to green"

И теперь можно пушить снова. Но сервер не даст запушить, ведь у нас локально и на ремоуте уже разные истории одной ветки. Можно запушфорсить:

git push force

Но это может быть очень плохо, если над веткой работает несколько человек. Кто-то мог уже поверх нашего коммита свои коммиты накатать. Но есть хороший параметр force-with-lease, который перезапишет ветку только тогда, когда никто поверх не дописал свои коммиты:

git push --force-with-lease

В этом случае никто не пострадает.

Андерс Хейлсберг (автор Тайпскрипта) опубликовал пост в блоге:
https://devblogs.microsoft.com/typescript/typescript-native-port/

В общем, TypeScript скоро станет в 10 раз быстрее, вернее, он уже стал таким, просто пока эту версию не сделали общедоступной.

Вот такой прирост скорости компиляции крупных проектов теперь показывает tsc:

Как видно, прирост на порядок - т.е. примерно в 10 раз. Достигается это за счет использования Golang для работы tsc, а не JS. Сам по себе JS быстрый, но он упирается в один поток. А кто писал на Go, то знает, насколько легко там запустить горутину. Теперь tsc будет использовать несколько имеющих потоков, что и даст прирост скорости компиляции.

Обратите внимание, это полноценная работа tsc, а не как у esbuild, где только транспиляция без проверки типов.

На момент написания этого поста текущая версия TypeScript - 5.8.2. Следующая мажорная версия - 6-я - будет всё ещё на JS-е, а вот 7-я версия будет уже на "нативном" коде, т.е. компилироваться из Go. Автор их так и называет:

В общем, новость хорошая. Быстрее будет не только компиляция в JS, то и VSCode будет работать быстрее, потому что там все подсказки в редакторе, даже если это JS-код, реализованы с помощью тайпскрипта.

Между прочим в мире VueJS большая новость - активно разрабатывается Vue Vapor. По основной идее этого проекта во VueJS исчезнет виртуальный DOM, который являлся важной частью всего VueJS. Теперь работа будет вестись напрямую с DOM и меняться будут только нужные HTML элементы, если срабатывает реактивность.

А еще интересная деталь: пишут, что будет работать только с Composition API, а Options API уйдёт на свалку истории. А ведь говорили, что этого не будет и старый Options API будет поддерживаться до последнего. Плюс обязателен script setup.

Недавно смотрел на ютубе ролик, где автор осуждающе назвал нетворкинг в IT кумовством. Если кто не знает, так называемый нетворкинг в IT - это когда у тебя много околоайтишных знакомств и ты с помощью этого можешь найти работу/нанять человека.

Так вот в IT привычное "кумовство", имхо, не работает. Это не госсектор, где можно пристроить племянника, брата-свата, друга сына маминой подруги. IT - это одно из тех направлений, где важны опыт и знания. Никому не нужен дятел, который не имеет работать. По факту работники в айтишечке - это пролетариат. И чем выше уровень работника, тем работодателю лучше, ведь работник выдаёт более качественный результат за меньшие сроки.

Мало того, плохой работник в разработке может вообще не выдать результат за неимением навыков и опыта. И зачем такое надо работодателю?

Подавляющее большинство работодателей в разработке ПО - это бизнес. А бизнес считает деньги. Даже бизнес по типу какого-нибудь банка со значительной долей государства среди собственников нынче всё равно ведёт себя как полноценное коммерческое предприятие.

Это в госуправлении и всяких чиновничьих клоаках можно очередным замом устроить своего одногруппника из института или внука брата бабушки. Или придумать никому не нужный отдел и там своих людей посадить. В IT такое не прокатит.

Представьте, что вы держите фирму, которая проектирует частные дома на заказ. Возьмёте ли вы на работу архитектора, который не знает как рассчитывать количество и толщину арматуры? То же самое и в разработке ПО.

Работаю разрабом в одной небольшой конторе, которая поддерживает несколько онлайн-магазинов крупного предприятия. Знаете, что самое сложное в работе? Нет, не разобраться в чужом коде. Нет, не провести крупный рефакторинг всей кодовой базы.

Самое сложное - понять, что от тебя хотят. Самое сложное и важное - предвосхитить будущие проблемы, связанные с переделкой, и сообщить об это заказчику заранее, разъяснить так, чтобы люди поняли. А фантазий у заказчика может быть много :) Если ТЗ сформулировано как ХЗ, то фиг какая нейросеть заменит разраба ещё много лет.

Чтобы четко сформулировать запрос в какой-нибудт ChatGPT, сначала нужно абсолютно все вводные данные. А когда всё у тебя есть, то и ChatGPT нафик не нужен, можно без него обойтись.

Ну, а кнопки красить и макака сможет, это да.