Cross Join - канал о разработке

Hewlett Packard Enterprise запустила новый суперкомпьютер El Capitan

Hewlett Packard Enterprise поставила рекорд - компания создала самый мощный суперкомпьютер в мире. El Capitan, установленный в Ливерморской лаборатории США, способен выполнять более 1.7 квинтиллиона вычислений в секунду.
Одна из самых интересных особенностей El Capitan - его система охлаждения. Компания полностью отказалась от вентиляторов в пользу жидкостного охлаждения. Это не только делает систему тихой, но и невероятно энергоэффективной - на каждый ватт потребляемой энергии приходится почти 59 миллиардов вычислений.

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

В основе суперкомпьютера лежат новейшие процессоры AMD Instinct MI300A, объединяющие в себе возможности обычных и графических процессоров с быстрой памятью. Вся система состоит из более чем 11000 таких вычислительных узлов, связанных между собой сверхбыстрой сетью HPE Slingshot.

Подъехали годные каналы по митапам и хакатонам:

Митапочная — для тех кто хочет:
- Участвовать в неформальных встречах, где обсуждаются актуальные темы, делятся знаниями и опытом;
- Поделиться своими идеями и проектами;
- Найти новых друзей и коллег по интересам.
Митапы — это отличная возможность для нетворкинга и профессионального роста!

Хакатоночная — для тех кто хочет:
- Узнать о предстоящих хакатонах и конкурсах;
- Найти команду или единомышленников для совместной работы;
- Создать что то уникальное за короткое время.
Хакатоны — это шанс проявить себя, реализовать свои идеи и получить ценный опыт!

Присоединяйтесь!

Я вот чего не понимаю.

Сейчас в мире продолжается тема с заталкиванием людей обратно в офисы. Окей, менеджерам легче, когда они видят людей лично, кто-то считает, что люди в офисах будут работать эффективнее. Допустим, хотя никаких внятных подтверждений этому пока нет, исследования противоречивы. (Если знаете такие - скиньте.) Ну, допустим, даже так.

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

Это просто напрямую стоит денег: люди, готовые работать в офисе стоят в среднем дороже, чем люди, которым дают выбор. Цена - это баланс спроса и предложения. Если предложение состоит только из людей одного города (где стоит офис), да еще и работающих только в офисе, а не дома - это прям существенно меньше чем "любые люди".

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

И вдвойне странно, если офисов много в разных частях страны/мира, и команда всё равно общается друг с другом через интернет.

Gemini посоветовал пользователю умереть. "Умри , пожалуйста", говорит

Лог чата пока еще доступен по ссылке

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

https://habr.com/ru/articles/857784/

ахаха, сегодня я узнал, что в JavaScript обдумывают завезти оператор ?=, который делает обработку ошибок в Гошном стиле. Т.е. натурально, проверку ошибки на nil null

const [error, result] ?= await fetch("https://example.com/data");

if (error) {
   // do something
}

правильно, пусть все страдают, а то чё только гошники

Пора заводить рубрику "слоупок".

Бесит, когда запускаешь терминал, в терминале набираешь что-то частое, например docker, жмешь стрелку вверх (zsh), а там в истории какой-то мусор от других проектов, которые ты недавно пощупал.

Ну так вот, нашёл классный плагин для zsh - per-directory-history. Он запоминает команды отдельно для каждой папки.

Ctrl+G переключает между локальной и глобальной историей.

Включается просто - добавить в список плагинов per-directory-history

Чума просто

Пишут, что в Go 1.24 мапы будут переключены на алгоритм SwissTable

https://github.com/golang/go/issues/43930#issuecomment-2458068992

API хочется создавать, начиная со спецификации, а потом генерить по ней код "контроллеров", тогда код и дока всегда будут актуальны. Для описания http API есть стандарт OpenAPI (бывший swagger), но он довольно многословный, создавать эти огромные yaml неудобно.

Ну так вот, я недавно узнал, что у Майкрософт есть свой стандарт typespec, который можно сконвертить в те же километровые емлы.

Выглядит миленько

React Native полностью переделан

После 6 лет разработки команда React Native представила полностью переписанную архитектуру фреймворка (0.76) – самое значительное обновление с момента создания React Native. Это результат масштабной работы над улучшением производительности, стабильности и возможностей платформы.

