Программирование *

Всем привет!

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

• корпоративные архитекторы, выравнивающие архитектурные шаблоны

• внутренние платформы, обязательные к использованию внутри компании и реализующие единообразно нефункциональные требования

• техрадар как способ ограничить технологический стек

• единые практики найма и онбординга

• корпоративная модель данных — как антипод принципа DDD, когда существует некая общая для организации единственно верная доменная модель...

Так вот — что мне нравится в парадигме DDD, что она говорит — не надо бороться, надо принять как данность, расслабиться и получать удовольствие от своего ограниченного контекста). Ремарка – речь про применение закона в проектировании ПО.

Всем привет!

Разработка ПО - очень динамичная сфера. Мэйнфреймы, ассемблер, CSV, RDBMS, C, Delphi, Java, REST, MQ, git, DevOps, Docker, k8s, Kafka, noSQL, microservices, reactive programming, DataLake, GitOps, ChatGPT...
Но есть вещи, которые не меняются. 1967 год, сформулирован закон Конвея - Любая организация, которая разрабатывает систему (в широком смысле), вынуждена создавать проекты, структуры которых являются копией структуры связей организации. Причем если верить wiki, а в данном случае IMHO это можно делать, закон был доказан, видимо на исследовании реальных компаний.
Так вот, читаю сейчас одну интересную книгу про внедрение DDD - Domain Driven Development, 2022 года выпуска. В главе про внедрение вижу такой совет - начать с того, что определить бизнесовые поддомены в компании, на основании которых будут строится ограниченные контексты - одна из ключевых сущностей DDD. Как их проще всего определить? Рекомендуется посмотреть на структуру организации. Закон Конвея в DDD)

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

Всем привет, прошел уже 1 месяц с того момента как я опубликовал свою первую статью на habr и около 2,5 месяцев с первого дня разработки моей игры. В этом посте я бы хотел рассказать о прогрессе, которого я смог достичь за то время, которое прошло с момента последней публикации.

В обновлении я добавил такое как:

• Возможность разобрать блоки обратно в материалы

• Добавил множество строительных блоков и блоков интерьера

• Переписал процедурный генератор мира и добавил новые структуры

• Добавил рабочие инструменты и обновил принцип добычи материалов, теперь вам нужно иметь кирку, чтобы добывать камень, вам нужно иметь топор, чтобы добывать древесину

• Написал систему проигрывания саундтреков

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

• Провел оптимизацию рисовку игрового мира

• Теперь игра доступна не только для Windows, но еще и для Linux

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

30 мая 2024 года Docker Hub перестал работать в России из-за геоблокировки и санкционных ограничений. Обсуждение попыток решения этой ситуации есть на Хабре в этой публикации.

Заблокированы сайты https://www.docker.io/ и https://hub.docker.com/.

Работают сайты: https://forums.docker.com/ и https://www.docker.com/

С VPN доступ открывается. При этом из wsl2 образы не скачиваются даже с включенным VPN.

Решение с доступом:

Выбираем любое:
https://daocloud.io
https://c.163.com/
https://registry.docker-cn.com
https://mirror.gcr.io

Открываем настройки Docker Daemon:

nano /etc/docker/daemon.json

И добавляем зеркало, например:

{
  "registry-mirrors": ["https://mirror.gcr.io"]
}

Затем делаем рестарт:

service docker restart

Второй вариант с зеркалом:

nano /etc/sysconfig/docker

OPTIONS='--selinux-enabled --log-driver=journald --registry-mirror=<MIRROR>'

Mistral представила нейросеть Codestral-22B, которая знает 80+ языков программирования. Codestral превосходит по производительности Llama-3, CodeLlama и даже GPT-4o, а также весит в три раза меньше.

Модель Codestral-22B умеет писать и рефакторить код, подсказывает наилучшие решения задач и даже паттерны проектирования. Её можно интегрировать в свои проекты с помощью API или просто использовать в VS Code. Нейросеть знает даже Fortran и COBOL.

Тест нейросети Codestral-22B доступен здесь или прямо в браузере.

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

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

Проект написан на языке Python и распространяется под лицензией GPLv3+. Готовые сборки, не требующие наличия в системе Python, доступны для GNU/Linux, Windows и Android (Termux).

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

