Kobezzza. База в программировании

Kobezzza. База в программировании pinned «🔔Открытый урок. Регистрация открыта. 🎙️Тема: Паттерны работы с битами в JavaScript 🗓️ 18 февраля (вторник) в 19:00 МСК 🎓 Урок ведет: Андрей Кобец Ребят, приглашаю вас на первый открытый урок в этом году, где мы продолжим изучать тему работы с байтами,…»

🔔Открытый урок. Регистрация открыта.

🎙️Тема: Паттерны работы с битами в JavaScript

🗓️ 18 февраля (вторник) в 19:00 МСК

🎓 Урок ведет: Андрей Кобец

Ребят, приглашаю вас на первый открытый урок в этом году, где мы продолжим изучать тему работы с байтами, битами и бинарными данными в JavaScript. Этот урок является логическим продолжением предыдущей лекции по типизированным массивам, который я делал осенью.

Что обсудим:

✔️ Как передавать меньше данных по сети

✔️ Как React и Vue используют битовые маски, чтобы оптимизировать потребление памяти

✔️ Какой тайный числовой тип есть во всех VM JS

✨ Если вы пропустили предыдущие уроки, то у нас для вас отличная новость! За регистрацию на этот урок, мы откроем тебе запись двух предыдущих уроков на тему:

1. Построение структур данных поверх типизированных массивов

2. Сегменты памяти программы

❗️Записи прошлых лекций будут у тебя в личном кабинете в Kobezzza.Lab и откроются сразу после регистрации!

Сейчас смотрю запись кс и прям доволен как слон) Настолько много даже простых вещей узнаю, о который очень мало где говорится) Особенно приятно то, что приходя после довольно рутинных вещей, погружаешься в максимально нестандартные задачи)) Жаль конечно что не в лайве, т.к. иногда все таки появляются вопросы по материалу и домашкам) В общем спасибо за такой курс) В рунете если и возможно что то подобное найти то это явно не так просто)

Зачем нужен Kobezzza.Lab и куда мы идем?

Я часто слышу возражения из серии «как это применимо в реальных проектах; хочу больше практических примеров; никогда такого не встречал» и т.д. Зачастую такое пишут либо те, у кого немного опыта (до трех лет), либо у кого действительно на работе очень простые рутинные задачи, в которых нет места для сложных инженерных решений.

Создавая свои образовательные программы, я хочу, чтобы Kobezzza.Lab стало для вас тем пространством, где вы можете расти в знаниях вне работы, вы тренируетесь на таких задачах, которые на текущей работе к вам просто не придут.

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

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

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

Большой курс по Computer science стал первым шагом в этом направлении, вторым шагом стало его расширение за счет курсов по инфраструктуре и сборке фронтенд. Дальше у меня в планах разработать серию небольших прикладных курсов, которые очень подробно разбирают узкие темы/инструменты, как, например, IndexedDB. Я хочу максимально упаковать свои знания так, чтобы вы заходили на Kobezzza.Lab, как на портал, где вы сможете получить ответы на самые сложные темы, с которыми сталкиваетесь в работе.

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

Да еще много предстоит работы для реализации моих планов, но масштаб не может страшить инженера.

Всем базы!

🧐 Итак, когда же стоит использовать Proxy? Давайте я перечислю кейсы, с которыми я лично сталкивался на практике, где Proxy помогают делать замечательные вещи:

1. Readonly обертка над изменяемым объектом. С помощью API Proxy мы можем всего за несколько десятков строк написать универсальную обертку чтения для любого объекта с полным сохранением его интерфейса. Причем, не важно, какого размера наш объект, ведь цену за Proxy мы платим только в момент непосредственной работы перегрузок.

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

3. Создание наблюдаемых объектов. Еще один очень классный кейс использования Proxy. Наблюдаемые объекты могут применяться в самых разных задачах от аналитики и логирования, до перехода к реактивной модели программирования (например, именно так делает Vue3).

4. Реализация множественного наследования без копирования. Штука спорная конечно, но бывает очень нужная. Proxy позволит нам изящно перехватывать обращения к свойствам и самостоятельно управлять логикой диспетчеризации.

5. Обертка для валидации данных. Если мы хотим предварительно проверить данные предаваемые методам оригинального объекта, но не менять его API.

6. Обертка для мемоизаций операций над объектом. Например, чтобы каждый метод вызывался ровно один раз.

7. Обертка для изменения API. Например, у нас есть некоторый объект, чьи методы мы хотим перегрузить, чтобы они все возвращали промисы. С Proxy такой код может занять всего несколько строчек кода, т.к. нам достаточно написать универсальную перегрузку. Именно так и реализована библиотека idb, которая весит 1КБ, но перегружает весь API IndexedDB.

8. Обертки для сокрытия части функционала. Например, чтобы нельзя было обратится к свойствам, чьи имена начинаются с _.

9. Ленивые обертки. Отлично подходит для ситуаций, когда мы не знаем какими свойствами и методами должен обладать наш объект. Или, мы не хотим делать лишнюю работу, до тех пор, пока она реально не потребуется. Простейший пример, мы можем создать объект, где при первом обращении к свойству будет создаваться символ и затем уже сохранятся в объект по имени свойства. Это позволит избавить нас от рутины явного создания множества констант и переносит плату за создание символа в момент первого использования.

const s = symbolGenerator();

console.log(s1.foo);
// ...
console.log(s1.bar);

И то же самое, но явно.

const foo = Symbol('foo');
const bar = Symbol('bar');

console.log(foo);
// ...
console.log(bar);

Т.е. Proxy позволяют нам не писать Boilerplate код для описания таких локальных символов, а просто сразу начать их использовать. Сразу отмечу, что если вы хотите экспортировать символ, то тогда лучше явно сделать константу.

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

Еще классной особенностью Proxy является возможность создания бесшовных оберток. Допустим, что есть сторонняя библиотека ожидающая объект определенного вида, а хочется добавить некоторую дополнительную логику (например, добавить мемоизацию). С помощью Proxy вы реализуете такое за несколько строк кода, а принимающая сторона даже не поймет подвоха, т.к. с её точки зрения ничего не поменялось.

Нужен ли вам Proxy или нет - зависит от конкретной ситуации в вашем коде. Но одно я знаю точно - если вы не разберетесь в этом API, то вы никогда и не узнаете нужен он вам или нет.

Всем базы!

🧐 API Proxy в JavaScript позволяет перегрузить работу множества объектных операторов, таких как ., delete, in и т.д.

Работает это следующим образом: мы передаем объект, который хотим перегрузить в конструктор Proxy, а вторым аргументом описываем сами перегрузки. Результатом будет новый объект, который выступает в роли прокси для исходного.

const myObject = {a: 42};

const proxy = new Proxy(myObject, {
  // Перегружаем чтение свойства объекта
  get(target, key) {
     // Тут пишем нашу логику
  }
})

Следует отметить, что мы перегружаем именно работу операторов. Например, если мы перегрузили get, то мы можем перехватить обращение к свойству (даже если такового свойства реально нет). Разумеется, у Proxy есть своя цена, но платим мы её не в момент создания прокси объекта, а при срабатывании перегруженных операций. И тут у нас две основных статьи затрат:

1. Обработка перегруженной операции может быть в несколько раз медленней.
2. Цену добавляет и код, который выполняете вы в самой перегрузке.

Является ли это проблемой? Зависит от конкретных ситуаций. Конечно, увидев синтетический тест, где производительность прокси в 3-4 хуже, чем у обычных объектов, то можно схватится за голову. Но потом стоит успокоиться и посмотреть сам тест, где операции чтения/записи делаются миллионы раз. Маловероятно, что ваше приложение создает даже близко похожую нагрузку. Конечно, если использовать несколько раз завернутый прокси (прокси в прокси), то ситуация может стать драматичнее, но даже в таком случае не факт, что вы это заметите.

В одной из лекций моего грядущего курса по IndexedDB я рассказываю про библиотеку idb.

Библиотека представляет собой обертку над ванильным IndexedDB API и добавляет некоторые улучшения: поддержку Promise, асинхронные итераторы, хэлперы для транзакций и т.д. Но самое главное, что библиотека позволяет вам в любой момент времени перейти обратно в плоскость ванильного АПИ и обратно для любого объекта idb/IndexedDB.

Весит она при этом ~1KB, а её исходный код с комментариями занимает всего 300 строк.

Как же ей удается быть такой функциональной, но маленькой? Никакого секрета тут нет: idb работает через Proxy над нативным IndexedDB API и определяет 3 ловушки (get, set, has). И это прям супер классный кейс для использования Proxy:

1. Вся работа библиотеки сводится к перехвату методов к хранилищу и врапингу результата в Promise или AsyncIterator. Благодаря Proxy и динамической диспетчеризации получается очень мало кода.
2. Работа с хранилищем асинхронная и явно не будет выполниться большое количество раз в секунду времени, а значит и негативный эффект от Proxy мы тут совсем не заметим.
3. Весь нативный API IndexedDB доступен даже если в стандарт добавят новые методы, т. к. перехват осуществляется "на лету".

Я, вроде бы, писал статью про хорошие кейсы для применения Proxy и вот idb можно прям в эту копилку добавить. Еще поинт про то, что нужно знать лучше свои инструменты.

Всем базы!

Мы получили образовательную лицензию!🎆

Я очень рад, что наша школа программирования Kobezzza.lab получила официальную лицензию на осуществление образовательной деятельности! Теперь и министерство образования РФ подтверждает, что наша школа соответствует самым высоким стандартам качества образования!🏅

Регистрационный номер лицензии: 👇

№ Л035-01218-23/01835619

🎓 Главная задача нашей школы повышать глубину знаний студентов и расширять кругозор, чтобы они могли справляться с самыми сложными инженерными задачами, не только для своего карьерного роста, но и для созидания новых технологий. Мы тщательно выбираем темы наших курсов, чтобы они развивать инженерное мышление и закрывать те пробелы в знаниях, которые мешают открывать новые горизонты в профессии Frontend разработчика.

⭐️ Теперь вам еще проще будет получать налоговый вычет: Обучение в лицензированной школе дает вам гарантированное право на налоговый вычет, что снижает расходы на образование. Социальный налоговый вычет можно оформлять ежегодно, возвращая до 13% от стоимости оплаченного обучения, но не более 19 500 рублей (в соответствии с ограничением на максимальную сумму вычета — 150 000 рублей в 2024 году).

💼Также многим работодателям, которые оплачивают обучение за своих сотрудников важно чтобы школа обладала образовательной лицензией. Теперь она у нас есть и еще больше работодателей смогут с нами сотрудничать. Сейчас мы активно работаем с такими компаниями как - Сбербанк, Яндекс, Гринатом, МТС Диджитал, Почта Банк, Райфайзенбанк, Озон технологии, Авито тех и др.

🦾Присоединяйтесь к Kobezzza.Lab и растите в экспертизе с каждым нашим продуктом. Ознакомиться с образовательными программами.

Читаю сейчас Стивена Кинга "Как писать книги". Особенно понравился один из советов: этап написания книги сводится к написанию черновика, а затем переписыванию несколько раз (Кинг пишет, что обычно переписывает черновик 2-3 раза). И, также, у него приводится несколько очень полезных дополнений к этой стратегии: нельзя перечитывать/переписывать свою работу сразу после окончания первичной работы - вместо этого, надо положить её в стол и дать время ей настояться; нельзя показывать первый черновик никому, даже самым близки людям, т.к. на этой стадии любая их критика (положительная или отрицательная) может слишком сильно повлиять на весь ход работы - показывать можно только уже хотя бы один раз переписанный черновик.

Эти советы, с моей точки зрения, прекрасно ложатся и на запись видео материалов. Если говорить про меня, то первичная фаза записи самая мучительная: мне вечно не нравится результат (то звук, то свет, то как я говорю, то как я выгляжу); добавьте к этому, если в момент таких мучений перфекциониста к вам подойдет жена и скажет "почему ты не смотришь в камеру", то из-за отчаянья и обиды хочется удалить решительно все записанное, забиться в угол и разреветься (пару раз, в начале моего блогерского пути, такое было взаправду). И сейчас мне кажется, что правда, стоит сделать перерыв между записью первичного материала и монтированием, как и старательно скрывать от всех любопытствующих сырые исходники.

Вообще, процесс записи я изменяю (будь то совершенствование или эксперименты) буквально при каждой новой работе. Вот с IndexedDB я попробовал подход с отдельной записью презентации и live-code. Раньше я делал это за раз и это часто приводило к испорченным дублям и нервам. Писать раздельно стало намного проще.

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

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

🧐 Сегодня прочитал, что CSS функция attr получила возможность подставлять свои значения не только в content.

Раньше attr использовался исключительно с псевдо-элементами для генерации доп. разметки, чаще в кейсах различных тултипов.

<style>
.tooltip::after {
  content: attr(data-tooltip);
  display: none;
  background-color: yellow;
  padding: 5px;
  border: 1px solid black;
  position: absolute;
  margin-top: 10px;
}

.tooltip:hover::after {
  display: block;
}
</style>

<div class="tooltip" data-tooltip="Это подсказка!">Наведи на меня</div>

Но теперь у нас появилась возможность использовать его с любыми другими CSS свойствами.

<style>
[data-color] {
  color: attr(data-color type(<color>), red);
}
</style>

<div data-color="blue">Какой-то текст</div>

Здесь мы интерпретируем значение из атрибута data-color с помощью новой функции type как значение свойства color.
Обратите внимание, что вторым параметров в attr мы задаем значение по умолчанию.

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

Летал тут на пару дней в Турцию (Стамбул), чтобы перезагрузится после бодрого начала года. Да-да, вроде только месяц пролетел, а я уже успел немного подвыгореть. Тут конечно сказались и эмоциональные качели с увольнением, и кранч с новым турбо-курсом по IndexedDB. В общем, стало понятно, что нужно взять таймаут.

Во время своего мини-отпуска, я поймал себя на мысли, что совсем не умеют "нормально" работать. Под "нормально" я имею в виду не упахиваться до полной бессознательности. Знаете это дурацкое чувство, когда вроде уже многое успел за день, но раз силы есть, то начинаешь работать еще и еще. К концу дня доводишь себя до эмоционального истощения, которое непременное появится с какой-либо багой/проблемой. И потом измученный ты заводишь будильник на 6 утра, чтобы пораньше встать и вернуться к работе.

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

Кто знает, может осознание проблемы - это первый шаг к её решению?

Сегодня у меня последний день в Яндексе: осталось написать прощальный пост на работе и сдать рабочий ноут. Все еще немного волнуюсь, но уже скорее больше в позитивном русле)

Тем временем пришли почти все книги для моей подготовки к аспирантуре. Я хочу попробовать силы в компьютерном зрении и машинном обучении, поэтому вы можете видеть большое количество книг по математике. Как обычно - иду от базы :)
Пробовать поступить буду в следующем году, но уже созвонился с приемной комиссией Сириуса и рассказал о себе.

Также, хочу таки завести хобби в геймдеве, но мне тут скорее интересен ни сколько часть про игры, сколько про технологии. Поэтому среди книжек есть литература по OpenGL и Vulcan.

В целом безумно рад, что появилось много времени на учебу - последние годы мне этого прям не хватало.

PS: работа над новым турбо-курсом идет полным ходом. Уже записаны и почти смонтированы 3 лекции, осталось 2. Традиционно ошибся со временем: думал справлюсь за 2 недели, а в итоге 2 недели только делал презентации (и это в полный рабочий день), потом неделю записывал/монтировал и, видимо, еще уйдет неделя. Чтобы немного развеется и выдохнуть, решили с Дашей на несколько дней слетать в Турцию.

PSPS: Знаю, что обещал открытую лекцию по работе с битами в конце января, но из-за кранча над турбо-курсом все поехало. Лекция обязательно будет, но ориентировочно в середине февраля.

Всем базы!

Привет, ребят! У нас появилась идея подготовить для вас контент совместно с нашим юристом, с которым работаем уже много лет сами. Пока по формату не определились, может быть подкаст или эфир проведем. Помогите нам, пожалуйста, определиться с темой. Что из ниже перечисленного вам наиболее интересно? Если мы что-то упустили, закиньте свой вариант в комментарии, пожалуйста 🙏🏻

