Kurgan-Telecom Ru | Информационные технологии

В наше время программирование стало очень доступным из-за развития инструментов и языков. Написать «привет, мир» может практически каждый, а количество фреймворков для JavaScript уже воспевается в шутках. Теперь, чтобы выделиться и впечатлить друзей и коллег, нужно спускаться глубже. Придумаем свой язык шуточный программирования! 

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

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

Приветствую всех!

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

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

Sparkwriter4

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

Вообще говоря, когда видишь словосочетание «безлопастной», да ещё и «ветрогенератор», то это вызывает своеобразный когнитивный диссонанс, так как мы привыкли к абсолютно другому, и в нашем понимании, ветрогенератор частенько представляет собой огромную конструкцию, с внушительного размера лопастями… 

Однако, как выясняется, для генерации электроэнергии вовсе не обязательны такие менструозные конструкции, и, генератор может выглядеть (в самом простом варианте) — как просто, грубо говоря, вертикально установленная палка и пластина, причём, без каких-либо лопастей! При этом, какая-либо привычная нам механика, совершающая некое движение отсутствует!

Расшифровав человеческий геном (им, кстати, был геном самого Джеймса Уотсона, одного из авторов модели двойной спирали ДНК), ученые недолго довольствовались результатом. Наука концентрировалась на больших генах, кодирующих крупные белки длиной в ~300 аминокислот, но обнаружилось, что такие гены занимают всего ~1–2% ДНК. Все остальное, по логике экономии объяснений, решено было считать «мусором» — junk DNA, накопившимся побочным продуктом эволюции.

Еще до открытия структуры ДНК Уотсон и Крик наблюдали случаи, когда темный протеом (или «темная материя генома», по выражению журналиста New Scientist) вел себя далеко не пассивно. А через полвека обнаружилось: то, что считали шумом и мусором, скрывает миллионы smORF (малых открытых рамок считывания), способных кодировать небольшие белковые соединения — микропротеины.

По разным оценкам, в человеческом геноме может существовать ~3 млн таких потенциальных микробелков. Экспериментально подтверждено — лишь ~1 200. Функции известны и того меньше. Было очень мало способов понять, какие из них действительно важны.

Приветствую! В этой статье я расскажу, как мне удалось запустить DOOM на осциллографе Siglent SDS5034X. Для этого пришлось найти шелл (вендор получил мой репорт), адаптировать систему ввода игры под энкодеры на лицевой панели и вывести звук на встроенную «пищалку».

Привет, Хабр!

  Многие знают, что один из четырех всадников апокалипсиса типов собеседований в Бигтех — это так называемое «Behavioral interview». Этот тип собеседований вполне заслуженно считается самым недооцененным среди всех остальных. Казалось бы… Прийти и поговорить про опыт и поотвечать на всякие дурацкие вопросы непонятно зачем. 

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

На текущий момент у меня было 6 собеседований в Бигтех, и только один раз у меня получилось пройти эту часть. 5 раз я слышал что‑то вроде «Не хватило конкретики, на ваш опыт мы ожидали большего».

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

Давайте честно разберем архитектуру человека как программно-аппаратного комплекса.

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

Это, в свою очередь, подтолкнуло меня покодить на Си (чего я не делал сто лет) всякое, ориентируясь на WASM.

А это уже натолкнуло меня на мысль: а не подойдёт ли связка JS+WebAssembly как инструмент для создания минифицированных проектов в духе демосцены?

Короче, хоть я к демосцене никаким боком, но что мешает мне написать игрульку в сайз-факторе 4K? Исключительно for fun.

За последние пару лет я провёл сотни технических собеседований — от junior до senior специалистов. И я обнаружил что есть одна тема, с пониманием которой есть проблемы почти у всех кандидатов с кем мне доводилось общаться. Это Virtual DOM.

Почти каждый кандидат объясняет его примерно так:

“Virtual DOM нужен, чтобы обновлять не всю страницу, а только её часть. Поэтому всё работает быстрее.”

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

Комплекс pg_expecto помогает администраторам PostgreSQL собирать и структурировать статистику производительности, превращая сырые метрики в понятные отчёты. Однако ключевая проблема всегда оставалась неизменной: интерпретация данных. Именно здесь на помощь приходят большие языковые модели. Интеграция pg_expecto с DeepSeek позволяет выйти за рамки сухих цифр и графиков — нейросеть выступает в роли эксперта, который не просто фиксирует аномалии, но и объясняет причинно-следственные связи между падением скорости, ростом ожиданий и состоянием инфраструктуры.

В представленных отчётах DeepSeek не только выявил переход от проблем с записью к проблемам с чтением в первом инциденте, но и точно определил во втором случае виновника деградации — новый тяжёлый запрос на фоне острого дефицита памяти. Благодаря pg_expecto, нейросеть оперирует не догадками, а точными статистическими показателями (корреляциями, трендами R², приоритетами ожиданий), превращая процесс расследования инцидента из гадания по графикам в быстрый и доказательный анализ.

GitHub - Комплекс pg_expecto для статистического анализа производительности и нагрузочного тестирования СУБД PostgreSQL

