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

Сервис «Сбера» 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 у меня в ТГ

26 апреля 2024 года состоялся релиз эффективной многопоточной среды обработки Kafka на Ruby и Rail проекта Karafka 2.4.

Исходный код этого инструментария опубликован на GitHub под лицензией LGPLv3.

В новой версии проекта исправлены ранее обнаруженные ошибки, а также внесены улучшения и изменения. В Karafka 2.4 прекращена поддержка Ruby 2.7 и используется инструментарий WaterDrop 2.7.

Неосознанный отбор

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

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

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

2. Дают боевые задачи. Как правило, в этом случае интервьюеры особо не готовятся к собеседованию, а готовят только сами задачи. Здесь интервьюер может спросить решение какой-то архитектурной проблемы. Для грейда ниже может попросить разработать какой-то компонент на React. Для собеседования могут браться даже реальные задачи из Jira.

При этом кандидаты тоже делятся на 2 типа:
1 тип готовится к собеседованиям
2 тип не готовится к собеседованиям

Второй тип будет работать хуже? Не думаю

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

***

Подписывайтесь на мой телеграм-канал Вайтишная

Go SDK
Будучи скромным гофером хочу отметить, что решение тех или иных задач - требует понимание базы и идиом языка. Конечно, есть замечательная документация, есть не менее замечательный хаб, но пока самые-самые сердечки это репозитория go, где в центре внимания легендарный пакет runtime и sync.
Вот несколько примеров, как описан sync.Map в коде, комментарии к которому и реализация методов отвечает на многие вопросы

