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

MTS AI выводит на рынок ассистента для разработчиков — ИИ-сервис Kodify, созданный на базе собственной большой языковой модели (Large Language Model, LLM) Cotype.

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

Модель не требует дообучения и доступна клиентам сразу после установки. Kodify поддерживает наиболее популярные среды разработки и генерирует код на Python и Java. По запросу клиента разработчики MTS AI могут добавить поддержку Go и других популярных языков программирования. Также Kodify может перевести код с одного языка на другой — например, для оптимизации устаревшего софта или интеграции с другим проектом.

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

Kodify можно запустить в формате on-premise на инфраструктуре заказчика — вся обработка и генерация кода будет происходить только в контуре компании. «Это также позволит дополнительно обучить нейросеть на собственных примерах и полностью управлять источниками информации», — пояснил в MTS AI.

Всем привет!

TDD конечно крутая штука в плане правильного проектирования сервиса. Правильное проектирование - имеется в виду получить публичное Java API, удобное для использования, если не с первого раза, то с меньшим количеством итераций.

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

Что там может быть:

• входные данные -> выходные данные

• обработка возможных исключений

• повторный запуск: идемпотентность, докат или ошибка

• параллельный запуск

• поведение при различных значениях настроек

• поведение при различных настройках кодировки, языка, часового пояса, файловой системы

• эффекты из-за отсутствия транзакционности (там где ее нет) ...

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

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

Нужны ли iOS-разработчики в 2024 году и какие навыки пригодятся джуниорам? Команда Практикума провела исследование рынка труда, тут резюмируем ключевые выводы:

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

• Перед собеседованием важно повторить основы (например, по подборкам вопросов на собеседовании для iOS-разработчиков), а также проверить свой профиль на GitHub — закрыть слабые места и подготовиться к вопросам о проектах.

• Софтскилы для джуниора не менее важны, чем знание Swift. Неумение рассуждать или агрессивное поведение на собеседовании практически гарантируют отказ работодателя, а чрезмерное волнение может помешать кандидату показать лучшие результаты. Чтобы этого избежать, можно посмотреть собеседования на YouTube или попросить знакомого разработчика провести тестовое интервью.

• Знание многопоточности, SwiftUI и Combine, а также навык написания тестов необязательны, но увеличивают количество потенциальных вакансий и повышают шансы на скорое трудоустройство.

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

→ Познакомитесь с языком Swift и запустите своё первое приложение в Xcode — игру Pong. 15 часов курса «iOS-разработчик» бесплатно.

Amazon опубликовал открытый игровой движок Open 3D Engine на базе технологий CryEngine (opennet.ru)

Для симуляции физических процессов поддерживаются NVIDIA PhysX, NVIDIA Cloth, NVIDIA Blast и AMD TressFX. Имеется встроенная сетевая подсистема с поддержкой сжатия и шифрования трафика, симуляции сетевых проблем, средствами для репликации данных и синхронизации потоков. Поддерживается универсальный mesh-формат для игровых ресурсов, автоматизация генерации ресурсов на языке Python и загрузка ресурсов в асинхронном режиме.

Всем привет!

Наткнулся на интересную статью про различные типы разработчиков https://habr.com/ru/articles/135865/ Тут не про уровень - джун, миддл, сеньор, - а про разные названия должностей и что за этим стоит. Кодер, хакер, разработчик, инженер, архитектор...
В целом классификация норм, но хотел бы подсветить пару моментов.

Архитектор вполне может быть и часто живет в своей башне из слоновой кости, где он бесполезен. Но есть как минимум два кейса, где польза есть:

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

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

Разница между разработчиком и инженером. На первый взгляд особой разницы не видно. Очевидно, что диплом не делает инженера лучшим спецом, чем разработчик. Но рассмотрим ПО для критической инфраструктуры: авиаперевозки, космос, атомные станции, медицина.
ПО нужно сертифицировать. А раз так, то и сертификация разработчика, который это ПО пишет, выглядит логичной. Как минимум есть подтверждение, что он сдавал экзамен по чему-то важному, что требуется в данной отрасли. Но речь именно про специализированные экзамены, а не про программирование на Java или не дай бог Pascal)