Регистрация в GitHub, авторизация и токен для работы скрипта не требуются. Поддерживается парсинг звёзд с проверками на ошибки и ограничения, имитация результатов, отчёты в CLI и HTML в том числе с расчётами дат.

Работа shotstars рассчитана на средние и небольшие проекты, имеющие до 6000 звёзд (лимит API GitHub в 6K звезд/час).

«Архитектура программного обеспечения» — обновлённый курс Яндекс Практикума

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

Основное про курс:

• Много практики: по окончанию курса вы сможете добавить в портфолио 11 проектов.

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

• Диплом о профессиональной переподготовке или сертификат по окончанию обучения.

Вы научитесь:

• Проектировать и реализовывать микросервисные архитектуры, управлять ими.

• Применять паттерны масштабируемости, устойчивости и взаимодействия между сервисами.

• Развёртывать приложения в облачных средах с помощью Kubernetes, Docker и Terraform, управлять ими.

• Выстраивать стратегии миграции в облако и управлять большими объёмами данных.

• Применять репликацию, шардинг и обработку данных в реальном времени.

• Создавать решения для мониторинга с помощью Prometheus и Grafana.

• Применять лучшие практики в области безопасности, включая управление идентификацией и доступом (IAM).

• Интегрировать функции безопасности в дизайн и развёртывание приложений.

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

Ближайший старт обучения — 27 июня и 25 июля.

Узнать о курсе подробнее и начать учиться бесплатно →

Задача обеспечения безопасности REST API может быть менее очевидной, но важно помнить, что REST API используется везде, где пользователю сайта или приложения нужно предоставить данные с сервера.

Приглашаю на вебинар 30 мая в 12:00, посвященный превентивной защите REST API.

Ведущие вебинара — Вадим Шепелев, инженер по информационной безопасности Вебмониторэкс и Лев Палей, CISO Вебмониторэкс.

О чем расскажем на вебинаре:

• Польза от спецификации API и как её собрать на основании трафика

• Какие типы уязвимостей это позволит обнаружить

• Как уменьшить поверхность атаки при помощи «ПроAPI Защита»

Регистрируйтесь по ссылке.

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

Компания Вебмониторэкс приглашает на вебинар 30 мая в 12:00, посвященный превентивной защите REST API.

Ведущие вебинара — Вадим Шепелев, инженер по информационной безопасности Вебмониторэкс и Лев Палей, CISO Вебмониторэкс.

О чем расскажем на вебинаре:

• Польза от спецификации API и как её собрать на основании трафика

• Какие типы уязвимостей это позволит обнаружить

• Как уменьшить поверхность атаки при помощи «ПроAPI Защита»

Кому полезно:

• Специалистам, участвующим в разработке критичных для бизнеса веб-приложений

• Руководителям подразделений по информационной безопасности

• Специалистам Application Security

Почему полезно:

• Актуальная проблема защиты REST API обусловлена участившимися атаками на веб-ресурсы российских компаний

Регистрируйтесь по ссылке.

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

«Эксперты „Сбера“ провели обширное тестирование различных ИИ‑ассистентов разработчика на более чем 17 тыс. файлов с кодом, в ходе которого сервисам предлагалось продолжить фрагмент исходного кода, и производился замер того, насколько точно предсказывается его следующая строка. Результаты показали, что по интегральной доле верно предсказанного кода на языке Java сервис GigaCode показал результат на 2% лучше, чем GitHub Copilot, и на 3% и 6,5% лучше, чем Codeium и TabNine», — рассказал старший вице‑президент, руководитель блока «Технологическое развитие» «Сбера» Андрей Белевцев.

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

Сервис GigaCode помогает в режиме реального времени по фрагменту кода сгенерировать наиболее вероятные его продолжения непосредственно в среде
разработки. Решение поддерживает более 15 языков программирования (Java, Python, JavaScript, TypeScript, C/C++ и другие), а также совместимо со множеством редакторов и интегрированных сред (IDEA, PyCharm, VSCode, Jupyter и другие).

Опубликованы первые выпуски проекта Bend, развивающего высокоуровневый язык программирования для параллельных вычислений, который позиционируется как альтернатива низкоуровневыми языкам, таким как CUDA и Metal, обладающая выразительным синтаксисом и возможностями для повышения удобства разработки, свойственными таким языкам, как Python и Haskell. Код проекта написан на языке Rust и распространяется под лицензией Apache 2.0.