1. Стартап. С чего начать и как в будущем взаимодействовать с инвестором. Опционы, право собственности на продукт.
2. Легализация доходов в РФ от валютных удаленок, крипты и прочих доходов. Что важно знать, чтобы не иметь проблем с налоговой и не только.
3. Операции с недвижимостью как безопасно продать/купить, а также о тонкостях взаимодействия с риелтором.
4. Регистрация и защита прав на товарный знак/прав на разработку
5. ИП или Самозанятый.
Как легально получать доход с минимальными издержками, без проблем с гос органами и комфортно для контрагента (клиента)

Голосовать ниже 👇🏻

Ребят, а кто в теме, поясните плз. Последнюю неделю количество спам ботов на канале заметно выросло. Большая часть как то связана с криптой и, внезапно, Трампом. Что там такого произошло? 🙈

Пока мой план читать больше в этом году идет хорошо. Уже прочитал несколько технических книг, а вечером в качестве отдыха читаю развлекательное. И вот сейчас дочитываю "Кровь, пот и пиксели".

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

Помню, как мы еще будучи студентами делали свой стартап: сначала мы все горим энтузиазмом и работа заменяет жизнь; потом начинаются дедлайны и презентации перед инвесторами; в какой-то момент "концепция меняется" и в отведенные сроки нужно все переделать и с этим приходят бесконечные кранчи. В итоге все ненавидят то, чем занимаются, и хотят только одного - поскорее это закончить. Окончание, впрочем, не приносит удовлетворение, а лишь бесконечно опустошение. И неважно, закончилось все успехом или провалом. И только спустя некоторое время получается оглянуться и посмотреть на прошлый опыт и понять, что как хорошо, что тогда мы выдержали и не бросили все на пол пути.

В общем, однозначно рекомендую книгу к прочтению.

Ситуация, когда все нормально:

1. Вы отправили запрос на обновление данных по-заданному ИД и ревизии.
2. В БД данная ревизия числится последней актуальной, так что конфликта нет. Создается новый документ с новой ревизией.
3. ИД документа и новая ревизия приходят в качестве ответа на запрос.

Один из вариантов конфликта:

1. Вы отправили запрос на обновление данных по-заданному ИД и ревизии.
2. Параллельно вам, кто-то другой отправил запрос на обновление этих же данных. Его запрос выполнился раньше.
3. Т.к. ваша ревизия уже не является последней, то возникает конфликт. Ситуация отменяется, а в качестве ответа вернутся конфликтующие ревизии.
4. Вы должны явно в коде разрешить конфликт, например, смержить данные или определить, кто в итоге побеждает в конфликте, а затем отправить снова запрос на обновление, но уже с актуальной ревизией.
5. Если пока вы разрешали конфликт, произошла новая запись, изменяющая данные, то ситуация повторится.

Данные алгоритм называется "разрешение конфликтов при записи". Возможен и другой сценарий, при котором вы разрешаете конфликты при чтении. Например, во время синхронизации Master узлов обнаруживается конфликт: CouchDB сохраняет оба документа, а затем при запросе чтения может вернуть список конфликтных ревизий. Ну а дальше вы должны как-то конфликт разрешить.

Предвижу вопрос, но если каждое изменение документа создает копию, то ведь БД быстро разрастется? Да, но чтобы этого не произошло, в CouchDB фоном работает процесс уплотнения: разрешенные ревизии (которые не создают конфликты) постепенно удаляются. На самом деле, с такой вот избыточностью работают очень многие СУБД, так что алгоритм не новый.

Последнее, что хочется еще рассказать, что в отличие от многих СУБД, где синхронизация состояние достигается исключительно на основе журнала операций, то в CouchDB можно буквально подписаться на поток изменения БД. Получается вы можете не только синхронизироваться состояние, но и моментально отображать его на все остальные части системы.

А на сегодня все. Всем базы!

🧐 В прошлой статье я обещал разобрать нюансы распределенной СУБД для Master-Master репликаций и LocalFirst на примере CouchDB.

Итак, давайте сразу определимся с особенностью репликации типа Master-Master (также известную как Multi-Master). В общем случае у нас есть два типа узлов БД:

1. Узлы, которые обслуживают запросы на чтение и запись (Master узлы).
2. Узлы, которые обслуживают только запросы чтения (Slave).

И если в конфигурации Master-Slave у нас в один момент может существовать только один Master, то в Master-Master все усложняется.

На сервере такую стратегию репликации используют для масштабирования БД на разных ЦОД-ах. В таком случае в рамках одного ЦОД обычно существует один Master и множество Slave. А уже между ЦОД-ами Master узлы синхронизируется друг с другом с помощью интернета. И мало того, что узлы должны синхронизироваться и решать конфликты, так еще между ними может пропасть интернет... На клиенте в таком кейсе ситуация не лучше, а может и хуже. Для клиента состояние оффлайна не "форс-мажор", а обычный юзкейс.

Ок, давайте разберем как такие ситуации решаются в СУБД CouchDB. Почему именно она? Дело в том, что эта СУБД целенаправленно создавалась под репликации типа Master-Master. Чего не скажешь о многих других СУБД, где такая функциональность достигается дополнительными решениями.

CouchDB - это документ-ориентированная СУБД. Каждая запись в БД это что-то похожее на JSON объект. Объекты могут иметь глубокую вложенность, содержать под-массивы, а также бинарные файлы через механизм "вложений". В отличие от MongoDB, в CouchDB нет понятия коллекций - все документы пишутся только в одну коллекцию. Если вам нужно больше одной коллекции, то создавайте новую БД - что в итоге приводит к тому, что архитектура нашей БД изначально рассчитывает на сегментированность. CouchDB не поддерживает механизма транзакций, а значит и нет проблем с их масштабированием.

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

Получается, что любое изменение - это копирование (Copy-On-Write), которое имеет свой отпечаток, а версии данных остаются на хранения в БД. Круто, но как нам это поможет в разрешении конфликтов?

Но если задуматься, то теперь у нас появляется явная возможность понять, является ли запись конфликтной или все нормально.

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

* мы используем на клиенте туже СУБД, что и на сервере в режиме Master-Master репликации;
* мы используем/разрабатываем абстрактный протокол синхронизации и дополнительно реализуем код на клиенте и сервере для неё.

Первый вариант выглядит более простым, т.к. зачем делать работу, которая уже ХОРОШО сделана за вас. Но в реальной жизни ситуации бывают разные и реализация своего формата может быть оправдана. Например, потому что вы не хотите завязывать на конкретные инструменты.
Однако главный смысл здесь в том, что мы больше не общаемся с сервером по средствам запросов и API. Мы пишем offline код и используем движок синхронизации.

3. На самом деле пункт 2 можно разбить на два варианта. Что если мы хотим реализовать распределенную БД на множестве компьютеров клиентов и общаться вообще без сервера (WebRTC). То тут больше подойдут другие варианты архитектур, например, No Master. Но я напишу про это как-нибудь отдельно.

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

В одной из своих прошлых статей я перечислил список API браузера, которые используются при создании приложений с поддержкой Offline или Local First.
А их на самом деле и не много: ServiceWorker, CacheStorage, IndexedDB, OPFS (File System). С определенными оговорками сюда же можно добавить LocalStorage и Cookies.

И сегодня хочется поговорить про архитектуру таких приложений. Концептуально тут два подхода:

1. Мы делаем обычное веб приложение: т.е. у нас есть явно модель удаленного сервера с которым мы общаемся по средству сетевых запросов используя один из возможных протоколов (например, REST, RPC, SOAP или GraphQL). Сервер для нас выступает в роли некоторого черного ящика (хотя при том же RPC, он становится более открытым), а клиент в таком случае называется тонким (хотя степень тонкости в современных приложениях может отличаться).

А уже потом мы добавляем offline. И тут тоже есть 2 варианта развития событий:

* мы просто хотим, чтобы в offline наше приложение работало на чтение;
* мы хотим, чтобы в offline режиме наше приложение поддерживало запись.

В случае первого варианта мы фактически говорим о локальном хранилище как о кэше для чтения. С точки зрения дизайна СУБД это похоже на режим репликации вида Master-Slave. Для такой реализации в простейшем варианте хватит ServiceWorker + CacheStorage со стратегией Network First. IndexedDB (или альтернативы) тут могут понадобиться, если мы захотим поддержать самостоятельную обработку поисковых запросов. Либо, если мы хотим оптимизировать объем загружаемых данных, а не кэшировать кучу ответов сервера.

А вот добавление записи все усложняет. Почему? Ну при использовании хранилища как кэша у нас есть простая стратегия: сервер всегда прав. А когда появляется запись, то у нас уже могут возникать ситуации, что данные были добавлены в хранилище во время offline, а потом на другом устройстве/браузере были добавлены снова... Думаю понимаете к чему я веду. В такой ситуации неизбежны конфликты (а добавьте к этому что и на сервере возможны конфликты из-за распределенной природы репликаций). Но проблема в том, что мы можем не учитывать это изначально при проектировании БД и сервера, т.к. offline добавляется потом.

Чаще всего попытки решения конфликтов делаются исключительно логикой на клиенте. И тут сразу проблема синхронизации логики (если есть, например, android, ios и web клиенты и т.д.), а затем проблемы, что исключительно на клиенте решать такие конфликты в общем случае просто невозможно. Но самое главное, что у нас появляется два отдельных кейса работы: online и offline.

2. Альтернативным может быть вариант, когда мы делаем изначально offline приложение, а online является просто дополнительной опцией. Что поменялось? Мы избавились от явной прослойки в виде сервера. Теперь при написании кода нашего приложения мы работаем ИСКЛЮЧИТЕЛЬНО используя API для локальной работы. У нас больше нет серверных точек, с которыми мы общаемся по средствам запросов (либо такие моменты явно ограждены).

Но ведь, фактически, сервер у нас все равно есть (например, сервер БД). Как происходит взаимодействие? С помощью синхронизаций локальной и удаленной БД. Ближайший аналог из мира СУБД - это режим репликаций вида Master-Master (Multi Master). Технически, такого рода репликации могут делать по-разному: либо асинхронная синхронизация операционных/логических журналов, либо асинхронное чтения потока изменений, либо периодическая синхронизация средствами пакетной обработки. Следует сказать, что далеко не каждая СУБД в принципе поддерживает такой режим репликаций. Например, тот же PostgreSQL или Oracle так не умеют, а делается это через отдельные проекты как Bucardo или GoldenGate. С другой стороны, многие NoSQL СУБД by-design рассчитаны на такую стратегию репликаций. Например, CouchDB, Couchbase или Cassandra.

🧐А у меня тем временем кипит работа над новым турбо-курсом по IndexedDB.

Вчера доделал программу/презентацию предпоследней лекции. А на следующей неделе уже планирую запись/монтаж.

Поделюсь планом того, что получается:

Курс сфокусирован с одной стороны над пониманием и разбором IndexedDB - этому посвящено первые три лекции.

Сначала мы учимся работать с IndexedDB "большими" мазками, а затем детально разбираем транзакции, запросы, обновление схемы и индексов. Попутно знакомимся с полезными инструментами по типу idb, idb-keyval и localforage.

Четвертая лекция полностью сфокусирована над использованием библиотеки Dexie.js (включая сервис DexieCloud).

А последняя лекция полностью сфокусирована над проблемой клиент-серверной синхронизации, подходе LocalFirst на примере использования CouchDB и её клиентской реализации PouchDB.

В итоге 5 лекций после которых вы в полной мере поймете и разберете IndexedDB, а также популярные библиотеки. И под "поймете" я имею в виду реально разберемся в вопросах "зачем и почему".

Почему говорю про это, т.к. в описании API IndexedDB вопрос "зачем" как правило игнорируется. Например, при описании транзакций обычно пишут, мол можем добиться атормарности группы операций в рамках одной транзакции и как пример дан "если при записи произойдет ошибка, то все операции транзакции будут отменены". Не знаю как у вас, а у меня такое объяснение приводит к появлению множества вопросов. А вот если посмотреть на транзакции сквозь призму того, что одновременный доступ к IndexedDB доступен из любого потока, то сразу становится ясны и мотивы и реализация.

В общем, как обычно, копаю глубоко (но дозировано). Будет мега круто!

PS: цену курса раскрывать не буду, но она вас приятно удивит. Хочу сделать IndexedDB доступнее во всех смыслах 😄

Ушел из Яндекса 🙈

Вообще, как я писал раньше, с одной стороны давно уже задумывался про это, а с другой - постоянно мучался в сомнениях правильности моего выбора. И так вышло, что в конце прошлого года в Едадиле произошли структурные сокращения, а меня перевели в ротацию (это такой переход между отделами внутри компании). И для меня это было знаком свыше: теперь все, не нужно делать сложное решение об уходе, а просто уходить.

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

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

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

Пополнил свою библиотеку несколькими новыми книгами:

1. Стренг Г. "Линейная алгебра и ее применение". Случайно наткнулся на эту книгу в Ozon. Книга достаточно старая (оригинал вышел 1980), но листая оглавление меня заинтересовало, что ко всем излагаемым темам есть кейсы применения в жизни. Для человека не очень искушенного в математике как я, такие примеры являются находкой, т. к. самостоятельно дойти до того, что условно решения задача класса K нужно применять N бывает непросто. В общем интересно будет изучить. Это не первая моя книга такого рода, так что настроен оптимистично.

2. Фаулер М. "Основы UML". Я давно порывался разобраться с UML, т. к. это технология прошла мимо меня в университете, а потом как то все руки не доходили. Книжка совсем небольшая, так что как минимум для ознакомления и закрытия пробелов по важной теме точно будет не лишним. Да и к тому же с Фаулером у меня сложилась хорошая история: его книги написаны просто и по делу.

3. Эккель Б. "Философия Java". В одном из недавних постов про мою библиотеку мне сделали замечания, что серия CS у меня не полная и не хватает этой книжки, поэтому не долго думая я оформил покупку. Я люблю такого рода книжки: они полезны для меня как для преподавателя (я отмечаю как манеру повествования, стратегию введения в темы, так и нюансы самих технологий, а также мотивы, которые двигали разработчиков при реализации). В общем будет интересно прочитать.

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

Буквально на днях узнал о добавлении нового хэлпера в стандартную библиотеку JS - RegExp.escape. Метод крайне полезный и поэтому присутствует во многих библиотеках хэлперов. Суть его крайне проста: он принимает строку и возвращает её копию с экранированными символами, которые имеют значение в синтаксисе регулярных выражений.

Например,

RegExp.escape('foo.bar') === "\\x66oo\\.bar" 

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

Зачем это нужно? Тут 2 кейса:

1. Когда мы формируем RegExp на основе некоторой строки или конкатенации строк мы должны думать, где мы хотим использовать RegExp символы, а где нет.

Например,

// true, ведь . ознает любой символ кроме перевода строки
new RegExp(['foo', 'bar', 'bla'].join('.')).test('foo$bar#bla');

// false, все символы распознаются "как есть"
new RegExp(RegExp.escape(['foo', 'bar', 'bla'].join('.'))).test('foo$bar#bla');

2. Когда мы передаем строку в метод, который неявно формирует из него RegExp. Например, так делают методы search и replaceAll у строки.

// Позиция найдена, ведь . ознает любой символ кроме перевода строки
'helloworld'.search('.');

// Позиция не найдена
'helloworld'.search(RegExp.escape('.'));

Ну что-же, с небольшим отрывом победила тема про работу с битами. Так что, ориентировочно, в конце января мы с вами соберемся вечером, чтобы как следует разобраться в вопросах: как и зачем 🙈💪

Хочу в конце этого месяца провести открытый урок.

Есть две потенциальных темы:

1. Побитовая работа с данными в JS. Хочу обсудить как и зачем это можно использовать в кейсах Frontend, Node и JS.

2. Cравнение бинарных форматов данных (MessagePack, Protobuf, Thrift, Avro). Разобрать схемы кодирования этих форматов и сравнить их между собой, а также сравнить с текстовыми вариантами (JSON, XML).

Что скажете?

Впечатляет? Уверен, что да. И повторюсь, использовать чистый IndexedDB не сильно сложнее LocalStorage. Нужно просто принять правила игры IndexedDB.

1. Если в LocalStorage мы все пишем в глобальную область и должны сами думать про конфликты, то в IndexedDB про это подумали за нас. Нам нужно только указать имя БД к которой мы подключаемся (в рамках одного Origin может быть много БД).