Ключевые изменения

Новая версия обеспечивает полную поддержку современных возможностей React, включая Suspense, Transitions и автоматический батчинг. В React Native наконец появился полноценный useLayoutEffect – теперь работа с лейаутом стала синхронной и предсказуемой. Это позволяет корректно позиционировать элементы интерфейса без промежуточных состояний и визуальных артефактов.

Улучшение производительности

Мост между JavaScript и нативным кодом полностью удален. Коммуникация теперь происходит напрямую через JavaScript Interface (JSI), что существенно ускоряет работу приложения и его запуск. Новый рендерер может обрабатывать несколько деревьев компонентов одновременно в разных потоках с разными приоритетами. Это позволяет прерывать низкоприоритетные обновления для обработки пользовательского ввода, обеспечивая отзывчивость интерфейса даже при сложных вычислениях.

Технические улучшения

Система нативных модулей была полностью переработана. Теперь доступен синхронный доступ к нативным интерфейсам с полной типобезопасностью между JavaScript и нативным кодом. Появилась возможность писать кроссплатформенный код на C++, который работает на всех поддерживаемых платформах: iOS, Android, Windows и macOS. Модули загружаются лениво, что значительно сокращает время запуска приложения и потребление памяти.

View Flattening, ранее доступный только на Android, теперь работает и на iOS благодаря общему C++ рендереру. Эта оптимизация автоматически упрощает глубокие деревья компонентов, улучшая производительность рендеринга.

Проверено в продакшене

Новая архитектура уже активно используется в крупных приложениях: Facebook, Instagram, Expensify, Kraken и BlueSky. Facebook и Instagram для Meta Quest также построены на новой архитектуре. Это демонстрирует её готовность к применению в проектах любого масштаба и сложности.

Процесс миграции

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

Популярные библиотеки, такие как react-native-mmkv и Reanimated, уже получили значительные улучшения от перехода на новую архитектуру. MMKV стал полностью кроссплатформенным C++ модулем с улучшенной типобезопасностью, а Reanimated 4 получил возможность управлять анимациями и лейаутом в разных потоках.

Дальнейшее развитие

В планах команды React Native – улучшение встроенных компонентов и расширение поддержки современных веб-стандартов. Event Loop теперь работает в соответствии с веб-спецификациями HTML Standard, что в будущем позволит использовать такие API как microtasks, MutationObserver и IntersectionObserver.

Практическая информация

Совместимость используемых библиотек можно проверить на reactnative.directory. Официальная документация содержит подробное руководство по миграции. При возникновении проблем всегда есть возможность отключить новую архитектуру через конфигурацию проекта.

Если нужно с помощью ChatGPT сделать сразу несколько файлов с кодом, например целый проект, то это неудобно, надо копировать каждый файл отдельно и хз как это организовать, в общем тупо как-то. Вчера я увидел интересный лайфхак (здесь): можно гопчат попросить сделать bash-файл, который создаст тебе проект со всеми файлами, env переменными и т.д.

Например, такой промт:

"Создай проект на Go 1.23, который делает API для todo list. Данные хранить в Postgres. Создай проект со всеми необходимыми файлами, docker-compose и env переменными. Сделай это в виде bash файла, который сразу всё правильно создаст. Проект назови proverka"

в итоге реально был создан bash файл, который при запуске создал проект. Этот проект сбилдился (я сделал только одну правочку в импортах), запустился через docker-compose, всё ок. Правда, версия Go была не такая, зачем-то туда приделался Gorm, но не суть, это мелочи и можно поиграться с промтом

Устал искать работу?

Мы - YourOffer, HR-агентство, помогающее специалистам найти работу в следующих направлениях:

📊 Аналитика
📆 Менеджмент
🗂 Data Science
💻 Разработка

Что мы предлагаем:

🔹 Индивидуальное карьерное руководство и составление резюме
🔹 Подготовка к техническим интервью и подбор вакансий в топ-компаниях
🔹 Успешные истории трудоустройства в компании Тинькофф, Сбербанк, Яндекс и другие

Наш уникальный подход:

🔹 Нет предоплаты - платим только после успешного трудоустройства
🔹 Средний срок трудоустройства - всего 2,5 месяца

