Последнее время копался сразу в двух довольно «мозголомных» штуках — Haskell и Kubernetes. Оба инструмента умные, красивые и местами пугающе глубокие. Чем больше в них погружаешься, тем чаще ловишь себя на мысли: кажется, я только что приоткрыл дверь в очень большой и странный мир. Ниже — мысли по ходу этого погружения, без учебников и пафоса, просто как я это прожил.
В Haskell есть бесконечные списки — и это не метафора. Они действительно бесконечные, потому что язык вычисляет значения лениво.
Философия простая: даже если выражение огромное, Haskell считает ровно столько, сколько нужно прямо сейчас. Не больше. Технически это называется вычислением до слабой головной нормальной формы (WHNF) — то есть «понять, что это за штука, но не разворачивать её полностью».
Пример из жизни:
Этот список начинается с двойки и идёт дальше через один — 2, 4, 6, 8… и так без конца. Но если я напишу:
Или ещё пример:
Но у ленивой стратегии есть и тёмная сторона — space leak, утечка памяти.
Она возникает, когда мы вроде бы «ничего не считаем», но держим в памяти кучу отложенных вычислений. Типичная ситуация:
Если написать неаккуратно, Haskell может сначала наоткладывать миллионы сложений, а потом внезапно понять, что память закончилась. Формально он был ленивым, а по факту — слишком терпеливым. Поэтому ленивость — это мощный инструмент, но обращаться с ним нужно осознанно.
Haskell я поизучал и решил остановиться, и вот почему. Главная особенность Haskell — в его происхождении. Он вырос из академической среды: университеты, исследователи, строгая математика, чистые абстракции. Отсюда и стиль языка — «строим собор»: всё выверено, логично, красиво, под присмотром умных архитекторов. Рекурсивные типы, функторы, аппликативы, монады — всё на своих местах.
С одной стороны, это огромный плюс. Haskell даёт редкое ощущение интеллектуальной чистоты и надёжности. С другой — он часто кажется далёким от повседневных задач. Академическая логика не всегда совпадает с тем, как думает инженер, которому нужно просто «чтобы работало здесь и сейчас».
Инженерный мир живёт практикой и эксплуатацией. Если идея прекрасна в теории, но требует недель вхождения и особого мышления — она сложна в применении. В этом и напряжение вокруг Haskell: язык мощный и точный, но дружелюбным он становится только после того, как ты к нему дорастаешь. Большинство не дорастает. Я тоже решил отложить функциональное программирование. Но опыт его освоения был весьма занимательным.
Я всё ещё ковыряюсь в Kubernetes. Нашёл на официальном сайте реально хорошие гайды — написаны понятно, без лишней магии, тот же пример с WordPress и MySQL зашёл отлично https://kubernetes.io/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/
Но чем дальше лезу, тем сильнее ощущение, что Kubernetes — это какой-то новый Linux: огромный, многослойный и у каждого он «свой». И в какой-то момент поймал себя на мысли, что без живых задач его можно изучать бесконечно и так ни к чему конкретному не прийти. Поэтому решил поставить обучение на паузу и вернуться к нему, когда появится реальная задача, а не просто академический интерес.
В какой-то момент я понял, что снова делаю типичную айтишную ошибку: изучаю мощные инструменты просто потому, что они мощные. Haskell и Kubernetes — отличные штуки, но они не любят праздного любопытства. Им нужны задачи, боль и контекст. Так что я нажал на паузу без чувства вины. Знания никуда не делись, опыт остался, а интерес — жив. Значит, всё было не зря.
В Haskell есть бесконечные списки — и это не метафора. Они действительно бесконечные, потому что язык вычисляет значения лениво.
Философия простая: даже если выражение огромное, Haskell считает ровно столько, сколько нужно прямо сейчас. Не больше. Технически это называется вычислением до слабой головной нормальной формы (WHNF) — то есть «понять, что это за штука, но не разворачивать её полностью».
Пример из жизни:
nums = [2,4..]Этот список начинается с двойки и идёт дальше через один — 2, 4, 6, 8… и так без конца. Но если я напишу:
take 3 nums Haskell даже не пытается «построить весь список». Он честно говорит: «Мне нужны только первые три — окей, вот 2, 4, 6. Остальное не трогаем».Или ещё пример:
head (map (*2) [1..]) Кажется, что тут бесконечность на бесконечности, но по факту вычисляется только: 1 → умножили на 2 → получили 2 → остановились. Магия? Нет, лень. В хорошем смысле.Но у ленивой стратегии есть и тёмная сторона — space leak, утечка памяти.
Она возникает, когда мы вроде бы «ничего не считаем», но держим в памяти кучу отложенных вычислений. Типичная ситуация:
sum [1..10000000]Если написать неаккуратно, Haskell может сначала наоткладывать миллионы сложений, а потом внезапно понять, что память закончилась. Формально он был ленивым, а по факту — слишком терпеливым. Поэтому ленивость — это мощный инструмент, но обращаться с ним нужно осознанно.
Haskell я поизучал и решил остановиться, и вот почему. Главная особенность Haskell — в его происхождении. Он вырос из академической среды: университеты, исследователи, строгая математика, чистые абстракции. Отсюда и стиль языка — «строим собор»: всё выверено, логично, красиво, под присмотром умных архитекторов. Рекурсивные типы, функторы, аппликативы, монады — всё на своих местах.
С одной стороны, это огромный плюс. Haskell даёт редкое ощущение интеллектуальной чистоты и надёжности. С другой — он часто кажется далёким от повседневных задач. Академическая логика не всегда совпадает с тем, как думает инженер, которому нужно просто «чтобы работало здесь и сейчас».
Инженерный мир живёт практикой и эксплуатацией. Если идея прекрасна в теории, но требует недель вхождения и особого мышления — она сложна в применении. В этом и напряжение вокруг Haskell: язык мощный и точный, но дружелюбным он становится только после того, как ты к нему дорастаешь. Большинство не дорастает. Я тоже решил отложить функциональное программирование. Но опыт его освоения был весьма занимательным.
Я всё ещё ковыряюсь в Kubernetes. Нашёл на официальном сайте реально хорошие гайды — написаны понятно, без лишней магии, тот же пример с WordPress и MySQL зашёл отлично https://kubernetes.io/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/
Но чем дальше лезу, тем сильнее ощущение, что Kubernetes — это какой-то новый Linux: огромный, многослойный и у каждого он «свой». И в какой-то момент поймал себя на мысли, что без живых задач его можно изучать бесконечно и так ни к чему конкретному не прийти. Поэтому решил поставить обучение на паузу и вернуться к нему, когда появится реальная задача, а не просто академический интерес.
В какой-то момент я понял, что снова делаю типичную айтишную ошибку: изучаю мощные инструменты просто потому, что они мощные. Haskell и Kubernetes — отличные штуки, но они не любят праздного любопытства. Им нужны задачи, боль и контекст. Так что я нажал на паузу без чувства вины. Знания никуда не делись, опыт остался, а интерес — жив. Значит, всё было не зря.
Kubernetes
Example: Deploying WordPress and MySQL with Persistent Volumes
This tutorial shows you how to deploy a WordPress site and a MySQL database using Minikube. Both applications use PersistentVolumes and PersistentVolumeClaims to store data.
A PersistentVolume (PV) is a piece of storage in the cluster that has been manually…
A PersistentVolume (PV) is a piece of storage in the cluster that has been manually…
❤3👍1
Перечитал роман «Гиперион» Дэна Симмонса. Впервые я читал его около двадцати лет назад, ещё студентом, и тогда без колебаний поставил ему 10/10. Сейчас впечатление изменилось.
«Гиперион» — это не совсем космоопера в привычном смысле. Скорее роман-путешествие и сборник притч. Семь паломников летят к планете Гиперион, чтобы встретиться с загадочным и смертельно опасным Шрайком накануне галактической войны. По пути каждый из них рассказывает свою историю — о любви, вере, науке, страхе и ответственности.
По сути, «Гиперион» — это разговор о религии в XXVIII веке, о вере и её трансформации. Здесь сосуществуют католицизм, ислам, иудаизм и новые духовные течения. Религия в романе не догма, а живой и болезненный процесс поиска смысла.
Само название отсылает к поэме Джона Китса «Гиперион», посвящённой битве олимпийских богов и титанов. Титан Кронос пожирает своих детей, но Зевс освобождает братьев и побеждает его. Гиперион — титан света, готовящийся к войне. Поэма Китса описывает смену старых богов новыми, переход от стихийных сил к персонифицированным божествам. Этот мотив смены эпох и богов напрямую отражается в романе Симмонса.
Паломничество к «святой земле» имеет в мире «Гипериона» ключевое значение. Считается, что Шрайк исполнит желание одного из паломников, а остальных принесёт в жертву. Один из героев — военный — уже сталкивался с Шрайком, обитающим в Гробницах Времени, которые движутся из будущего в прошлое. Он видел своих спутников, распятых на Древе Боли. При этом идея о том, что один металлический бог с лезвиями вместо тела способен решить проблемы цивилизации, копившиеся веками, вызывает у меня серьёзные сомнения.
Особенно запоминается история священника Поля Дюре. Католическая церковь в XXVIII веке находится в упадке и фактически превратилась в маргинальную секту. Основная религия галактики — дзен-гностицизм, который Симмонс намеренно описывает фрагментарно. Можно лишь предположить, что в его основе — отказ от ритуалов и акцент на личном, внутреннем общении с Богом. Учитель Дюре на Гиперионе заражается крестоформом — паразитом, прикрепляющимся к позвоночнику и воскрешающим человека после смерти. Каждое возрождение сопровождается деградацией личности: стирается память, притупляется разум. Формально это путь к бессмертию, но по сути — утрата человечности, вечная жизнь без свободы и воли.
История поэта Мартина Силена посвящена упадку поэзии в XXVIII веке. Одна из его книг становится популярной исключительно благодаря маркетингу. Он отчаянно пытается вернуть славу, написав новое произведение. Лично мне этот сюжет кажется ироничным: поэзия, по ощущениям, умирает уже несколько веков — и всё никак не умрёт окончательно.
Война показана через призму опыта профессионального солдата Федмана Кассада — мусульманина, тактика и офицера элитных подразделений. Его история — размышление о войне как о замкнутом, самовоспроизводящемся круге, в котором меняются только декорации.
Профессор этики Сол Вайнтрауб сталкивается с проклятием своей дочери Рахели: она молодеет с каждым днём, превращаясь из женщины в младенца. Вайнтрауб — иудей, ему снятся сны, в которых Яхве требует принести дочь в жертву. Он размышляет об этике жертвоприношения и вступает в спор с библейским мифом об Аврааме. Если бы сын Авраама погиб, считает Вайнтрауб, тот не стал бы поклоняться такому Богу — потому что Бог стал бы злым.
Если двадцать лет назад «Гиперион» вызывал у меня безоговорочный восторг, то сегодня он оставляет более противоречивые чувства. Это осознанно фрагментарное произведение — смесь космооперы, философского трактата, религиозной притчи, хоррора и киберпанка. Роман обрывается намеренно: основные события начинаются уже в следующей книге — «Падение Гипериона». Шрайк, Гробницы Времени и многие ключевые загадки долго остаются без объяснений.
И всё же это великая книга. В моём личном рейтинге — 9/10. Рекомендую к прочтению.
«Гиперион» — это не совсем космоопера в привычном смысле. Скорее роман-путешествие и сборник притч. Семь паломников летят к планете Гиперион, чтобы встретиться с загадочным и смертельно опасным Шрайком накануне галактической войны. По пути каждый из них рассказывает свою историю — о любви, вере, науке, страхе и ответственности.
По сути, «Гиперион» — это разговор о религии в XXVIII веке, о вере и её трансформации. Здесь сосуществуют католицизм, ислам, иудаизм и новые духовные течения. Религия в романе не догма, а живой и болезненный процесс поиска смысла.
Само название отсылает к поэме Джона Китса «Гиперион», посвящённой битве олимпийских богов и титанов. Титан Кронос пожирает своих детей, но Зевс освобождает братьев и побеждает его. Гиперион — титан света, готовящийся к войне. Поэма Китса описывает смену старых богов новыми, переход от стихийных сил к персонифицированным божествам. Этот мотив смены эпох и богов напрямую отражается в романе Симмонса.
Паломничество к «святой земле» имеет в мире «Гипериона» ключевое значение. Считается, что Шрайк исполнит желание одного из паломников, а остальных принесёт в жертву. Один из героев — военный — уже сталкивался с Шрайком, обитающим в Гробницах Времени, которые движутся из будущего в прошлое. Он видел своих спутников, распятых на Древе Боли. При этом идея о том, что один металлический бог с лезвиями вместо тела способен решить проблемы цивилизации, копившиеся веками, вызывает у меня серьёзные сомнения.
Особенно запоминается история священника Поля Дюре. Католическая церковь в XXVIII веке находится в упадке и фактически превратилась в маргинальную секту. Основная религия галактики — дзен-гностицизм, который Симмонс намеренно описывает фрагментарно. Можно лишь предположить, что в его основе — отказ от ритуалов и акцент на личном, внутреннем общении с Богом. Учитель Дюре на Гиперионе заражается крестоформом — паразитом, прикрепляющимся к позвоночнику и воскрешающим человека после смерти. Каждое возрождение сопровождается деградацией личности: стирается память, притупляется разум. Формально это путь к бессмертию, но по сути — утрата человечности, вечная жизнь без свободы и воли.
История поэта Мартина Силена посвящена упадку поэзии в XXVIII веке. Одна из его книг становится популярной исключительно благодаря маркетингу. Он отчаянно пытается вернуть славу, написав новое произведение. Лично мне этот сюжет кажется ироничным: поэзия, по ощущениям, умирает уже несколько веков — и всё никак не умрёт окончательно.
Война показана через призму опыта профессионального солдата Федмана Кассада — мусульманина, тактика и офицера элитных подразделений. Его история — размышление о войне как о замкнутом, самовоспроизводящемся круге, в котором меняются только декорации.
Профессор этики Сол Вайнтрауб сталкивается с проклятием своей дочери Рахели: она молодеет с каждым днём, превращаясь из женщины в младенца. Вайнтрауб — иудей, ему снятся сны, в которых Яхве требует принести дочь в жертву. Он размышляет об этике жертвоприношения и вступает в спор с библейским мифом об Аврааме. Если бы сын Авраама погиб, считает Вайнтрауб, тот не стал бы поклоняться такому Богу — потому что Бог стал бы злым.
Если двадцать лет назад «Гиперион» вызывал у меня безоговорочный восторг, то сегодня он оставляет более противоречивые чувства. Это осознанно фрагментарное произведение — смесь космооперы, философского трактата, религиозной притчи, хоррора и киберпанка. Роман обрывается намеренно: основные события начинаются уже в следующей книге — «Падение Гипериона». Шрайк, Гробницы Времени и многие ключевые загадки долго остаются без объяснений.
И всё же это великая книга. В моём личном рейтинге — 9/10. Рекомендую к прочтению.
👍3❤1
Перед Новым годом решил наконец системно разобраться с AI.
Не «поиграться», а именно понять, как он работает и как выжимать из него максимум.
Остановился на ChatGPT — использую его каждый день, логично начать с того, что уже встроено в рабочий процесс.
Начал с бесплатного курса «Как упростить жизнь с помощью нейросетей» от Т-Ж https://t-j.ru/pro/ai-text/. Курс короткий, но неожиданно полезный. Самое ценное — про формулирование запросов. Оказывается, это отдельный навык, а не «ну я и так написал нормально».
Отдельно зашла статья про креативность. SCAMPER, латеральное мышление, метод фокальных объектов — внезапно понял, что креатив можно не ждать, а вызывать по инструкции. В итоге курс прошёл быстро, даже сертификат дали.
Параллельно начал курс «Практическое руководство по ChatGPT 5». Там уже про более продвинутые вещи: проекты, ассистенты, сценарии использования. Досмотрел примерно до середины — отложил, но вернусь.
Если кажется, что ты уже «мастер промптов», очень рекомендую игру Say What You See от Google Arts & Culture. https://artsandculture.google.com/experiment/say-what-you-see/jwG3m7wQShZngw
Дают картинку — твоя задача описать её так, чтобы нейросеть сгенерировала максимально похожую. Сначала легко. Потом начинается ад. Абстракции, детали, композиция. Очень хорошо отрезвляет и показывает, как сложно на самом деле точно описывать то, что видишь.
А потом неожиданно в жизнь ворвался SQL.
На работе начали сыпаться отчёты: где звонили, где не звонили, по каким линиям, в какие даты. Полез разбираться — и понял, что в датах и регулярках SQL «плаваю». Пришлось учиться.
Нашёл курс «SQL для анализа данных с Глебом Михайловым», курс интересный. Он показывает, как работать с данными как дата-аналитик через Google Colab https://colab.research.google.com/. Идея хорошая, но без практики не зашло.
По совету руководителя программистов зашёл на https://sql-academy.org/ — и вот это уже то, что нужно. Теория сразу закрепляется практикой. Впервые нормально уложились в голове запросы по датам — ровно то, что нужно для отчётов.
Например,
И тут сложился интересный инсайт.
SQL и промпты к AI очень похожи. Оба — декларативные языки. Ты не объясняешь, как делать, ты точно формулируешь, что хочешь получить. И если на входе мусор, на выходе будет ровно такой же мусор. Garbage in — garbage out.
В общем, неожиданно полезная неделя декабря: чуть больше понимания, как формулировать мысли — и для машин, и для себя.
Не «поиграться», а именно понять, как он работает и как выжимать из него максимум.
Остановился на ChatGPT — использую его каждый день, логично начать с того, что уже встроено в рабочий процесс.
Начал с бесплатного курса «Как упростить жизнь с помощью нейросетей» от Т-Ж https://t-j.ru/pro/ai-text/. Курс короткий, но неожиданно полезный. Самое ценное — про формулирование запросов. Оказывается, это отдельный навык, а не «ну я и так написал нормально».
Отдельно зашла статья про креативность. SCAMPER, латеральное мышление, метод фокальных объектов — внезапно понял, что креатив можно не ждать, а вызывать по инструкции. В итоге курс прошёл быстро, даже сертификат дали.
Параллельно начал курс «Практическое руководство по ChatGPT 5». Там уже про более продвинутые вещи: проекты, ассистенты, сценарии использования. Досмотрел примерно до середины — отложил, но вернусь.
Если кажется, что ты уже «мастер промптов», очень рекомендую игру Say What You See от Google Arts & Culture. https://artsandculture.google.com/experiment/say-what-you-see/jwG3m7wQShZngw
Дают картинку — твоя задача описать её так, чтобы нейросеть сгенерировала максимально похожую. Сначала легко. Потом начинается ад. Абстракции, детали, композиция. Очень хорошо отрезвляет и показывает, как сложно на самом деле точно описывать то, что видишь.
А потом неожиданно в жизнь ворвался SQL.
На работе начали сыпаться отчёты: где звонили, где не звонили, по каким линиям, в какие даты. Полез разбираться — и понял, что в датах и регулярках SQL «плаваю». Пришлось учиться.
Нашёл курс «SQL для анализа данных с Глебом Михайловым», курс интересный. Он показывает, как работать с данными как дата-аналитик через Google Colab https://colab.research.google.com/. Идея хорошая, но без практики не зашло.
По совету руководителя программистов зашёл на https://sql-academy.org/ — и вот это уже то, что нужно. Теория сразу закрепляется практикой. Впервые нормально уложились в голове запросы по датам — ровно то, что нужно для отчётов.
Например,
-- Извлекает часть даты (год, месяц, день и т. д.) для указанной даты
SELECT EXTRACT(YEAR FROM DATE '2022-06-16') AS year;
И тут сложился интересный инсайт.
SQL и промпты к AI очень похожи. Оба — декларативные языки. Ты не объясняешь, как делать, ты точно формулируешь, что хочешь получить. И если на входе мусор, на выходе будет ровно такой же мусор. Garbage in — garbage out.
В общем, неожиданно полезная неделя декабря: чуть больше понимания, как формулировать мысли — и для машин, и для себя.
Учебник Т—Ж
Бесплатный курс «Как упростить жизнь с помощью нейросетей»
Как превратить любую текстовую нейросеть в помощника на работе, в учебе и в быту
👍5
На работе всплыла интересная задача. Менеджер по продажам звонит клиенту и общается с ним. Спустя некоторое время клиент перезванивает — уже на общий номер отдела продаж. Идея простая: АТС должна соединить клиента с тем менеджером, с которым он общался ранее.
Алгоритм довольно прямолинейный: берём номер клиента; ищем его в исходящих звонках отдела продаж; если нашли — соединяем с нужным менеджером; если нет — отправляем звонок в общую очередь отдела. По сути, такой «реверс‑прокси» для мини‑АТС.
Все звонки пишутся в MySQL. Значит, логичное решение — выполнить SQL‑запрос к CDR и получить номер менеджера. Но до меня это уже реализовали: написали bash‑скрипт, который выполняет SQL‑запрос, парсит результат регулярными выражениями и возвращает номер менеджера.
Я около двух часов пытался разобраться в логике этого скрипта и в том, что именно делают эти регулярки. Код нечитаемый, поддерживать его сложно — как инструкция к китайскому квадрокоптеру, переведённая через автопереводчик. К тому же реализация архитектурно неудачная: из dialplan запускается внешняя команда; основной поток блокируется; клиент слышит паузу; результат пишется во временный файл; потом файл читается и удаляется. Работает — да. Но выглядит как решение «на коленке».
В Asterisk есть несколько программных интерфейсов, и один из них — AGI (Asterisk Gateway Interface). AGI позволяет вызывать внешние программы (Node.js, Python, C и т.д.) прямо из dialplan и передавать им всю информацию о звонке: CallerID, канал, переменные. Скрипт, в свою очередь, управляет логикой — что воспроизвести, куда направить вызов, какие переменные установить.
Механика работы довольно простая. Asterisk запускает скрипт и передаёт ему окружение в виде набора строк формата «ключ: значение». После пустой строки начинается интерактивный режим: скрипт отправляет команды вроде
Для начала я написал простой AGI‑скрипт на Node.js, который воспроизводит в трубке «Привет, мир». Ирония в том, что именно это оказалось самым сложным этапом. Саму бизнес‑логику — SQL‑запрос и выбор нужного менеджера — буду дописывать уже после Нового года.
Эта задача неожиданно упёрлась не только в Asterisk, но и в SQL. Сейчас я прохожу курс на [https://sql-academy.org/](https://sql-academy.org/): сначала всё было элементарно, но как только начались соединения таблиц, сложность задач резко выросла.
Параллельно я скачал книгу Е. П. Моргунова «PostgreSQL. Профессиональный SQL» и довольно быстро понял, что всё изученное ранее — по сути, арифметика. В книге разбираются графы, рекурсии и другие нетривиальные конструкции, которые уже ощущаются как «высшая математика» для SQL.
SQL вообще не такой простой язык, как может показаться на первый взгляд. На нём можно писать полноценные программы. Я даже знаю один банк, где вся бизнес‑логика была реализована исключительно на хранимых процедурах.
P.S. В Telegram‑чате меня как‑то спросили: «Такое ощущение, что ты только работаешь и учишься — отдыхать успеваешь?»
Успеваю. Просто это технический блог. Даже на один пост при готовом материале уходит около часа. А на большие и сложные статьи, например по ZFS, может уйти три‑четыре недели на сбор и проверку информации. Если подробно описывать вообще всё, что происходит, всё свободное время уйдёт только на блог. Зато следующим постом подведу итоги года и расскажу, что было у меня по разным сферам жизни.
Алгоритм довольно прямолинейный: берём номер клиента; ищем его в исходящих звонках отдела продаж; если нашли — соединяем с нужным менеджером; если нет — отправляем звонок в общую очередь отдела. По сути, такой «реверс‑прокси» для мини‑АТС.
Все звонки пишутся в MySQL. Значит, логичное решение — выполнить SQL‑запрос к CDR и получить номер менеджера. Но до меня это уже реализовали: написали bash‑скрипт, который выполняет SQL‑запрос, парсит результат регулярными выражениями и возвращает номер менеджера.
Я около двух часов пытался разобраться в логике этого скрипта и в том, что именно делают эти регулярки. Код нечитаемый, поддерживать его сложно — как инструкция к китайскому квадрокоптеру, переведённая через автопереводчик. К тому же реализация архитектурно неудачная: из dialplan запускается внешняя команда; основной поток блокируется; клиент слышит паузу; результат пишется во временный файл; потом файл читается и удаляется. Работает — да. Но выглядит как решение «на коленке».
В Asterisk есть несколько программных интерфейсов, и один из них — AGI (Asterisk Gateway Interface). AGI позволяет вызывать внешние программы (Node.js, Python, C и т.д.) прямо из dialplan и передавать им всю информацию о звонке: CallerID, канал, переменные. Скрипт, в свою очередь, управляет логикой — что воспроизвести, куда направить вызов, какие переменные установить.
Механика работы довольно простая. Asterisk запускает скрипт и передаёт ему окружение в виде набора строк формата «ключ: значение». После пустой строки начинается интерактивный режим: скрипт отправляет команды вроде
SET VARIABLE, EXEC Dial или STREAM FILE, а Asterisk синхронно отвечает результатами выполнения. Всё происходит пошагово и предсказуемо. Без временных файлов, без bash‑магии, с нормальным кодом и понятной логикой.Для начала я написал простой AGI‑скрипт на Node.js, который воспроизводит в трубке «Привет, мир». Ирония в том, что именно это оказалось самым сложным этапом. Саму бизнес‑логику — SQL‑запрос и выбор нужного менеджера — буду дописывать уже после Нового года.
Эта задача неожиданно упёрлась не только в Asterisk, но и в SQL. Сейчас я прохожу курс на [https://sql-academy.org/](https://sql-academy.org/): сначала всё было элементарно, но как только начались соединения таблиц, сложность задач резко выросла.
Параллельно я скачал книгу Е. П. Моргунова «PostgreSQL. Профессиональный SQL» и довольно быстро понял, что всё изученное ранее — по сути, арифметика. В книге разбираются графы, рекурсии и другие нетривиальные конструкции, которые уже ощущаются как «высшая математика» для SQL.
SQL вообще не такой простой язык, как может показаться на первый взгляд. На нём можно писать полноценные программы. Я даже знаю один банк, где вся бизнес‑логика была реализована исключительно на хранимых процедурах.
P.S. В Telegram‑чате меня как‑то спросили: «Такое ощущение, что ты только работаешь и учишься — отдыхать успеваешь?»
Успеваю. Просто это технический блог. Даже на один пост при готовом материале уходит около часа. А на большие и сложные статьи, например по ZFS, может уйти три‑четыре недели на сбор и проверку информации. Если подробно описывать вообще всё, что происходит, всё свободное время уйдёт только на блог. Зато следующим постом подведу итоги года и расскажу, что было у меня по разным сферам жизни.
👍3
Друзья, поздравляю вас с Новым 2026 годом 🎄✨
Пусть он начнётся без критических инцидентов 🚨, внезапных «падений продакшена» ❌ и срочных правок в последний момент. Желаю, чтобы системы работали стабильно ⚙️, решения принимались осознанно 🧠, а технический долг постепенно сокращался 📉 — без авралов и выгорания.
Пусть в новом году будет больше понятных архитектур 🏗, аккуратных конфигов 📄 и задач, которые действительно развивают 🚀. Желаю, чтобы обучение приносило удовольствие 📚, новые технологии ложились в голову без боли 💡, а сложные проблемы решались не за счёт нервов, а за счёт опыта и спокойствия 😌.
Спасибо, что читаете этот блог 🙌, делитесь мыслями и находите здесь что-то полезное для себя. В 2026 году желаю нам всем больше здравого инженерного подхода 🧩 и удовольствия от того, что мы делаем 😊. С Новым годом 🎉 — пусть он будет стабильным, продуктивным и технологически чистым!
Пусть он начнётся без критических инцидентов 🚨, внезапных «падений продакшена» ❌ и срочных правок в последний момент. Желаю, чтобы системы работали стабильно ⚙️, решения принимались осознанно 🧠, а технический долг постепенно сокращался 📉 — без авралов и выгорания.
Пусть в новом году будет больше понятных архитектур 🏗, аккуратных конфигов 📄 и задач, которые действительно развивают 🚀. Желаю, чтобы обучение приносило удовольствие 📚, новые технологии ложились в голову без боли 💡, а сложные проблемы решались не за счёт нервов, а за счёт опыта и спокойствия 😌.
Спасибо, что читаете этот блог 🙌, делитесь мыслями и находите здесь что-то полезное для себя. В 2026 году желаю нам всем больше здравого инженерного подхода 🧩 и удовольствия от того, что мы делаем 😊. С Новым годом 🎉 — пусть он будет стабильным, продуктивным и технологически чистым!
❤9
2025: длинная дистанция без иллюзий
Коротко о главном
2025 год оказался не годом достижений, а годом выживания и пересборки. Без громких побед, зато с большим объёмом честной внутренней работы: переосмысление профессии, денег, здоровья и собственных ожиданий. Если описывать его одной метафорой — это был бег с препятствиями без зрителей и аплодисментов.
Работа и рынок
Конец 2024 года я встретил увольнением и пятью месяцами поиска работы. За это время рынок труда показал себя во всей красе: он сломан, перегрет и абсолютно не гуманен к соискателю. Поиск работы превратился в отдельную профессию: курсы по алгоритмам, soft skills, работа с карьерными коучами и постоянная правка резюме. Результат — 1–2 собеседования в неделю вместо привычных 1–2 в день.
Эффект «импортозамещения» закончился: деньги в IT кончились, неключевые проекты закрылись, а рынок окончательно стал рынком работодателя. Когда финансовая подушка начала стремительно таять, я вернулся к очевидному: за плечами 20 лет системного администрирования.
Попытка вернуться в профессию выглядела сюрреалистично. Вакансии сисадминов напоминали цирк с грустными клоунами: от кандидата требуется всё, платить готовы почти ничего. Школы, больницы, государственные учреждения — текучка, завалы и выжженная земля. Один визит в поликлинику как кандидата, скорее для расширения кругозора, окончательно убедил меня: на таком месте можно застрять на годы, разгребая чужие ошибки.
В итоге я нашёл компанию, где работаю сейчас. Она занимается продажей и обслуживанием банковского оборудования. Я пришёл как связист по Asterisk. Около 500 абонентов, до меня — пять разных специалистов, каждый оставил после себя собственный почерк. Горы Perl-скриптов, криво переписанных на bash, неиспользуемый код и отсутствие целостной архитектуры. Цветущий сад я не вырастил, но значительную часть мусора удалось вывезти.
Что удалось сделать
1. Голосовое меню Asterisk и интеграция с Bitrix24. Третья попытка оказалась удачной. Базовый принцип — ни один звонок не должен пропадать. Сколько проживёт текущая версия, покажет время.
2. Оптимизация телефонии: отключены два оператора связи и половина телефонных номеров, которые фактически не использовались, но стабильно съедали бюджет.
3. OfeliaMerge — отдельный проект и утилита для конвертации cron-задач из bash-формата в формат Ofelia при миграции серверов.
Отдельным открытием стал процесс найма разработчиков изнутри. На одну вакансию за день может прийти до полутора тысяч резюме. Сначала автоматическая фильтрация по ключевым словам через AI, затем живое общение и отбор самых сильных кандидатов. Рынок работодателя без иллюзий.
Здоровье
Со здоровьем всё было тяжело. Головные боли преследовали весь год: ощущение, будто в голову несколько раз в день забивают гвоздь. Проблема оказалась сосудистой. После смены нескольких неврологов я нашёл цефалголога, и назначенное лечение наконец дало ощутимый эффект.
С сентября по декабрь — почти непрерывные ОРВИ. Только восстановишься — снова сляжешь. К вечеру состояние было таким, будто весь день разгружал вагоны. Плюс удаление зуба и регулярные визиты в аптеки. Этот год наглядно показал: здоровье — это не фон, а полноценный проект, требующий внимания и ресурсов.
Финансы
Финансово 2025 год прошёл под словом «апож». Финансовая подушка была полностью израсходована за время поиска работы. Портфель на фондовом рынке из-за последних геополитических событий превратился в сверхдолгосрочную инвестицию на 20–30 лет.
Криптопортфель показал минус 70 процентов за год — около 3000 долларов. Убыток пока бумажный, выходить из позиций я не стал.
С переходом на новую работу доход снизился примерно в три раза, а расходы остались прежними. Пришлось провести аудит: отключить неиспользуемые подписки, оптимизировать траты, перейти на более дешёвые решения. Итог — жизнь по средствам.
Финансовые цели на 2026 год простые и приземлённые:
1. Финансовая подушка безопасности.
2. Отпуск.
3. Наращивание криптопортфеля.
Системное администрирование
Из программиста я снова стал системным администратором. В работе — Asterisk, FreeBSD, ZFS, Debian, Zabbix.
Коротко о главном
2025 год оказался не годом достижений, а годом выживания и пересборки. Без громких побед, зато с большим объёмом честной внутренней работы: переосмысление профессии, денег, здоровья и собственных ожиданий. Если описывать его одной метафорой — это был бег с препятствиями без зрителей и аплодисментов.
Работа и рынок
Конец 2024 года я встретил увольнением и пятью месяцами поиска работы. За это время рынок труда показал себя во всей красе: он сломан, перегрет и абсолютно не гуманен к соискателю. Поиск работы превратился в отдельную профессию: курсы по алгоритмам, soft skills, работа с карьерными коучами и постоянная правка резюме. Результат — 1–2 собеседования в неделю вместо привычных 1–2 в день.
Эффект «импортозамещения» закончился: деньги в IT кончились, неключевые проекты закрылись, а рынок окончательно стал рынком работодателя. Когда финансовая подушка начала стремительно таять, я вернулся к очевидному: за плечами 20 лет системного администрирования.
Попытка вернуться в профессию выглядела сюрреалистично. Вакансии сисадминов напоминали цирк с грустными клоунами: от кандидата требуется всё, платить готовы почти ничего. Школы, больницы, государственные учреждения — текучка, завалы и выжженная земля. Один визит в поликлинику как кандидата, скорее для расширения кругозора, окончательно убедил меня: на таком месте можно застрять на годы, разгребая чужие ошибки.
В итоге я нашёл компанию, где работаю сейчас. Она занимается продажей и обслуживанием банковского оборудования. Я пришёл как связист по Asterisk. Около 500 абонентов, до меня — пять разных специалистов, каждый оставил после себя собственный почерк. Горы Perl-скриптов, криво переписанных на bash, неиспользуемый код и отсутствие целостной архитектуры. Цветущий сад я не вырастил, но значительную часть мусора удалось вывезти.
Что удалось сделать
1. Голосовое меню Asterisk и интеграция с Bitrix24. Третья попытка оказалась удачной. Базовый принцип — ни один звонок не должен пропадать. Сколько проживёт текущая версия, покажет время.
2. Оптимизация телефонии: отключены два оператора связи и половина телефонных номеров, которые фактически не использовались, но стабильно съедали бюджет.
3. OfeliaMerge — отдельный проект и утилита для конвертации cron-задач из bash-формата в формат Ofelia при миграции серверов.
Отдельным открытием стал процесс найма разработчиков изнутри. На одну вакансию за день может прийти до полутора тысяч резюме. Сначала автоматическая фильтрация по ключевым словам через AI, затем живое общение и отбор самых сильных кандидатов. Рынок работодателя без иллюзий.
Здоровье
Со здоровьем всё было тяжело. Головные боли преследовали весь год: ощущение, будто в голову несколько раз в день забивают гвоздь. Проблема оказалась сосудистой. После смены нескольких неврологов я нашёл цефалголога, и назначенное лечение наконец дало ощутимый эффект.
С сентября по декабрь — почти непрерывные ОРВИ. Только восстановишься — снова сляжешь. К вечеру состояние было таким, будто весь день разгружал вагоны. Плюс удаление зуба и регулярные визиты в аптеки. Этот год наглядно показал: здоровье — это не фон, а полноценный проект, требующий внимания и ресурсов.
Финансы
Финансово 2025 год прошёл под словом «апож». Финансовая подушка была полностью израсходована за время поиска работы. Портфель на фондовом рынке из-за последних геополитических событий превратился в сверхдолгосрочную инвестицию на 20–30 лет.
Криптопортфель показал минус 70 процентов за год — около 3000 долларов. Убыток пока бумажный, выходить из позиций я не стал.
С переходом на новую работу доход снизился примерно в три раза, а расходы остались прежними. Пришлось провести аудит: отключить неиспользуемые подписки, оптимизировать траты, перейти на более дешёвые решения. Итог — жизнь по средствам.
Финансовые цели на 2026 год простые и приземлённые:
1. Финансовая подушка безопасности.
2. Отпуск.
3. Наращивание криптопортфеля.
Системное администрирование
Из программиста я снова стал системным администратором. В работе — Asterisk, FreeBSD, ZFS, Debian, Zabbix.
👍7
FreeBSD оказалась отдельным испытанием. Она похожа на Linux ровно до первого серьёзного шага в сторону, а дальше начинаются собственные правила игры: свои ключи, свои подходы, свои грабли. Docker нет, вместо него — Jail. NodeJS пришлось собирать из исходников. Зато ZFS из коробки — мощь: снапшоты, кеширование, сжатие. Если бы не лицензия, эта файловая система давно стала бы стандартом де-факто.
DevOps
Основная система готовится к переезду в Kubernetes, поэтому год прошёл под знаком k8s. Я прошёл два курса и много практиковался. Kubernetes не столько сложный, сколько объёмный. Чтобы повторить возможности docker-compose даже на одной ноде, требуется минимум 1–2 месяца обучения, а также время и терпение.
Параллельно я поработал с Ansible и написал плейбук для первичной настройки Debian, познакомился со стеком Prometheus и Grafana и сделал демопроект для мониторинга WordPress. В сравнении с Zabbix связка Prometheus + Grafana показалась мне более гибкой и удобной.
Впереди — Terraform. Поднимать десятки серверов вручную желания нет.
Программирование
Фронтенд на текущей работе не нужен. Основной фокус — бэкенд и чат-боты для Bitrix24. Asterisk оказался куда сложнее, чем кажется: 25 лет разработки продукта и четыре разных программных интерфейса.
Я прошёл курсы по NodeJS и NestJS, прочитал книгу В. И. Светлакова «Архитектура бэкенда». Рост как специалиста ощущается отчётливо: от проблем с синтаксисом — к вопросам архитектуры и проектирования.
Я познакомился с очередями сообщений через RabbitMQ, следующим шагом для меня станет Kafka. Параллельно я изучал разные языки программирования: прошёл курс по Haskell и хочу попробовать Rust, C и C++. В конце года решил повторить использование SQL — отчёты по АТС быстро показывают пробелы в знаниях.
Сильное влияние на моё восприятие программирования оказали книги Тейта Брюса «Семь языков за семь недель» и «Код. Тайный язык информатики» Чарльза Петцольда. Они расширяют взгляд на Computer Science и заставляют иначе смотреть на привычные технологии.
Искусственный интеллект
В 2025 году я осознанно начал разбираться в AI. Раньше использовал его поверхностно, теперь понимаю, насколько плохо знал возможности инструментов. В 2026 году планирую идти глубже и использовать их более системно.
English
Летом я закрыл уровень B1+. Для текущей работы этого достаточно: документацию читаю, обучающие видео понимаю. Главное осознание — офлайн-курсы дают лишь небольшую часть результата, остальное обеспечивают самостоятельная практика и дисциплина.
Хобби, культура и отдых
Музыка осталась важной частью жизни. Домашний звук вышел на новый уровень, концерты и живые выступления по-прежнему радуют. Было много книг, спектаклей, экскурсий и лекций. Этот блок я намеренно оставляю кратким — он про эмоции и впечатления, а не про отчёты.
Итог
2025 год стал для меня годом тихой, но важной внутренней работы. Без показных побед, зато с честным взглядом на себя, свои ограничения и реальные возможности. Я выхожу из него не идеальным и не успешным по чек-листу, но более устойчивым и собранным. А значит, всё происходившее имело смысл.
DevOps
Основная система готовится к переезду в Kubernetes, поэтому год прошёл под знаком k8s. Я прошёл два курса и много практиковался. Kubernetes не столько сложный, сколько объёмный. Чтобы повторить возможности docker-compose даже на одной ноде, требуется минимум 1–2 месяца обучения, а также время и терпение.
Параллельно я поработал с Ansible и написал плейбук для первичной настройки Debian, познакомился со стеком Prometheus и Grafana и сделал демопроект для мониторинга WordPress. В сравнении с Zabbix связка Prometheus + Grafana показалась мне более гибкой и удобной.
Впереди — Terraform. Поднимать десятки серверов вручную желания нет.
Программирование
Фронтенд на текущей работе не нужен. Основной фокус — бэкенд и чат-боты для Bitrix24. Asterisk оказался куда сложнее, чем кажется: 25 лет разработки продукта и четыре разных программных интерфейса.
Я прошёл курсы по NodeJS и NestJS, прочитал книгу В. И. Светлакова «Архитектура бэкенда». Рост как специалиста ощущается отчётливо: от проблем с синтаксисом — к вопросам архитектуры и проектирования.
Я познакомился с очередями сообщений через RabbitMQ, следующим шагом для меня станет Kafka. Параллельно я изучал разные языки программирования: прошёл курс по Haskell и хочу попробовать Rust, C и C++. В конце года решил повторить использование SQL — отчёты по АТС быстро показывают пробелы в знаниях.
Сильное влияние на моё восприятие программирования оказали книги Тейта Брюса «Семь языков за семь недель» и «Код. Тайный язык информатики» Чарльза Петцольда. Они расширяют взгляд на Computer Science и заставляют иначе смотреть на привычные технологии.
Искусственный интеллект
В 2025 году я осознанно начал разбираться в AI. Раньше использовал его поверхностно, теперь понимаю, насколько плохо знал возможности инструментов. В 2026 году планирую идти глубже и использовать их более системно.
English
Летом я закрыл уровень B1+. Для текущей работы этого достаточно: документацию читаю, обучающие видео понимаю. Главное осознание — офлайн-курсы дают лишь небольшую часть результата, остальное обеспечивают самостоятельная практика и дисциплина.
Хобби, культура и отдых
Музыка осталась важной частью жизни. Домашний звук вышел на новый уровень, концерты и живые выступления по-прежнему радуют. Было много книг, спектаклей, экскурсий и лекций. Этот блок я намеренно оставляю кратким — он про эмоции и впечатления, а не про отчёты.
Итог
2025 год стал для меня годом тихой, но важной внутренней работы. Без показных побед, зато с честным взглядом на себя, свои ограничения и реальные возможности. Я выхожу из него не идеальным и не успешным по чек-листу, но более устойчивым и собранным. А значит, всё происходившее имело смысл.
👍8
Прошла первая неделя нового года. Итоги я подвёл, планы составил (см. прошлый пост) и, как говорил Леонид Ильич Брежнев: «Наши цели ясны, задачи определены. За работу, товарищи!».
В первую неделю нового года я решил заняться двумя вещами: изучить Rust и попробовать написать собственный язык программирования.
Почему Rust?
Что-то низкоуровневое я хотел изучить давно. Есть миф, что «настоящие программисты пишут только на C, C++ и ассемблере». Конечно, это не так.
Современный разработчик чаще пишет фичи, чем работает с железом. Он скорее водитель, чем механик. Но понимание того, как всё устроено внутри, всё равно даёт серьёзное преимущество.
Я посмотрел несколько видео про Rust.
«Язык Rust и функциональное программирование» https://www.youtube.com/watch?v=1Q3hGTqbH8Q
Главная мысль простая и очень здравая: лучшего языка не существует — есть язык под конкретный контекст. Функциональные языки вроде Elixir и Erlang отлично подходят для распределённых систем и бизнес-логики, но начинают проигрывать на тяжёлом парсинге и больших объёмах данных. В таких случаях уже уместен Rust: высокая производительность, контроль над памятью и заимствованные из функционального программирования идеи — ценой более высокого порога входа. На практике выигрывает гибридный подход: логика остаётся на высокоуровневых языках, а вычислительно нагруженные части реализуются на системных.
«OR: Rust без иллюзий» https://www.youtube.com/watch?v=sKNLaQtN7OA
Это прагматичный разбор без хайпа. Rust даёт безопасность памяти, строгий компилятор и хороший туллинг, но платой становятся сложная эргономика, медленная компиляция и непростая работа с unsafe-кодом и асинхронностью. Часто он уступает Go по скорости разработки. Вывод тот же: язык вторичен, первичны архитектура, работа с памятью и понимание операционных систем. Rust стоит изучать осознанно — как инструмент под конкретные задачи, а не как универсальный ответ на всё.
Я за гибридный подход. В Node.js без проблем встраиваются нативные модули на Rust, плюс есть WebAssembly, который тоже можно писать на нём. Если коротко: Rust — снайперская винтовка, Node.js — автомат Калашникова. Каждый хорош на своём месте.
Я уже начал изучать Rust. Пока курсы либо слишком поверхностные, либо слишком хардкорные. На данный момент больше всего зашли:
— https://metanit.com/rust/tutorial/
— https://rustlings.rust-lang.org/ - упражнения с починкой кода
— https://doc.rust-lang.org/book - официальный Rust Book
Зачем мне свой язык программирования?
На работе у меня горы кода на Asterisk, написанные задолго до меня. Формально всё работает, но любая правка превращается в археологические раскопки.
Основная проблема — мёртвый код: функции, которые никто не вызывает.
В идеале задача выглядит просто: построить граф вызовов и удалить всё, что не используется. Попытки решить это с помощью регулярных выражений не взлетели — код не только мёртвый, но ещё и битый. В этот момент и пришли на ум формальные грамматики и AST (Abstract Syntax Tree — абстрактное синтаксическое дерево).
Нашёл хорошее видео «Пишем свой язык программирования с нуля»
https://www.youtube.com/watch?v=iQHj1JWOLzA
Видео показывает, как и зачем на практике создают языки программирования: от реальных историй с DSL (Domain-Specific Language — предметно-ориентированный язык) в продакшене до базовой теории компиляции — лексера, парсера, AST и семантики — и её применения. Автор пошагово разрабатывает простой язык Kek: описывает грамматику, генерирует парсер с помощью ANTLR ([https://www.antlr.org/](https://www.antlr.org/)), добавляет выражения, переменные, условия, циклы и функции, а затем компилирует всё в WebAssembly, честно разбирая возникающие ограничения и баги.
Общий вывод простой: если правила становятся сложнее if-else, пора думать о грамматике и парсере, а не о костылях.
В первую неделю нового года я решил заняться двумя вещами: изучить Rust и попробовать написать собственный язык программирования.
Почему Rust?
Что-то низкоуровневое я хотел изучить давно. Есть миф, что «настоящие программисты пишут только на C, C++ и ассемблере». Конечно, это не так.
Современный разработчик чаще пишет фичи, чем работает с железом. Он скорее водитель, чем механик. Но понимание того, как всё устроено внутри, всё равно даёт серьёзное преимущество.
Я посмотрел несколько видео про Rust.
«Язык Rust и функциональное программирование» https://www.youtube.com/watch?v=1Q3hGTqbH8Q
Главная мысль простая и очень здравая: лучшего языка не существует — есть язык под конкретный контекст. Функциональные языки вроде Elixir и Erlang отлично подходят для распределённых систем и бизнес-логики, но начинают проигрывать на тяжёлом парсинге и больших объёмах данных. В таких случаях уже уместен Rust: высокая производительность, контроль над памятью и заимствованные из функционального программирования идеи — ценой более высокого порога входа. На практике выигрывает гибридный подход: логика остаётся на высокоуровневых языках, а вычислительно нагруженные части реализуются на системных.
«OR: Rust без иллюзий» https://www.youtube.com/watch?v=sKNLaQtN7OA
Это прагматичный разбор без хайпа. Rust даёт безопасность памяти, строгий компилятор и хороший туллинг, но платой становятся сложная эргономика, медленная компиляция и непростая работа с unsafe-кодом и асинхронностью. Часто он уступает Go по скорости разработки. Вывод тот же: язык вторичен, первичны архитектура, работа с памятью и понимание операционных систем. Rust стоит изучать осознанно — как инструмент под конкретные задачи, а не как универсальный ответ на всё.
Я за гибридный подход. В Node.js без проблем встраиваются нативные модули на Rust, плюс есть WebAssembly, который тоже можно писать на нём. Если коротко: Rust — снайперская винтовка, Node.js — автомат Калашникова. Каждый хорош на своём месте.
Я уже начал изучать Rust. Пока курсы либо слишком поверхностные, либо слишком хардкорные. На данный момент больше всего зашли:
— https://metanit.com/rust/tutorial/
— https://rustlings.rust-lang.org/ - упражнения с починкой кода
— https://doc.rust-lang.org/book - официальный Rust Book
Зачем мне свой язык программирования?
На работе у меня горы кода на Asterisk, написанные задолго до меня. Формально всё работает, но любая правка превращается в археологические раскопки.
Основная проблема — мёртвый код: функции, которые никто не вызывает.
В идеале задача выглядит просто: построить граф вызовов и удалить всё, что не используется. Попытки решить это с помощью регулярных выражений не взлетели — код не только мёртвый, но ещё и битый. В этот момент и пришли на ум формальные грамматики и AST (Abstract Syntax Tree — абстрактное синтаксическое дерево).
Нашёл хорошее видео «Пишем свой язык программирования с нуля»
https://www.youtube.com/watch?v=iQHj1JWOLzA
Видео показывает, как и зачем на практике создают языки программирования: от реальных историй с DSL (Domain-Specific Language — предметно-ориентированный язык) в продакшене до базовой теории компиляции — лексера, парсера, AST и семантики — и её применения. Автор пошагово разрабатывает простой язык Kek: описывает грамматику, генерирует парсер с помощью ANTLR ([https://www.antlr.org/](https://www.antlr.org/)), добавляет выражения, переменные, условия, циклы и функции, а затем компилирует всё в WebAssembly, честно разбирая возникающие ограничения и баги.
Общий вывод простой: если правила становятся сложнее if-else, пора думать о грамматике и парсере, а не о костылях.
👍4
Написание собственного языка — не магия. Вся теория известна давно, инструменты тоже есть: ANTLR, LLVM ([https://llvm.org/](https://llvm.org/)). Самое сложное здесь — не реализация, а экосистема. Моя задача куда проще: взять конкретный код, убрать всё лишнее и получить чистую, понятную базу. Посмотрим, что из этого выйдет.
YouTube
Язык Rust и функциональное программирование
Попробуйте пройти курс "Мидл-python разработчик" от Яндекс.Практикума — https://ya.cc/t/hXi8AHc7KrWWo
Первая часть бесплатно!
Канал гостя https://www.youtube.com/channel/UCGSkIYm61rlzMWLfEdqXlhQ
00:00 - Функциональщина, Rust и все все все
00:34 - платят…
Первая часть бесплатно!
Канал гостя https://www.youtube.com/channel/UCGSkIYm61rlzMWLfEdqXlhQ
00:00 - Функциональщина, Rust и все все все
00:34 - платят…
Началась первая рабочая неделя.
Взялся за задачу обработки входящих звонков для менеджеров по продажам. Идея простая: менеджер звонит клиенту — у клиента высвечивается номер отдела продаж, где работает сразу куча менеджеров. Потом клиент решает перезвонить в течение часа, набирает общий номер отдела, а система должна соединить его именно с тем менеджером, который звонил.
Решается это тоже просто: звонки сохраняются в базе данных, а программа сопоставляет номер клиента и номер менеджера обычным SQL‑запросом.
Начал писать программу, используя Asterisk Gateway Interface (AGI). И довольно быстро стало понятно, что без AGI SQL‑запрос из АТС вообще не вызвать — напрямую Астериск с базой не разговаривает.
Сразу начались проблемы, о которых я даже не подозревал.
Первое — логирование. Я решил писать все вызовы скрипта в собственный лог. Но внезапно оказалось, что данные не пишутся в файл. То ли права, то ли путь, то ли глобальные переменные — несколько часов бился в эту стену. В итоге плюнул и стал писать в лог Asterisk. С ним, как ни странно, никаких проблем не возникло.
Вторая боль — деплой.
Скрипт я разрабатываю на своём компьютере под Windows, а запускаться он должен на АТС под FreeBSD, в конкретной папке и с конкретными правами. Подключиться к серверу просто так нельзя — нужен сертификат. В результате я подставлял сертификаты, писал bash‑скрипт, который делает несколько разных настроек, чтобы мой код на FreeBSD вообще стартовал. Несколько часов ушло на то, чтобы по факту… скопировать и переименовать файл.
Самое смешное, что я думал: основной проблемой будет SQL‑запрос к MySQL. Использовал библиотеку mysql2 (https://www.npmjs.com/package/mysql2) — и тут всё завелось без единого сюрприза.
По вечерам изучал Rust.
Все курсы по Rust делятся на две крайности: либо для совсем новичков (что такое циклы, условия и переменные), либо сразу для матерых профессионалов — многопоточность, мультипроцессорные системы и прочая тяжёлая артиллерия. А мне нужно что‑то среднее.
Нашёл отличный курс «Программирование на Rust» (https://www.youtube.com/playlist?list=PLlb7e2G7aSpTfhiECYNI2EZ1uAluUqE_e). Лектор хорошо и подробно объясняет, постоянно сравнивает Rust с другими языками. Но есть нюанс — почти нет практики. А концепции в Rust хитрые, и без большого количества практики они просто не укладываются.
В какой‑то момент я поймал себя на вопросе: а почему вообще Rust?
Ответ для себя сформулировал такой: для расширения кругозора и понимания низкоуровневого программирования. И тут важно — низкоуровневое программирование не равно Rust. Полез дальше, нашёл лекции по C/C++ — буду осваивать их.
Да, Rust стоит на плечах C++, да, многие проблемы он реально решил. Но «упарываться» в Rust ради Rust я точно не собираюсь.
В итоге неделя получилась показательной: сама бизнес‑логика задачи оказалась самой простой частью, а реальная сложность, как обычно, всплыла вокруг — в логах, правах, деплое и окружении. Зато каждый такой затык наглядно показывает, где на самом деле проходят границы системы и почему одних знаний языка или библиотеки для работы с ней недостаточно.
Взялся за задачу обработки входящих звонков для менеджеров по продажам. Идея простая: менеджер звонит клиенту — у клиента высвечивается номер отдела продаж, где работает сразу куча менеджеров. Потом клиент решает перезвонить в течение часа, набирает общий номер отдела, а система должна соединить его именно с тем менеджером, который звонил.
Решается это тоже просто: звонки сохраняются в базе данных, а программа сопоставляет номер клиента и номер менеджера обычным SQL‑запросом.
Начал писать программу, используя Asterisk Gateway Interface (AGI). И довольно быстро стало понятно, что без AGI SQL‑запрос из АТС вообще не вызвать — напрямую Астериск с базой не разговаривает.
Сразу начались проблемы, о которых я даже не подозревал.
Первое — логирование. Я решил писать все вызовы скрипта в собственный лог. Но внезапно оказалось, что данные не пишутся в файл. То ли права, то ли путь, то ли глобальные переменные — несколько часов бился в эту стену. В итоге плюнул и стал писать в лог Asterisk. С ним, как ни странно, никаких проблем не возникло.
Вторая боль — деплой.
Скрипт я разрабатываю на своём компьютере под Windows, а запускаться он должен на АТС под FreeBSD, в конкретной папке и с конкретными правами. Подключиться к серверу просто так нельзя — нужен сертификат. В результате я подставлял сертификаты, писал bash‑скрипт, который делает несколько разных настроек, чтобы мой код на FreeBSD вообще стартовал. Несколько часов ушло на то, чтобы по факту… скопировать и переименовать файл.
Самое смешное, что я думал: основной проблемой будет SQL‑запрос к MySQL. Использовал библиотеку mysql2 (https://www.npmjs.com/package/mysql2) — и тут всё завелось без единого сюрприза.
По вечерам изучал Rust.
Все курсы по Rust делятся на две крайности: либо для совсем новичков (что такое циклы, условия и переменные), либо сразу для матерых профессионалов — многопоточность, мультипроцессорные системы и прочая тяжёлая артиллерия. А мне нужно что‑то среднее.
Нашёл отличный курс «Программирование на Rust» (https://www.youtube.com/playlist?list=PLlb7e2G7aSpTfhiECYNI2EZ1uAluUqE_e). Лектор хорошо и подробно объясняет, постоянно сравнивает Rust с другими языками. Но есть нюанс — почти нет практики. А концепции в Rust хитрые, и без большого количества практики они просто не укладываются.
В какой‑то момент я поймал себя на вопросе: а почему вообще Rust?
Ответ для себя сформулировал такой: для расширения кругозора и понимания низкоуровневого программирования. И тут важно — низкоуровневое программирование не равно Rust. Полез дальше, нашёл лекции по C/C++ — буду осваивать их.
Да, Rust стоит на плечах C++, да, многие проблемы он реально решил. Но «упарываться» в Rust ради Rust я точно не собираюсь.
В итоге неделя получилась показательной: сама бизнес‑логика задачи оказалась самой простой частью, а реальная сложность, как обычно, всплыла вокруг — в логах, правах, деплое и окружении. Зато каждый такой затык наглядно показывает, где на самом деле проходят границы системы и почему одних знаний языка или библиотеки для работы с ней недостаточно.
👍4
Про рабочие инциденты и обучение
Иногда рабочие задачи, обучение и случайные открытия неожиданно складываются в одну логичную цепочку. Ниже — небольшой срез последних событий: рабочий инцидент, погружение в низкоуровневое программирование и напоминание о том, что простых технологий не бывает.
Оптимизация телефонии
На работе у меня продолжается эпопея с оптимизацией телефонии.
Решил отключить ставшие ненужными телефонные номера. И, как это часто бывает, вместе с ненужными отключил очень даже нужные.
Самое интересное: крупный зелёный оператор официально отключает номера в течение 30 дней, но два нужных номера отключили уже через пару часов после официального письма.
На следующий день ушло ещё одно письмо, и на обратное включение потребовалось уже два дня.
Это были не критичные входящие номера, а номера из пула исходящих. Пул просто сократился с 18 до 16. Пользователи этого не заметили, никаких жалоб не поступало.
Тем не менее поволновался я изрядно.
Вывод простой: даже некритичные изменения в инфраструктуре не дают расслабляться.
Изучение C и низкого уровня
Параллельно начал изучать C и иду по курсу «Добрый, добрый C/C++ с Сергеем Балакиревым» на Stepik
https://stepik.org/course/193691/syllabus
Курс рассчитан на новичков, но при этом хорошо сбалансирован: без примитивности и без перегруза. Главное — много практики.
Прошёл пока около 10%, но уже достаточно глубоко погрузился в форматеры функций printf() и scanf(). С непривычки они даются непросто. Интересно, что похожий синтаксис спецификаторов используется и в современном Go.
Если кто-то считает, что C устарел — это не так. Он по‑прежнему жив и активно используется. По сути, C — это высокоуровневая обёртка над ассемблером, поэтому под микроконтроллеры до сих пор пишут именно на нём, и без понимания работы «железа» на низком уровне там не обойтись.
Отдельно для себя смотрю канал Olga Pavlova
https://www.youtube.com/@olgapavlova
После этого особенно хорошо видно, что USB и Wi‑Fi — далеко не простые протоколы.
Для меня это стало входом в совершенно новый мир низкоуровневого программирования.
Практика SQL
Также прошёл курс по SQL:
https://sql-academy.org/
Курс понравился и в целом оказался великолепным: удачное сочетание теории и практики. Продвинутые темы — оконные функции, транзакции и хранимые процедуры — освещены достаточно поверхностно, поэтому планирую разбирать их отдельно.
Сначала казалось, что сертификат получится быстро, но по окончании курса его не выдают автоматически — для получения требуется решить 50 практических задач, и с каждым уровнем они становятся сложнее, так что легко его не получить.
SQL оказался не таким простым, как я ожидал. Зато радует большое количество задач, на которых можно хорошо потренироваться. Это, пожалуй, лучший формат обучения.
Итог
В итоге всё это хорошо укладывается в одну картину: работа регулярно подкидывает неожиданные ситуации, а обучение помогает спокойнее к ним относиться и лучше понимать, что происходит под капотом. Чем глубже разбираешься в инструментах — от телефонии до C и SQL, — тем меньше сюрпризов и тем увереннее чувствуешь себя в повседневной инженерной рутине.
Иногда рабочие задачи, обучение и случайные открытия неожиданно складываются в одну логичную цепочку. Ниже — небольшой срез последних событий: рабочий инцидент, погружение в низкоуровневое программирование и напоминание о том, что простых технологий не бывает.
Оптимизация телефонии
На работе у меня продолжается эпопея с оптимизацией телефонии.
Решил отключить ставшие ненужными телефонные номера. И, как это часто бывает, вместе с ненужными отключил очень даже нужные.
Самое интересное: крупный зелёный оператор официально отключает номера в течение 30 дней, но два нужных номера отключили уже через пару часов после официального письма.
На следующий день ушло ещё одно письмо, и на обратное включение потребовалось уже два дня.
Это были не критичные входящие номера, а номера из пула исходящих. Пул просто сократился с 18 до 16. Пользователи этого не заметили, никаких жалоб не поступало.
Тем не менее поволновался я изрядно.
Вывод простой: даже некритичные изменения в инфраструктуре не дают расслабляться.
Изучение C и низкого уровня
Параллельно начал изучать C и иду по курсу «Добрый, добрый C/C++ с Сергеем Балакиревым» на Stepik
https://stepik.org/course/193691/syllabus
Курс рассчитан на новичков, но при этом хорошо сбалансирован: без примитивности и без перегруза. Главное — много практики.
Прошёл пока около 10%, но уже достаточно глубоко погрузился в форматеры функций printf() и scanf(). С непривычки они даются непросто. Интересно, что похожий синтаксис спецификаторов используется и в современном Go.
Если кто-то считает, что C устарел — это не так. Он по‑прежнему жив и активно используется. По сути, C — это высокоуровневая обёртка над ассемблером, поэтому под микроконтроллеры до сих пор пишут именно на нём, и без понимания работы «железа» на низком уровне там не обойтись.
Отдельно для себя смотрю канал Olga Pavlova
https://www.youtube.com/@olgapavlova
После этого особенно хорошо видно, что USB и Wi‑Fi — далеко не простые протоколы.
Для меня это стало входом в совершенно новый мир низкоуровневого программирования.
Практика SQL
Также прошёл курс по SQL:
https://sql-academy.org/
Курс понравился и в целом оказался великолепным: удачное сочетание теории и практики. Продвинутые темы — оконные функции, транзакции и хранимые процедуры — освещены достаточно поверхностно, поэтому планирую разбирать их отдельно.
Сначала казалось, что сертификат получится быстро, но по окончании курса его не выдают автоматически — для получения требуется решить 50 практических задач, и с каждым уровнем они становятся сложнее, так что легко его не получить.
SQL оказался не таким простым, как я ожидал. Зато радует большое количество задач, на которых можно хорошо потренироваться. Это, пожалуй, лучший формат обучения.
Итог
В итоге всё это хорошо укладывается в одну картину: работа регулярно подкидывает неожиданные ситуации, а обучение помогает спокойнее к ним относиться и лучше понимать, что происходит под капотом. Чем глубже разбираешься в инструментах — от телефонии до C и SQL, — тем меньше сюрпризов и тем увереннее чувствуешь себя в повседневной инженерной рутине.
👍4