//...
// Load, LoadAndDelete, LoadOrStore, Swap, CompareAndSwap, and CompareAndDelete
// are read operations; Delete, LoadAndDelete, Store, and Swap are write operations;
// LoadOrStore is a write operation when it returns loaded set to false;
// CompareAndSwap is a write operation when it returns swapped set to true;
// and CompareAndDelete is a write operation when it returns deleted set to true.
type Map struct {

//...
// Range may be O(N) with the number of elements in the map even if f returns
// false after a constant number of calls.
func (m *Map) Range(f func(key, value any) bool) {
	// We need to be able to iterate over all of the keys that were already
	// present at the start of the call to Range.
	// If read.amended is false, then read.m satisfies that property without
	// requiring us to hold m.mu for a long time.
	read := m.loadReadOnly()
	if read.amended {
		// m.dirty contains keys not in read.m. Fortunately, Range is already O(N)
		// (assuming the caller does not break out early)...
    ...

Всем приятного копания базы и профессионального роста.

В стандартной C-библиотеке Glibc выявлена уязвимость (CVE-2024-2961), приводящая к переполнению буфера при преобразовании специально оформленных строк в кодировке ISO-2022-CN-EXT функцией iconv().

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

При преобразовании строк в кодировке UCS4, в соответствии с требованиями RFC 1922, библиотека Glibc добавляет некоторые escape-символы, выделяющие части строки, в которых кодировка была изменена.

Уязвимость в вызвана некорректной проверкой границ внутренних буферов функцией iconv(), что может привести к переполнению буфера максимум на 4 байта. При переполнении за границу буфера могут быть записаны определённые фиксированные значения, такие как '$+I', '$+J', '$+K', '$+L', '$+M' и '$*H'. Несмотря на то, что эксплуатация подобной уязвимости для выполнения кода кажется маловероятной, этого оказалось достаточно для подготовки нескольких прототипов эксплоитов для удалённой атаки на PHP-приложения, приводящей к выполнению кода.

Уязвимость проявляется с 2000 года и устранена в находящейся в разработке ветке Glibc 2.40. Исправление также доступно в виде патчей для выпусков Glibc с 2.32 по 2.39. В дистрибутивах проследить за исправлением уязвимости можно на страницах: Debian, Ubuntu, Gentoo, RHEL, SUSE, Fedora, Arch.

Источник: OpenNET.

В размышление о статье "Нужны ли программистам алгоритмы?".

Проблема не в том, нужны или не нужны алгоритмы, а в том, что в России нет развитой айтишной школы, как в США. Нет того уровня образования (как в Калтехе, к примеру). То, что есть сейчас - это прям скажем, беда. Натягивание советской школы на новые реалии. Настолько, что Яндекс даже создает свои учебные заведения, чтобы получить хоть каких-то вменяемых специалистов.

Нужны не знания алгоритмов. Нужны специалисты с инженерным мышлением. У человека без образования мышление хаотичное, несистемное. Он не способен на анализ, упрощение и синтез. Грубо говоря, лупит код, как бог на душу положит, чем больше, тем лучше.

Удалил пост по просьбе.

Вебмониторэкс приглашает вас 17 апреля в 12:00 (мск) на вебинар, во время которого мы раскроем тему значимости обеспечения безопасности API в современных условиях.

Ведущие вебинара - Лев Палей, CISO и Сергей Одинцов, системный аналитик Вебмониторэкс.

Расскажем об изменении ландшафта угроз и отражении этих изменений в OWASP API Security.
Подробно рассмотрим обеспечение безопасности веб-приложений в наиболее атакуемых отраслях (телекоммуникационные компании и интернет платформы).
Покажем, как платформа «Вебмониторэкс» решает задачи по защите веб-приложений и API.

Почему полезно:
  - Узнаете о новых уязвимостях в OWASP API Security и вариантах их эксплуатации
  - Получите рекомендации по защите своих API
  - Увидите примеры, иллюстрирующие изменения OWASP API Security

Продолжительность вебинара 1 час 30 минут!
Регистрируйтесь на вебинар по ссылке.

Приглашаем на день открытых дверей онлайн-магистратуры Яндекс Практикума!

→ Бесплатный вебинар 10 апреля в 18:00

Расскажем про восемь IT-программ онлайн-магистратуры совместно с ведущими вузами, на которые можно поступить в 2024 году. В списке партнёров — ИТМО, НИТУ МИСИС, РАНХиГС, ТГУ и Финансовый университет.

Спикеры:

• Сергей Бережной, директор по взаимодействию с разработчиками в Яндексе;

• Анастасия Ждановская, руководитель программ высшего образования в Яндекс Практикуме;

• Павел Шлюпкин, старший IT-рекрутер в Яндекс 360;

• Елена Шоломова, менеджер команды сопровождения в Практикуме.

Кому будет полезно:

• Всем, кто хочет получить магистерское образование в сфере IT;

• Всем, кому важно получить диплом государственного образца;

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

→ Регистрация

Шаблон декомпозиции ModelView Fractal

Каждый ModelView выступает в роли модели/контроллера для ведомых ModelView и в качестве отображения для владеющего ModelView. Часть логики может выноситься как в чистые Model, так и в чистые View, которые являются лишь вырожденными случаями ModelView.

$my_user_list $my_view
	- \Owner ModelView
	users? /$my_user
	kids /
		<= Row*0 $my_user_row
			user <= user*

$my_user_row $my_card
	- \Having ModevView
	user $my_user
		avatar => image
		nickname => message

$my_card $my_view
	- \View not Model
	kids /
		<= Image $my_image
			uri <= image \about:blank
		<= Message $my_text
			text <= message \
	
$my_user $my_model
	- \Model not View
	avatar? \
	nickname? \

✅ Каждый ModelView полностью контролирует внутренние ModelView и ничего не знает про внешние.
✅ Любой ModelView может шариться между разными другими ModelView на любом уровне композиции.
✅ Изменение интерфейса ModelView требует изменения только лишь его владельцев.
✅ Фрактальная структура легко масштабируется на приложения любого размера.

Шаблон декомпозиции Model-View-Presenter

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

// Presenter
class User_preview {
	user: User
	card = new Card({
		image: ()=> this.user.avatar,
		message: ()=> this.user.nickname,
		color: ()=> this.user.skin.color,
		click: ()=> this.skin_change(),
	})
	skin_change() {
		this.user.skin = Skin.random()
	}
}

// View
<div class="Card" onclick={click} style={{ background: color }}>
	<img src={ image } />
	<p>{ message }</p>
</div>

// Model
class User extends Model {
	avatar: string
	nickname: string
	skin: Skin
}

✅ Легко добавлять новые отображения, не меняя модели. И наоборот.
✅ Изменение интерфесов модели или отображения требует изменения только лишь презентеров.
❌ Трёх слоёв слишком мало на больших масштабах.
❌ Для использования состояния одного презентера из другого необходимо искусственное вынесение его в модели.