Готовы начать путь к своей мечте?
Присоединяйтесь к нам сегодня и по ссылке: https://clck.ru/3E8rnA

Реклама. ИП Лукин А.В. ИНН: 772460658942 erid: 2VtzqvH6cT2

Devjobscanner пропарсил 12 миллионов вакансий (за 1.5 года) и составил топ самых востребованных языков. Из интересного - Ruby и PHP, про смерть которых я слышу уже лет 10, по прежнему хорошо себя чувствуют и всех нас еще переживут. С++ че-то немного пошел вниз

иногда комментарии в коде очень важны

Я айтишник и я устал!

С годами работы в IT все сильнее напрягает рутина, прокрастинация, куча задач и 0 желания их выполнять. Че делать?

Хватит грызть самого себя и заставлять через силу - сделаешь только хуже!

Лучше подпишись на того, кто уже не первый год работает с IT-специалистами и помогает им справиться с апатией и прокрастинацией - Психолог с научным подходом.

✔️ Как оторваться от ленты соцсетей и сесть за работу с удовольствием?
✔️ Как спокойно общаться с коллегами, если они бесят?
✔️ Как избавиться от постоянной тревожности?
✔️ Как успокоить конфликты в семье и перестать срываться на всех, а вместо этого получить поддержку и понимание со стороны близких?

Подписывайся на канал @remizov_changes - начни работать и жить в кайф, не скатываясь в кризисы и выгорание!

А в закрепе тебя уже ждут бонусы:
👨🏻‍💻 Видео, в котором ты найдёшь ответ на вопрос «Почему у тебя нет энергии и что с этим делать» + гайд как it-специалисту вернуть энергию, даже если не получается отдохнуть.

https://t.me/+z-dCSKRNVlQ3YTBi

Гоферы, пройдите опрос 2024

Прошлогодний опрос показал, что гошники в основном бывшие пыхари, и от языка хотят они одного: улучшения обработки ошибок :)

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

FizzBuzz Enterprise Edition

Думаю, все знают задачку Fizz Buzz (выведи Fizz, если число делится на 3, Buzz, если на 5, FizzBuzz если на 3 и на 5). Посмотрите, как делают эту задачу серьёзные люди. Для серьёзного бизнеса. Какие стратегии, фабрики, интерфейсы и всё такое.

Это настоящее пособие по паттернам, а паттерны - это язык, облегчающий общение разработчиков

В догонку к предыдущему посту про гибкость vs простота. В языке Go очень интересно сделаны интерфейсы.

Например, есть какой-то класс (точнее структура с методами) с методом getWeather(city), который является обёрткой над внешним сервисом погоды.

type WeatherService struct {
    apiKey string
}

func (w *WeatherService) GetWeather(city string) (string, error) {
    // http вызов внешнего API
    return "Sunny", nil
}

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

type WeatherAnalyzer struct {
    weatherService *WeatherService // конкретный класс
}

func (wa *WeatherAnalyzer) AnalyzeWeather(city string) string {
    weather, err := wa.weatherService.GetWeather(city)
    if err != nil {
        return "Unable to analyze weather"
    }
    if weather == "Sunny" {
        return "Great day for a picnic!"
    }
    return "Maybe stay indoors"
}

// Использование
func main() {
    ws := &WeatherService{apiKey: "some-api-key"}
    wa := &WeatherAnalyzer{weatherService: ws}
    result := wa.AnalyzeWeather("New York")
    fmt.Println(result)
}

И тут мы ВНЕЗАПНО поняли, что покрывать тестами это неудобно (ибо внешние вызовы), и лучше бы написать интерфейс, чтобы потом его замокать. Или у нас вдруг появился еще один сервис погоды, и нужен интерфейс. Так вот, в Go достаточно просто ПО МЕСТУ добавить интерфейс с описанием нужных в этом месте методов, а сам класс погоды останется неизменным.

Вот как это будет выглядеть:

// WeatherService остается без изменений

type WeatherProvider interface {
    GetWeather(city string) (string, error)
}

type WeatherAnalyzer struct {
    weatherProvider WeatherProvider
}