Из возможностей языка Bend отмечается быстрое распределение объектов, поддержка использования функций высшего порядка, замыканий, продолжений, неограниченной рекурсии, сопоставления с образцом, рекурсивных сопоставлений (fold) и циклов (bend), целочисленных, строковых и списочных типов. Поддерживается два варианта синтаксиса: в стиле Python и в стиле Haskell. В программах не требуется указание управляющих распаралелливанием аннотаций, явного создания потоков и выставления блокировок. Распараллеливание производится автоматически, например, при вычислении выражения "((1 + 2) + (3 + 4))", операции "1 + 2" и "3 + 4" будут выполнены параллельно.

Программы на языке Bend могут выполняться на оборудовании, обеспечивающем массовый пареллелизм, например на GPU, демонстрируя практически линейный рост производительности в зависимости от числа вычислительных ядер. Код на языке Bend компилируется в низкоуровневое промежуточное представление HVM2 (Higher-order Virtual Machine 2), которое затем компилируется в представление на C и CUDA.

Источник: OpenNET.

Стоит ли становиться тимлидом?

Привет, на связи Spectr! Опубликовали запись круглого стола «Стоит ли становиться тимлидом?» с митапа DevTalks.

Получится отличный круглый стол и очень полезная и конструктивная дискуссия. И вот почему:

• очень крутая модерация круглого стола Виктором Корейша;

• очень классный состав участников в разрезе ролей, который позволил рассмотреть вопрос с разных сторон: CTO, ТимЛид, руководитель отдела и рядовой разработчик;

• очень вовлеченный в дискуссию зал: было очень много полезных комментариев и взглядов;

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

Какими качествами должен обладать тимлид? Как проходят собеседования на должность руководителя? Как все успеть и не растерять навыки разработчика? На эти и многие другие вопросы ответили:
— Виктор Корейша (Ozon, руководитель отдела MessageBus и Storage; ведущий подкаста о жизни в IT «Кода кода»)
— Максим Харитонов (Ozon, руководитель группы разработки Storage)
— Никита Ильин (Spectr, backend-разработчик)
— Олег Казаков (Spectr, CTO)

Вырасти из джуна в мидла с подарочным курсом от Практикума

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

Дело в хард- и софтскилах. Сотрудники с «мягкими» навыками на 8% быстрее получают повышение, чем те, кто обладает только хардскилами. А комбо «твёрдые» + «мягкие» ускоряет продвижение на 13%. 

Топ-5 навыков, которые ускоряют карьеры:

• Умение работать в команде: +11%

• Навыки решения проблем: +11%

• Коммуникативность: +11%

• Организационные навыки: +11%

• Лидерские навыки: +10%

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

Вывод: чтобы вырасти в карьере, нужны сильные софты. Поэтому мы дарим мини-курс «Навыки рабочей коммуникации» — всем, кто купит любой курс для специалистов с опытом до 30 июня.

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

• анализировать аудиторию, чтобы вас слушали и слышали;

• структурировать информацию и чётко доносить свои мысли;

• управлять вниманием слушателей с помощью сторителлинга и других приёмов;

• получать нужные результаты от встреч;

• разрешать конфликты и находить решения, которые всех устроят.

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

Выбрать курс и узнать подробнее об акции можно на сайте.

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

Компания Вебмониторэкс ответит на этот и другие вопросы на своем вебинаре 16 мая.
Теорию подкрепит практический кейс заказчика.

 О чем расскажем на вебинаре:

- На что обратить внимание при обеспечении безопасности API в современных условиях. - Изменения в инфраструктуре. Что дальше?
- Защита и управление API. Почему это важно.
- Подходы по защите API. От зрелости к эффективности: Знать. Защищать. Не допускать. - Реализация на платформе «Вебмониторэкс»: компоненты для защиты и управления API.  

Ведущий вебинара — Лев Палей, CISO Вебмониторэкс. Специальный гость — Кирилл Ильин, CISO «СберАвто». Он честно и открыто расскажет о задачах, практике и результатах защиты API в своей компании.  

Кому полезно:

- Специалистам, участвующим в разработке критичных для бизнеса веб-приложений
- Руководителям подразделений по информационной безопасности
- Специалистам Application Security  

Почему полезно:

- Узнаете о современной концепции управления API
- Увидите пример ее реализации на платформе «Вебмониторэкс»
- Услышите от CISO об успешном опыте защиты и управления API на примере компании «СберАвто»  