* Но и внутри БД у нас есть деление на объектные хранилища. Т.е. в одной БД app может быть несколько хранилищ для разных данных.
* Если мы хотим использовать дополнительные индексы для хранилища, то их надо описать (логично).
* Если в рамках обновления кода приложения мы что-то поменяли в БД (добавили/удалили хранилище или индекс), то у нас есть встроенный протокол миграции.

2. Т. к. IndexedDB разделяется между разными потоками, то нам необходима некоторая структура по типу RWLock для защиты от гонок. В IndexedDB это делается через API транзакций, которых бывает ровно 2 вида (чтение и чтение+запись).

* В рамках одной транзакции можно делать более одного запроса к БД, что гарантирует согласованность данные при работе с хранилищем из множества потоков.

Вот и все. Давайте напоследок дам простой пример:

1. Мы хотим данные нашего приложения хранить в БД под названием myApp. В этом БД сделаем 2 хранилища: в одном будут храниться некоторые JS объекты, где ключом будет являться поле _id, а в другой будем хранить картинки.

core/storage.js

export const storage = (() => {
    const db = indexedDB.open('myApp', 1);

    db.addEventListener('upgradeneeded', (e) => {
        const db = e.target.result;

        // Создаем в БД 2 хранилища
        if (e.oldVersion === 0) {
            // Говорим, что ИД должен браться из поля _id
            db.createObjectStore('users', {keyPath: '_id'});
            db.createObjectStore('images');
        }
    });

    return result(db);
})();

// Небольшой хелпер для удобства работы с Promise
export function result(target) {
    return new Promise((resolve, reject) => {
        const success = (e) => {
            resolve(e.target.result);
            target.removeEventListener('error', error);
        }

        const error = (e) => {
            reject(e.target.error);
            target.removeEventListener('success', success);
        };

        target.addEventListener('success', success, {once: true});
        target.addEventListener('error', error, {once: true});
    })
}

2. Используем наше БД в любом месте нашего приложения.

import * as db from './core/storage';

async function saveSomeData() {
  const
    imageName = 'image.jpeg',
    image = await (await fetch(`//example.com/${imageName}`)).blob();

    // Открываем транзакцию на запись в 2 хранилища БД
  const t = (await db.storage).transaction(['users', 'images'], 'readwrite');

    // Просто передаем объект JS (причем ключом же является одно из его же поле _id)
  t.objectStore('users').put({_id: 0, name: 'Bob', age: 22});
    
    // Просто передаем Blob, а вторым параметром ключ
  t.objectStore('images').put(image, imageName);
}

async function getSomeData() {
    // Для чтения из users откроем транзакцию на чтение
  const t = (await db.storage).transaction('users');
    
    // get вернет значение по ключу, getAll вернет массив значений и т.д.
  console.log(await db.result(t.objectStore('users').get(0)));
}

Как видите все свелось к добавлению одного маленького хэлпера для удобства работы с Promise и описания какие хранилища существуют в БД. А дальше все также делается 1-2 строчками, как и в LocalStorage.

Разумеется, возможности IndexedDB намного больше описанных в этом простом примере, но если они вам не нужны, то вы можете их просто не использовать. При этом использовать большие сторонние библиотеки по типу PouchDB или Dexie.js для таких задач абсолютно нет смысла.

Всем базы!

🧐 В мире Frontend и не только есть такие вещи, про которые есть устоявшееся мнение, что они "сложные" или "запутанные".

Про них часто говорят, что "они нужны только если вы делаете $name", а в остальных случаях используйте что-то другое. В итоге это приводит к тому, что большая часть разработчиков просто интуитивно до последнего игнорирует их. И, действительно, никому не хочется разбираться в сложном.

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

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

А знаете, что удивительно? Что очень многие знают про ограничения LocalStorage и легко расскажут о "костылях" для того чтобы их обходить. Читая и слушая все это формируется мнение, что IndexedDB крайне неудобное и редко нужное в жизни API. Но правда в том, что это неправда (вот такой вот каламбур).

IndexedDB не сильно сложнее того же LocalStorage, но при этом лишено его недостатков. Да, есть ситуации, где LocalStorage или SessionStorage подойдут лучше, но в реальности в огромном количестве ситуаций где разработчики использую LS лучше подойдет именно IndexedDB. Давайте просто перечислим плюсы IDB:

1. Размер хранилища гораздо больше: например, в FF используется подход, что на каждый Origin (упрощая, протокол + домен) выделяется 10% от диска, но не более 10 Гб. LocalStorage имеет ограничение 5-10 Мб.

2. Не только key-value: можно делать запросы на диапазоны, например, извлеки все объекты, где ключ больше/меньше некоторых значений (даты, числа, строки - не важно).

3. Не только один ключ: мы можем создавать вторичные индексы для удобного поиска по разным ключам.

4. Нет проблем с конфликтами имен ключей, т. к. есть разделение на БД. Более того, встроен автоматический механизм обновления БД через версии.

5. Автоматическая сериализация и парсинг JS объектов: вам не нужно предварительно преобразовывать значения в строки, а затем думать как это распарсить - все просто работает из коробки.

6. Поддержка байтовых буферов, типизированных массивов и блобов: хотите сохранить картинку в IndexedDB - просто берете и сохраняете.

7. Хранилище IndexedDB разделяется между потоками: мы можем читать и писать в хранилище из основного потока, WebWorker потока, другой вкладки на том же Origin и т.д. Отсутствие гонок гарантирует встроенный механизм транзакций.

8. Асинхронный интерфейс и поддержка курсоров: проблема LocalStorage, что если мы читаем или пишем в него большую строку, то это тормозит все (из-за синхронного API). В IDB такой проблемы нет, более того, мы можем считывать и загружать данные в хранилище частями по курсору.

9. Удобная централизованная обработка ошибок с помощью событий: вы можете обрабатывать ошибку каждого отдельного запроса или просто сделать универсальный обработчик.

Вчера, наконец, разложил свои книги. Получился этаж базы, затем этаж функциональщины и прикладного, а потом этаж инфраструктуры и инструментов 😃

PS: заметил, что ml не сгруппирован у меня. Не дело 😃

🌴 ПРО МАЛЬДИВЫ

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

1️⃣ Это не так дорого, как кажется. Мне всегда казалось, что Мальдивы это что-то на очень богатом и меньше 1,5 млн такой отдых не стоит. Оказалось, что получить все, чем прекрасны Мальдивы - безлюдные песчаные пляжи, водные виллы, лазурную воду с богатым водным миром можно и по цене в три раза дешевле. Наша поездка на семь ночей в новый отель Barcelo Wale Lagoon пр системе “все включено» стоила нам 507 тыс + перелет. Но есть варианты и дешевле! И уверен, что там будет тоже замечательно. Из подборки 5* отелей самая низкая цена, что предлагалась была 380 тыс. Но есть вариант сильно дешевле, о нем будет дальше.

2️⃣ Перелет. Лететь из Москвы 9 часов прямым рейсом Аэрофлота. Можно и с пересадкой через Дубай. Если вы тяжело переносите длинные перелеты, то мне кажется приколный вариант , задержаться на пару дней в ОАЭ и потом уже в Мале, к тому же рейс будет короче, всего 4 часа. Но есть нюанс, в основном рейсы из ОАЭ прилетают в районе 15 вечера, а гидросамолеты летают только в дневное время, поэтому если ваш отель далеко, а рейс задержали, то есть риск застрять до утра в терминале. Поэтому такой вариант подойдет для отелей к которым нужно добраться на катере, такой трансфер доступен круглосуточно.

3️⃣По питанию и алкоголю. Лучше брать сразу тариф с питанием, так как питаться по меню достаточно дорого, даже закуски начинаются от 8 usd за небольшую порцию, а алкоголь там вообще космос. С собой алкоголь привозить запрещено, забирают на прилете, даже пакеты duty free. Вам их вернуть на обратном пути, но за каждый день хранения придется заплатить порядка 4 долларов.

4️⃣Сезонность. Считается, что с ноября по апрель высокий сезон и в это время мало дождей, и цены соответственно выше. Но в целом погода и зимой и летом здесь одна и та же, около 30 градусов, за исключением того что летом может быть больше дождей. Зато цены летом сильно ниже.

5️⃣Если бронировать заранее (декабрь-январь) то можно получить хорошую цену со скидкой 40% на лето и осень. Мы, например, забронировали уже 3 недели на июль в другой отель, более активный, так как хотим поехать с ребенком. Тоже все включено, вилла на берегу, получилось 15 000 usd. Но пока ничего не платили, оплата будет за 35 дней до поездки. Если не получится, то можно просто отменить без штрафа. Полетим с тем же агентством, нам все понравилось. Туроператор Maldives online (не реклама, если что). У них в группе можно и подборки разные посмотреть.

6️⃣Атмосфера. Мальдивы это спокойный отдых. Главное развлечение это купаться с рыбками, днем массаж, вечером бар с живой музыкой. И так каждый день. Нам такое не надоедает, но, возможно, особо активным это не подойдет, но а таком случае можно просто менять отели каждые несколько дней и будет всегда новизна.

7️⃣Ну и самое главное - как полететь еще дешевле. С 2008 года Мальдивцам разрешили сдавать свое жилье и принимать гостей и с этого момента стали очень популярны local islands, острова где живут местные. Там вы можете забронировать сами жилье, но и добираться будете сами, выстраивать все маршруты и брать риски на себя. Но в целом мне кажется это ничем не отличается от поездки в Тайланд или Шри Ланку в плане организации, и если у вас есть опыт организации себе таких поездок, то и на Мальдивах вы справитесь. Но и ценник будет в разы дешевле отелей.

В общем, если вы когда-то мечтали полететь на Мальдивы, то не откладывайте, это вполне посильная задача для программиста по деньгам, а отдыхать практически без людей вокруг это вообще отдельный вид удовольствия для интроверта 😁

Отличных вам поездок в 2025 году, куда бы вы не отправились 🫶

Вот праздники и пролетели! Надеюсь все успели отдохнуть или хотя бы перевести дух.

Я в этом году решил даже не пробовать делать что-то полезное в праздники. Зато, устроил себе VR марафон и прошел Half-Life Alyx - это просто восторг 😍 ! Совершенно иной уровень погружения. Особенно понравился уровень, где нужно прятаться от бессмертного зомби и зажимать себе рот, чтобы не кашлять от спор растений 🙈 В общем однозначно рекомендую. Только жаль, что до сих пор проектов для VR уровня Alyx не так много.

А еще, Даша подарила мне сертификат на курсы вокала и я уже провел 2 занятия и мне безумно понравилось. Так что собрался теперь заниматься на постоянной основе. Да и Даша на меня глядя тоже записалась на вокал 😄

А сегодня стал потихоньку раскачиваться на работу: устроил капитальную уборку в кабинете; наконец решил расставить свои книги... Одним словом - настраиваюсь!

В общем всех с первым рабочим днем!

С Новым годом! 🍾🍾🍾🍾🍾🍾🍾🥳🥳🥳🥳🥳

Ну а теперь по планам на следующий год.

1. Я всерьёз размышляю над уходом с работы в Яндексе, чтобы полностью сфокусироваться над Kobezzza.Lab и блогом. Это очень волнительный шаг, про который я с одной стороны много думал, но постоянно откладывал. Думаю, всё решится в начале следующего года.

2. Переосмысление и перезапись всех моих старых интенсивов в формате турбо-курсов. Первый на очереди будет TypeScript.

3. Совместно с Димой Холстининым разработать и провести курс по сборке Frontend. Это будет следующая итерация курса по WebPack, который мы делали в 23 году.

4. Разработка и проведение курса по Rust и Wasm.

5. Разработка и проведение Марафона подготовки к собеседованиям 2.0.

6. Разработка и запись небольших интенсивов и турбокурсов по темам, которые я давно задумал, но все откладывал. Тут и IndexedDB, и Nginx и многое другое.

7. Продолжать вести формат открытых лекций. Хотелось бы провести минимум лекций 8 за год.

8. Выступать на конференциях (уже получил приглашение на новый CodeFest).

9. Слетать на Байканур на запуск пилотируемой ракеты.

10. Слетать всей семьей недели на 2-3 на Мальдивы (было так круто, что я хочу добавки).

11. Больше читать! Уже составил план книг к прочтению: тут и техническое, так и романы.

12. Almost Unreal: слетать в Японию. Мы задумали это путешествие еще сначала как свадебное 7 лет назад, но в итоге отложили до 20 года. А потом началась пандемия и уже купленные билеты пришлось сдавать обратно. Вот попытка номер 3.

В общем, как вы видите планы большие и амбициозные. Посмотрим, удастся ли мне реализовать их.

Ну а вам ребят, хочется пожелать, чтобы в грядущем году у вас сбыли все ваши планы и мечты. Успехов в карьере, здоровья и семье. Всех виртуально обнимаю. С наступающим новым годом! 🥂🎉

Мой год в картинках 🎄

🎄До нового года остается совсем немного времени, а значит настало время проводить старый, подвести итоги и помечтать над планами на следующий.

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

🎓Школа KobezzzaLab.

1. В том году я провел свой самый длинный поток CS: 9 месяцев, 57 лекций и 15 практик, более 200 часов суммарно контента! И понял, что больше такой формат делать не буду, но про это подробнее в планах.

2. Я записал турбо-курс по командной строке. А самое удивительное, что я смог сделать это параллельно с ведением курса и работой.

3. Совместно с Димой Холстининым мы записали турбо-курс по отладке и запустили новый курс по инфраструктуре Frontend.

4. Расширили нашу команду школы (нас уже 10!).

5. Зарегистрировали торговый знак Kobezzza.Lab. Да и вообще стали полноценным работающим бизнесом.

📝Блог и некоммерческая образовательная деятельность.

1. С конца лета я стал более активно вести телеграмм и увеличил аудиторию блога в 2 раза!

2. Начали проводить новый формат онлайна - открытые лекции.

3. Выступил на CodeFest.

4. Записал 3 подкаста. Два своих и один как гость.

🛋️ Бытовые

1. Мы наконец-то закончили ремонт на нашей квартире! Вернее согласились, что закончили основной этап. Кто давно на меня подписан, знает про эту эпопею - мы нарвались на мошенников (с которыми теперь судимся). Сначала до последнего надеялись в честность людей, но в итоге пришлось заново оплачивать всю мебель уже у другой компании. Эпопея заняла почти 2 года и закончилась примерно в сентябре.

2. Мы купили новую машину моим родителям (Cherry Tigo 7 ProMax если кому интересно).

3. Мы начали и уже почти закончили ремонт (вот это скорость ремонта в Мск!!!) на квартире моих родителей.

🤩 Эмоции и отдых:

1. Два раза сходил в отпуск! В начале года всей семьёй слетали в ОАЭ, а закончили год на Мальдивах.

2. Испытал чувство невесомости на специальном самолете-лаборатории!

3. Прошел RDR2 (суммарное прохождение заняло почти 4 года). Да и вообще стал потихоньку закрывать гештальты по играм (да-да, я помню, что мне 4-й десяток, но что поделать). Например, пока был в отпуске, прошел на SteamDeck "Middle-earth: Shadow of Mordor", который отложил аж в 2014 году.

💪🏻А еще я похудел на 10кг и не набрал их обратно!

Фух, вроде ничего не забыл. Всегда удивительно смотреть на объём проделанной работы: если бы мне поставили такой план, то я вероятно покрутил бы у виска и сказал, что это маловероятно. Но задротство и труд - все перетрут.

С другой стороны еще более амбициозными выглядят планы на 25 год, но про этом в отдельном посте.

🧐 Сегодня прочитал про проект CobolCraft. Если кратко, то это сервер Minecraft написанный с нуля на Cobol.

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

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

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

2. Это весело. Такое программирование сродни просмотру увлекательного фильма или игре. Программирование - это не только работа, деньги и выгорание.

Короче, годнота. Вот, например, зацените реализацию парсера JSON на Cobol.

Хо-хо-хо, ребят! Если вы не знаете чтобы такого подарить своему коллеге по Frontend, или же хотите всем намекнуть что подарить вам, то спешу с радостной новостью: теперь на нашем сайте можно приобрести подарочный сертификат на Kobezzza-бонусы.

Kobezzza-бонусы - это эквивалент валюты для оплаты полностью или частично любых продуктов KobezzzaLab. Один бонус равнозначен одному рублю. Например, у вас есть 7000 бонусов, а значит вы можете получить скидку в этом же размере на более дорогой продукт или же оплатить полностью (если продукт стоил меньше, то разумеется у вас сохранится остаток).

