Вы / ваши коллеги фигачите код. Как понять, что кода в одном файле достаточно и пора разделять?

Когда вы получаете контракт очень часто есть такая штука как sign-on бонус. И часто вы еще подписываете бумагу, мол, если работать буду, то через год компании ничего не должен. А если уволюсь, то должен выплатить обратно.

В целом идея то понятно, компании не в лом потратить N деняк, чтобы держать разработчика на работе. 2-3 месяца пока ворвется в проект, за месяц потыкает, осознает все и будет 7-10 месяцев человек работу реальную работать.

Работает это как "подкупленная лояльность". Откройте в линкедине людей из амазона, очень часто люди работают 2 года ровно и уходят. Почему? Потому что у амазона есть практика "Second year bonus", который работает точно также как sign-on. Мне предлагали такую схему, но начитавшись отзывов решил не идти в амазон. Менеджер команды который меня собеседовал и рассказывал перспективы команды в итоге месяца через три ушел (ровно после отметки в 2 года).

Одно из недавних открытий:
В TS есть такая штука как геттеры и сеттеры.

Вот у вас есть массив, у него есть .length, у Map есть size. И у кастомных классов вы можете делать подобное:

const language = {
  set current(name) {
    this.log.push(name);
  },
  log: []
};

// or

class Cat {
  get legs() {
    return 4;
  }
}

И как бы это ок, но мне в голову пришло — стоп, а как это работает в нативном ЖС?

А все так же, нативная поддержка есть чуть ли не с доисторических времен: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/set

Самое удобное сравнение языков со строгой и нестрогой динамической типизацией какое я слышал звучало вот так:

Вот хочешь ты завести boolean переменную. Ты пишешь что-то типа var a = true. Язык с нестрогой динамической типизацией не знает, будет ли в следующий момент времени записано в переменную что-то другое. Например объект. (И как итог там нужен указатель будет) Вот виртуальной машине и приходится выделять памяти достаточно чтобы указатель туда всунуть.

Другое дело строгие статические языки. Сказал bool, значит бит.

Хотя это никак не оправдывает повальную прожорливость сайтов и приложений уровня слака.

Я закончил школу разработчиков hh (курсы/стажировка компании), где ты не только обучался, но тебе за это еще и деньги платили!!!

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

Но это тоже пример эдакой бартерной лояльности отдаленно похожий на sign-on bonus. Компания дает тебе образование, платит за время, что ты учишься. Сколько ты должен такой «долг» оплачивать? Есть ли он?

По факту такой долг есть только в голове конкретного выпускника, потому что hh не связывал тебя условиями. Некоторые ребята уходили через год, а некоторые, через лет 7 (не будем показывать пальцем, но это был я).

Морали здесь нет. Просто вспомнилось на фоне современных инфоцыган-курсов, которые 300к хотят за недообучение.

Хотите хорошей подготовки — существует огромное количество бесплатных курсов, людей и компаний, которые своей репутацией отвечают за качество материала и которые действительно инвестировали в то, чтобы то самое образование было полезным.


А hh я дико благодарен, ребята неимоверно крутые

Порассуждал вот здесь, о том, почему новый sql синтакс от верселя бомбовый. К слову, мы в вотсапе используем template functions немало: https://twitter.com/xnimorz/status/1655578867397009412

Знаете такой проект как Dexie?

Проект начинался как удобное API для работы с IndexedDB. Сейчас Dexie это и subscriptions, удобные мутации, куча сахара и даже синк с серверной ДБ можно сделать.

И у меня есть 3 вещи сказать:
1. Dexie чутка тормознутый. То есть, в погоне за сахаром, некоторые операции могут быть сильно медленнее, чем если бы использовать нативный IndexedDB.
Но нативный IndexedDB человек в сознанательном состоянии использовать не будет. Это ужасная мешанина, где проектировщики забили вообще на какие-либо паттерны. Я могу тут очень много возмущаться, да.

2. Dexie "любит" манкипатчить данные.То есть промисы -- заманкипатчены, сделан аналог зон, и так далее.
Ну и отвечая на вопрос "насколько плохо заманкипатчены промисы" -- очень, первый промис уходит в микротаск, остальные выполняются в том же скопе. В итоге ломается очередность выполнения и происходит "трешовый треш". Хотя это уже для самой IndexedDB не так то и нужно

3. У вас все равно будет своя абстракция сверху над Dexie, если ваши юзкейсы больше чем "просто положи пару джойснчиков". Так как и типизация нужна, и какое-то подобие порядка и т.п.

Что делать?
Либо уходят на idb Арчибальда, либо страдают и едят кактус. Почему я пишу? Я тут на работе недавно закончил свой ORM писать, чтобы Dexie заменить, да, который в качестве стора использует IndexedDB и уж очень много шишек на IndexedDB набил.
Возможно высижу и пойду на какую-нибудь конфу с докладом, а то перерыв больше двух лет получается ж!

Давайте я кратко расскажу чем я занимаюсь в Meta. Работаю я в WhatsApp. Фронтенд в его обычном понимании - реакты, и прочее - я не писал более 2 лет. А за последние три года фронтенд который я писал, был специфичен.

WhatsApp не хранит данные на сервере, все сообщения и прочее хранится на пользовательском девайсе. Весь messaging e2e encrypted. https://faq.whatsapp.com/820124435853543/?locale=en_US - Вот тут публичная документация (white paper ссылка внизу страницы), где описано, как всё и происходит.

