Чтобы мозг не раскисал, учу Си. Язык простой и одновременно довольно сложный. А ещё в нём есть куча undefined behaviour - неопределённое поведение компилятора для пограничных случаев, которых на самом деле масса.

Вот пример простейшей функции:

int get_zero(void) {
  int num;
  return num & 0;
}

Переменная num не инициализирована, значит там могут сидеть любые "мусорные" биты.
& - это оператор побитового И, который сравнивает последовательно биты двух чисел и ставит в соответствующий бит возвращаемого числа 1, только если оба бита - это 1, иначе поставит туда 0.

Вроде всё просто и кажется, что функция всегда должна вернуть 0, ведь "побитовый и" с нулём всегда вернёт ноль.

123 // 00000000 00000000 00000000 01111011
0   // 00000000 00000000 00000000 00000000

Сравнение битов двух чисел выше всегда вернёт 0, т.к. второе число тоже 0. Неважно, какие там будут биты у первого числа, всегда в итоге 0.

Но проблема кода здесь связана со спецификацией Си. Код небезопасен, потому что теоретически компилятор может делать всё что угодно! Программа может "упасть", компилятор может удалить код и прочее. Компилятор имеет право делать что угодно в этом случае. Undefined behaviour - это поведение программы, для которого стандарт языка не накладывает никаких требований, стандарт не говорит, что должно или не должно произойти!

Т.е. писать код таким образом в Си - опасно. Даже переполнение обычного signed int (он же просто int) в Си - это уже undefined behaviour!

int x = 2147483647; // Максимальное значение
x = x + 1; // Опачки - undefined behaviour - рисково!

Вот такое приходится учить. А кто-то жалуется на сложности Golang.

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

А практически при наличии одной электронной почты на Gmail можно создавать в интернет-сервисах огромное количество аккаунтов, не меняя адреса. Дело в том, что Gmail игнорирует регистр символов и наличие точек в имени пользователя.

Допустим есть пользователь c такой гугловской почтой:

vasya.pupkin.example@gmail.com

Если поменять регистр букв в имени юзера и отправить письмо на:

Vasya.PUPkin.example@gmail.com

то ему придёт письмо в настоящий ящик!

Сколько таких комбинаций возможно? Очень много!

Мало того, можно подобавлять точки в адрес:

va.s.ya.pu.p.k.in.example@gmail.com

и ему тоже придёт письмо в ящик-оригинал.
Даже если убрать точки из оригинала:

vasyapupkinexample@gmail.com

то письмо тоже придёт!

Представьте, сколько десятков тысяч комбинаций можно сделать с точками и изменениями регистра букв. Можно насоздавать тысячи вредительских аккаунтов, если сайт не защитился от этой "фишки" гуглопочты. Банить устанешь.

Новость пришла откуда не ждали: монополизация во фронтенде - Vercel купил Накст. Они и так владели Некстом (главным SSR-фреймворков для Реакта), а теперь у них руки добрались и до вьюшной экосистемы.

Об этом сообщил создатель NuxtJS - Daniel Roe (ник danielroe на Гитхабе). Чисто теоретически Накст остаётся независимым, а Vercel купил только NuxtLabs, а также нанял себе ключевых разработчиков Накста. А практически - у них теперь Nuxt и они теперь будут задавать направление развития.

Не знаю, хорошо это и плохо, но монополизация - это точно плохо.

If you try to use Quill Editor with Nuxt 3 when rendering a page in SSR you will get this error:
That means NodeJS doesn't have the global variable 'document'. Because SSR rendering is executed in
a NodeJS environment, not a browser.

The sad fact: <client-only> won't help with this problem. The problem with quill's code is that during import, it assumes it's being executed in the browser. I hope you remember that the code imported from the module is not just imported, but executed, i.e. the authors of Quill wrote it so that the 'document' object is immediately accessed there. Very bad.

One solution is to disable SSR, but its an awful solution. But the second solution is to use dynamic JS imports.

My <script lang="ts" setup> in QuillEditor.vue in Nuxt 3 project:

import 'quill/dist/quill.core.css';
import 'quill/dist/quill.snow.css';
// import Quill from 'quill'; // SSR problem with 'document', need to use dynamic import
import type Quill from 'quill';

const elemForQuillEditor = ref<HTMLDivElement|null>(null);

let editor: null|Quill = null; // Do not store in ref() - it causes bugs!

// ...