Доступны сертификаты на бонусы от 3 до 25 тысяч.

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

1. Обновленный курс по TypeScript 5.
2. Обновленный курс по сборке Frontend.
3. Курс по Rust и Wasm.

А также в планах курсы: IndexedDB, курс по асинхронному и конкурентному программированию в JS, обновление курса по регулярным выражениям... Одним словом есть где развернуться.

Переходи на сайт и сделай подарок базы для себя или своего коллеги.

В модуль интернационализации Intl был добавлен новый API DurationFormat.

Фактически, это логичное продолжение API по интернационализации дат и времени, но теперь у нас появляется возможность генерировать текст для описания "длительности". Например,

// '1 час, 46 минут 40 секунд'
new Intl.DurationFormat('ru-RU', {style: 'long'}).format({hours: 1, minutes: 46, seconds: 40});

Это API отлично подойдет для сценариев, когда вам нужно сказать "когда последний раз обновлялся контент" или "когда вы были в сети" и т.д. Помню в своё время самостоятельно писал такую штуку и помучался знатно. Здорово, что теперь это стало частью стандартной библиотеки JS. Теперь осталось только дождаться поддержки во всех браузерах (везде кроме FF поддержка уже есть).

К слову, рекомендую потратить время на изучение модуля Intl - там очень много чего интересного.

Написал пост выше и понял, что мои функции можно упростить используя API TextEncoder/TextDecoder.

function toBase64(str) {
    return new TextEncoder().encode(str).toBase64();
}

function fromBase64(str) {
    return new TextDecoder().decode(Uint8Array.fromBase64(str));
}

🥳 API Uint8Array получил обновление в виде плеяды методов типа fromBase64, fromHex, toBase64, toHex, setFromBase64, setFromHex и это очень круто, т.к. раньше приходилось такой код писать руками.

А еще, используя эти методы можно наконец забыть про кривые методы window.atob и window.btoa, которые мы использовали для конвертации строк в формат base64. Почему кривые? Ну, они поддерживают только ASCII диапазон, а значит, например, преобразовать кириллические символы у нас не получится. Но теперь это не проблема.

function toBase64(str) {
    // Наши строки закодированы в UTF-16, поэтому делаем на их основе Uint16Array и извлекаем буфер
    const buf = new Uint16Array(
        str.split('').map((s) => s.charCodeAt(0))
    ).buffer;
    
    // Смотрим на буфер как на поток байт и кодируем в base64 строку
    return new Uint8Array(buf).toBase64();
}

function fromBase64(str) {
    // Декодируем строку в байты
    const buf = Uint8Array.fromBase64(str).buffer;
    
    // Делаем из Uint16Array обратно строку
    return new Uint16Array(buf).reduce((res, code) => res + String.fromCharCode(code), '');
}

Всем базы!

А у нас, кстати, наконец-то появился единый сайт со всеми продуктами - https://kobezzza.ru/

Теперь там можно будет получить полную информацию по всем нашим продуктам.

На след год большие планы по обновлению имеющихся интенсивов (первый в списке TS). И конечно же, Rust 🔥

С удивлением недавно узнал, что функция fetch обзавелась новым параметром keepalive.

Что это за зверь? Ну смотрите, исторически, не важно что мы использовали в качестве транспорта для асинхронных запросов (XHR, Fetch, и т.д.) у нас была неизменна логика: если пользователь уходит со страницы или закрывает браузер, то и все незаконченные запросы также прерывались. Если же нам было нужно такое поведение (например, для отправки аналитики), то существовало специальное API navigator.sendBeacon.

document.addEventListener('visibilitychange', function logData() {
  if (document.visibilityState === 'hidden') {
    navigator.sendBeacon('/log', analyticsData);
  }
});

Но проблема в том, что sendBeacon уж слишком примитивен: у вас есть URL, данные и вы можете использовать только POST запросы. Даже header запроса тут не установить. И вот теперь у нас появилась такая возможность используя стандартное Fetch API (правда поддержка только в новейших версиях браузеров, например, в FF только с версии 133).

fetch('/log', {
  method: 'POST',
  body: analyticsData,
  keepalive: true
});

Разумеется, как и в sendBeacon так и в keepalive есть ограничение на размер отправляемых данных: они не могут превышать 64кб. Но я считаю, что такое изменение в API не может не радовать. По моему опыту проведения собеседования, половина разработчиков даже не знает о наличии navigator.sendBeacon.

Закончил вчера разработку плана грядущего курса по TypeScript. Кажется получилась просто пушка! Кому любопытно, то вот оставлю ссылку на план. Если есть вопросы-предложения, то пишите в комментариях.

А еще в процессе подготовки узнал о фиче, которая почему-то прошла мимо меня, но на практике очень и очень полезна. Речь про оператор as, который позволяет удобно делать переименование ключей в объектном типе.

Покажу сразу пример из документации:

type Getters<Type> = {
    [Property in keyof Type as `get${Capitalize<string & Property>}`]: () => Type[Property]
};
 
interface Person {
    name: string;
    age: number;
    location: string;
}

// type LazyPerson = {
//   getName: () => string;
//   getAge: () => number;
//   getLocation: () => string;
// }
type LazyPerson = Getters<Person>;

Просто и изящно. Фича появилась уже достаточно давно (TS 4.1), но я до сих пор по старинке использовал рекурсивную типовую функцию.

БАЙКОНУР ВСТРЕЧАЙ!

На эйфории после невесомости, мы решили не отпускать тему космоса и купили тур на Космодром Байконур на запуск РН «Союз МС-27» с 12.03. по 17.03. Это пилотируемый запуск, так что будем провожать настоящих космонавтов 🤩

P.S. Думаю повторить полет в невесомости. В моменте так все быстро пролетело, кажется, что во второй раз уже со знанием процесса можно лучше запечатлеть в памяти само состояние невесомости.

P.P.S. А еще меня заинтересовала программа «Здоров, как космонавт». На две недели заезжаешь в Звездный городок и проходишь проверку, физическую и психологическую, с чуть меньшей интенсивностью, но такую же какую проходят все, кто готовится в космонавты. Ну и заключение еще дадут по состоянию здоровья и рекомендации.

Ну вот я и дома! 🔥

Правда не обошлось без приключений. Наш рейс с 8 вечера перенесли на 00.40 ночи, а значит дома я был только пол шестого утра 🙈 Сегодня день в полукоматозном состояние 🙃

В Сочи уже во всю чувствуется новогодний вайб, но у нас еще остались незаконченные дела в этом году 🧐

Напоминаю, что все кто взял на нашей черной пятнице 8-ю форму, то у нас впереди две крутых live лекции: развитие карьеры программиста и большая лекция по System Design. Проходить лекции будут 23 и 27 декабря.

Ну и приду в себя после перелетов и в планах на этот год есть еще парочка интересных статей 🧐

Невесомость - это разъёб

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

Сам полет в невесомости (режим) предваряется и оканчивается перегрузкой 2g, т.к самолет сначала резко летит вверх, а потом вниз. Очень странное ощущение: мне казалось что даже мои губы стали такими тяжелыми, что я с трудом улыбался. Проще всего было переносить лежа, когда тебя буквально вжимало в мат.

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

Вообще передвигаться в невесомости довольно сложно. Это не плаванье, где мы отталкиваемся руками или ногами. Тут ты оттолкнулся в начале и дальше летишь сшибая все на своем пути 😂 Более менее освоился я только под самый конец.

Сам режим длиться 25 секунд и каждые 5 секунд идет отсечка. Всего 10 режимов. К 20 секунде надо вернуться вниз, иначе можно больно ударится об пол. Там хоть и маты, но высота потолка 4 м и все равно можно поранится. Т.к. я поначалу вообще мало что понимал, то карабкаться вниз я начинал уже на 15 секунде 🤣🤣

🤢По вестибулярке и тошноте: я чувствовал себя хорошо. Легкая тошнота была уже только в конце, но многим стало плохо уже вначале. Кого то рвало. Даша сошла с дистанции уже после третьего режима. Я думаю тут все индивидуально. Но вот вечером уже перед сном я стал ощущать сильные головокружения 🫣 такая фантомная невесомость 😃

Вообще, я бы однозначно повторил этот опыт, чтобы насладится невесомостью уже более осознанно 🥰

P.S. Это видео, что ребята сами успели снять, еще будут профессиональные фотки и видео, тоже поделюсь потом👌🏻

Наш полет в невесомости состоялся! 😱 эмоций через край сейчас 🙃 приду в себя и напишу подробно

🥶Мы опять в Москве, сегодня будет очередная попытка полететь в невесомость. Боюсь даже загадывать, но в 7:30 мы уже были на КПП Центра подготовки космонавтов. Если не получится, то завтра еще попытка, а если нет, то уже не знаю когда 🤷 Завтра в любом случае возвращаемся в Сочи и врываемся в последние рабочие недели перед НГ🎄

P.S. Хочу написать отдельный пост по Мальдивам, рассказать про нюансы своей поездки и как недорого туда можно слетать. Если интересно, поддержите огоньками.

Выкладываю запись вчерашнего live - https://youtu.be/BOIOWUuDyYc

В общем сегодня мы тоже не полетели. На этот раз военные не дали добро на вылет (аэродром принадлежит военным). Немного расстроились конечно, но зато встретились с нашим студентом - он живет рядом.

Сейчас едем в Москву, проезжали Бауманку и очень понравился их слоган: Юра, мы все исправим 😃

Мне очень понравился сайт, неон, картинки, текста

Просто потрясающе! Андрей, спасибо Вам большое! За материалы, за контент, за такую возможность зайти на КС во фронтенд 🥩🥩🥩

🗂️ СОСТАВ ЧЕРНОЙ ПЯТНИЦЫ

Ну что же, мы вот и наступила черная пятница 🥳

Расскажу про формы пакетов и почему они именно такие. Как референс мы брали формы владения световым мечем из вселенной звездных войн.

Первые 3 формы там формируют основу, для дальнейшего развития. Так и у нас первые 3 формы состоят из интенсивов и миникурсов, которые формируют базовые знания по аспектам js и не только. Сюда входят все интенсивы и турбо-курсы, которые мы когда-либо выпускали.

4,5 и 6 формы содержат в себе возможность приобрести в записи легендарный курс CS во Frontend. Мы даем возможность приобрести отдельные модули или все сразу. Учитывая, что следующий поток будет только в 26 году - это по истине уникальное предложение.

Ну и последняя форма содержит в себе буквально все, что мы когда-либо выпускали по самой большой скидке. Есть рассрочка + обратите внимание, что за каждую 100% оплату мы даем кешбек 7% бонусами на любые следующие покупки.

А самое круто, что мы разыграем 2 бесплатных места на грядущий курс по расту! Любой купивший любой пакет автоматически участвует в конкурсе.

Не упустите свою возможность!

https://kobezzza.ru/blackfriday24

КОСМИЧЕСКАЯ РАСПРОДАЖА НАЧАЛАСЬ!!

https://kobezzza.ru/blackfriday24

И да пребудет с вами сила! ✊🏻

Полет перенесли на завтра 😭

Погода не позволила. Обидно, но так бывает. Хорошо, что у нас есть день в запасе.

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

Конечно, удивительная профессия. Но еще более удивительно, что космонавтом может стать любой обладатель высшего технического образования и богатырского здоровья до 35 лет. Да-да, вам необязательно быть летчиком испытателем. Сейчас есть специальные программы, которые доступны всем. Говорят, что средний возраст для приема в отряд космонавтов 28 лет. Подготовка занимает около 10 лет. Помимо физического здоровья очень важно быть рукастым, потому что основная задача космонавта в космосе это проведение научных экспериментов в особых условиях космоса, а еще в случае чего надо и что-то починить, приварить, даже пломбу временную себе поставить мочь и провести хирургическую операцию. Этому и многому другому обучаются 10 лет перед полетом, а после полета снова на обучение. В этом смысле космонавт это вечный студент.

Мне, к сожалению, уже 35. Но если вам меньше и вы мечтали в детстве стать космонавтом, то шанс есть 😉

P.S. Кстати, Юлия Пересильд (актриса) не должна была лететь в космос, было 50 кандидаток, но всех отсеяли по здоровью, а Юлия оказалась самая выносливая. Режисер был в бешенстве, но что поделать, в космосе «блата» нет 😅

Мы уже готовы, а погода нет 😬 Полет перенесли, пока на 12-13 дня. Ждем! Надеюсь все сложится. Держите за нас кулачки 👊🏻

Ну и пользуясь случаем, напомню, что завтра в 9:00 у нас стартует «Космическая распродажа». Только 2 дня или пока закончатся места. Предложение просто сумасшедшее! Ближайшие года 2 ничего подобного мы делать точно не будем.
Скидки до 82% 😱 Если не хотите пропустить начало продаж, подпишитесь на наш бот. Он первым выдаст ссылку на сайт распродажи.

https://t.me/Kobezzzainfo_bot

Ну все, идем на экскурсию в Центр подготовки космонавтов, пока ждем разрешение на вылет.

День X

День X уже завтра! И нет, это не черная пятница, хотя уверен многие ждут именно ее. Я же говорю о своем полете в невесомость, который состоится уже завтра 😱

Сбор на КПП звездного городка назначен на 7:45 утра и поэтому мы решили остановиться рядом. Так что я сейчас в Москве, еду по МКАД в сторону Щелково. Честно говоря, немного волнительно как там все пройдет.

Пару слов об играх

23 ноября на курсе CS во Frontend прошла финальная защита второй курсовой работы. И уже традиционно среди проектов всегда есть игры.

В этот раз курсовые готовили три команды по темам: игра-платформер, движок для создания презентаций и rogue-like игра. Все ребята проделали большую работу и представили замечательные проекты. Посмотреть защиту и их проекты можно по ссылке: https://www.youtube.com/watch?v=_tPCw46VtTU

Как вы ,наверное, знаете, мне самому тема игр очень интересна, но в первую очередь с технической точки зрения.

Почему? Да просто разработка своей игры с нуля может потребовать от вас применения огромного количества навыков: тут и работа с Canvas, линейная алгебра, физика, работа с типизированными массивами и бинарными структурами данных, конкуретное и многопоточного программирование, разработка шейдеров... В общем это целый клондайк для оттачивания и практики самых разных скиллов. Да и к тому же это очень весело!

Но как я писал в предыдущем посте, вы можете это монетизировать! Вы можете разрабатывать инди-проекты и дистрибутировать их используя Яндекс.Игры, AppStore, GooglePlay, Steam и неплохо на этом зарабатывать (при условии, что в вашу игру действительно интересно играть). Так что тут получается джекпот - вы можете начать делать проект для оттачивания навыков, а потом сделать его основой для монетизации.

Как по мне, это отличная альтернатива разработке библиотек или UI виджетов. А вы как считаете?

Как еще заработать программисту
Часть 4

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

🛠 Развивай свои проекты

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

🕹 Еще как вариант можно разрабатывать свои инди-игры и размещать их на различных платформах по типу Steam или Яндекс.Игры. И да, тут тоже можно хорошо зарабатывать.

Понимаю, что все хотят услышать примеры, поэтому выложу проект моего коллеги с работы - https://xdsoft.net/jodit/.
Это WYSIWYG редактор, у него есть бесплатная и платная версия. Не буду говорить конкретные цифры, но скажу, что доход от этого проекта у него ОЧЕНЬ хороший.

Есть еще один кейс, когда разработка своих решений может принести дивиденды. На этот раз мой личный пример. У меня не раз была ситуация, когда мои разработки использовались людьми, которые потом приглашали меня на работу на очень хорошие условия. Например, в Едадиле использовался DSL-ЯП для описания шаблонов - https://snakeskintpl.github.io/docs/index-ru.html, а затем я получил приглашение на работу. Так что бывает и так.

Ок, какие же здесь нюансы?

1. Нужно понимать, что нужно людям. Т.е. ваша библиотека должна не только работать, но и закрывать потребности людей.
2. Разработка своего проекта требует времени и компетенций. Фактически мы снова возвращаемся к очередной комбинации пункта 1 и 2.
3. С другой стороны, разработка своих решений будет хорошим драйвером ваших профессиональных навыков.
4. Мало разработать хорошее решение, но нужно и продвигать его.

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