Регистрируйтесь по ссылке.

Вебинар про защиту API 16 мая в 12:00

Совместно с Игорем Котенковым подготовили для себя и для вас Бинго-карточку на предстоящую трансляции OpenAI, чтоб было интереснее наблюдать!

Что именно покажут на презентации не уточнялось, но по словам Sam. A.:
`not gpt-5, not a search engine, but we've been hard at work on some new stuff we think people will love! feels like magic to me`

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

В своем канале я оставлю короткую выдержку новостей и о какой магии говорят в openai!

Готов HTML и EPUB книги об учебной операционной системе xv6.

Яндекс.Диск:

• Книга об xv6 на русском языке в формате PDF

• Книга об xv6 на русском языке в формате EPUB

• Книга об xv6 на русском языке в формате HTML

Google.Drive: https://drive.google.com/drive/folders/1Rt7hcHysWAilDn64uf-RpLACuJ39YKaR

Языку программирования BASIC исполнилось 60 лет. 1 мая 1964 года в Дартмутском колледже в США математики Джон Кемени (John G. Kemeny) и Томас Курц (Thomas E. Kurtz) успешно запустили первую программу на их недавно разработанном языке программирования BASIC (Beginner's All-Purpose Symbolic Instruction Code) на принадлежащем колледжу мейнфрейме General Electric GE-265 с поддержкой множества терминалов. Вопреки распространённому убеждению, в момент своего появления это был компилируемый язык.

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

При проектировании языка использовались следующие восемь принципов. Новый язык должен был:

• быть простым в использовании для начинающих;

• быть языком программирования общего назначения;

• предоставлять возможность расширения функциональности, доступную опытным программистам;

• быть интерактивным;

• предоставлять ясные сообщения об ошибках;

• быстро работать на небольших программах;

• не требовать понимания работы аппаратного обеспечения;

• защищать пользователя от операционной системы.

В конце 70-х и начале 80-х годов BASIC оставался программным интерфейсом и квази-ОС для популярных домашних компьютеров Atari 800, TRS-80, Commodore VIC-20, Commodore 64, ZX Spectrum, TI-99/4A, BBC Micro и IBM PC.

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

31 июля 2020 года влогер MattKC опубликовал видеоролик, в котором попытался уместить игру в QR-коде. В результате он написал вариант «Змейки», которая занимает 2953 байта. Исполняемый файл такого размера возможно уместить в QR-коде, поскольку этот формат кодирует до 3 КиБ данных.

Эксперимент влогера не остался без внимания. Уже 3 августа свой вариант показал Брайан Каллахан. Эта «Змейка» требует всего 2024 байта. Впрочем, вариант MattKC ужимается с помощью Crinkler до 1,4 КиБ.

Дальнейшие эксперименты ушли ниже тысячи, а потом и сотни байтов. В последние месяцы развернулась борьба за каждый байт. В ноябре 2023 года удалось заменить ассемблерную инструкцию и выиграть целый байт. Ещё два байта сэкономили две недели назад за счёт замены jae и xor на adc.

Итоговый вариант — это «Змейка» на 58 байт для Microsoft DOS. Для сравнения: ничего не выполняющая программа на C gcc -Os -w -xc - <<< "main;"на 64-битном Linux займёт 15 776 Б. 58 байт — это немного даже для текстовых данных: хватит на небольшое предложение или последовательность эмодзи по типу «??‍❤️‍?‍????‍♀️??‍❤️‍?‍??».

Конечно, в QR-коде эта игра тоже уместится. Также автор выложил онлайн-демку (управление по стрелкам клавиатуры на ПК или свайпу на мобильных устройствах).

github.com/donno2048/snake

Лучший способ самопрокачки для инженеров

Я считаю, что лучший способ прокачать свои скиллы - это сделать сайд-проект.

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

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

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

Я за свою карьеру сделал огромную пачку сайд-проектов. Какие-то были неудавшимися стартапами, другие же я делал с целью разобраться в конкретной теме. Свой первый сайд-проект я сделал ещё до получения первой официальной работы - это был RSS-ридер на C# и WPF.

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

И даже сейчас я продолжаю делать сайд-проекты. Один из них вы читаете прямо сейчас ?

Больше интересного про жизнь в IT у меня в ТГ