Прошёл финал чемпионата Яндекса по программированию.

В этот раз я делал задачи как для квалификационного этапа, так и для финала. К сожалению в этом году мою задачу снова никто не решил. Но в этот раз многие попытались.

Что самое забавное, решение можно было записать в 10 строк. Как только эта задача появится на coderun.yandex.ru, обязательно поделюсь)

Поздравляю победителей! И жду новых участников в следующем году

Обновил parvis до версии 0.2.0🏃‍♂️
https://www.npmjs.com/package/parvis

parvis — фреймворк на virtual dom, позволяющий писать интерфейсы, используя привычный jsx и компонентный подход. Он поддерживает реактивное обновление стейта, хуки для методов жизненного цикла и поддержку ts. При этом очень мало весит.

В новой версии он больше не имеет внешних зависимостей (теперь их 0), и размер бандла также уменьшен на пару килобайт (esm с 21 до 19).

Начать очень легко, вся документация помещается в README. Пробуйте, несите фидбек, ставьте звёздочки и всё такое)

Прямо сейчас на мероприятии в честь людей, которые делают молодёжные программы, в том числе и для стажеров.

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

Если вы или ваши знакомые хотят попасть на стажировку в Яндекс, приглашаю в инфраструктуру! Я сам начинал со стажировки, и с тех пор не пожалел. У нас теперь даже сайт есть infra.yandex.ru

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

П.С. пост не проплачен и не является рекламой и финансовой рекомендацией

Впервые в жизни пошёл на балет (щелкунчик). Место действия — Мариинский театр, Санкт-Петербург.

Это было лучше, чем я ожидал. Даже сидя на третьем ярусе, так как нормальные места раскупили за месяцы) Теперь я ещё разбираюсь, какие где лучше места (любой ярус, центр, 1 ряд).

Всем искусства!👯‍♀👯‍♀👯‍♀

В идеальном языке программирования не нужен while.

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

Я утверждаю, что в подавляющем числе задач мы можем дать верхнюю оценку количества шагов ЗАРАНЕЕ ☝️.

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

А как же вычислимость по Тьюрингу? В прикладном программировании задач с неизвестным количеством итераций исчезающе мало. Однако я говорил только про синхронные вычисления. Ничто не мешает выделять асинхронно по 2^32 шагов в каждом новом асинхронном событии. Это на случай математических задач, а для промышленного 🚜 программирования хватает итерации по структурам.

Поздравляем, вы переизобрели функциональное программирование! Не совсем, ведь в нём есть рекурсия, а значит,  можно пропустить условие выхода и упереться в стек вызовов. Тут уже хорошо, что вообще есть ограничение на длину этого стека. Чтобы этого избежать, самое простое решение — запретить рекурсию 🙅‍♀. Но это тоже довольно малый диапазон задач.

Итого, в идеальном языке программирования должен отсутствовать while ❌ и рекурсия ❌, и достаточно итерации ✅ по структурам.

Немного про параметризацию сервисов proto 🌚

У меня в базе несколько типов объектов, фиксированное количество, их поля описаны в прото файлах. И есть метод get, который получает объект по его id. Что мы делаем в прото? Конечно, создаём service. Вот только мы хотим точно знать, какой объект вернется, например, в запросе передав тип объекта.

Проблема в том, что в прото нет ни параметризации (дженериков), ни наследования. Какие варианты?

Можно забить 🥴 и использовать bytes, а уже в системе типов целевого языка правильно добавить типы (например через интерфейсы в go или дженерик типы в typescript). Это простой вариант, но работа перекладывается на целевые языки, причём работа механическая.

Есть другой путь, сделать несколько прото сервисов. Под каждый тип объекта будет сервис со своим методом rpc Get, и соответственно в returns можно указать правильные message для нужного типа. Всё выглядит хорошо, но нужно писать много однообразного прото. Тут на помощь приходит кодогенерация 🤯

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

Каюсь, что использовал go для написания скрипта, просто много кода на go, и мне хочется набить руку в этом языке. Вот собственно сам скрипт (упрощён для понимания)

package main

import (
 "fmt"
 "os"
 "strings"
)

var objects = []string{"A", "B", "C"}

// сопоставление имён типов объектов и их message
func createObjectMapMessage() string {
    // ...
}

// генерация service c методами rpc
func createObjectService(name string) string {
    // ...
}

func createAutogenProto() string {
 services := []string{}
 for _, name := range objects {
  services = append(services, createObjectService(name))
 }

    // в service.proto лежат общие части для сообщений ответов
 result := fmt.Sprintf(`syntax = "proto3";

import "service.proto";

%s

%s
`, createObjectMapMessage(), strings.Join(services, "\n"))

 return result
}

func main() {
 text := createAutogenProto()
 os.WriteFile("autogen.proto", []byte(text), 0666)
}

Забавно, что go генерирует прото, а потом protoc из прото генерирует go код. Цикл замкнулся)

Ещё в Питере перед новым годом закупился новой порцией книг, ищу свежую научную фантастику. Не люблю воздевать палец к небу и провозглашать, что Азимов, Лем и Дик были гениями, а все современные просто меркнут на их фоне. В прошлом году я рекомендовал трилогию Квантовый вор (Райаниеми), и авторы прошлого века просто не могли в своих произведениях применять научные знания нашего времени, например квантовые вычисления и вообще программирование продвинулись далеко.

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

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

Ведь как известно, любая достаточно продвинутая технология неотличима от магии!