Подытожить хочется тем, что любой успех - это результат в первую очередь большого труда. Да, удача оказаться в нужное время в нужном месте или знать нужного человека тоже имеет место, но в первую очередь труд. Другое дело, что и труд бывает разный: если в 20 лет мы можем спать по 4-5 часов и трудиться на нескольких работах, то уже даже в 30 это становится куда сложнее, поэтому брать нужно именно опытом и экспертизой.

Всем базы!💪

Как еще заработать программисту
ЧАСТЬ 3

Окей, в первый двух частях мы разбирали вполне очевидные способы увеличения ЗП. Если угодно, их можно назвать спринторский (больше работать) и марафонский (больше компетенций).
А теперь хотелось бы обсудить другие способы. Будет 2 поста.

🎙Развивай личный бренд.

Сейчас многие специалисты ведут свой блог, занимаются менторством или запускают свои образовательные курсы. Фактически мы видим тут комбинацию из того, что мы обсуждали в части 1 (работай больше) и части 2 (работай лучше).

🧐Какие тут нюансы:

1. От вас требуется развивать навыки, которые вам могут даваться с трудом. Например, умение хорошо говорить, писать или преподавать. В целом многие крутые разработчики с большим трудом справляются с такими задачами.

2. Добавьте сюда навыки звука и видеозаписи, монтажа и т.д. Ответственно заявляю - это ни разу не просто, особенно в начале пути.

3. Как ни крути - это получается вторая работа, хоть работаем мы на себя и своё имя.

По личному опыту могу сказать, что по-началу кажется, что ты двигаешь просто наугад: я не был активный пользователь соцсетей; я ничего не знал про то, что значит быть блогером; я абсолютно не понимал что мне надо делать. Первый год был примерно таким: ты не умеешь говорить, записывать звук, видео, но при этом жутко перфекционируешь и в итоге тратишь месяц на записывания одного ролика, качество которого все равно тебе не нравится, а потом наблюдаешь статистику в 100 просмотров.

❗️И тут главное не опустить руки и не сдаться. Будет казаться, что это не твоё, что это никому не нужно. Однако, спустя 4-ре года после начала доход от этой деятельности превышает в 2-3 раза доход от программирования, но и здоровья и сил также было потрачено немало.

🩶При этом стоит добавить, что изначально в моем образовательном проекте были только я и моя жена Даша. Я занимался производством контента, а продвижением и бизнес-частью Даша. Думаю, что в одного я бы просто не осилил такую работу, так что учитывайте это сразу. Сейчас у нас в команде 11 человек: дизайнер, юрист, бухгатер, команда тех поддержки, продукт менеджер... В общем уже работающий бизнес, так что я всерьез рассматриваю вариант сделать его своей единственной работой и перестать зашиваться.

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

Одним словом, выбор за вами.

Следующая часть будет заключительная, но, пожалуй, самая интересная. Чуть позже выложу 😉

Как программисту зарабатывать больше?
Часть 2

Про то, к чему приводит наличие нескольких работ мы поговорили в части 1. Рассмотрим теперь другой вариант:

Работать лучше 💪

Если в первом случае мы растим количество рабочих часов, то здесь мы растим их стоимость. С моей точки зрения - это самая правильная стратегия на долгой дистанции. Давайте разбираться почему:

1. Формирование глубоких знаний это долгий и сложный процесс. А значит и количество специалистов и конкуренция между ними обратно пропорциональна уровню компетенций.
Говоря проще: чем сильнее ваши знания, тем меньше людей способных конкурировать с вами, а значит и ваша цена растет.

2. Такой способ работы предполагает постоянные вызовы (новые задачи и опыт, постоянные сложности и нюансы). Что-что, но скучной такую работу не назовешь, а поэтому и выгорание вам не светит.

⛔️Основной минус этой схемы - это время и задачи необходимые для роста. Причем чем компетентней вы будете становиться, тем больше времени и сложностей вам понадобится, чтобы получить следующий лвл-ап. С другой стороны, это время плавно раскладывается на вашу жизнь и в моменте вы успеваете и отдыхать и работать. К тому же, с возрастом юношеская дурь и выносливость нас покидают, поэтому со временем это становится единственным способом оставаться конкурентноспособным на рынке.

Ок, а где искать такую работу? 👀

Как я писал в одном из своих недавних постов, что всегда сначала должны идти знания: никто вам не даст работу и ЗП на миллион если вы не знаете на миллион. Я прекрасно помню момент лет 10 назад, когда считал, что достиг потолка рынка и расти больше некуда. Тогда это было 250к в месяц. Более того, тогда мне казалось, что я достиг не только топа по зарплате, но и по скиллам (как бы сейчас это смешно не звучало, но добавьте к этому еще и юношеский максимализм). Разумеется, когда я погрузился в мир Computer Science; стал изучать другие ЯП и домены, то ощутил, что я не просто не дотягиваю до названной планки, но и откровенно слаб. Я снова "пошел на учебу", как бы "обнулив" свои знания.

❗️Вот почему я так топлю за базу. База как бы является фундаментом для более глубоких знаний. Т.е. условно говоря, если вы не понимаете как устроены фундаментальные структуры данных или работа с битовыми операторами, то вы просто закрываете от себя часть навыков, которые вы могли бы применить в работе. На одной из недавних открытых лекций по бинарным структурам данных я показал, что в определенных задачах бинарное представление может радикально уменьшить размер данных для хранения и передачи, а также скорость парсинга и серелизации. И это лишь один пример.

И знаете что? 😳

Это фактически перезапустило мою карьеру. По мере приобретения новых знаний я стал применять их в работе. А затем в какой-то момент обнаружил, что род моей деятельности стал совершенно другим по сравнению с типовой Frontend разработкой. То же самое происходило и с ЗП: если раньше я мог просто комфортно жить на свою ЗП, то, например, за один только 21 год я купил 3 квартиры: в Сочи, Москве и Дубае. Да, в ипотеку, но с весомым первоначальным взносом. И это все на одной только работе. И если вы думаете, что я такой один, то отмечу, что знаю много ребят, которые достигли еще большего успеха.

Если нравится тема, поддержите огнями 🔥 У нас еще будет третья часть, где обсудим еще два варианта для монетизации. Так что не переключайтесь.

💵Как программисту зарабатывать больше?
Часть 1

Да-да, именно так. Я часто пишу про рост карьеры со стороны формирования крепких знаний, но для многих куда более актуальным встает вопрос увеличения ЗП. Поэтому решил поделиться способами, которые опробовал сам, или лично видел как это использовали другие.

🥵 Работать больше.

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

❌Что НЕ ТАК в этой схеме:

1 Эта схема требует лошадиного здоровья и выносливости, ибо выгорать вы будете на ней со скоростью спички.
2 В таком подходе очень сложно подружиться с продуктовой разработкой, где вам нужно тщательное погружение в проект с решением нестандартных задач - у вас просто на этой не будет хватать времени и сил. С заказной разработкой в этом плане проще, но там возникает другая проблема из пункта 3.
3 Делая однотипные задачи вы максимум научитесь делать их быстрее, а вот новых знаний получите едва ли.

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

✅ Но, тем ни менее, есть ситуации, когда такой подход может быть оправдан:

1.1. Вы остро нуждаетесь в деньгах (болезнь ваша или родственников, первый взнос ипотеки и т.д.). Вы берете вторую работу временно, чтобы накопить нужную сумму денег. Как только накопили - сразу бросаем.
1.2. Вы рассматриваете вторую работу как более перспективную и планируете в будущем полностью перейти туда. Т.е. тут две работы скорее часть переходного периода.
1.3. Вы развиваете свой бизнес, который в дальнейшем должен стать вашей единственной работой. Я выделил это отдельным пунктом, т.к. развитие своего бизнеса штука сложная и непредсказуемая. В такой стратегии от вас потребуется максимум выносливости.

Я вероятно в своё время перепробовал множество вариаций этой схемы и сейчас фактически совмещаю работу с личным бизнесом. Я писал про это подробно в статье "как я все успеваю". Рекомендую с ней ознакомиться и, вероятно, вы поймете, что этот путь не для вас.

Дальше будет еще 2 поста о том какие есть еще варианты и кому подойдут. А пока давайте обсудим этот способ. Поделитесь комментариями своим мнением 👇🏻

🙈 Не используйте href="javascript:void(0)".

Сейчас работая с Геткурсом обратил внимание, что они активно юзают такой вид ссылок для создания псевдоссылок.

В чем же тут проблема и как я это обнаружил? Начнем со второго: я хотел перейти по ссылке и открыть её в новой вкладке, поэтом нажал на неё с зажатым Сtrl - в итоге у меня открылась вкладка с белым экраном и урлом href="javascript:void(0)". Явно не то, что я ожидал увидеть.

Ок, какие тут проблемы?

1. С точки зрения доступности ссылки должны обязательно куда-то вести: либо на другую страницу, либо на эту же, но к какому-то конкретному месту (якорные ссылки).
2. Ссылки вида href="javascript:void(0)" будут препятствовать внедрению CSP заголовков на вашем сервисе.
3. А также могут просто не работать в некоторых браузерах.
4. Если вы хотите сделать псевдоссылку, то используйте, например, <button>. Использовать href="#" тоже не надо, т.к. это также нарушение доступности и семантики.

💪 Два основных кейса для строителя.

Продолжаю вчерашнюю статью с кейсами алгоритмов/паттернов из обычной разработки. Сегодня простой пример с паттерном Строитель.

Про что этот паттерн? Он позволяет разбить создание экземпляра объекта или операцию на вызов нескольких методов. Фактически, теперь вместо одного конструктора у нас будет множество методов и один терминальный в конце.

Например:

const AppRequest = Request.useCredential.header('Content-Type', 'application/json');

const UserRequest = AppRequest.url('/user');

// Создам PUT запрос для создания пользователя
UserRequest.put({name: 'Bob', age: 42}).then(console.log);

В данном примере у нас получается два частично примененных конструктора Request, причем UserRequest за основу использует AppRequest в котором описаны базовые настройки запросов нашего приложения. А сам запрос уже создается используя терминальный метод put.

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

Второй кейс про оптимизацию. Строитель позволяет нам "схлопнуть" множество методов при создании объекта или операции в один. Например, у нас есть класс для работы с LocalStorage, но мы не хотим писать в него "на каждый чих", а предварительно подготовить данные для сохранения и сохранить их разом потом. А с другой стороны нам хочется удобства работы с таким API.

const MyStorage = KVStorage.newBucket();

// Где-то в вашем коде
MyStorage.set('key1', data1);

// Где-то в вашем коде
MyStorage.set('key2', data2);

// Где-то в вашем коде
MyStorage.set('key3', data3);

// Создаем объект хранилища, а также серелизуем данные из бакета и сохраняем "за раз"
const dataStorage = MyStorage.create(localStorage, 'myStore');

Как видите подход здесь тот же: мы разбили создание экземпляра KVStorage вместо одного конструктора на множество методов. А вот семантика первого и второго примера отличаются. В первом мы создаем частично примененные конструкторы для удобного разделения кода на части. А во втором мы накапливаем некоторый объем данных перед тяжелой операцией создания и тем самым уменьшаем количество обращений к хранилищу.

Это очень простой, но безумно полезный паттерн, который используется повсеместно. Например, присмотритесь к стандартному модулю Crypto из Node.js.

Как же реализовать Строителя? Самый простой вариант это использовать статические методы класса и классы-выражения.

class MyRequest {
    static _state = {};
    
    static url(url) {
        const newState = {...this._state, url};
        return class extends this { static _state = newState; }
    }

    static method(method) {
        const newState = {...this._state, method};
        return class extends this { static _state = newState; }
    }
    
    static create(params) {
        return new MyRequest({...this._state, ...params});
    }
}

MyRequest.url('/example').method('POST').create({body: 'my-data'});

🧐 Я неоднократно говорил, что для применения любой технологии или инструментов знания первичны.

Говоря более просто: вы сначала должны освоить что-то, чтобы потом это что-то применить. Глупо надеяться на то, что столкнувшись с какой-либо задачей вы поймете, что её нужно решать каким то правильным образом, который осталось только загуглить. Нет, я не говорю, что так не бывает - бывает, но как правило такие места ну уж очень очевидны. Например, вам нужно масштабировать изображение и вы гуглите алгоритмы. А вот видеть применимость в полутонах - тут вам и ChatGPT не поможет.

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

Вот вам простой пример. Есть у нас модуль инициализации приложения - его задача проинициализировать модули, которые должны гарантированно выполняться ДО рендера самого приложения. И вот в чем проблема: эти модули, как правило, работают асинхронно; какие-то требуют, чтобы перед ними проинициализировались другие, а какие-то можно (и нужно) запускать максимально параллельно; а еще легко допустить цикл, который приведет к появлению dead-lock.

Описываются зависимости вот так:

import { loadSession } from 'core/init/dependencies/load-session';
import { loadedHydratedPage } from 'core/init/dependencies/loaded-hydrated-page';
import { whenDOMLoaded } from 'core/init/dependencies/when-dom-loaded';

import { dependency } from 'core/init/dependencies/helpers';

export default {
  loadSession,

  // Этот модуль должен инициализироваться после loadSession
  loadedHydratedPage: dependency(loadedHydratedPage, 'loadSession'),

  // Этот модуль должен инициализироваться после всех модулей
  whenDOMLoaded: dependency(whenDOMLoaded, '*')
};

Разумеется, в реальной жизни модулей (как и связей между ними) гораздо больше. Ну и вот встает задача, как теперь сделать реализацию? Изначально мой коллега использовал отсортированный массив, который при каждом завершении инициализации модуля перетасовывался и сортировался заново. Код был очень запутанный, ненадежный и неэффективный (хотя, в этом месте это было не столь важно). Когда мне нужно было доработать этот модуль, то я столкнулся с тем, что сделать это "без костылей" не представляется возможным. Поэтому я просто написал реализацию заново. И это не потребовало много времени и кода, т.к. здесь мы имеем обычную задачу на топологическую сортировку с обработкой циклов.

Итак, я просто построил граф представляющий модули и их связи, а далее просто применил алгоритм Тарьяна и упаковал его в интерфейс итератора. Может, звучит сложно, но фактически у нас простая рекурсивная функция с раскраской посещенных узлов - кода совсем ничего. А используя интерфейс итератора мы можем написать самый обычный spread в которой проинициализировать все модули. Просто и изящно.

Promise.all(createDependencyIterator(dependencies).map(([_, {init}]) => init(appState)));

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

К чему я все это веду? К тому что не надо строить перед собой стену из аргументов: "алгоритмы не нужны", "все уже написано за нас", "нужно уметь решать только прикладное". Да, действительно часто нам не нужно самим реализовывать алгоритмы, но если вы их не знаете, то вы о них вероятно и не подумаете. А бывает, что реализовать алгоритм выходит проще, чем велосипедить своё решение.

Всем базы! 💪

В последнем релизе Chrome 131 внесены изменения для поддержки новых тегов внутри select.

На самом деле это часть подготовки к реализации обновленной спецификации HTML контролов. Т.е. да-да, вы правильно поняли, спустя столько лет наконец-то select можно будет нормально кастомизировать!
Вот, предлагаю ознакомиться со спекой и примерами - https://open-ui.org/components/customizableselect/

<select>
  <button>
    selected option: <selectedcontent></selectedcontent>
  </button>
  <option>one</option>
  <option>two</option>
</select>

<style>
  select, ::picker(select) {
    appearance: base-select;
  }
</style>

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

Если хотите посмотреть защиту курсовых работ первого и второго потоков, то переходите на сайт курса CS - https://kobezzza.ru

Скрольте в самый низ.

Только что закончилась предзащита курсовых работ на курсе по CS. Ребята показали демки своих проектов и получили обратную связь. Сама же защита будет 23-го ноября. В общем все по серьезному 🙈

Но знаете что, я ловлю себя на мысли, что из года в год студенты допускают одни и те же ошибки:

1. Откладывают разработку презентации и её прогон на последний момент.
2. Занижение своего реального труда и результата (многим кажется, что их проект плохой, хотя это совсем не так).
3. Слишком сильно распыляются: хочется сразу сделать все, но так как временя ограничено, то нужен фокус.

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

А у ребят осталась неделя, чтобы все доработать и поправить. Кто был студентом, тот подтвердит, что это еще очень много времени 💪

Тизер подкаста 🔥

🎧 Слушать аудио версию