func (wa *WeatherAnalyzer) AnalyzeWeather(city string) string {
    weather, err := wa.weatherProvider.GetWeather(city)
    if err != nil {
        return "Unable to analyze weather"
    }
    if weather == "Sunny" {
        return "Great day for a picnic!"
    }
    return "Maybe stay indoors"
}

Потому что в отличие от Java/PHP/etc не нужно писать что класс имплементирует что-то там. Если у класса есть методы такие же как в интерфейсе, то он подходит под сигнатуру

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

Теперь мы можем легко создать мок для тестирования (упрощенный пример)

type MockWeatherProvider struct {
    MockWeather string
}

func (m *MockWeatherProvider) GetWeather(city string) (string, error) {
    return m.MockWeather, nil
}

func TestWeatherAnalyzer(t *testing.T) {
    mockProvider := &MockWeatherProvider{MockWeather: "Sunny"}
    analyzer := &WeatherAnalyzer{weatherProvider: mockProvider}
    
    result := analyzer.AnalyzeWeather("Test City")
    expected := "Great day for a picnic!"
    
    if result != expected {
        t.Errorf("Expected %s, but got %s", expected, result)
    }
}

У этого конечно есть и недостатки.

Очень интересный документ на github, который на различных примерах утверждает, что при программировании во главу угла нужно ставить когнитивную нагрузку от твоего кода и всегда это держать в голове.

Как делить на модули, когда нужно или не нужно использовать микросервисы, гексагональную архитектуру и т.д. Что важнее: гибкость/универсальность кода или простота.

TLDR: используйте сложные трюки только там, где они действительно нужны.

https://github.com/zakirullin/cognitive-load

Давайте пофантазируем.

Что, если сделать свой отдельный Go, который бы транспилировался в обычный? как TS -> JS

Я бы добавил туда как минимум две вещи, которые точно никогда не появятся в Go, и половине людей там и не нужны:

1. Сахар для обработки ошибок (как-нибудь как в Расте, чтобы обработка была всё еще явной, но синтаксически попроще). Плюс синтаксис для ловли паник тоже попроще.

2. Добавил бы немного structured concurrency: запретил бы голый вызов команды go. Синтаксически заставить дожидаться завершения горутины в той же функции, где она была запущена.

Может, еще с каналами что-то намутить, чтобы заставить их закрывать примерно там же, где в них шла запись (в том же пакете?)

Тогда это получится язык в 10 раз более читаемый и в 10 раз менее запутанный в вопросах concurrency

#непрокниги

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

Эти вопросы я собрал при помощи коллег, когда проходил интервью в Яндекс 360. Дополняйте своими вопросами в комментариях.

Я наверно слоупок, только сейчас узнал о программе dust, замене du

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

Запустил в папке с проектами, сразу нашел гигабайтные node_modules в старых проектах, прикольно.

подробнее тут (там куча полезных параметров)

Ставится просто brew install dust

Вышел PostgreSQL 17

Производительность:

Существенно улучшена работа с памятью. Вакуум теперь потребляет до 20 раз меньше памяти, что ускоряет его работу и снижает нагрузку на систему.
Запись при высокой конкурентной нагрузке стала быстрее в 2 раза благодаря оптимизации обработки WAL.
Улучшена производительность запросов с использованием условий IN для B-tree индексов.
Добавлена поддержка SIMD-инструкций (в том числе AVX-512) для ускорения вычислений.
Оптимизирована производительность COPY для экспорта больших объемов данных.

Для разработчиков:

Расширена поддержка JSON: добавлен JSON_TABLE для конвертации json в обычные таблицы PostgreSQL.
Появились новые конструкторы и функции для работы с json: JSON, JSON_SCALAR, JSON_SERIALIZE, JSON_EXISTS, JSON_QUERY, JSON_VALUE.
Улучшена команда MERGE: добавлена поддержка RETURNING и возможность обновления представлений.
EXPLAIN теперь показывает время, затраченное на локальное чтение и запись блоков, а также использование памяти.

Репликация и обновление:

Упрощен процесс обновления между мажорными версиями при использовании логической репликации. Теперь не нужно удалять слоты репликации при обновлении.
Добавлен контроль отказоустойчивости для логической репликации.
Представлен инструмент pg_createsubscriber для конвертации физической реплики в логическую.