Глоссарий терминов | Postgres DBA | Дзен

Привет, Хабр!

Меня зовут Виктор, и я хочу рассказать, как бытовая рабочая задача привела меня к тому, что я написал полноценный аудиоредактор, который работает целиком в браузере - без единого запроса на сервер. Под капотом - Web Audio API, OfflineAudioContext, порт LAME-энкодера на JavaScript и немного стыдных архитектурных решений, о которых тоже расскажу.

Сегодня утром я прошёл лайв-кодинг в одну англо-продуктовую компанию. Написал ноль строчек кода руками. Задеплоил результат на свою VPS прямо во время звонка. Интервьюер сказал: "It's so wonderful just how much everything has changed." А неделю назад другая компания не зачла мне тестовое, потому что я забыл про запрет AI.

20+ собесов за последние месяцы. Фронтенд, бэкенд, фулстек, AI-инженер. Python, TypeScript. Разные рынки, разные компании, совершенно разное отношение к одному и тому же инструменту. Я не теоретик, который рассуждает о будущем. Я прямо сейчас хожу на эти собесы и вижу, как рынок разламывается пополам.

В этой статье решим следующую задачу с межрегионального химического турнира

2023:

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

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

В Enterprise-разработке программного обеспечения прямо сейчас происходит точно такой же тектонический сдвиг, финал которого изменит не просто ИТ-индустрию, а само мироустройство.

Работая в крупном финтехе и пройдя путь от разработчика и техлида до руководителя направления разработки (управляя пятью командами) и ведущего архитектора решений, становится очевиден один факт: классическая кросс-функциональная Agile-команда из 7-8 человек необратимо теряет свою экономическую эффективность. Изменилась сама природа создания систем.

Я год наблюдал, как в нашей команде junior и middle разработчики почти полностью пересели на автогенерацию кода. Сначала это выглядело как ускорение. Через несколько месяцев начали всплывать странные эффекты: деградация архитектурного мышления, рост скрытого техдолга и зависимость от подсказок. В этой статье — не морализаторство, а практические наблюдения, конкретные примеры кода и вопросы, которые мне самому пришлось себе задать.

Я думаю, многие айтишники не любят принимать заявки от пользователей по телефону. Многим знакома ситуация, когда служебный телефон находится в режиме «без звука», и только индикатор активности линии выдаёт, что кто‑то пытается дозвониться до IT‑отдела. Или когда айтишники редко находятся на рабочем месте, а координатора в отделе, который бы принимал заявки и передавал их затем своим коллегам, нет. Раздавать свой личный номер всем я, например, не хочу — иначе замучают потом звонками по всякой ерунде.

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

Мы с коллегой долго решали, что всё‑таки использовать для решения задачи сбора заявок от пользователей в нашей небольшой поликлинике. Пробовали различные мощные Service Desk и Help Desk‑системы, даже настроили GLPI — кто не знает, это такой «монстр», который может много: начиная от инвентаризации всех устройств в сети до работы в качестве Service Desk‑системы для сбора заявок от пользователей. Но чтобы настроить шлюз для получения почты, нужно столько лишних движений сделать, что просто диву даёшься, как можно было так «заоверинжинирить» систему, что ею просто не хочется пользоваться. К тому же работа через email — это не то, чего мы хотели. Это сложно и как‑то уж чересчур формализованно.

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

Мы проводим Школу программистов hh уже в 16-й раз. За это время через программу прошли сотни студентов, 115 выпускников в итоге стали частью команды hh и продолжают с нами работать. Формат Школы остается практичным и прозрачным: три месяца теории и четыре месяца командного проекта под руководством наших инженеров — реальная работа над продуктом с ментором из компании, а не сухие учебные примеры.

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

В этой статье я проведу традиционный разбор вступительных заданий в нашу Школы программистов, которая для многих становится реальным шансом попасть в hh.ru.

Человек всю свою история учился справляться со страхом. Сначала он молился богам, потом возводил стены, потом научился считать. Теперь он роет убежища — не в панике, а с расчётом. Девять квадратных метров спасают людей каждый день. Подвал за двадцать тысяч долларов даёт неделю независимости. Люксовый комплекс за десять миллионов пытается решить задачу, которую деньги не могут полностью решить: как остаться человеком, когда ты заперт под землей? Поговорим об инженерии, которая встречается с психологией. И том, как мы считаем риски и покупаем время.

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

Это разбор реального опыта внедрения доступности в крупном веб-продукте с десятками микросервисов и сложным фронтендом. Без лозунгов, зато с кодом, ошибками, переработками дизайн-системы и неожиданными проблемами в CI. Поговорим про ARIA, серверный рендеринг, мобильные скринридеры, автоматическое тестирование и про то, почему доступность — это не про alt у картинок, а про архитектуру.

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

Мы работали над крупной B2B-платформой. Много форм, таблиц, кастомных контролов, графиков, drag-and-drop, модалки внутри модалок. И в какой-то момент заказчик сказал: продукт должен соответствовать WCAG 2.1 AA. Причём не формально, а чтобы им реально могли пользоваться люди с ограничениями по зрению и моторике.

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

Давайте по порядку.