Уф, неделька снова была безумной. Надо было успеть закончить основную работу перед отпуском, подготовить материалы к распродаже, а еще закончить работу над подкастом...
Что за подкаст? А вот сейчас расскажу и покажу.

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

VK видео - https://vk.com/video-211241500_456239067

YouTube - https://www.youtube.com/watch?v=4fetKWGAoPA

29-30 ноября у нас состоится КОСМИЧЕСКАЯ РАСПРОДАЖА!

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

Запомните эти даты - 29-30 ноября
2 дня распродажи.
Скидки от 65% до 77%.

Если вы хотели у нас что-то купить, но вам было дорого, то это ваш звездный час. Таких цен мы не давали никогда и очень возможно, что никогда уже не дадим. Это предложение которое нужно хватать и бежать… учиться!
Количество мест ограничено.
Кто успел, того и световой меч. Если вы поняли о чем я 😏

Сегодня пройдет последняя лекция на 3-м потоке CS во Frontend 💪

Даже не верится, что 9 месяцев так быстро пролетели. Но оглядываясь на проделанную работу становится даже не по себе от того, какой объем информации мы прошли: 57 лекций в среднем по 2-2.5 часа, 14 практик, 45+ домашек, 2 курсовые 🙈

Что дальше? У ребят скоро будет защита курсовых, а потом я немного выдохну и вплотную приступлю к разработке курса по Rust ❤️

🤓 ООП. Часть 8. Julia.

Продолжаю серию статей посвященных реализации ООП в разных ЯП. И сегодня на очереди Julia.

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

Итак, Пост-ОО ЯП могут сильно отличаться от языка к языку, но объединяет их то,

1. что с одной стороны они появились уже после всеобщего хайпа по ОО (как правило, это конец нулевых или десятые);
2. в них нет явно понятия объекта или оно сильно отличается от привычных ОО языков, которые используют концепции Simula и Smalltalk;
3. а с другой стороны, в них есть множества черт дизайна из ООП, и если принять некоторые оговорки, то на них можно писать в почти привычном нам ОО стиле.

Также следует отметить, что "писать в ОО стиле" можно почти в любом ЯП от С до Хаскеля. Только разница в том, что эта концепция может быть чужда ЯП, а значит никаких встроенных примитивов и элементов дизайна для этой парадигмы нет; такие программы могут работать хуже, чем идиоматические для конкретного ЯП. Поэтому у нас вырисовывается три множества ЯП по отношению к ООП:

1. ОО языки: продолжатели идей Simula и Smalltalk; есть явная сущность типа "объект"; поддержка наследования и полиморфизма подтипов. Типичные примеры: C++, Java, C#, JS, Python и т.д. Обратите внимание, что некоторые из этих ЯП не ограничиваются лишь одной ОО парадигмой.

2. Пост-ОО языки: идейные продолжатели ОО концепции; отсутствует явная сущность типа "объект" на уровне ЯП; наличие примитивов и элементов дизайна из мира ООП. Типичные примеры: Rust, Julia, Go. Обратите внимание, что эти ЯП из списка сильно отличаются друг от друга. Тот же Go можно скорее назвать процедурным, но с другой стороны там есть интерфейсы, обобщенное программирование через дженерики, инкапсуляция данных и поведения (структуры и методы), встраивание (аналог наследования).

3. Языки без поддержки ОО. Тут все просто: писать в ОО стиле в таких ЯП может и можно, но это будет просто неудобно и не эффективно.

Итак, введение закончилось и можно приступить к основной теме, к Julia. У Julia очень интересные предки и мотивы появления.

1. С одной стороны проект задумывался как аналог Python для научных вычислений и машинного обучения, но быстрый "из коробки": т.е. отсутствует необходимость в переписывании отдельных модулей на С или использования нативных библиотек.
2. С другой стороны, Julia впитал в себя черты R и Matlab.
3. Очень сильно в Julia чувствуется влияние ФП языков, и даже присутствует очень гибкая система макросов и рефлексии в стиле Lisp.

С другой стороны Julia не отрицает другие ЯП: вы можете совместно использовать библиотеки на С, Fortran и даже Python. Причем делается это ну очень просто.

Ок, но мы тут говорим про ООП. Как с этим в Julia? Необычно. С одной стороны у нас есть:

1. Структуры и кортежи в стиле C или Rust. Позволяют нам объединить множество данных в рамках одного типа с ассоциативным доступом. В каком сегменте памяти хранить такие структуры решает компилятор в зависимости от ситуации.
2. Абстрактные типы с поддержкой наследования. Позволяют нам выстраивать иерархию типов и использовать их для полиморфизма. При этом наследования для не-абстрактных типов у нас нет.
3. Объектом в Julia является функция, а методами - конкретные реализации функции (перегрузки). Без паники, сейчас объясню. В Julia мы можем создать одну и туже функцию, но с разным количеством аргументов, или аргументы будут отличаться по типам.

function foo()
  42
end

function foo(a:: Int32)
  a + Int32(10)
end

function foo(a:: Int64)
  a + 100
end

# 42
foo()

# Int32(20)
foo(Int32(10))

# 200
foo(100)

Это очень похоже на перегрузки из Java, только более могущественные. И получается, что если я хочу сделать структуру и дать ей реализацию, то я просто описываю нужные мне функции.

struct User
  name:: String;
  age:: UInt32;
end

function getName(user:: User)
  user.name
end

function getAge(user:: User)
  user.age
end

bob = User("Bob", 42)

getName(bob)

Выходит, что методом структуры является функция-перегрузка под конкретный тип. В Runtime для типа User будут созданы свои версии функции. Это похоже на подход с мономорфизацией из С++ и Rust.

4. Можно заметить, что Julia из коробки поддерживает большой набор встроенных числовых типов, но только числами тут все не ограничивается. ЯП поддерживает разные кодировки для строк (по умолчанию UTF-8), массивы, матрицы, вектора и много чего еще. Стандартная библиотека тут впечатляет.

5. В языке динамическая типизация, но есть возможность использовать явное аннотации типов. Эти аннотации будут использоваться не только для статического анализа, но и для оптимизации компилятором.

6. Программы Julia можно запускать без предварительной компиляции и она будет делаться в момент работы программы (JIT), либо явно скомпилировав и запускать бинарный файл.

7. В языке используется интересная сборка мусора на основе Mark&Sweep сборщика и механизмов на основе статического анализа кода.

При этом ЯП имеет очень хорошую поддержку ФП парадигмы: все операторы - это функции; все (или почти все) есть выражение и т.д.

Можно подытожить, что Julia на первый взгляд достаточно далека от привычных нам ОО языков, но с другой стороны она использует многие элементы дизайна из мира ОО. Чем еще не один пример эволюции парадигм в языках? ФП с дружелюбным лицом, знакомый ОО, но без его недостатков. Красота!

Привет, ребят! Собрали список постов за октябрь:

🎙 О личном
35 лет! Спасибо, что со мной! 🥳: Немного о планах и благодарностях в день рождения!

🤖 ИИ и продуктивность
• Сквозь дебри TypeScript вместе с ChatGPT: небольшая заметка про то, как электронный помощник помог мне написать UnionToTuple.
Как AI делает мою работу проще и эффективнее: Личный опыт использования AI-инструментов для документации, работы с данными и автокомплита.

🧑‍💻 Продолжаем серию постов про ООП
Часть 7. Rust: Разбираем объектно-ориентированные черты Rust и его отличия от классического ООП.

💡 Обновления языков и платформ
- CPython 3.13: долгожданное ускорение: Новая версия с поддержкой JIT и отключением GIL — шаг к повышению производительности Python.
- Deno 2.0: поддержка NPM и совместимость с Node.js: Вышел релиз с поддержкой NPM, популярных фреймворков и улучшенной совместимостью.
- Node.js 23.0: стабилизация TypeScript и новые API: Node.js 23.0 добавляет стабильную поддержку TypeScript, синхронную загрузку ESM, WebStorage и SQLite API.

🎓 Курсы и обучение
- Курс «Инфраструктура Frontend» открыт для записи!: Погрузитесь в инфраструктуру с акцентом на Frontend-задачи: CI/CD, Docker, Kubernetes. Старт 3 декабря.
- Как я оказался в DevOps и почему это стало точкой роста: История о миграции инфраструктуры, которая привела меня к DevOps и открыла новые перспективы.

🔧 Технические советы и оптимизация
- Как мы интегрируем TypeScript трансформеры в проект для оптимизации Vue-компонентов: Делюсь опытом интеграции TS трансформеров для работы с Vue и оптимизации кода.
- Как избежать ошибок в старых браузерах с помощью eslint: Как настройки eslint помогают избежать багов на старых версиях браузеров.

🙈 Последние 2 недели были оч нагруженными, но и продуктивными: мы записали новый подкаст и скоро его выложим; новая открытая лекция; завершающая часть на курсе по CS и подготовка к курсу по инфре; а еще ко мне в гости приезжали друзья и мы гоняли на пару дней в горы. В общем, если вам показалось, что я куда-то пропал, то это не показалось 😄

Планирую на этой неделе написать давно обещанную статью по Julia и подход там к ОО, а сегодня хочу поделиться прикольным кейсом с работы.

КЕЙС

Для начала небольшая вводная часть: основная часть сервиса Едадил - это работа внутри нативного суперапа. Каждый из наших разделов внутри: поиск, кешбеки, купоны и т.д. - это отдельный миниап (или микрофронтенд, если угодно). Каждый такой миниап собирается как отдельный HTML файл в который уже проинлайнены скрипты и стили.

Такой подход позволяет мобилке легко скачивать все связанные ресурсы за один запрос на локальную ФС и дальше при необходимости уже работать автономно. На самом деле, здесь еще и менее очевидные плюсы: отсутствие дополнительных запросов за статикой позволяет лишний раз не дергать диск, который на многих мобильных устройства весьма убитый. Но есть и обратная сторона - со временем приложение становится больше и больше, и если средний сетевой канал позволяет достаточно быстро выкачать апдейты (gzip всех спасает), то вот фаза "компиляции" на старте становиться уже слишком большой.

И вот мы в ситуации, когда просто "попилить" приложение на ассеты не получается, из-за создаваемой нагрузки на диск. А с другой стороны у нас образовалось огромное бутылочное горлышко на стартовой фазе парсинга JS/CSS. Ситуация как будто патовая.

И вот несколько недель назад я стал думать, а как бы можно было это полечить, причем желательно без огромных вложений в разработку. И к моему удивлению я почти сразу придумал весьма простое, но изящное решение. Нам нужно написать плагин к Webpack, который бы все ассеты, спрятанные за вызов import() подгружал бы в HTML не через тег script, а через template. Особенность template в том, что его содержимое как-бы игнорируется браузером, а значит и нет фазы парсинга. Далее, наш плагин при первой загрузке такого ассета через import() создает на основе его содержимого Blob, делает на него ссылку через URL.createObjectURL, а затем мы уже монтируем его как script.

Такой подход позволяет нам сделать небольшой критический js/css, а все остальное парсить по требованию. С другой стороны первый вызов import() будет замедляться из-за необходимости выполнения парсинга, но как будто профит от улучшения старта должен все нивелировать.

В общем сгрузил своим бойцам идею и пошел заниматься другими задачами. И вот на прошлой неделе ребята сделали MVP и лонгтаска на старте уменьшилась на 40%! Да, для прода решение еще нужно потюнить и потестить. Но уже понятно, что решение крайне эффективное и весьма простое (ведь Webpack позволяет такие штуки).

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

Всем базы!

😱 Еще два часа и цена вырастет на 10 000 руб.

Я успею
Я с вами

⏰ Осталось 5 часов до повышения цены на курс «Инфраструктура Frontend»

Что важно знать о курсе:

1. Над содержанием курса мы работали с Димой вместе и я всегда держу руку на пульсе во время курса, потому что это и моя репутация и моя школа и тут все должно быть на высоте.

2. Дима прекрасно объясняет и хорошо структурирует информацию. Особенно доходчиво говорит для начинающих специалистов. Он буквально за руку вас ведет через весь курс. Всегда на связи в чате. Если нужны доп лекции и занятия - всегда идет на встречу. У нас нет ни одного возврата на курсе по Webpack, который вел Дима год назад и абсолютное большинство выпускников после окончания курса высоко отметили манеру преподавания.

3. Курс практический. Это значит, что помимо ДЗ, у вас еще будет возможность отрабатывать полученные навыки на тестовом проекте в GitLab, который мы специально оплатили для вас на период курса. И да вы можете задавать вопросы и по своим рабочим задачам и пет проектам, Дима вам обязательно поможет.

4. Каждый наш курс это квинтэссенция полезной информации, которая необходима для широко кругозора Frontend инженера и знания, которые мы передаем, выстраданы в первую очередь из опыта работы. По этой же причине курс веду не я, а Дима, потому что именно он сражается с инфраструктурами задачами каждый день вот уже 4 года и кому как не ему знать все тонкости.

5. Диму в команду Kobezzza.Lab я пригласил сам, так как уверен в нем как в специалисте и потому что он обладает той экспертизой, которой у меня нет в нужном объеме. Специалисты по инфраструктуре всегда на вес золота в команде и таких специалистов не много. Поэтому считаю цену на курс совершенно оправданной и справедливой, и рад, что Дима согласился поделиться с вами своей экспертизой.

6. Цена на курс сейчас с учетом рассрочки всего 10 000 руб./мес при условии рассрочки на 6 месяцев. Мы предоставляем рассрочку для любой страны. Чтобы узнать подробнее пишите в бот - https://t.me/Kobezzza_bot

7. Вы будете учиться в очень сильном окружении. Уже сейчас на курсе ребята из таких компаний как Сбертех, Росбанк, Райфайзенбанк, Яндекс Беспилотники, Яндекс Фантех, Doc Doc, Едадил, Авито и другие.

8. Все лекции и созваны будут в Лайве, но запись, конечно же, будет. Можете смотреть в удобное время или в своем темпе. Доступ к материалам курса до 1 мая 2025 года, позже можно его продлить еще на год. Чат с участниками у вас навсегда. К слову чат Webpack до сих пор жив и многие им пользуются.

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

10. Это последний курс в этом году и в ближайшие полгода. Следующий будет Сборка в апреле и Rust в сентябре. Еще планирую Typescript сделать расширенный и несколько интенсивов. На этом в общем-то все на следующий год.

11. При оплате без рассрочки, мы вернем кэшбэк 3000 кобеззза бонусов, которые можно потратить на любые другие продукты от нас.

Сайт курса - https://kobezzza.ru/infrastructure

Если остались вопросы, задавайте в комментариях или в бот.

Увидимся на курсе!

😲А бывало ли у вас такое, что код собрали. протестили, задеплоили, а потом у пользователей в старых браузерах летят ошибки?

Вроде бы сборка должна это учитывать, но что-то все равно пошло не так. 😒

Написали для вас статью как с помощью простого советского... Как с помощью (внезапно) eslint можно починить эту проблему 👇

https://teletype.in/@kobezzza/aC5xBRbLOk0

Ну сегодня то точно Хэллоуин уже? Можно анекдоты травить? 😏

🤩 Отзывы с пылу с жару. Завтра все, кто регистрировался получат письмо на почту с инструкцией как посмотреть запись. Ну а кто не в первый раз, то у вас запись появится в личном кабинете на GetCourse.

Это было 3 час хардкора! 🙈💪 Всем спасибо, кто был! ❤️

Уже начинаем, жду вас на вебе!

Через 40 минуток начинаем! 💪 Ссылка на трансляцию должна была прийти вам на почту. Ну а если не пришла, то пишите в комментарии и мы поможем 😉

А сегодня Хэллуин что ли? Тогда у меня для вас анекдот 😀

UPD: оказалось завтра, тогда завтра расскажу 😂

Ну что же, вот и среда, а значит сегодня в 19.00 пройдет очередная открытая лекция!

Напоминаю, что сегодня у нас будет тема посвящена "Сегментам памяти программы". Тема важная и нужная для тех кто хочет глубже понимать как работает их программа и как писать код, чтобы он лучше работал.

В программе у нас будет теория с презентацией и live-coding секция, где мы напишем свой стек и кучу на JS. Ну и конечно ответы на ваши вопросы 😉

В общем всех жду!

PS: для посещения лекции нужная регистрация - https://kobezzzalab.ru/segmentsveb