Безопасность и управление:

Новые опции TLS для более гибкой настройки безопасности соединений.
Добавлена предопределенная роль pg_maintain для выполнения задач обслуживания.
Улучшены возможности резервного копирования: поддержка инкрементальных бэкапов в pg_basebackup.

Мониторинг и анализ:

Добавлено отображение прогресса при вакууме индексов.
Новое системное представление pg_wait_events для более детального анализа ожидающих сессий.

Я принес. Гуманизм против «эффективного менеджмента». Почему заботиться о людях выгодно

Вы знаете, что я тот еще гуманист 🙂 Поэтому не мог пройти мимо этого лонгрида https://habr.com/ru/articles/816545/
Текст большой, так что наливайте чай-кофе, заводите один таймер pomodoro и погружайтесь.

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

Так что, граждане тимлиды, этот контент вам точно будет полезен.

Дженерик алиасы типов в Go в 1.24 : что это и зачем они нужны

Представьте, что вы работаете над крупным проектом на Go, который развивается уже несколько лет. В какой-то момент вы понимаете, что структура пакетов, которую вы изначально выбрали, больше не отвечает потребностям проекта. Вам нужно перенести некоторые типы из одного пакета в другой. Звучит просто, верно? Но не тут-то было!

Проблема рефакторинга в больших проектах

Представим, что у вас есть популярный пакет oldpkg с типом User:

package oldpkg

type User struct {
    ID   int
    Name string
}

Теперь вы хотите перенести этот тип в новый пакет newpkg. Но ваш тип User используется в сотнях мест по всему проекту и в зависимых проектах. Как провести такой рефакторинг без боли?

Go 1.9 представил концепцию алиасов типов. Это позволяет нам создать новое имя для существующего типа без создания нового типа. Вот как это выглядит:

package newpkg

import "path/to/oldpkg"

type User = oldpkg.User

Теперь newpkg.User и oldpkg.User - это один и тот же тип. Мы можем постепенно обновлять использование oldpkg.User на newpkg.User по всему проекту, и компилятор будет счастлив.

Но что насчет дженериков?

С появлением дженериков в Go 1.18 возникла новая проблема. Как быть, если наш тип User использует параметры типа? До сих пор алиасы типов не поддерживали параметры типа. Но это изменится в Go 1.24

Дженерик алиасы типов

Представим, что наш тип User теперь дженерик:

package oldpkg

type User[T any] struct {
    ID   T
    Name string
}

В Go 1.24 мы сможем создать алиас для этого типа следующим образом:

package newpkg

import "path/to/oldpkg"

type User[T any] = oldpkg.User[T]

Это позволяет нам сохранить полную совместимость типов при переносе дженерик-типов между пакетами.

Когда это будет доступно?

В Go 1.23 вы можете включить поддержку дженерик алиасов типов с помощью флага GOEXPERIMENT=aliastypeparams.
В Go 1.24 (ожидается в начале 2025 года) эта функция будет включена по умолчанию.

Подробности здесь

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

https://openai.com/index/introducing-openai-o1-preview/

Среди программистов довольно часто встречаются перфекционисты. Чаще, чем в других профессиях.

А ты? Перфекционируешь небось?

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

Импорты должны быть отсортированы по хитрым правилам. Перед return должен быть перевод строки, иначе мы все умрём. (Или что там у вас?)

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

Короче. Предлагаю лайфхак.

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

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

Баланс между читаемостью кода и скростью разработки. Разберитесь идеально, досконально, перфектно, что сильно влияет на читабельность , а что неидеально лишь тратит ресурсы.

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

Забавная статья. ChatGPT деминифицировал код.

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

Тогда он сначала попросил ChatGPT объяснить принцип работы, а потом просто сказал, мол, а сгенери-ка ты нормальный человеко-читаемый typescript.

И на его удивление, получилось просто почти идеально.

Т.е., гопчат сработал как деминификатор кода.

https://glama.ai/blog/2024-08-29-reverse-engineering-minified-code-using-openai

Фиганул статью на хабр про монокультуру в программировании: https://habr.com/ru/articles/838682/ Где рассказываю про то, как монокультура (использование одной технологии повсеместно) мешает и вредит проектам