Я занимаюсь тем, что имплементирую такой клиент. Как шифровать сообщения, как менеджить ключи, в общем, как делать так, чтобы e2e encryption работал, сообщения не терялась, БД работала быстро и так далее.

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

Все это требует достаточно хитрой инфраструктуры, ретраев, где данные критичны, защищенную дистрибуцию данных и так далее.

«Сломанность» современного веба отлично демонстрирует вот этот вот пример:

Про SPA все заговорили где-то в 2016, а то и раньше и начали их массово шлепать.
И вот как шлепались такие штуки? Нужно чтобы приложение и с жс и без работало (лол, многие сайты так и не научились этому). И поэтому нужны ссылки, переходы вот это вот все.

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

И вроде бы норм, но ведь такой костыль если вдуматься? Это каждая ссылка оборачивается в хандлер. И поэтому фреймворки полезли массово клепать «правильные компоненты ссылки».

И вот самое смешное, что мы сколько, 10 лет жили в таком состоянии и норм?
И вот появилось navigation api, чтобы наконец-то переходы по ссылкам заработали.
https://developer.chrome.com/docs/web-platform/navigation-api/

Вот только ни в сафари, ни в фф это не заработает. https://caniuse.com/?search=navigation%20api

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

Гг вп фф

Раз уж твиттер решил ввести ограничения, то переползаю по-немногу в телеграм

Я тут на днях наткнулся на твит, где выложили код:

const fetchData = async () => {
    const response = await fetch('https://website.com');
    const data = await response.json();
    return data;
}

Как бы, добавь await и вроде бы все ок будет.
Но на самом деле мало-мальский fetch сделать - это с ума сойти.

Вот тут рассказал https://blog.xnim.me/why-even-simple-window-fetch-might-be-tricky

#TIL
Кроме Килобайтов есть Кибибайты:

https://www.logicmonitor.com/blog/what-the-hell-is-a-kibibyte#:~:text=A%20%E2%80%9Ckibibyte%E2%80%9D%20is%20equal%20to,1000%2C%20or%2010%5E3.

Вы уже зарегались в тредс?

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

Посмотрим как оно пойдет дальше. Если у вас есть аккаунт в тредс, кидайте в комментарии, я подпишусь 😅

https://www.threads.net/@xnim.me

Я тут впервые за пару лет последних подался на конференцию.
Пока не буду говорить куда, а то еще не возьмут (хайли лайкли). Но сам факт того, что подался уже достаточно важен для меня.

О чем хочу доклад делать? Про IndexedDB. Это очень интересная штука, которая работает в виде БД у нас в браузере с очень неудачным АПИ.
Этот апи на протяжении трех версий базы данных пытаются дорабатывать напильником и вот когда пишешь к этой радости ORM осознаешь насколько
1) написать хорошее апи сложно
2) хорошо ты знаешь нецензурную лексику.

Вот про IndexedDB и может случиться доклад.

Если наберется сил, буду в этот канал скидывать интересные инсайты по IDB.

Набросал пару слов о строках, а точнее о том, о чем редко в JS говорят:
1. Где строки хранятся
2. Можно ли получить exception складывая строки 0_о

https://blog.xnim.me/what-i-know-about-javascript-string

Как вы не знаете, я очень люблю готовить. Пузико в 80 кило тому доказательство.

Поэтому, публикую лучший рецепт эвер scrambled eggs.

Нам понадобится:

1. Маленькая, но глубокая кастрюля с антипригарочным покрытием (в идеале)
2. 3-5 яичек
3. Примерно 10-30 грамм сливочного масла (чем больше, тем "водянистей" и жирнее, но бархатнее на внешний вид и вкус). Я обычно беру по ощущениям "вот должно быть збс".
4. Соль, перец на глаз (для грамовок - от 4й части чайной ложки для тех кто не любит, до половины)
5. Терпение

Алгоритм
1. Берем кастрюлю. Разбиваем в нее все яйца. Кидаем все сливочное масло сверху.
2. Ставим на маленький огонь и начинаем мешать. Мешаем средне-интенсивно. По визуальным эффектам: смесь крутится, но не плескается. Важно мешать все пространство (тип оставлять середину или края не вариант)
3. Через 20 секунд снимаем кастрюлю с огня и мешаем секунд 5-10 без кастрюли
4. Повторяем шаг 2-3, но снимать начинаем не после 20 секунд, а после 30-35 и мешать без кастрюли мешаем по секунд 10-15. Повторять нужно будет раза 4-5. Если вдруг на второй или третий раз яйца уже превратились не в жидкость, а в яичницу -- огонь был слишком большой или передержали. В смысле вкусно все равно будет, но не настолько.
5. Когда яйца начали превращаться из жидкости в яичницу (на 4-5 раз), то снимаем с огня и мешаем около секунд 50-60.
6. Добавляем соль перец
7. Ставим последний раз на огонь, и также мешаем, но смотрим на консистенцию. Как только дошла до "мне это нравится" -- снимаем, подаем

Вы великолепны

AI оценивает ваш pull request на предмет потенциальных багов.

Верим?

Написал огромную статью, которую хотел бы видеть года эдак 3 назад, когда только начинал работать с IndexedDB.

Она покрывает почти все, что есть в этой базе данных и также рассказывает о всяких перфоманс штуках, которые ускорят транзакции в ней. https://blog.xnim.me/indexeddb-guide

Примеры потыкать прилагаются :)