Kobezzza. База в программировании pinned «🔥 Сегодня открытый урок “Сегменты памяти программы”! 🔥 📅 30 октября в 19:00 (МСК) ✍🏻 Вот что тебя ждет: - Разберем анатомию программы: стек, куча, text, rodata, data, bss — узнаешь, как все это работает. - Память в многопоточных программах: и посмотрим…»

🔥 Сегодня открытый урок “Сегменты памяти программы”! 🔥

📅 30 октября в 19:00 (МСК)

✍🏻 Вот что тебя ждет:

- Разберем анатомию программы: стек, куча, text, rodata, data, bss — узнаешь, как все это работает.

- Память в многопоточных программах: и посмотрим, как это реализовано в JavaScript.

- Реализуем свой стек и кучу на ArrayBuffer: покажем, почему говорят, что стек быстрее кучи, и в чем конкретно это проявляется.

- Альтернативные подходы: узнаешь про языки, где вообще нет кучи или стек заменен регистрами.

Урок больше теоретический, но если ты хочешь попробовать Rust или C, то для тебя это станет отличной практикой.
🤩И да, будем много лайвкодить!

❗️Все бесплатно, с тебя только регистрация. Запись будет у тебя в твоем ЛК на Getcourse.

🥳 Наконец то стало доступно моё выступление с последнего CodeFest!

Лекция посвящена теме парсерных комбинаторов. Рекомендую ознакомиться 😉

https://www.youtube.com/watch?v=xVYPe83tOUc

🧐 В недавней открытой лекции с Димой Холстинином я сказал, что сейчас активно интегрирую TS трансформеры к нам в проект. И вот сейчас хочу рассказать о том, что сделал сейчас и какие планы вообще.

Но для начала разберемся, что вообще такое TS трансформеры. Ну смотрите, у нас есть ЯП TypeScript: фактически, этот тот же JS, но в который добавили возможность явного описания типов + некоторые новые Runtime конструкции по типу Enum, Namespace и т.д. Т.к. нативно TS код исполнятся в браузере не может, то его надо предварительно транслировать в программу на JS. Делается это с помощью отдельных инструментов: TSC, ESBuild, SWC и т.д. Некоторые из этих инструментов просто трансляторы (ESBuild, SWC), а некоторые уже являются компиляторами (TSC).
Отличие компилятора от транслятора в том, что компилятор еще проводит статический анализ кода и может делать различные оптимизации.

Так при чем тут трансформеры? Большая часть этих инструментов работает через предварительное построение AST по коду, а затем уже последовательное применение операций трансформации этого AST, после чего конечный вариант обратно сериализуется в строку (программу на JS). В недавней лекции Дима как раз про это рассказывал. И вот некоторые инструменты, такие как TSC или Babel позволяют добавить свои функции трансформации AST в общий флоу компиляции. Таким образом мы можем расширить наш ЯП новыми прикольными возможностями.

Итак, я буду говорить о наших кейсах использования TS трансформеров для TSC и Webpack ts-loader.

1. Мы используем ОО подход для описания компонентов приложения и мы используем Vue, который из коробки такой подход не поддерживает.
2. Чтобы подружить ужа с ежом мы используем подход с построением DSL на классах. DSL описывается с помощью декораторов и механизмов рефлексии.

@component({functional: true})
class bInput extends iBlock {
    @prop(String)
    value: string = '';
    
    @field((ctx) => ctx.sync.link('value'))
    valueStore: string;
    
    submit() {
        // ...
    }
}

Мы используем классы и декораторы, чтобы сформировать так называемый мета-объект компонента. Он содержит в себе набор всех входных параметров компонента, полей, методов и т.д. А далее мы просто создаем компонент уже используя нашу библиотеку компонентов (Vue). При этом получается, что сам экземпляр класса не используется.

И вот тут как раз возникают сложности:

1. Чтобы извлечь дефолтное значение свойства, нам придется все равно создать экземпляр класса, что не бесплатно.
2. Если мемоизировать создание экземпляра, то для объектных значений придется предусмотреть клонирование значений.
3. Для кейсов с override свойств без явного использования декораторов также возникают проблемы.
4. Чтобы получить набор методов/аксессоров у класса, надо в Runtime использовать методы рефлексии по типу Object.getOwnPropertyNames, что также не бесплатно.

И вот как раз, чтобы исправить все эти проблемы я стал использовать TS трансформеры. Что в итоге я сейчас реализовал.

1. Все значения по умолчанию автоматически добавляются в декоратор @defaultValue.

@component({functional: true})
class bInput extends iBlock {
    @prop(String)
    value: string = '';
    
    @field()
    valueStore: string = this.sync.link('value');
}

=>

@component({functional: true})
class bInput extends iBlock {
    @defaultValue('')
    @prop(String)
    value: string = '';

    @defaultValue(function () { return this.sync.link('value'); })
    @field()
    valueStore: string = this.sync.link('value');
}

А значит больше создавать инстанс класса не нужно вовсе.

2. Все методы и акссессоры автоматически получают декоратор @method

@component({functional: true})
class bInput extends iBlock {
    submit() {
        // ...
    }
    
    get foo() {
        // ...
    }
}

=>

@component({functional: true})
class bInput extends iBlock {
    @method('method')
    submit() {
        // ...
    }

    @method('accessor')
    get foo() {
        // ...
    }
}

Таким образом для сбора информации о методах больше не нужна рантайм рефлексия.

В будущем я планирую вообще отказаться от использования декораторов в runtime и сразу генерировать финальный мета-объект на этапе компиляции. И это уже фактически техника статической компиляции кода, т.е. часть кода выполняется не в Runtime, а на этапе компиляции, а в конечной программе мы видим уже результат. Такого рода оптимизации давно используются во многих ЯП: C/C++, Rust, Nim и т.д. И теперь мы можем делать это и в TS.

Использование трансформеров открывает огромные возможности для увеличения выразительности и эффективности кода. У меня в планах есть перевыпуск моего интенсива по ТС в формате миникурса, где я подробно расскажу о том как писать такие трансформеры.

Всем базы! 💪

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

Кто хотел послушать про "Побитовые операции", то не переживайте - проведем как-нибудь потом.

Итак, про что же будет лекция:

1. Обсудим анатомию программы по существующим сегментами памяти: стек, куча, text, rodata, data, bss и т.д.

2. Обсудим организацию памяти в многопоточных программах и посмотрим как это реализовано в JS.

3. Реализуем свой аналог стека и кучи на основе ArrayBuffer и поймем почему же "стек быстрее кучи" и "где именно быстрее".

4. Обсудим альтернативные реализации: например, есть ЯП где нет кучи или вместо стека используются регистры.

В целом можно рассматривать данную лекцию как теоретическую (хотя мы будем много live-кодить), но если посмотреть на неё под углом того, что вы хотите попробовать Rust/C, то она превращается в практическую 😄

В общем 30 октября, 19.00, всех жду.

Ссылку на регистрацию скину потом отдельно.

PS: кто не смотрел мою лекцию по работе с типизированными массивами, то стоит глянуть предварительно.

Мне тут подарили на ДР проигрыватель для винила. Сегодня подключил к колонкам, включил оригинальную пластинку The Beatles - Rubber Soul. Какой же кайф! Прям эстетическое удовольствие ❤️

Я ретроград или это правда оч круто? 😄

Сегодня завтракали с Дашей и я рассказал ей историю, как в 15 году работал в стартапе и нам потребовалась помощь по миграции с Heroku на AWS.

В те дни я практически не имел никаких знаний в области DevOps и когда я стал разбираться, то в момент словил легкую панику! Столько новых инструментов: Docker (его я на базовом уровне знал), Packer, Ansible, Terraform, Docker Swarm, Kubernetes... И самая большая проблема, что из-за обилия нового было сложно даже понять, что нам конкретно нужно, а что нет.

Мы решили обратиться к аутсорс компаниям, которые занимаются DevOps и нам выкатили счет толи на 2, толи на 4 миллиона за настройку всей инфры! Меня тогда от этого нехило бомбануло, т.к. я подсознательно чувствовал, что наша задача была намного проще и явно не стоила таких денег. В итоге мы нашли через знакомых человека, который адаптировал флоу со своей текущей работы для нас, но выглядело это как "Пизанская башня из говна и палок". Чтобы это все не рухнуло мы наняли потом человека на постоянку, который стал постепенно рефакторить нашу инфраструктуру.

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

Самостоятельно разобраться я не смог и в итоге пошел на курсы по DevOps и сейчас понимаю, что это было правильным решением. Курсы сняли главную проблему - туман войны. У меня сложилось понимание: что делает каждый из инструментов, когда оно нужно и как это использовать вместе. А дальше уже вектор движения стал понятен.

К тому же все это происходило почти параллельно с увольнением человека, который отвечал за инфру и вся эта ответственность легла в команде на мои плечи, пока к нам не пришел Дима Холстинин. Так что считай знания сразу же закреплялись на практике.

К чему я все это веду? Не надо ждать пока клюнет жареный петух. А с другой стороны, я не вижу на рынке подвижек по поводу того, что в мире FrontOps стало больше специалистов. Их по-прежнему очень мало и это в лучшем случае пара человек на всю команду. А в худшем - ни одного, и все работает на "скопированных" из StackOverflow ответов и ChatGPT. Так что для вас это может быть точкой роста.

Но это еще не все! На прошлой неделе мы анонсировали новый курс: Инфраструктура во Frontend.

Курс разбирает темы: статического анализа кода (включая отдельную лекцию по внутренней архитектуре ESlint и разработке своих плагинов); работа с Node.js пакетами; настройка CI/CD; Docker и Kubernetes; деплой и мониторинги. В общем такой FrontOps если угодно. Подробнее тут https://kobezzza.ru/infrastructure

Также можно ознакомится с открытой лекцией "Статические проверки кода и их оркестрация", которую мы проводили на прошлой неделе. Она как раз создана на основе материалов с курса.
Для просмотра надо просто пройти бесплатную регистрацию - https://kobezzzalab.ru/codes

А самое главное: курс можно оплатить от работодателя! И мы даже приготовили специальную презентацию.

🙃 Ну, как говорится, всех с понедельником!

Расскажу про планы на эту неделю: хочу написать новую статью из цикла ООП и разобрать ЯП Julia, а также хочу рассказать о прикольных кейсах использования TS-трансформеров (я как раз сейчас на работе начал их активное использование).

А 30-го октября планирую провести новую открытую лекцию. Выбираю из двух возможных тем:

1. Практическое пособие по использованию побитовых операторов в JS.
2. Сегменты памяти программы. Своя реализация стека и кучи на JS.

Какая тема вам больше нравится? Также можете накидать в комментарии свои предложения.

Мне сегодня 35! 🥳

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

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

В общем, друзья, хочу сказать спасибо вам! Спасибо, что однажды подписались на меня. Спасибо, что не отписываетесь, если моё мнение не совпадает с вашим. Спасибо, что выбираете мои образовательные программы. Спасибо! ❤️

PS: Знаете какой подарок мне подарила Даша? Точно не угадаете 🙈. 28 ноября я совершу полет в невесомости: вылет с аэродрома на специальном самолете, на котором тренируются астронавты и в течение часа я смогу ощутить это удивительное чувство. Я в предвкушении, но естественно один без Даши не полечу 😂.

Kobezzza. База в программировании pinned «🚀Курс "Инфраструктура Frontend". Продажи открыты! Знание инфраструктуры и умение её настраивать — это отдельное направление в разработке. Вам не обязательно заниматься типовой продуктовой разработкой — можно стать специалистом по инфраструктурным задачам.…»

🚀Курс "Инфраструктура Frontend". Продажи открыты!

Знание инфраструктуры и умение её настраивать — это отдельное направление в разработке. Вам не обязательно заниматься типовой продуктовой разработкой — можно стать специалистом по инфраструктурным задачам.

Это включает:
• настройку инструментов статического анализа кода,
• сборку,
• развертывание тестовых сред,
• деплой,
• автоматизацию процессов (прехуки, CI/CD),
• и многое другое.

Количество задач здесь велико, и наш курс научит вас их решать.

📌 О курсе

Мы спроектировали курс максимально практическим. Все лекции посвящены решению конкретных проблем инфраструктуры. Он рассчитан на тех, кто хочет повысить свои компетенции, либо уже занимается инфраструктурными задачами.

Важно отметить, что курс ориентирован именно на Frontend разработчиков. Все примеры и задачи связаны с реальными проблемами, с которыми сталкивается Frontend. Например, мы рассмотрим реализацию BFF для SSR, Docker, Ansible и Kubernetes — все с позиции типичных задач.

Как будет проходить курс:

• Старт курса: 3 декабря
• 2 лекции в неделю: вторник и четверг, 19:00 МСК
• Каждые 2 недели по воскресеньям: разбор домашних заданий и ответы на вопросы

Чего на курсе не будет?

Мы не будем углубляться в сборку. Этому посвящен отдельный курс, который планируется на май 2025 года.

Вышла новая версия платформы Node.js 23.0

Из интересного:

1. Стабилизация режимов --experimental-strip-types и --experimental-transform-types для поддержки TS.
2. require теперь можно использовать для загрузки ESM модулей в синхронном режиме без необходимости использовать top await import.
3. Использование ESM модулей теперь не требует специального расширения или флага в package.json.
4. Добавлен API WebStorage, который предоставляет временное хранилище типа ключ-значения как в localStorage/sessionStorage.
5. Добавлен API SQLite.
6. Добавлена опциональная поддержка кэширования скомпилированного кода на диске для существенного ускорения запуска модулей.
7. Движок V8 обновлён до версии 12.9, применяемой в Chromium 129.

В целом релиз очень годный. Особенно радует движение по синергии CommonJS и ESM модулей.

У нас все готово, встречаемся через 15 минут на уроке 🙌🏻

Ссылка на вход у вас на почте. Не забудьте проверить спам и рассылки ❗️

Если возникнут трудности со входом, пишите в комментарии к этому сообщению. Ребята из моей команды вам оперативно помогут.

Ребят, последнее напоминание: сегодня в 19.00 пройдет открытая лекция по инструментам статического анализа кода и их оркестрации.

Чтобы попасть на лекцию нужно предварительно зарегистрироваться (это бесплатно) - https://kobezzzalab.ru/codes

Также, сегодня расскажем про грядущий курс по инфраструктуре и откроем продажи.

Будет интересно! Всех ждем!

🧐 Как я использую AI инструменты в работе?

Инструменты основанные на методах машинного обучения и AI уже несколько находятся на вершине хайпа в IT отрасли. Нас уверяют (особенно стараются в компании Nvidia), что программисты скоро не будут нужны вовсе, т.к. все сможет сделать искусственный интеллект. Кто-то после таких заявлений впадает в легкую панику, а кто-то скептически покачает головой и пойдет работать дальше.

Я не буду пытаться предсказать будущее, хотя признаюсь, что я пока скорее скептик. Но вот чего точно не стоит делать, так это отгораживаться от новых технологий. Дело в том, что когда я попробовал тот же ChatGPT, то он практически мгновенно заменил для меня поисковую систему: ему можно задать вопрос в свободной форме и получить конкретный ответ. Вот из недавнего: я спросил как в TypeScript преобразовать размеченное объединение в кортеж и получил сразу снипет с кодом и его объяснением. Да, это решение можно найти и "классическим" способом через поиск, но с ChatGPT это становится намного удобнее.

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

1. Генерация документации по скелету: я пишу короткое описание того, что делает модуль/класс/функция и прошу ChatGPT сгенерить "нормальное" описание. Удивительно, но ChatGPT не только формирует текст в читаемом виде, но и часто добавляет важные пункты, которые я упустил. Также, он прекрасно справляется с переводом на английский и написание такой документации становится очень простой.

2. Генерация имен переменных и других идентификаторов. Признаюсь, для меня придумать емкое название часто становится очень сложной задачей: я либо скатываюсь в atob/btoa, либо в convertUserStructureToCustomFormat. А вот ChatGPT справляется с этим играючи. Ему можно просто сказать что делает сущность или предложить свои варианты, а дальше он сгенерирует наиболее подходящие имена. Очень экономит время.

3. Операции с текстом. С недавнего времени я полюбил использовать ChatGPT для задач, где надо взять какую-нибудь CSV и сформировать отчет по ней/преобразовать к другому формату. Если раньше я почти сразу начинал писать AWK скрипт для таких вещей, то теперь можно отдать файл ChatGPT и в свободной форме попросить сделать что-то. Сразу скажу, что не всегда получается и писать "по старинке" тоже приходится, но для простых сценариев работает отлично.

