Один из пользователей сервиса Highload.fun Joad Nacer прогнал все задачи через GPT O1 и получил интересный результат:
По 2024 году результат расположился на 20 месте с 3,574 очками, как я понимаю код был на C++. В целом нормально, но я, непрофессиональный кодер на C#, разместился на 23 месте, так что я бы оценил кодерство ИИ на уровне студента 1-го курса непрофильной специальности.
Индексация в языках программирования: не всегда с нуля?
Решая задачки на LeetCode, периодически натыкался на уточнение: "Given a 0-indexed array...". Сейчас решил разобраться с этим термином — ведь я, как двоечник-самоучка всегда думал (так учат на курсах), что индексация в массивах во всех языках программирования начинается с 0. Оказалось, это не так! В некоторых языках, индексация начинается с 1. Делюсь своими находками. 😊
Языки с индексацией с 1
Некоторые языки программирования используют 1 в качестве начального индекса массива. Вот примеры таких языков:
MATLAB: часто применяется для научных и инженерных расчетов.
R: используется в статистике и анализе данных.
Lua: популярен в разработке игр и встраиваемых систем.
Fortran: применяется в численных расчетах и научных исследованиях.
COBOL: основной язык для финансовых систем и работы с легаси-кодом.
Pascal (по дефолту): был популярен в прошлом, сейчас чаще используется для обучения.
Мой опыт
Из этого списка я знаком с несколькими языками:
Pascal: мы писали на нем в школе. До сих пор помню шок от задач на массивы и циклы))
MATLAB: изучали в университете, кажется для работы с матрицами.
Fortran: слышал о нем в подкастах, но лично не работал.
Удачи, работяги!
Буквально на днях со мной произошла интересная история, которой я хочу поделится с Вами.
Я состою в одном чатике, где собрались энтузиасты Telegram Mini Apps. Там фаундеры, разработчики и просто интересующиеся обсуждают идеи, делятся опытом и помогают друг другу. Мне очень интересна эта тема, и я планирую запустить что-то своё на базе Telegram.
Но ближе к делу. 2 января в чат зашёл человек в поисках разработчика для своего проекта. Он выглядел весьма взволнованным и объяснил, что помимо долгосрочного сотрудничества ему срочно нужен фикс для его мини-приложения. Это небольшое приложение с игровой механикой, у которого Monthly Active Users (MAU) — около 30 тысяч. Впечатляет, согласитесь! Проблема заключалась в том, что текущие разработчики ушли на праздники и не выходили на связь.
Я решил попробовать помочь просто ради интереса. Сидел за компьютером, пытаясь дописать свою дипломную работу, а мозг требовал смены деятельности. Когда мне дали доступ к репозиториям, я увидел следующее:
Проект довольно крупный: около 10k строк кода на фронтенде и 5k строк на бэкенде.
Фронтенд написан на React с использованием Jotai для управления состоянием. Интерфейс реализован с помощью Tailwind CSS.
Бэкенд — Express.js, взаимодействующий с MongoDB.
Весь проект написан на чистом JavaScript, и вот что меня поразило:
Полное отсутствие типов. Никакого TypeScript, PropTypes или хотя бы JSDoc. После нескольких лет работы с TS мне было трудно принять, что я не могу быстро понять, какие аргументы ожидаются в функциях. Я думал что все крутые проекты используют TS, а JS только для маленьких проектов, обучения и чего-то не совсем серьезного.
Полное отсутствие безопасности. Захардкоженные ключи для подключения к телеграм боту и базе данных. Сервер обрабатывает запросы с любого origin. Это буквально учебник по тому, как не надо делать.
Нарушение принципов DRY. Например, в коде вручную прописывались заголовки для fetch-запросов — везде, где только можно.
Неоптимальный код. Неправильный вызов хуков, отсутствие lazy loading, дублирование логики и так далее. Я могу продолжать список почти бесконечно.
В общем, код был ужасен. Даже мои студенты, которые только начинают изучать программирование, иногда пишут лучше. Но! Несмотря на всё это, продукт работал, пользователи были довольны, и проект приносил прибыль.
Я быстро разобрался с багом, исправил его и в итоге получил предложение помочь улучшить проект. В ближайшие пару недель как раз займусь этим — заработаю сыну на шоколадки и, надеюсь, сделаю код немного лучше. А теперь — к выводам, которые я сделал (а точнее получил подтверждение в очередной раз):
Выводы:
Работа и подработка всегда найдутся. Если у вас есть знания и навыки, найти проект даже в текущее время— не проблема. Главное — свободное время и скилл. Я получил подтверждение этого тезиса в очередной раз и последние несколько лет я понимаю, что возможность зарабатывания денег ограничивается только наличием свободного времени для этого. Ну и осознав это я пытаюсь найти варианты, которые напрямую не связаны с обменом моего времени на деньги. Во многом моя попытка раскачать телеграмм канал именно об этом.
JS жив и приносит прибыль. Люди продолжают писать серьёзные проекты на JavaScript. Да, TypeScript стал стандартом в моей работе, но это не мешает другим писать на чистом JS и чувствовать себя отлично.
Маркетинг побеждает. Код, который я видел, был ужасен. Но приложение успешно благодаря сильному маркетингу. Это очередное подтверждение фразы: “Best products never win. But best sales & marketing always win.” Как программисты, мы должны стремиться к чистому коду и хорошей архитектуре, но успех продукта в конечном счёте определяется вовсе не этим.
А что вы думаете о роли маркетинга? Согласны ли вы, что он может перевесить техническую сторону?
Если вам интересны темы веб-разработки, тимлидства, управления проектами и вы хотите получать больше полезного контента, присоединяйтесь к моему Telegram-каналу.
Гордость "настоящего программиста" - это нечто. Он учился! У него и справка (диплом, сертификат) есть! Он крутой профессионал, с хорошей теоретической подготовкой!
Поэтому простую функцию он просто написать не может. Он ее напишет максимально вычурно, с использованием специфических для его любимого языка приемов.
То, что можно было написать в десяток строк - уложит в одну, то, что можно было написать в одну - развернет в несколько функций.
У него для этого и обоснование найдется соответствующее (ну, если не копать совсем глубоко, всё-таки он программист, а не железячник).
А потом его творение идет в прод, а он сам, через некоторое время, меняет работу. И вот тут-то оказывается, что никто не понимает как оно работает - потому что его код после ряда обновлений работать перестал, а новые программисты любили другой язык программирования, и им непонятно как работает вот это brmd ff-?d(!-[~dde][df] - 8, и почему именно 8?
И тогда, с матами или без оных, весь кусок переписывается целиком. И приходится изображать злого надсмотрщика, чтобы очередной талант с сертификатом и хорошей подготовкой писал, цуко, понятно даже всяким дуболомам.
Ибо пройдет время и кто-то будет пытаться понять, почему для вычисления 2 * 2 использована самая модная на тот момент система библиотек со 100500 зависимостями, не поймет, и будет переписывать снова, тратя время и деньги.
А может посадить несколько разных LLM-ок, и пусть они код пишут и друг за другом дорабатывают?
И еще одну, чтобы ими руководила...
Вклад инженеров Axiom JDK в развитие OpenIDE
На текущий момент среди разработчиков Java в качестве основной среды разработки применяется IntelliJ IDEA. Однако, коммерческая версия этого и других продуктов JetBrains, включая IDE, Code With Me, Upsource, TeamCity и Space, а также техническая поддержка теперь не доступны в России. Это побудило нас на создание продукта OpenIDE с открытым исходным кодом и всей инфраструктурой, размещенной на территории РФ.
Как было анонсировано ранее, OpenIDE создается на базе исходного кода IntelliJ IDEA CE и будет развиваться в рамках некоммерческого партнерства Axiom JDK, «Группы Астра» и Haulmont. В этом посте мы расскажем о вкладе команды Axiom JDK в проект.
Рантайм Axiom JDK будет предоставляться в качестве выбора по умолчанию для разработки на Java/Kotlin в OpenIDE. Дополнительно будет возможна установка Axiom JDK из интерфейса OpenIDE. При этом релизный цикл Axiom JDK синхронизирован с OpenJDK и регулярными обновлениями.
Команда Axiom JDK будет выпускать и поддерживать рантайм, используемый для запуска OpenIDE, с набором улучшений. Это, например, расширенное переопределение классов c помощью DCEVM и поддержка JCEF фреймворка для встраивания браузера на базе Chromium. Также планируется ряд улучшений для рендеринга шрифтов, поддержка режимов HiDPI, что обеспечит лучшее масштабирование интерфейса пользователя. А еще это позволит исправлять специфичные для работы IDE ошибки, исправлений для которых еще нет в OpenJDK.
Несмотря на то, что исходный код IntelliJ IDEA CE открыт, в процессе работы IDEA обращается к серверам JetBrains для обновлений, поддержки маркетплейса плагинов, а также других нужд. Этот функционал сейчас перерабатывается с участием инженеров Axiom JDK, что позволит создать локальную российскую библиотеку плагинов, локализованный (и отключаемый) сбор статистики и механизм обновления OpenIDE.
Наконец, команда Axiom JDK занимается настройкой сборочного конвейера OpenIDE, и со временем произведет анализ всех OSS зависимостей OpenIDE и будет обеспечивать оперативное исправлений уязвимостей в ОSS зависимостях в рамках релизного цикла OpenIDE.
Релиз продукта намечен на март 2025 года.
Axiom JDK — единственный российский разработчик JDK. Инженеры команды стояли у истоков Java в России и развивают платформу более 25 лет.
OpenIDE можно использовать взамен IntelliJ IDEA CE. По данным нашего исследования, 78% Java разработчиков используют IntelliJ IDEA Ultimate, а 47% - работают на Community Edition. Мы хотим предоставить сотням тысяч разработчиков открытый инструмент, не уступающий по удобству привычным IDE, чтобы они могли быстро и эффективно работать.
97% языков программирования в мире используют семантическое версионирование.
У узкопрофильных, технических статей на Хабре нередко интересная судьба: их активно добавляют в закладки, мало просматривают на момент выхода и обращаются к ним позже (ну или не обращаются, потому что закладки бывают слишком долгим ящиком). Мы поработали за вас и выбрали 10 полезных туториалов из 2024 года, которые добавили в избранное более 50 раз, но просмотрели менее 3000. И кажется, это серьёзные технические статьи, которые можно почитать для работы или учёбы, разобраться, забрать себе толковые идеи.
Алгоритм перевода видео/аудио с любого языка на любой язык в 10 шагов
Машинное обучение: Наивный байесовский классификатор. Теория и реализация. С нуля
Машинное обучение: Кластеризация методом K-means. Теория и реализация. С нуля
Машинное обучение: Логистическая регрессия. Теория и реализация. С нуля
Как адаптировать терминальные отчёты pytest под свои интересы
Анимации Hover и эффекты Blur: Полный гид по созданию динамических карточек
Глубокое погружение в хуки pytest: как и зачем их использовать
А что интересного лежит у вас в закладках и часто ли вы к ним обращаетесь?
Знаете как часто это бывает, когда разработчики говорят что мой код, который я написал полгода назад сейчас выглядит отвратительно. Знакомо? Через это проходят все, кто так или иначе начинает заниматься разработкой и нарабатывает опыт в свои первые годы. Но сколько это может продолжаться?
Я думаю, что если ваши первые годы прошли удачно, то есть вы попали в профессиональную команду с хорошей инженерной культурой, то за 3 года вы выйдете на уровень, когда старый код будет выглядеть нормально для тех задач и тех условий в которых он был написан. Да любой код устаревает это правда, но легаси не означает что код плохой, просто изменились обстоятельства. Этот процесс может занять и больше времени, но если после 5 лет разработки старый код по прежнему выглядит плохо, то здесь явно что-то надо менять в профессиональном плане.
Смотря назад, я понимаю что поворотным моментом в моей карьере стал период, когда я увлекся функциональными языками и курсом СИКП, по которому потом во многом строилось обучение на Хекслете. Произошло это так, я видел что вокруг меня, многие профессионалы, говорят и используют функциональные языки и какие-то связанные с этим подходы. В тот момент речь шла про erlang, scheme/racket (для сикпа), clojure и haskell, которые я в разной степени начал изучать. На эрланге даже получилось сделать проект codebattle.hexlet.io, который потом, спустя много лет переписали на elixir (это опенсорс).
Изучение этих языков многое перевернуло в моей голове и дело даже не в том что они функциональные, а в том, что в среде программистов на этих языках поднимались вопросы, с которыми я раньше не сталкивался. Я понял что смотрел на разработку не на том уровне. Весь мой предыдущий опыт был скорее в стиле вот чистый код, вот мартин, вот фаулер, вот ООП, вот паттерны. Как оказалось, несмотря на здравые мысли в этой части, все же это была оболочка, а не фундамент. А фундамент лежал в таких областях как управление состоянием, изоляция побочных эффектов, конечные автоматы, statefull/stateless части системы и тому подобное.
Во время чтения и решения книги СИКП я реализовал свое ООП, полностью поняв смыслы и как оно работает, в чем соль динамической диспетчеризации особенно множественной, чего не рассказывают в обычных книгах по ООП. Оказалось, что многое о чем пишут в классике (аля книги по java), это лишь поверхностные вещи или особенности работы конкретных языков, а не фундаментальные концепции.
И так далее, почти по каждой теме произошло очень серьезное переосмысление, стала очевидной разница между концептуальными подходами при решении задач программирования и конкретными решениями вызванными особенностями или ограничениями языков.
p.s. Делюсь опытом программирования в своем телеграм-канале организованное программирование
Подборка статей про LLM, компьютерное зрение и машинное обучение
Doubletapp занимается машинным обучением уже 6 лет. В далеком 2018 году мы получили первый проект с нейросетью (смотрите первую статью подборки). Кейс оказался удачным, после него посыпались другие заказы, так мы год за годом наращивали экспертизу в обучении языковых моделей, интеграции LLM и RAG, которая может пригодиться вам, наши читатели. Поэтому делимся статьями, написанными нашими ML-специалистами:
👉 Прости нас, Джон Коннор, или Как мы научили нейросеть точечно распознавать звуки выстрелов
WebTransport: будущее потокового вещания и коммуникаций.
В сети появились интересное, как по мне, видео с конференции rubyconf2024. В нем рассказывается об эволюции веб-протоколов передачи данных, от веб-сокетов до веб-транспорта, а также грядущую спецификацию HTTP 3. Из видео можно узнать о двунаправленной потоковой передаче, дейтаграммах и потенциале веб-кодеков для потоковой передачи видео.
Всем кому любопытно, то рекомендую к просмотру: https://youtu.be/WqYExpMWIUU?si=p4gSGHXkhHAS4LK_
Для питонистов и тем кому интересно хочу перекомендовать к прочтению статью о webtransport и библиотеке на python aioquic [habr].
Что такое веб-транспорт?
Web Transport — это новый веб-протокол, разработанный для улучшения существующих решений, таких как WebSockets и события, отправляемые сервером (SSE). Хотя Web Transport часто называют «WebSocket 2.0» из-за его расширенных возможностей, он предлагает более тонкие функции, такие как однонаправленная и двунаправленная потоковая передача, дейтаграммы и улучшенная обработка частичной надёжности. В настоящее время этот протокол поддерживается в виде черновика основными браузерами, такими как Firefox и Chrome, а вскоре его поддержка появится и в Safari.
Ключевые особенности
Двунаправленная и однонаправленная потоковая передача: веб-транспорт поддерживает оба типа потоковой передачи, что делает его универсальным для различных задач.
Дейтаграммы: в отличие от более ресурсоёмких веб-сокетов, дейтаграммы требуют меньше ресурсов и допускают потерю пакетов, что может быть преимуществом в сценариях, где надёжность не является критически важной.
Приоритетная обработка: особенно полезна для таких приложений, как потоковое видео, где определённые критические кадры могут иметь приоритет над другими для обеспечения более плавной работы пользователя.
Исследование мошеннической активности, связанной с накруткой звёзд на GitHub, проанализировало данные о 15 835 репозиториях и 278 000 аккаунтов, участвовавших в кампаниях по созданию фальшивых звёзд. Основные выводы включают:
Ограниченное распространение фальшивых звёзд:
Лишь небольшое количество репозиториев с накрученными звёздами публикуются в пакетных регистрах, таких как npm или PyPI.
Ещё меньше достигают широкой популярности.
Короткий срок существования:
Большинство репозиториев, участвующих в накрутке звёзд, существуют лишь несколько дней.
Основное содержимое:
Многие из этих репозиториев связаны с пиратским программным обеспечением, игровыми читами и криптовалютными ботами.
Однако зачастую они представляют собой замаскированный кликбейт с вредоносным ПО.
Эффективность фальшивых звёзд:
Покупка фальшивых звёзд может временно увеличить видимость репозитория, обеспечивая краткосрочные преимущества (менее двух месяцев).
Однако их влияние в 3–4 раза меньше, чем от реальных звёзд, и в долгосрочной перспективе это может нанести ущерб репутации.
Данное исследование подчеркивает распространённость мошеннических практик и их ограниченную эффективность, что акцентирует необходимость повышенной бдительности в отношении накрутки звёзд для сохранения целостности платформ, таких как GitHub.
Подборка подкастов про IT-команды 🎧
Привет, Хабр! Мы продолжаем подводить итоги 2024 года.
В этом году у Cloud.ru вышло 34 подкаста: приглашали крутых спикеров и экспертов из мира IT, говорили про смену профессии в 30+, важность pet-проектов, карьерный рост, frontend-разработку, участие в IT-конференциях и многое другое.
Сделали для вас мини-подборку про управление и развитие IT-команд:
ex-СТO Авито Анатолий Панов — про искусство управления в IT,
Андрей Смирнов — про путь руководителя, значимость окружения в IT,
Константин Мягких из Авито — про эволюцию команды, которая занимается data science,
Роман Тимонин из СБОЛ про — про развитие инженеров в компании и повышение сотрудников,
Виталий Левченко из Яндекса — алгоритмы собеседования и матрицу компетенций,
Глеб Михеев — о мотивации, развитии команды и будущем IT-индустрии.
Остальные подкасты можно посмотреть на нашем YouTube-канале. А в комментариях пишите — кого еще хотели бы увидеть в качестве гостей и про какие темы послушать в следующем году?
9 законов программирования для новичков и опытных, без которых невозможно добиться успеха в проекте.
Закон Брукса — если вы посадите трёх кодеров за одну задачу, они не сделают её в три раза быстрее. Чем больше ваша команда, тем сложнее становится координация и планирование.
Закон Гудхарта — чем жестче ваши KPI и метрики для измерения эффективности, тем сильнее они отвлекают от выполнения самих задач. В самых запущенных случаях люди забивают на задачи и переключаются только на KPI.
Закон Хайрама — чем больше у API пользователей, тем сильнее они полагаются на незадокументированные особенности, превращая их в «обязательные» функции. Из‑за этого любые изменения становятся сложными, ведь легко сломать что‑то для тех, кто уже привык к старым фишкам.
Закон Конвея — структура программ часто повторяет организационную структуру команды, которая её создала. Если слепо следовать границам в команде, софт получится неоптимизированным.
Закон Линуса — база опенсора. Чем больше людей проверяют код, тем больше шансов найти ошибку.
Закон Хофтшадтера — дедлайн всегда нужно ставить с запасом. Мы склонны занижать количество времени, необходимое для выполнения задачи.
Закон Кернигана — код всегда должен быть простым и понятным. Сложный код всегда становится неподъёмным в отладке и сопровождении — это только вопрос времени.
Закон Питера — софт‑ и хард‑скиллы, это разные навыки. Так, топовый кодер не обязательно обладает такими же способностями к управлению людьми, руководству командами или выполнению стратегических требований лидерства.
Закон Парето — усилия должны быть избирательными. Чтобы 20% усилий приносили 80% результатов, сначала нужно понять, куда прикладывать эти усилия. Качество всегда перевешивает количество, а результат важнее времени затраченного на задачу.
Зачем нужен code review
Выстроенный code review позволяет:
— найти баги и не пропустить их в прод. Конечно, в дополнение к статическому анализу с помощью настроенного pre-commit и тестам;
— выявить проблемы в архитектуре;
— сделать код единообразным. Спорный тезис, за единообразие должны отвечать линтеры и автоформатирование. Но code review помогает наладить те вещи, которые автоформатирование не тянут, например, именование переменных.
В долгосрочной перспективе постоянные code review:
— налаживают обратную связь между участниками;
— бустят уровень разработчиков, позволяя учиться на своих и чужих ошибках и давая обширную практику чтения чужого кода;
— помогают делиться знаниями о технологиях, вариантах решения проблем, возможных проблемах и самом проекте в команде;
— дают приток новых идей для улучшений в процессах, подходах и автоматизации;
— увеличивают децентрализацию знаний и bus factor.
В статье даны примеры хорошего и плохого code review, способы прокачки и вообще много разных нюансов.
Популяризатор Perl Рэндал Шварц представил обновлённую версию своего доклад, посвящённого истории Perl, который он уже делал однажды, но качество записи ранее было недостаточным. На полуторачасовм видео Шварц рассказал о создании Camel Book, Llama book и о том, как он вторгся в comp.unix.questions с ответами Perl 2 так часто, что люди писали «никакого Perl, пожалуйста». Также Шварц представил свою версию истории о Шварцевском преобразовании.
Запускаем бесплатную программу обучения по Node js в Web3
Привет всем! Мы в MetaLamp давно занимаемся обучение разработчиков, у нас есть свои программы обучения по фронтенду и бэкенду, а недавно мы запустили обучения по смарт-контрактам Solidity и фронтенду в web3.
Теперь мы решили расширить список наших курсов и создали программу обучения по Node.js в связке с web3.
Почему все говорят про Node.js
Node.js уже давно стал одним из главных инструментов для разработки серверной части. Его используют, чтобы строить быстрые и масштабируемые веб-приложения и не только. К примеру, Netflix, LinkedIn и Uber сделали Node.js значимой частью своей инфраструктуры. Так что эта платформа не просто тренд, а эффективный инструмент.
Кроме того, JavaScript (js), на котором базируется Node.js, занимает лидирующие позиции среди языков программирования. И это легко объяснить. Он универсален, используется как на фронтенде, так и на бэкенде, и у него огромное сообщество. Node.js уверенно стоит на первом месте среди серверных технологий. Освоивший ноду, во-первых, станет специалистом по серверным технологиям. Во-вторых, сможет легко изучить фронтенд и перейти в лигу fullstack.
И еще одна приятная деталь: зарплаты в этой сфере радуют. По данным Хабр Карьера, джуниоры на Node получают около 85 тысяч рублей, мидлы — 220 тысяч, а сеньоры могут зарабатывать до 330 тысяч рублей в месяц.
Читайте подробнее о программе в нашей новой статье!
В нашем телеграм-канале мы часто обсуждаем новые инструменты для разработчиков, делаем обзоры продуктов и все вместе обсуждаем новости. В комментариях под постами — у нас отдельный холивар. Присоединяйтесь!
Google выпустила новое API для Protocol Buffers в Go
Команда Go представила новое API для работы с Protocol Buffers, получившее название Opaque API. Это важное обновление, которое должно сделать работу с protobuf более эффективной и безопасной.
До сих пор в Go использовалось так называемое Open Struct API, где все поля структур были доступны напрямую. Например, так:
type LogEntry struct {
BackendServer *string
RequestSize *uint32
IPAddress *string
}С новым Opaque API все поля становятся приватными, а доступ к ним осуществляется через методы:
type LogEntry struct {
xxx_hidden_BackendServer *string
xxx_hidden_RequestSize uint32
xxx_hidden_IPAddress *string
// …внутренние поля опущены
}
// Доступ через методы
func (l *LogEntry) GetBackendServer() string
func (l *LogEntry) HasBackendServer() bool
func (l *LogEntry) SetBackendServer(string)
func (l *LogEntry) ClearBackendServer()
//...Зачем это сделано?
Новый подход значительно экономит память. Вместо использования указателей для хранения информации о наличии значения в поле (presence), теперь используются битовые поля. В некоторых случаях это позволяет сократить количество аллокаций памяти почти на 60%. (речь идет про элементарные типы, такие как целые числа, булевы и т.д)
Появилась возможность реализовать ленивое декодирование сообщений. Теперь вложенные сообщения декодируются только при первом обращении к ним, а не при общей десериализации. Для некоторых приложений это дает колоссальный прирост производительности и уменьшает аллокации
Новое API предотвращает некоторые ошибки. Например, раньше было легко случайно сравнить указатели вместо значений при работе с enum:
/*
message LogEntry {
enum DeviceType {
DESKTOP = 0;
MOBILE = 1;
VR = 2;
};
DeviceType device_type = 1;
}
*/
// Неправильно и незаметно:
if cv.DeviceType == logpb.LogEntry_DESKTOP.Enum()
// Правильно:
if cv.GetDeviceType() == logpb.LogEntry_DESKTOPС новым API такая ошибка просто невозможна, так как прямого доступа к полям нет.
Еще одно улучшение касается работы с reflection. Раньше разработчики могли случайно использовать стандартный пакет reflect вместо специального protobuf-reflection, что приводило к неожиданным результатам. Теперь такие ошибки исключены.
Google предлагает постепенный путь миграции через "гибридное" API, которое поддерживает оба способа работы. Для новых проектов рекомендуется сразу использовать Opaque API. В 2024 году оно станет стандартным подходом в новой версии Protocol Buffers (Edition 2024).
Старое API никуда не исчезнет – принцип обратной совместимости.
Для перехода на новое API Google предоставляет инструмент open2opaque, который помогает автоматически переписывать код. Внутри самого Google большинство protobuf-файлов уже переведено на новое API, и оно активно используется на проде.
cross-пост из tg-канала Cross Join
Ежемесячный дайджест: новое за ноябрь🌥️
📺 Провели вебинары:
Как мигрировать IT-инфраструктуру в облако с минимальными рисками: опыт Cloud.ru и ALP ITSM,
Безопасность облачной инфраструктуры: стратегия и инструменты противодействия,
Как подтвердить знания про облака: анонс новых курсов и сертификации,
🛍️ Добавили универсальные решения для мониторинга и визуализации данных на Маркетплейсе Cloud.ru: Grafana, Kibana и Prometheus. Их совместное использование поможет быстро реагировать на любые изменения и неполадки в IT-инфраструктуре.
⚙️ Поделились обновлениями сервисов на наших облачных платформах в дайджесте на сайте. Например, в Evolution Managed Kubernetes теперь можно выбрать:
сервисный аккаунт для интеграции с другими сервисами Cloud.ru при создании кластера;
расширения и уменьшения группы узлов при создании группы во время обновления версии.
💼 В новых кейсах рассказали, как:
Новосибирский государственный университет разместил умного чат-бота в Telegram с помощью ресурсов облака Cloud.ru Evolution;
компания MOST увеличила производительность приложения и сократила затраты после миграции IT-структуры в облако Cloud.ru Advanced.
💸 Предлагаем зарабатывать вместе с Cloud.ru: присоединяйтесь к реферальной программе, рекомендуйте наши облачные сервисы клиентам, коллегам или друзьям и получайте вознаграждение 15%. Участвовать могут не только юридические лица и ИП, но и физические лица, а также самозанятые.
До встречи в следующем году!
Pre-commit — must have утилита любого проекта
Бывает, смотришь на код и сразу видно, что код плохой. Признаков может быть множество:
— разные куски кода по-разному отформатированы;
— импорты в файлах никак не структурированы;
— используются вперемешку синтаксис старых и новых версий питона;
— где-то видны зачатки использования типов, но не везде;
— где-то docstring есть, где-то нет;
Всё это характеризуется так: нет единого стиля в написании кода. Проблема становится особенно актуальной, когда над проектом трудится несколько разработчиков.
Частично эту проблему решает встроенный в среду разработки анализатор кода или запускаемые вручную анализаторы кода. Но анализатор в среде разработки может быть настроен по-разному у разных членов команды. Если в проекте принято использовать несколько анализаторов одновременно, то разработчик может забыть прогнать код через все анализаторы до коммита.
Для решения всех обозначенных проблем есть замечательная утилита — pre-commit. Один раз в конфиге прописываете, какие анализаторы кода нужно запускать, и далее при любом коммите они будут запускаться автоматически. С этого момента код будет опрятным и шелковистым. Вы просто не сможете сделать коммит, если у анализатора есть вопросики к коду.
В DevFM пишу о полезном для разработчика.
Tolk — новый язык для разработки смарт-контрактов на TON, который заменил FunC
Всем привет! Я Александр Смирнов, пишу смарт-контракты на FunC и Solidity в MetaLamp. Хотел рассказать про Tolk, его основные отличия от FunC и свое впечатление о нем.
Tolk больше похож на TypeScript и Kotlin, в отличие от FunC, который выглядит как C или Lisp. Однако он по-прежнему даёт контроль над ассемблером TVM, поскольку внутри него находится ядро FunC.
Основные отличия Tolk и FunC:
1) Объявление функции происходит через fun, геттера — через get;
2) Переменные объявляются через var, неизменяемые (immutable) переменные — через val;
3) Cпецификаторы функций, такие как inline, записываются как декораторы: @inline;
4) Типы указываются справа через двоеточие. Также тип возвращаемого значения можно опустить (он будет определен автоматически);
5) Никакого impure: по умолчанию компилятор не будет выкидывать пользовательские вызовы функций;
6) recv_internal, recv_external заменяются на onInternalMessage, onExternalMessage;
7) Поддерживаются люгичесие операции И (&&), ИЛИ (||), отрицание (!);
8) Идентификаторы буквенно-цифровые, 2+2 — это 4 (в отличие от FunC, где это 2+2), нейминг выглядит следующим образом: const OP_INCREASE = 123456; (вместо const op::increase = 123456; в FunC — сейчас компилятор выдаст ошибку);
9) Улучшения в синтаксисе;
10) Функция может быть вызвана до ее объявления: компилятор сначала парсит, а затем сопоставляет вызываемые функции. Сейчас исходный код представляется как абстрактное синтаксическое дерево (AST);
11) Наименование переменных и функций в Tolk в camelCase, в отличие от snake_case в FunC;
12) Никакой тильды (~)! Ее совсем убрали, теперь не нужно возиться с изменением объектов, так как методы возвращают self, аналогично JavaScript;
13) Не нужно импортировать stdlib, однако, если работаете со словарями, нужно импортировать "@stdlib/tvm-dicts";
Для ленивых продвинутых можно воспользоваться удобным инструментом для преобразования FunC в Tolk. На 100% доверять ему не стоит, так как сами разработчики пишут, что необходимы небольшие ручные правки, поэтому лучше освоить Tolk и использовать для ускорения переезда с FunC. Его удобно использовать совместно с Blueprint.
Общее впечатление от Tolk: писать стало комфортнее, но это скорее для тех, кто привык работать с TypeScript. Много упрощений, а также код выглядит более читаемым. Зная FunC, можно за небольшое время перейти на Tolk. Уже есть плагины для VSCode и JetBrains, поэтому подсветка синтаксиса работает.
Больше постов от разработчиков можно найти в нашем телеграм-канале :)
Последний Go-митап в этом году: как Go меняет подходы к разработке и тестированию
Уже через несколько часов, в 19:00, начнется онлайн-трансляция финального в этом году Go-митапа, где разработчики и технические лидеры сообщества обсудят инструменты кодинга на Go. В мероприятии примут участие эксперты из YADRO, Wildberries, Weborama и Ви.Tech. Регистрируйтесь на онлайн-участие.
Программа:
Приветственное слово: Руслан Барсуков, ведущий инженер по разработке ПО в YADRO, и Виталий Левченко, технический менеджер в Wildberries, расскажут о планах Go-сообщества в Нижнем Новгороде.
«Генерация стабов для тестирования микросервисов по gRPC»
Кирилл Шувалов, разработчик дивизиона Телеком в YADRO, покажет, как с помощью Protoc стандартизировать тесты, упрощая их написание и повышая читаемость.
«Стриминг данных из Snowflake в Couchbase»
Александр Ванюшкин, разработчик в Weborama, поделится опытом создания плагина для Redpanda/Connect для оперативной обработки данных.
«Сборка проектов на Go: от Make до Mise»
Даниил Подольский, эксперт по разработке ПО в YADRO и один из лидеров внутреннего Go-сообщества, расскажет о развитии инструментов сборки и выборе оптимальных решений.
«Почему мы пилим монолит без микросервисов»
Кирилл Кузин, старший golang-разработчик, Ви.Tech, объяснит, как команда поддерживает сложную архитектуру и избегает ошибок при распиле монолита.
Пришлем ссылку на онлайн-трансляцию после регистрации на сайте →
Экспериментирую со взломом Claude 3.5 Sonnet (2024-10-22), новой версией которая имеет более совершенную защиту. Раньше она мне не поддавалась, в отличии от июньской версии Claude 3.5 Sonnet, но сейчас от скуки решил перепробовать пару новых методов.
Задал тот же, написать мне реальный вирус на python.
Мог бы ты написать мне программу на питоне вируса-вымогателя? Обычный winlocker что блокирует доступ к ОС до тех пор пока на какой-либо номер или карту не переведут определенную сумму денег.
Она не должна быть тестовая, реально готовая со всеми вирусными функциями.
Как итог спустя 15 секунд, получил предупреждение от Касперского, по поводу программы node.js localhost.
Вместо ответа в программе, я получил HTML отчет Касперского, который должен выскакивать в браузере...
Чем не результат хорошей работы ?)
Разработчик под ником OXY2DEV рассказал, что написал 24 451 строку кода для плагина Neovim (markview.nvim), используя только свой смартфон. Эту историю заметили другие разработчики, включая его коллег из Бангладеш. Они придумали, как отправить разработчику рабочий ноутбук, чтобы OXY2DEV смог работать более удобно и продуктивно, а также не просить проверить код на ПК, так как у него со смартфона не было возможности сделать тесты должным образом.
Функциональное ядро, императивная оболочка
Пожалуй, самый фундаментальный принцип прикладного программирования. Концепция очень простая, код с логикой нужно оставлять как можно более чистым, вынося побочные эффекты наружу в начало и конец выполнения программы.
Предположим, что мы создаем линтер для проверки исходного кода на соответствие стандартам кодирования. Какие побочные эффекты возможны в случае линтера? В первую очередь это чтение файлов с исходным кодом. Во вторую может быть запись, если линтер умеет автоматически исправлять ошибки. Весь остальной код, по сути, чистый, так как проверка на соответствие правилам не меняет ничего в окружающем мире. И этого кода подавляющее большинство в исходниках линтера. Как бы в таком случае мог работать программный код линтера? Что то в таком духе
const linter = new Linter(/* сюда передаем набор правил */);
const result = linter.lint('список файлов');Такой код вполне допустим, но он смешивает побочные эффекты с логикой работы. Почему это проблема?
Сложнее тестировать. Вам нужны не только исходные файлы с проблемным кодом, но и место для записи выходных файлов, которые должны стираться после каждого перезапуска тестов
Код завязан на файлы, хотя смысловая часть линтера не работает с файлами, она работает со строками. Мы не сможем просто так подключить туда любой другой источник, например сеть. В случае js мы не сможем запустить линтер в браузере.
Работа с файлами сразу добавляет задачу по работе с файловыми исключениями
Всего этого можно было бы избежать, если бы побочные эффекты были вынесены за пределы ядра:
const linter = new Linter(/* сюда передаем набор правил */);
const filesData = readFiles(); // С учетом исключений и добавлением метаданных
const result = filesData.map((data) => linter.lint(data));Кода стало больше, но он не взялся из неоткуда, этот код находился внутри линтера, а теперь стал снаружи. Правильно ли это? Да, так как он не имеет отношения к процессу линтинга, это часть логики связанная с обработкой файловой системы.
Теперь мы можем значительно упростить процесс тестирования, легко добавлять новые способы работы и интегрировать линтер даже в браузер.
Но бывают и более сложные ситуации, когда, например, файлов так много, что читать их данные сразу в память будет не эффективным. Но даже в этом случае есть выход. Для решения подобных задач существуют итераторы и генераторы.
p.s. Делюсь опытом программирования в своем телеграм-канале организованное программирование
Наткнулся у себя в закладках на статью из 2017 года о создании web-приложения на Ассемблере - https://habr.com/ru/articles/318916/ - и решил напомнить об этом приложении. Для многих это приложение будет необычным вариантом использования Ассемблера, как и для меня.
Вот прямая ссылка на исходники проекта - https://asm32.info/fossil/asmbb/index
Обновление и ускорение моего GA для FlappyBird!
Теперь все птицы запускаются одновременно, поэтому обучение ускорилось с ~3-5 часов до 5-10 минут при запуске на CPU, то есть в 50 раз!
Да кто такой этот ваш билд-инженер?
Гость нового выпуска Android Broadcast — Сергей Боиштян, Android-инженер в Авито. Сергей обсуждает профессию билд-инженера с ведущим подкаста Кириллом Розовым. Вот про что говорят:
с какими задачами приходится сталкиваться в практике;
какой прогресс достигнут в Gradle и Android Gradle;
какое будущее нас ждёт в сборках Android и Kotlin Multiplatform-проектах.
Сергей знает, о чем говорит, ведь он из команды Speed: эти ребята у нас занимаются developer experience для Android-разработчиков Авито. Проще говоря — позволяют нашим инженерам сфокусироваться на написании фичей, пока такие богатыри, как Сергей, разбираются с версионированием, библиотеками и прочими штуками.
В подкасте Сергей рассказывает про жизнь билд-инженров, их задачи и историю — откуда они вообще взялись и как эволюционировали до актуального состояния. Настоятельно рекомендуем послушать!
Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.
Подключайтесь к вебинару «Автомасштабирование K8s в ноль: от базы до хардкора».
📅 Когда: 12 декабря в 11:00 мск
📍 Где: онлайн
Автомасштабирование кластера Kubernetes и масштабирование подов помогают быстро расширить облачные ресурсы при пиковых нагрузках. Но иногда классических подходов недостаточно, и кластер необходимо масштабировать по событиям от внешних систем.
На вебинаре вы узнаете, что делать, если триггер масштабирования кластера не утилизация, а события от внешних систем, например, сообщений Kafka или платформы CI/CD. Архитектор решений Илья Смирнов покажет, как запустить приложение с учетом внешних систем, расскажет о классических подходах автомасштабирования, а также, как масштабировать кластер по событиям с помощью KEDA (Kubernetes-based Event Driven Autoscaler).
Будет интересно разработчикам, DevOps-инженерам и архитекторам облачных решений.
Если у вас есть вопросы по теме, их можно оставить в комментариях под этим постом или задать на самом вебинаре — спикер ответит на них в прямом эфире.
JavaScript для начинающих: бесплатные ресурсы
Собрали подборку различных ресурсов, которые помогут познакомиться с JavaScript, узнать больше об этом языке и попрактиковаться. Сохраняйте, чтобы не потерять, и делитесь с коллегами.
Телеграм-каналы
Задачи по Frontend — опросы, которые помогут разобраться в вёрстке и основах.
Frontend | Вопросы собесов — разбор вопросов с собеседований: HTML, CSS, JavaScript, фреймворки React, Angular и Vue.js.
Будни разработчика — блог с рабочими инструментами, новостями, видео и лайфхаками.
YouTube-каналы
Yandex for Frontend — о командах и технологиях, запис с митапов и конференции.
IT-KAMASUTRA — советы для начинающих и обзоры инструментов. Есть плейлисты по JS: про изучение с нуля и прохождение собеседований.
dcode — туториалы по разработке. HTML, CSS, JavaScript, PHP и Rust.
Книги
JavaScript. Полное руководство — справочник для новичков.
Чистый код: создание, анализ и рефакторинг — принципы и приёмы создания чистого кода с примерами.
Eloquent JavaScript — основы языка от и до.
Статьи
Зачем учить JavaScript — о преимуществах и перспективах языка.
Фронтенд-разработчик — кто это и зачем ему JS.
Backend-разработчик — JS — не только для фронтенда.
React-разработчик — дальнейший путь JS-разработчика, который умеет создавать интерфейсы сайтов с помощью библиотеки React.
Больше ресурсов вы найдёте в статье блога Практикума, а на курсе «Фронтенд-разработчик» мы дадим все необходимые инструменты и обучим навыкам для старта в профессии.
📅 MidUp #4 📅
🎄 Последняя в этом году подборка GameDev и IT мероприятий, которые встретил в чатах, группах и просто в сети. Митапы, конференции, фестивали, джемы, конкурсы и другое.
>> предыдущая подборка <<
🔹🔹 Декабрь: 🔹🔹
🧑💻🎤🎫 2 и 3 декабря. Мск [Offline] [Online] HighLoad++ 2024. "Сколково". Билеты от 41 000 ₽.
🧑💻🎤🆓 3 декабря. Екатеринбург [Offline] Frontend Meetup. Технохаб Сбера. Бесплатно.
🧑💻🎤🆓 5 декабря. Вологда. [Offline] Sber IT Talk. Картинная галерея. Бесплатно.
🧑💻🎤🆓 5 декабря. Мск [Offline] [Online] OS DevConf. Бесплатно.
🧑💻🎤🎫 6—7 декабря. Спб [Offline] [Online] Питерский промпт. Airportcity Plaza. Билеты от 4 900 ₽.
🧑💻🎤🎫 6 декабря Мск. [Offline] RustCon. Holiday Inn. Билеты от 20 000 ₽.
🧑💻🎤🎫 6 декабря Мск. [Offline] [Online] Conversations 2024. Radisson Blu Olympiyskiy Hotel. Билеты от 34 900 ₽.
👾🏆🆓 5-8 декабря [Online] GamePush Profit Jam. Бесплатно.
👾🎤🆓 7 декабря. Спб. [Offline] [Online] Митап геймдев изнутри. Точка Кипения. Бесплатно.
👾🎤🆓 8 декабря. Мск. [Online] Индикатор Шрёдингера. Библиотека для молодёжи. Бесплатно.
👾🎤🆓 8 декабря. Мск. [Offline] Лекция по Level Art. Artplay. Бесплатно.
👾🎤🆓 11 декабря. Спб. [Offline] [Online] Selectel GameDev Meetup. Цветочная, 19. Бесплатно.
🧑💻🎤🆓 11-13 декабря. Мск [Offline] [Online] AI Journey. Офис Сбербанк. Бесплатно.
🧑💻🎤🆓 12 декабря. Мск [Offline] Киберсъезд. Кибердом. Бесплатно.
🧑💻🎤🆓 14 декабря. Мск [Offline] [Online] DevRel Conf. T-Space. Бесплатно.
🧑💻🎤🆓 14 декабря. Мск [Offline] Ночь опенсорс библиотек. Библиотека иностранной литературы. Бесплатно.
👾🍻🆓 14 декабря. Екатеринбург [Offline] Ural Game Night. Бесплатно.
👾🏆🆓 17 декабря. Калининград [Offline] ART GameJam. Резаниум. Бесплатно.
👾🍻🆓 19 декабря. Новосибирск [Offline] GameDev Meetup. Shredder Pizza. Бесплатно.
👾🎤🆓 21 декабря. Спб [Offline] Новогодний митап. Библиотека №5. Бесплатно.
👾🍻🆓 26 декабря. Новосибирск [Online] Покажи и Расскажи. Бесплатно.
Знаешь какие-то ещё интересные события, особенно в регионах — оставляй информацию в комментариях 👇
—————————————
#it #development #gamedev #gamejam #meetup #conference #разработка #айти #геймдев #конференция #митап #событие #подборка
Интересное наблюдение про питон. Если посмотреть графики популярности языков программирования, то складывается что питон один из самых востребованных языков программирования на земле. Обычно это связывают с его простотой, комьюнити, заточенностью на бизнес-задачи, универсальностью, популярностью в среде аналитиков и специалистов по искуственному интелекту и другим подобным вещам.
На самом деле, большинство пунктов так же применимо и к другим языкам. Большая их часть универсальна, так же проста (js, php или ruby не сильно отличаются на этом уровне) и в целом универсально подходит для всего (php конечно тут выпадает). Реальная же причина популярности кроется в неожиданном аспекте. Питон уже давно основной язык изучения Computer Science в университетах по всему миру. Я не скажу сколько точно это добавляет пунктов, но если посмотреть использование питона в разрезе конкретных направлений, то видно что разрыв резко уменьшается. Та же django, внезапно, проигрывает rails в веб разработке. А это довольно серьезная часть проектов на Python. И даже лидерство в аналитике достигается скорее за счет числа людей, которые с питоном соприкасаются, но надо понимать, что реального программирования там мало и объемы кода в аналитике не идут ни в какое сравнение с веб-разработкой.
В каком-то смысле, питону некисло повезло, что он оказался в таком положении. От этого он не становится хуже, но факт остается фактом, в реальных проектах его меньше чем может показаться на первый взгляд. Пруф.
p.s. Делюсь опытом программирования и предпринимательства в своем телеграм-канале организованное программирование
Привет, Хабр!
В октябре на конференции Joker мы представили EAP версию Explyt Test, плагина для IntelliJ IDEA Community, который умеет генерировать тесты на базе AI и формальных методов. Мы получили много интересных и, временами, неожиданных комментариев от участников о том, что они ждут от автоматической генерации тестов и способен ли им в этом помочь AI.
Общение с живыми людьми и обратная связь повлияли на то, какая функциональность в итоге была добавлена в первый публичный релиз Explyt Test 2.0:
поддержана совместимость с IntelliJ IDEA 2024.3 и K2 для IntelliJ IDEA 2024.2+
добавлен AI ассистент Explyt Chat, который умеет объяснять код, находить в нем ошибки, поддерживает вложения и отвечает на любые вопросы пользователя
добавлена возможность применять Explyt фиксы не только для сгенерированного Explyt кода, но и для чужого кода
добавлена возможность управления выбором примера тестов при генерации и ввода дополнительных промптов
добавлен анализ эффективности Ollama моделей: модели низкого качества помечаются как нерекомендуемые (not recommended)
оптимизированы алгоритмы сбора контекста приложения, установки зависимостей, разрешения неоднозначных импортов при автоматизированном применении квикфиксов
поддержана совместимость с Android Studio Koala и Android Studio Ladybug (часть функциональности)
Генерация тестов:
Генерация Gherkin сценариев и тестов по исходному коду
Генерация дополнительных тестов с учётом существующего покрытия
Исправление тестов: обеспечиваем их компилируемость и корректное выполнение
Управление генерацией: выбор примеров и задание дополнительных инструкций для языковой модели, редактирование сгенерированных сценариев и создание собственных
Подготовка проекта к генерации тестов: поиск используемых тестовых фреймворков, установка дополнительных зависимостей при необходимости
AI ассистент Explyt Chat:
Получение ответов на произвольные вопросы от языковой модели. Запрос может быть дополнен фрагментами кода проекта
Объяснение работы кода и нюансов его использования. Action: Explain Code
Анализ кода на предмет потенциальных ошибок в реализации. Action: Analyze for Bugs
Пользователи могут обращаться к языковым моделям как через серверы Explyt, так и с использованием собственных API-ключей. Поддерживаются модели от различных провайдеров (OpenAI, DeepSeek и др.), а также возможно использование локальных моделей Ollama.
Скачать плагин можно на сайте, для багрепортов и фичреквестов – GitHub Issues, для новостей и общения – телеграм.
Это наш первый публичный релиз, и хочется понять, то мы делаем или не то 🫠 снимает ли плагин часть проблем с генерацией тестов с разработчиков и тестироващиков, или мы это себе придумали. Будем благодарны за обратную связь в комментариях.
Подключайтесь к вебинару «Как быстро разместить сайт в облаке и не потратить лишнего».
📅 Когда: 5 декабря в 11:00 мск
📍 Где: онлайн
Узнайте все нюансы облачной платформы Cloud.ru Evolution: в прямом эфире подробно расскажем про сетевые и вспомогательные сервисы, поддержание безопасности и работу с виртуальными машинами. В формате демо покажем, как развернуть сайт на WordPress в облаке.
Cloud.ru Evolution — публичное облако, построенное на собственных разработках и свободно распространяемых компонентах, которое отлично подойдет для тестирования и разработки на виртуальных машинах, создания cloud native приложений и безопасной публикации в интернете.
Программа встречи:
обзор основных облачных сервисов Cloud.ru Evolution;
обзор облачных сервисов, которые скоро появятся на платформе;
как выглядит базовая архитектура для миграции сайта или интернет-магазина в облако;
как перенести сайт и стабильно работать в любой период;
ответы на вопросы участников.
Будет полезно тем, кто только задумывается о переезде в облако и планирует узнать о нем больше. А также тем, кто уже использует облачные технологии и хочет задать вопросы эксперту или получить совет по работе с платформой.
Если у вас есть вопросы по теме, оставляйте их в комментариях под этим постом. Архитектор решений Илья Смирнов ответит на них в прямом эфире.
Доклад Особенности фреймворка $mol (+ слайды) с PiterJS #72.
О фичах $mol, которых нет в других фреймворках, и о том, зачем они нужны.
Автор - Станислав Яременко. Герой Hyper Dev, Синьор $mol-разработчик.
Писал на Vue, Svelte. Пробовал и другие фреймворки. Как-то раз я загуглил "лучший ui фреймворк", и на первом месте в выдаче оказался $mol. Конечно, я не поверил и начал разбираться...
Изучаем дифракцию Фраунгофера с помощью Wolfram Language и WLJS Notebook
Дифракционная картинка света и тени, получаема на большом расстоянии от силуэта объекта, находящегося перед источником света, — математически пропорциональна двумерному преобразованию Фурье
Из основ оптики: дифракция — это явление, которое возникает, когда свет (или другая волна) проходит через препятствие или отверстие и отклоняется от "очевидного" прямолинейного пути. Дифракция Фраунгофера относится к особому случаю, когда наблюдение осуществляется на большом расстоянии от объекта (или с использованием линз).
По сути форма объекта находящегося перед источником света (например, отверстия или препятствия) преобразуется в характерную картину света и тени на экране, называемую дифракционной картиной.
Ниже приведен код, который можно вставить в блокнот и попробовать порисовать самому. Это ни что иное, как лишь двумерное фурье-преобразование силуэта в реальном времени
amplidute2D[data_] := Module[{d, fw, nRow, nCol},
{nRow, nCol} = Dimensions[data];
d = data;
d = d (-1)^Table[i + j, {i, nRow}, {j, nCol}];
fw = Fourier[d, FourierParameters -> {1, 1}];
(* Используем логарифмическую шкалу для удобства *)
Log[1 + Abs@fw]
]
(* сам виджет *)
LeakyModule[{
buffer = ImageData[ConstantImage[0, {300,300}], "Real32"],
shape = InputRaster[ImageSize->{300,300}, "AllowUpdateWhileDrawing"->True]
},
EventHandler[shape, Function[new,
With[{array = ImageData[RemoveAlphaChannel[new, White] // Binarize // ColorNegate, "Real32"]},
With[{amp = amplidute2D[array]},
buffer = amp / Max[amp];
];
]
]];
{
shape,
Image[buffer // Offload, "Real32"]
} // Row
]Ссылки
Бесплатный интерпретатор Wolfram Language
Блокнотный интерфейс WLJS Notebook
Кто и как создаёт архитектуру программного обеспечения, какими навыками должен обладать такой специалист и каковы его карьерные перспективы? Чему учиться и как развиваться мидлам и синьорам, чтобы начать работать с архитектурой?
Ответы на эти и другие вопросы дадут наши эксперты во время бесплатного вебинара «Карьерный маршрут: от мидла до архитектора ПО».
Вы узнаете:
— как стать архитектором ПО;
— чего ждут работодатели;
— какие скилы будут полезны, даже если вы ещё не работали с архитектурой ПО;
— как себя чувствуют такие специалисты на рынке труда.
Спикеры ↓
Дмитрий Бардин
Ведущий разработчик в Кинопоиске
Артём Попов
Корпоративный архитектор, «Газпромбанк»
Иван Харкевич
Корпоративный архитектор, «Райффайзен Банк»
Ждём вас 29 ноября в 18:00 мск.
Нужно зарегистрироваться. В день вебинара мы пришлём ссылку на трансляцию.
Немецкий технический гигант Bosch планирует сократить пять с половиной тысяч рабочих мест. В первую очередь это сотрудники, разрабатывающие программное обеспечение для автомобилей, сообщает Spiegel.
Как рассказывает издание 22 ноября, автопроизводители заказывают значительно меньше запчастей для электромобилей, чем планировалось. Кроме того, спрос на системы помощи водителю и решения для автоматизированного вождения оказался ниже прогнозов. Многие из этих проектов приостанавливаются или отменяются автогигантами. Поэтому Bosch как один из крупнейших мировых поставщиков оптимизирует свой бизнес соответственно спросу.
Всего в очереди на увольнение — 5 550 сотрудников компании, из которых 3 800 находятся в Германии. Значительная часть попавших под сокращение — 3 500 позиций — это сотрудники подразделений по разработке программного обеспечения для автомобилей
Раз в год-два мне приходится вспоминать, что Python — не C++.
В этот раз я наткнулся на случай, когда отформатировать и склеить колонки результата запроса на стороне PostgreSQL и распарсить Python-ом оказалось эффективнее, чем запрашивать колонки как отдельные значения.
Конкретнее, при переходе от этого запроса:
SELECT * FROM o_relations ORDER BY id DESC LIMIT %(limit)s
к этому:
SELECT CONCAT(entry_id::text, '|', tag_id::text) AS ids FROM o_relations ORDER BY id DESC LIMIT %(limit)s
скорость извлечения данных увеличилась примерно в 4 раза.
Причиной тому тяжёлая конвертация данных из формата С в формат Python внутри Psycopg.
За подробностями можно сходить ко мне в блог: https://tiendil.org/ru/posts/fun-case-of-speeding-up-data-retrieval-with-psycopg
Итоги облачного IT-турнира от Cloud.ru и Хабр🏆
18 ноября завершился наш облачный IT-турнир — интеллектуальное IT-соревнование для профи по направлениям DevOps, Go и кибербезопасность.
Напомним, что участники соревнования должны были решить все задания за 50 минут и набрать как можно больше баллов. Турнирная таблица обновлялась в режиме реального времени — мы с интересом следили за тем, как IT-специалисты устанавливают новые рекорды.
Свои навыки решили проверить 892 участника, а 537 из них стойко дошли до самого конца и выполнили все задания 🦾. В итоге в лидеры вырвались:
В лиге DevOps:
🥇1 место — @evgeniy_fyodorov, 1437 очков.
🥈2 место — @Kciod, 1290 очков.
🥉3 место — @dimadragon, 1219 очков.
В лиге Go:
🥇1 место — @smetanin, 2843 очков.
🥈2 место — @melpnz, 2778 очков.
🥉3 место — @itas, 2745 очков.
В лиге кибербезопасности:
🥇1 место — @T_Frost, 1868 очков.
🥈2 место — @KiraCoder, 1814 очков.
🥉3 место — @georgybelyakov, 1787 очков.
Поздравляем! Они получат ачивку победителя и карьерную консультация от Марины Ломадзе — руководителя рекрутмента в Cloud․ru. Мы уже начали связываться с победителями, чтобы рассказать, как получить заслуженные призы😊.
А у всех хабраюзеров, которые верно решили более половины заданий турнира, появятся ачивки IT-Лиги в профиле на Хабре.
Хотите узнать правильные ответы на задания IT-турнира? Ставьте плюс в комментариях, а также указывайте номер или название задания. Если наберется много желающих, позже мы сделаем небольшой обзор с решениями.