Но первая мысль, которая мне пришла в голову после прочтения - главное, чтобы ChatGPT не сделал из разработчика кодера)))

И вообще любая привязка к чужим библиотекам это очень порочная практика.

Мы провели исследование  и выяснили, что курс «Управление командой разработки» подходит руководителей DevOps, QA, DS и аналитиков. Сейчас 12% покупателей курса — проджект-менеджеры, а 14% — тимлиды различных направлений.

Приоритеты менеджеров:

• Стать более технически подкованными, чтобы лучше понимать разработчиков;

• Частично или полностью заменить тимлида, если в компании нет отдельной позиции;

• Стать увереннее, объективно оценивать свои навыки;

• Научиться оценивать время на выполнение задач;

• Повысить авторитет среди разработчиков.

Приоритеты тимлидов DevOps, QA, DS и аналитиков:

• Лучше справляться с текущей ролью (нет цели начать руководить разработчиками);

• Улучшить навыки управления и систематизировать знания;

• Проработать слабые стороны;

• Убедиться в своём подходе, не опираться на интуитивные решения. 

Для прохождения курса не требуются навыки программирования. Много внимания уделяется мягким навыкам с примерами из жизни руководителя разработчиков и тому, как:

• Управлять ресурсами и временем. Делегировать, планировать, находить баланс;

• Нанимать, адаптировать и мотивировать сотрудников, давать обратную связь;

• Ставить выполнение задач на поток, применять Scrum и Kanban;

• Проводить встречи результативно, находить подход ко всем в команде, взаимодействовать с заказчиками, решать конфликты.

В США разработчикам в экспериментальных целях платят, чтобы они программировали в режиме изменённого сознания (фактически накуренными). В Университете Мичигана проводят исследование «Накуренный во время программирования».

В рамках этого мероприятия планируется изучить влияние определенных веществ на продуктивность. За это платят $80. Для участия надо быть старше 21 года и знать Python.

Ранее исследование показало, что 59% респондентов уже кодили на работе под кайфом или в состоянии алкогольного опьянения.

Что почитать начинающим разработчикам на Go

Привет, Хабр! Меня зовут Алексей Артамонов, я лид команды интеграции в «Островке». Сделал подборку, что можно почитать для старта работы с Go:

• «The Go programming language» — азы для старта. Хотя синтаксис в Go простой, важно уметь из этих простых вещей собирать сложные конструкции. 

• Effective Go — практическое пособие для создания тех самых сложных конструкций.

• «Сто ошибок в Go» — ещё одна хорошая книга. Заход со стороны «как делать не надо».

• В различных обучающих программах очень много внимания уделяют монолитам, микросервисам и в принципе архитектуре. Но правда в том, что джун или мидл вряд ли столкнётся со столь глобальными задачами. Ему важнее уметь разбить свою логику по классам, пакетам, модулям. Важно писать качественный код. Для этого обязательно рекомендую книгу «Good code, bad code».

• Много полезного в книге «Принципы юнит-тестирования». Хорошие юнит-тесты неразрывно связаны с тем, как приложение разбито на модули, какие есть связи и зависимости.

• Два блога-рассылки: GoLang Blog и Awesome Go Weekly.

• Подкасты довольно сложны для восприятия в фоновом режиме. Особенно для новичков. Но если очень хочется: GoTime, GoPodcast и GoGetPodcast.

Обучение пройдёт легче, если уже знать какой-нибудь язык программирования. К примеру, в «Островке» два главных языка — Python и, собственно, Go. Главный секрет — желание и практика. Если хочешь стать программистом — надо сесть и начать кодить. Ни одна книга без практики не поможет стать программистом.

Разбор доклада Артёма Арутюняна про Архитектуру и Реактивное Программирование

Топ перлов:

• Реактивное программирование - это программирование на событиях.

• Реактивность нужна между модулями, а внутри - не нужна.

• По одному лишь графу связей можно понять правильно произведена декомпозиция или нет.

Мета: Копилка благодарностей, Новости, Форум

Всем привет!

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

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

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

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

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

• корпоративная модель данных — как антипод принципа 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 обусловлена участившимися атаками на веб-ресурсы российских компаний

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