async function createQuillAndSetListeners() {
  const Quill = (await import('quill')).default; // This is most important thing - usage of JS dynamic import

  if (!elemForQuillEditor.value) return;
  editor = new Quill(elemForQuillEditor.value, {
    theme: 'snow',
    modules: {
      history: {
        delay: 2000,
        maxStack: 500,
        userOnly: true,
      },
      toolbar: {
        container: [
          ['bold', 'italic', 'underline', 'strike'],
          ['link'],
          [{ list: 'ordered' }, { list: 'bullet' }],
          [{ script: 'sub' }, { script: 'super' }],
          [{ header: [1, 2, 3, 4, 5, 6, false] }],
          [{ color: [] }, { background: [] }],
          ['clean'],
          ['undo', 'redo'],
        ],
        handlers: {
          undo() {
            editor?.history.undo();
          },
          redo() {
            editor?.history.redo();
          },
        },
      },
    },
    placeholder: props.placeholder,
  });
  
  editor.on('text-change', () => {
    if (!editor) return;
    // ... my other code
  });
}

// ...

onMounted(createQuillAndSetListeners);

Now your Quill editor will work in Nuxt 3 even during SSR!

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

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

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

А вы знали, что теоретически 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! Толку от этого никакого, на сам факт забавен.
Можно джунов за собесах мучить :)

На Famabara появилась возможность перетаскивать мышкой части формы поста, если лень сортировать кнопками вверх/вниз. И, оказалось, что эта функция не работает в Firefox.
Багу 13 лет!!! Вы когда-нибудь видели, чтобы у популярного продукта не чинили баг столько времени? Пожалуйста:
https://bugzilla.mozilla.org/show_bug.cgi?id=739071

Если у предка стоит атрибут draggable="true", то клик мышкой по <textarea >или по <input type="text"> не позволит сфокусировать нормально в нужном месте текста. Мигающий промт возникнет или в начале текста или в том месте, где уже был до блюра.

<div draggable="true">
  <input value="Кликните в середину текста" type="text" />
</div>

Ну это совсем позорище! Багу поставили Priority: P3 и Severity: S3 (типа неважные вещи), а все дублирующие баг-репорты закрывают уже в течение 13 лет.

Есть одно решение, найденное в схожем багрепорте FF, но для contenteditable="true" - надо зажать Alt и кликнуть. Удобно, да? :)

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

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

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

Столкнулся по работе недавно с фулстек программистом, бывшим фрилансером. И немного если не токсично говорить озодачен совместной работой с ним.

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

И что вы думаете? Он вообще не умеет работать в команде. Он не задаёт вопросов, когда 100% нужно задавать вопросы. Всё делает сам и в своём стиле и потом мы разгребаем на код-ревью его код. Это раздражает. Если бы сначала спрашивал, то не было хотя бы велосипедов и всякой мути.

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

Я матёрый веб-разраб, но иногда офигеваю, когда узнаю, что-то новое среди банальных вещей, которые по идее уже знаю больше десяти лет. Сейчас речь о CSS.

Вот вы знали, что position: fixed может не работать в некоторых редких случаях? Если у любого (!) предка задано, например, свойство transform, то всё, привет: блок с position: fixed уже привязывается не к вьюпорту. Хотя transform у элемента-предка мог быть задан всего лишь для сдвига какой-нибудь менюхи вбок или вообще для выравнивания position-absolute-блока по центру родителя. Но нет, уже не будет работать, таковы правила.

Аналогично ведут себя CSS свойства perspective, will-change или filter у любого из предка.

Век живи - век учись.

Нет, не нужны. Простой ответ.
Я вкатывался несколько лет назад и мне никакие курсы не понадобились. И соответствующего вузовского образования у меня нет. И ничего, работаю и успешно решаю бизнес-задачи.

Если вам нужны курсы, чтобы вкатиться в айтишечку, значит вы скорее всего не подходите для этой работы. Все есть в онлайне, гугли на здоровье и учись. А если ты не можешь найти нужные материалы, не можешь организовать себя для учебы, не можешь структурировать найденную информацию, то как ты работать собрался? За ручку тебя на работе никто водить не будет.

Мало того, реальная работа сильно отличается от того, что спрашивают на собесах (такая хрень, увы). Т.е. нужно учиться проходить собеседования и учиться работать. Это два связанных, но разных направления.

Поправка. Разговор о программистах. Про остальные IT профессии не скажу.

Многие программисты наверняка видели спецификации разных интернет-технологий под названиями RFC ***.
Например:
RFC 9112 - это спецификация для протокола HTTP/1.1
RFC 3629 - это спецификация для кодировки UTF-8

Так вот аббревиатура RFC означает Request for Comments, т.е. "запрос комментариев". Выглядит странно, да? Типа стандарт, но требует каких-то комментариев.

Оказывается, это так просто сложилось исторически. Изначально всё действительно обсуждалось и требовало комментариев. Т.е будущий стандарт прорабатывался путём долгих обсуждений умных дядек. И через некоторое время все спецификации/стандарты стали публиковаться под таким термином - RFC, хотя по факту никаких комментариев уже не требуется, ведь это уже официальный финальный документ. В общем, RFC
- это термин из 60-80-х годов и ныне полностью утратил свой изначальный смысл.

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

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