4. Генерация бойлерплейта для тестов. ChatGPT можно попросить сгенерить "скелет" для тестирования того или иного модуля. Весьма удобно.

5. Автокомплит в IDE. Да, тут уже зависит от интеграции с IDE, но как только в том же WebStorm добавили статически обученную модель для автокомплита, то процесс написания кода стал намного удобнее.

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

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

Всем базы! 💪

Привет, инженер!

Представь: ты пишешь код, а проверка его качества идет на автомате. Звучит круто, да? Андрей Кобец и Дима Холстинин расскажут как это сделать на бесплатном вебинаре “Статические проверки кода и их оркестрация”!

🔧 О чем поговорим:
• Какие существуют статические проверки кода во frontend и чем они могут быть полезны
• Самые популярные инструменты для статических проверок и их альтернативы
• Существующие варианты запуска проверок и инструменты для управления запуском

Будет не скучно! Обсудим все на реальных примерах.

🎁 Кстати, приготовили для тебя интересные новости и приятные бонусы!

⏰ Когда: 16 октября в 19:00
📍 Где: Ссылка придет на почту после регистрации.
🔗 Регистрация: по ссылке в шапке профиля

Не пропусти! Запишись и приходи, обещаем, код станет легче 😎

Обняли, приподняли 🤗
Команда Kobezzza.Lab

Курс «Инфраструктура Frontend»

Больше года мы носили в себе идею о том, каким должен быть этот курс, на чем будет строиться практика, как все это организовать, и вот мы готовы вам его презентовать 🎉

Нужно сказать, что знание инфраструктуры и умение её настраивать - это считай отдельное направление в разработке. Да-да, вам совсем не обязательно заниматься типовой продуктовой разработкой, а можно взять на себя роль человека, который занимается инфраструктурными задачами.

К таким задача можно отнести:

▫️настройку инструментов статического анализа кода
▫️сборка
▫️развертывание сред для тестирования
▫️деплой
▫️автоматизацию процессов (прехуки и CI/DI) и многое другое.

Курс проектируется именно для Frontend разработчиков, т.е. все рассматриваемые на курсе проблемы так или иначе связаны с Frontend, например, реализация BFF для SSR. Docker, Ansible, Kubernetes на курсе будут также рассмотрены с позиции типовых решаемых задач.

🔺Когда презентация?

🗓️16 октября в 19:00 (после открытой лекции)

🔺Что будет?

1. Непосредственно лекция «Статические проверки кода и их оркестрация».
2. Расскажем о курсе, домашках и как строится обучение.
3. Откроем продажи по самой низкой цене.

🤑Тем кто будет на лекции мы дадим возможность зафиксировать самую низкую цену на курс на весь период продаж.

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

‼️ Все что от вас сейчас нужно, это зарегистрироваться на открытый урок 16 октября 👇🏻👇🏻👇🏻

Зарегистрироваться
Зарегистрироваться
Зарегистрироваться

🧐 Вышла новая версия платформы Deno 2.0.

Среди заявленных изменений:

1. Реализована обратная совместимость с Node.js и NPM. И вот с NPM, на мой взгляд, изначально было совершенно странное решение: его просто не было, как и не было альтернатив. Утверждалось, что надо просто ставить пакеты с Github, а чтобы не боятся удалений - форкать. Брр. Теперь поддержка NPM есть.

2. Добавлена поддержка package.json.

3. Добавлена поддержка популярных JavaScript-фреймворков, таких как Next.js, Astro, Remix, Angular, SvelteKit и QwikCity.

4. Добавлена поддержка рабочих пространств npm (workspace) и моно-репозиториев (monorepo) с раздельной обработкой зависимостей.

И много чего по мелочи. В целом релиз выглядит, как осознание и исправление изначальных ошибок.

Несмотря на то, что я отношусь к этому проекту скорее скептически, но он оказывает благоприятное давление на Node.js. Например, не так давно в Node была добавлена поддержка TypeScript из коробки, а ведь изначально это и было одной из фишек Deno.

А вы что думаете?

https://youtu.be/52yhBkkulXw?si=uIIjX3HI6T8WFUDt

Ютуб кинул в рекомендации. Получил огромнейшее удовольствие! Рекомендую к просмотру

🥳 Очередная открытая лекция пройдет 16 октября в 19.00!

В этот раз поговорим про инструменты статического анализа кода, а также как их можно и лучше запускать. Рассмотрим разные сценарии: во время разработки, проверки на прехуках, проверки в CI. Лекция будет полезна всем, кто хочет лучше разобрать об инфраструктуре "вокруг" вашего кода.

Как и в прошлый раз лекцию буду вести я и мой коллега Дима Холстинин. Доступ бесплатный, но нужно пройти предварительную регистрацию - https://kobezzzalab.ru/codes

По времени также планируем на часа 1.5-2. Ждем всех - будет интересно!

Вышла новая версия эталонной реализации Python - CPython 3.13.

Релиз достаточно интересный.

1. Добавлена экспериментальная поддержка JIT. Давно ожидаемая фича, которая уже имеется в альтернативных реализациях Python - PyPy, Pyston, GraalVM Python и т.д. В первую очередь JIT должен помочь на задачах связанных с обработкой данных и ML.

2. Экспериментальный режим отключения GIL. Если кратко, то в CPython Python код, который работает в потоке будет выполняться все равно последовательно. Говоря проще, то в один момент времени у нас выполняется только один набор Python инструкций. Это защищает от множества проблем возникаемых при параллельных вычислениях, но и ограничивает возможную производительность многопоточных программ.

Эти два пункта направлены на улучшение проблем с производительностью. Но такая ли это проблема? Дело в том, что в CPython изначально применялась парадигма: Python - это просто DSL для C. Там где вам нужен перф - вы должны писать модули на C и удобно интегрировать их вместе. И многие популярные Python библиотеки (например, NumPy) фактически являются библиотеками на C.

Но с другой стороны, такая вот потребность "переписывания" с простого и удобного Python на более сложный C многих раздражала. В конце концов язык Julia появился от мотивации: давайте сделаем Python, который не надо будет переписывать на С. Но и альтернативные реализации Python также искали способы ускорения работы самого интерпретатора.

Так что эти нововведения кажутся логичными и долгожданными.

В том то и дело что нет. Эти детали определяют контракты самого ЯП.

Думаешь почему в Java Double не типобезопасный тип, а Object - типобезопасный?

Ровно по причине, что объект всегда спрятан за указателем, размер которого соответствует битности системы. А Double всегда занимает 64 бита и на 32-битных системах это просто нельзя сделать атомарно без блокировок.

Или, другой пример. Я не могу передать null в Java там, где ожидается, например число.

Почему? Да потому что null - это объект и также является указателем. А число будет занимать размер согласно своему типу.

И так в каждом ЯП! Эти нюансы определяют дизайн.

И в Rust нет понятия объекта. Не потому что "какая то философия", а потому что реально нет такого типа, как и связанных с ним контрактов.

Но есть многие черты ОО языка. И получается, что "физически" объектов нет, но многие черты - есть.

Поэтому я и отнес его к ПостООП.

В Julia/Go тоже нет объектов, и эти языки сильно отличаются друг от друга, но там также есть черты от ООП.

Именно это я и разбираю.

🤓 ООП. Часть 7. Rust.

Меня несколько раз спрашивали подписчики, считаю ли я, что ООП как парадигма умирает?

Давайте я сразу отвечу на этот вопрос - нет, ОО по-прежнему очень актуальна. Хотя бы потому, что самые популярные в мире ЯП полностью или частично можно отнести к ОО парадигме. Хоть в ту же Java и добавили кучу физ из ФП, но классы и ОО по прежнему остаются главным структурным блоком этого ЯП. Более того, у нас вышло несколько новых ЯП с привычной ОО моделью, которые несмотря на свой юный возраст уже заняли свою значительную нишу. Речь тут, разумеется, идет про Kotlin и Swift.

Так что оставить панику. ОО сейчас актуальна, как и 30 лет назад. Но в ОО действительно есть много недостатков, которые закрываются паттернами. А в новых ЯП у нас появляется возможность взять самое лучше из мира ОО, но не брать плохое. Так и образовался пласт языков, которые я называю общим словом пост-ОО. Несмотря на общее название, языки этой группы могут сильно отличаться друг от друга. Объединяет их лишь то, что они отказались от традиционной Simula/Smalltalk ОО модели в пользу чего-то иного, но при этом сохранив определенные черты ОО языков. И вот сегодня речь пойдет про один из таких ЯП - Rust.

Rust очень интересный ЯП по многим аспектам, но в этих статьи мы разбираем языки на предмет реализации ОО модели. Однако, переде тем как сделать это, давайте посмотрим на прямых "родителей":

1. С. Да-да, именно C, а не С++. Rust перенял очень многое от своего знаменитого родственника. Более того, Rust имеет совместимость с C ABI, т.е. вы можете не только импортировать С библиотеки в программы на Rust, но и наоборот. Для этого в Rust даже существую специальные C-like структуры-данных: Union, CString и т.д.

2. Языки семейства ML (OCaml и Haskell): типизация, выведение типов, алгебраические типы, сопоставления с шаблонами, система характеристик, почти все конструкции являются выражениями.

3. Языки семейства Lisp. Макросы и мета-программирование.

4. Python. Да, именно так. Когда я начинал писать на Rust, у меня не проходило чувство дежавю по сравнению с Python. Тут и ассоциированные функции с явным self аргументом. Итераторы как определяющий элемент дизайна стандартной библиотеки. И много чего еще по мелочи.

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

- В Rust нет понятие класса или объекта со связанной с ней инкапсуляции данных и поведения.

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

fn main() {
  let x = 2.0;

  // Вызов метода через точку
  let y = x.powi(3);
  println!("2^3 = {}", y);
  
  // Вызов метода через явную квалификацию
  let z = f64::powi(x, 3);
  println!("2^3 = {}", z);
}

Реализовать/добавить новое поведение можно для любой структуры, а не только ту, что создали вы. Т.е. накинуть "новых методов" числам не составляет труда, однако работает это не через механизм динамической диспетчеризации как в Smalltalk, а за счет статической компиляции.

trait Double {
    fn double(self) -> Self;
}

impl Double for i32 {
    fn double(self) -> i32 {
        self * 2
    }
}

fn main() {
  let x: i32 = 5;
  
  // Выглядит как новый метод, но это сахар для Double::double(x)
  let result = x.double();
  println!("Удвоенное значение {} равно {}", x, result);
}

Явная инкапсуляция данных есть, но только на уровне модулей/крейтов (пакетов).

- В Rust нет наследования реальных типов, но есть наследование характеристик.

Характеристика с точки зрения ОО похожа на интерфейсы Java. В них также определяется набор "методов/свойств" для реализующих их структуры, а также могут быть реализации по-умолчанию. Главное отличие от интерфейсов в том, что мы можем реализовать характеристику для любого типа, а не только для своего. Обратное также справедливо: мы можем реализовать стороннюю характеристику для своего типа.

Кстати, операторы по типу +, -, ., [] - это тоже функции из различных характеристик, а значит мы можем их явно реализовывать для любого своего типа. Говоря проще: в Rust есть перегрузка операторов. Причем работает она абсолютно прозрачно.

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

А вот наследование характеристик оставили, но тут это выглядит не как создание отношения между сущностями, а скорее просто уточняющий контракт. Значит никаких вам override/super тут нет. И связанных с этим проблем нет.

- В Rust нет понятия объекта.

А значит нет разделения на объекты и примитивы. По-умолчанию почти все типы передаются по значению и могут храниться в стеке, но с другой стороны мы можем создать ссылку/указатель на любой тип, так и явно поместить его в кучу. Говоря простым языком, мы полностью контролируем где и как хранятся наши данные.

- Rust позволяет задавать зависимость от абстрактных типов.

Значит мы можем создать массив "итерируемых объектов", а не конкретных типов. Только вот загвоздка в том, что сделать массив, в котором будут лежать одновременно строки и вектора просто так не получится. Минуточку. Но почему?

Ну смотрите, в Java у нас любой объект всегда передается по указателю, а интерфейсы применяются только к объектам. Значит такой массив фактически был бы массивом указателей. А вот в Rust у нас объектов нет.

Зато ссылку/указатель мы можем создать явно на что угодно. И сможем объяснить компилятору, что у нас тут должна быть ссылка на сущность, которая реализует заданную характеристику. Значит все таки создать массив разных сущностей из приведенного примера мы сможем, но мы должны это ЯВНО описать компилятору.

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

А когда мы прячемся за указатель, то получается, что такого рода оптимизация становится невозможной на этапе компиляции, а значит для этого уже придется придумывать JIT. У Rust JIT нет, да и вообще Runtime очень маленький, поэтому язык использует дизайн "любая доп цена должна быть явной".

---

Уфф. Получилось много буков. Какой же тут вывод? В Rust безусловно присутствуют многие черты ОО языка, но, фактически, таковым он не является. Однако, получившееся смесь позволяет нам эффективно использовать черты ОО и ФП без сильного негативного эффекта обоих языков. Значит, безумное море-объектов в Java стиле вам не грозит, как и не грозит чрезмерный пуризм и контроль за эффектами в стиле Haskell.

Парадигмы программирования не стоят на месте и развиваются. А чтобы понимать почему в языках происходят те или иные изменения нужно понимать проблемы, а для этого изучать разные ЯП и расширять кругозор.

Но ООП не умирает, даже не болеет. Так что не бойтесь.

Всем базы!

🥳 Сегодня, оказывается, День учителя.

Как будто бы могу считать это еще одним своим профессиональным праздником. Три года назад я с Дашей начал небольшой образовательный проект, а теперь у нас команда из 10 человек и больше 700 студентов!

В общем принимаю поздравления ☺️

Дайджест новостей за сентябрь! Чтобы ты точно ничего не пропустил 😉

🎙 Мой первый подкаст:
• Куда движется современный фронтенд / отладка / интересные баги — с Димой Холстининым обсуждаем долгую карьеру в IT и путь инженера в текущих реалиях.

🧑‍💻 Продолжаем серию постов про ООП:
1. Часть 5. Java:
Анализ языка, который популяризировал ООП и его место между Simula и Smalltalk.
2. Часть 6. JavaScript:
Погружаемся в особенности ООП в JavaScript и сравниваем его с Java.

💡 Производительность и API:
• Web Codecs API в Firefox 130: Теперь API для низкоуровневой работы с мультимедийными потоками доступен и в Firefox. Как это меняет возможности веб-разработки?
• Scheduler API в Chrome 129: Методы для реализации кооперативной многозадачности в JavaScript стали более доступными. Обсуждаем преимущества и возможности.

🎓 Курсы и обучение:
• Конкурс курсовых работ на курсе CS и его победители:
1. 🥇 Composity — библиотека для функционального программирования в JS
2. 🥈 Rutf8 — библиотека с алгоритмами для сжатия текста
3. 🥉 Intersecti0n — реализация R-дерева для геометрических пересечений
• Мини-курс по отладке и профилированию Frontend: Новый интенсив о том, как эффективно использовать инструменты отладки и профилирования в вашей работе.

📅 В планах:
• Курс по инфраструктуре в Frontend стартует уже 3 декабря. Полная программа на 2 месяца, чтобы погрузиться в практические аспекты и прокачаться на реальных задачах.

🔧 Обновления и советы:
• Как я успеваю все: Поделился своими секретами планирования и работы над тремя разными проектами одновременно.
• Мой подход к отладке: Вспомнил времена IE6 и обсудил современные техники отладки, а также свои проверенные методы работы через console.log.

Надеюсь, что ты нашел что-то новое и полезное в этом месяце! 💪

Ну вот 2.5 часа лекции пролетели как 10 минут! Классный формат - обязательно будем продолжать.

Если не успели посмотреть сегодня, то не беда. Завтра все, кто зарегистрировался, получат ссылку на запись лекции.

Следующая открытая лекция пройдет 16 октября 💪 Будем говорить про инструменты статического анализа кода и их запуск (локально, прехуки, ci/cd).

Ну и last call: сегодня последний день, когда можно приобрести мини-курс по Debug по самой низкой цене - https://kobezzza.ru/debug

Завтра цена увеличится, так что не зеваем 💪

Всем базы!