Forwarded from ИА Панорама
Папа Лев XIV назвал Haskell сатанинским языком и запретил функциональное программирование
Текст: Эрвин Кляйн
Текст: Эрвин Кляйн
ИА Панорама
Папа Лев XIV назвал Haskell сатанинским языком и запретил функциональное программирование
Папа Лев XIV, выступая на конференции по искусственному интеллекту, заявил, что Господь проклял язык программирования Haskell и все парадигмы функционального пр...
😁41👍9🌚4😱3
Ментальные ловушки софтваре девелопера
в статье прям всю мою жизнь описали.
TLDR:
1. Планирование и оценки:
Ошибка планирования — недооценка времени на задачи, даже имея опыт подобных проектов
Эвристика доступности — принятие решений на основе недавних событий, а не реальной статистики
Эффект якоря — слишком сильная привязка к первой полученной оценке
2. Выбор инструментов:
Закон инструмента — использование знакомых технологий для всех задач подряд
Синдром "не изобретено здесь" — отказ от готовых решений в пользу разработки с нуля
Эффект присоединения к большинству — выбор трендовых технологий без учета реальных потребностей
3 .Работа в команде:
XY-проблема — попытка решить неправильно сформулированную задачу
Ошибка атрибуции — обвинение людей вместо анализа системных причин
Конформизм — молчание при несогласии с групповым решением
Предвзятость авторитета — слепое следование мнению старших коллег
4. Самооценка:
Синдром самозванца — недооценка собственных навыков
Эффект Даннинга-Крюгера — переоценка способностей новичками и недооценка экспертами
Эгоистическая предвзятость — приписывание успехов себе, а неудач — внешним факторам
5. Принятие решений:
Эффект IKEA — переоценка собственного кода и сопротивление рефакторингу
Велосипедный сарай — фокус на мелочах вместо важных проблем
Искажение выжившего — изучение только успешных кейсов без анализа провалов
Предвзятость подтверждения — поиск фактов, подтверждающих существующие убеждения
Вот такие когнитивные искажения на канале🫥 Cross Join
⠀
в статье прям всю мою жизнь описали.
TLDR:
1. Планирование и оценки:
Ошибка планирования — недооценка времени на задачи, даже имея опыт подобных проектов
Эвристика доступности — принятие решений на основе недавних событий, а не реальной статистики
Эффект якоря — слишком сильная привязка к первой полученной оценке
2. Выбор инструментов:
Закон инструмента — использование знакомых технологий для всех задач подряд
Синдром "не изобретено здесь" — отказ от готовых решений в пользу разработки с нуля
Эффект присоединения к большинству — выбор трендовых технологий без учета реальных потребностей
3 .Работа в команде:
XY-проблема — попытка решить неправильно сформулированную задачу
Ошибка атрибуции — обвинение людей вместо анализа системных причин
Конформизм — молчание при несогласии с групповым решением
Предвзятость авторитета — слепое следование мнению старших коллег
4. Самооценка:
Синдром самозванца — недооценка собственных навыков
Эффект Даннинга-Крюгера — переоценка способностей новичками и недооценка экспертами
Эгоистическая предвзятость — приписывание успехов себе, а неудач — внешним факторам
5. Принятие решений:
Эффект IKEA — переоценка собственного кода и сопротивление рефакторингу
Велосипедный сарай — фокус на мелочах вместо важных проблем
Искажение выжившего — изучение только успешных кейсов без анализа провалов
Предвзятость подтверждения — поиск фактов, подтверждающих существующие убеждения
Вот такие когнитивные искажения на канале
⠀
Please open Telegram to view this post
VIEW IN TELEGRAM
Strategizeyourcareer
✋ The 17 biggest mental traps costing software engineers time and growth
Bad estimates and flawed project decisions? Uncover 17 hidden thinking errors and learn to fix them for better code and team success
❤20🔥6👍2
Друзья делают корпоративный мессенджер, пройдите плиз короткий опрос, чем сейчас пользуетесь, какие боли и т.д. Чтобы мессенджер получился реально крутой.
Ссылка на опрос: https://forms.gle/ppMuWrXeLLgLdYND9
Спасибо!
Ссылка на опрос: https://forms.gle/ppMuWrXeLLgLdYND9
Спасибо!
Google Docs
Корпоративные мессенджеры
Мы создаем MVP корпоративного мессенджера с прицелом на безопасность, противодействие утечкам данных в условиях BYOD, высокую эргономику, легкость в управлении и администрировании.
Наша цель – сделать не просто удобный продукт для повседневного общения в…
Наша цель – сделать не просто удобный продукт для повседневного общения в…
😁13💩9🖕8👌4🤡4
Какие-то энтузиасты сделали свой язык Gauntlet (можно перевести как вызов, когда бросают перчатку в лицо), который почти такой же как Go, только "фиксит раздражающие особенности языка". Транспилируется в Go, так что, как я понял, совместим со всеми гошными либами.
https://github.com/gauntlet-lang/gauntlet
Вот описание от авторов языка, я с половиной не согласен, но в целом что-то в этой идее есть.
Какие проблемы Go решает Gauntlet?
- Раздражающая ошибка "неиспользуемая переменная"
- Многословная обработка ошибок (if err ≠ nil повсюду в вашем коде)
- Неудобный способ импорта и экспорта (например, использование заглавных букв для экспорта)
- Отсутствие тернарного оператора
- Отсутствие выразительной конструкции switch-case
- Сложные циклы for
- Странный оператор присваивания (чья это была идея использовать :=)
- Отсутствие способа плавно связывать функции в цепочки
Возможности языка
- Транспилируется в поддерживаемый, легко читаемый код на Golang
- Использует точно те же соглашения/идиомы, что и Go. Практически отсутствует кривая обучения.
- Последовательный и знакомый синтаксис
- Практически мгновенное преобразование в Go
- Простая установка с помощью единственного самодостаточного исполняемого файла
- Красивая подсветка синтаксиса в Visual Studio Code
Пример
🫥 Cross Join
⠀
https://github.com/gauntlet-lang/gauntlet
Вот описание от авторов языка, я с половиной не согласен, но в целом что-то в этой идее есть.
Какие проблемы Go решает Gauntlet?
- Раздражающая ошибка "неиспользуемая переменная"
- Многословная обработка ошибок (if err ≠ nil повсюду в вашем коде)
- Неудобный способ импорта и экспорта (например, использование заглавных букв для экспорта)
- Отсутствие тернарного оператора
- Отсутствие выразительной конструкции switch-case
- Сложные циклы for
- Странный оператор присваивания (чья это была идея использовать :=)
- Отсутствие способа плавно связывать функции в цепочки
Возможности языка
- Транспилируется в поддерживаемый, легко читаемый код на Golang
- Использует точно те же соглашения/идиомы, что и Go. Практически отсутствует кривая обучения.
- Последовательный и знакомый синтаксис
- Практически мгновенное преобразование в Go
- Простая установка с помощью единственного самодостаточного исполняемого файла
- Красивая подсветка синтаксиса в Visual Studio Code
Пример
package main
// Seamless interop with the entire golang ecosystem
import "fmt" as fmt
import "os" as os
import "strings" as strings
import "strconv" as strconv
// Explicit export keyword
export fun ([]String, Error) getTrimmedFileLines(String fileName) {
// try-with syntax replaces verbose `err != nil` error handling
let fileContent, err = try os.readFile(fileName) with (null, err)
let fileContentStrVersion = (String)(fileContent) // Type conversion
let trimmedLines =
// Pipes feed output of last function into next one
fileContentStrVersion
=> strings.trimSpace(_)
=> strings.split(_, "\n")
// `nil` is equal to `null` in Gauntlet
return (trimmedLines, null)
}
fun Unit main() {
let a = 1 // No unused variable errors
// force-with syntax will panic if err != nil
let lines, err = force getTrimmedFileLines("example.txt") with err
// Ternary operator
let properWord = @String len(lines) > 1 ? "lines" : "line"
let stringLength = lines => len(_) => strconv.itoa(_)
fmt.println("There are " + stringLength + " " + properWord + ".")
fmt.println("Here they are:")
// Simplified for-loops
for let i, line in lines {
fmt.println("Line " + strconv.itoa(i + 1) + " is:")
fmt.println(line)
}
}
⠀
Please open Telegram to view this post
VIEW IN TELEGRAM
GitHub
GitHub - gauntlet-lang/gauntlet: A compile-to-Golang programming language designed to alleviate some of Go's design choices 👾
A compile-to-Golang programming language designed to alleviate some of Go's design choices 👾 - gauntlet-lang/gauntlet
🤮16🤔7🤷♂4❤3💩3🔥2👍1💊1
Go отказывается от улучшения синтаксиса обработки ошибок
Команда разработчиков языка программирования Go приняла решение: они прекращают попытки изменить синтаксис для обработки ошибок. Об этом сообщил Роберт Грисемер в официальном блоге проекта.
Проблема, которую не смогли решить
Многословность обработки ошибок в Go — это главная жалоба разработчиков уже много лет. Типичный код выглядит так:
В некоторых функциях чуть ли не половину кода составляют именно такие проверки, что делает код трудночитаемым и отвлекает от основной логики.
Безуспешные попытки решения
За 7 лет команда Go предложила несколько вариантов:
2018 год: механизм check/handle — слишком сложный
2019 год: встроенная функция try() — скрывала поток управления, получила резко негативную реакцию сообщества
2024 год: оператор ? (как в Rust) — также не получил поддержки
Помимо официальных предложений, сообщество создало сотни собственных вариантов, но ни один не собрал достаточной поддержки.
Почему решили остановиться:
Прежде всего, отсутствует консенсус даже внутри самой команды Go. Любое изменение неизбежно создаст новую группу недовольных пользователей. В отличие от дженериков, которые можно не использовать, новый синтаксис ошибок придется применять всем разработчикам. Кроме того, стоимость таких изменений очень высока — потребуется обновить весь существующий код, документацию и инструменты.
Есть аргументы в пользу сохранения текущего положения. Go существует уже 15 лет, и возможность для кардинальных изменений давно упущена. Существующий способ обработки ошибок работает вполне нормально, а современные IDE с автодополнением значительно упрощают написание повторяющегося кода.
Что дальше?
Команда Go будет закрывать все новые предложения по изменению синтаксиса обработки ошибок без рассмотрения. Вместо этого они сосредоточатся на других улучшениях языка и стандартной библиотеки.
🫥 Cross Join
⠀
Команда разработчиков языка программирования Go приняла решение: они прекращают попытки изменить синтаксис для обработки ошибок. Об этом сообщил Роберт Грисемер в официальном блоге проекта.
Проблема, которую не смогли решить
Многословность обработки ошибок в Go — это главная жалоба разработчиков уже много лет. Типичный код выглядит так:
x, err := call()
if err != nil {
// обработка ошибки
}
В некоторых функциях чуть ли не половину кода составляют именно такие проверки, что делает код трудночитаемым и отвлекает от основной логики.
Безуспешные попытки решения
За 7 лет команда Go предложила несколько вариантов:
2018 год: механизм check/handle — слишком сложный
2019 год: встроенная функция try() — скрывала поток управления, получила резко негативную реакцию сообщества
2024 год: оператор ? (как в Rust) — также не получил поддержки
Помимо официальных предложений, сообщество создало сотни собственных вариантов, но ни один не собрал достаточной поддержки.
Почему решили остановиться:
Прежде всего, отсутствует консенсус даже внутри самой команды Go. Любое изменение неизбежно создаст новую группу недовольных пользователей. В отличие от дженериков, которые можно не использовать, новый синтаксис ошибок придется применять всем разработчикам. Кроме того, стоимость таких изменений очень высока — потребуется обновить весь существующий код, документацию и инструменты.
Есть аргументы в пользу сохранения текущего положения. Go существует уже 15 лет, и возможность для кардинальных изменений давно упущена. Существующий способ обработки ошибок работает вполне нормально, а современные IDE с автодополнением значительно упрощают написание повторяющегося кода.
Что дальше?
Команда Go будет закрывать все новые предложения по изменению синтаксиса обработки ошибок без рассмотрения. Вместо этого они сосредоточатся на других улучшениях языка и стандартной библиотеки.
⠀
Please open Telegram to view this post
VIEW IN TELEGRAM
👍41🤡34😢6🎉2🫡2❤1👎1
Вышел go 1.25 rc1 (ожидаемая дата релиза: август 2025)
Вот некоторые штуки, которые там есть:
>> Среда выполнения (Runtime)
GOMAXPROCS теперь учитывает контейнеры
На Linux автоматически ограничивается лимитами CPU в cgroup (важно для Kubernetes)
Динамически обновляется при изменении доступных CPU
Новый экспериментальный сборщик мусора
Включается через GOEXPERIMENT=greenteagc (описание GC)
Обещает снижение накладных расходов на 10-40%
>> Инструменты
Команда go
Новая директива ignore в go.mod для исключения каталогов
go doc -http запускает веб-сервер с документацией
Поддержка JSON в
Новые анализаторы в go vet
waitgroup - находит неправильное использование sync.WaitGroup.Add
hostport - предупреждает о проблемах с IPv6 в сетевых адресах
>> Стандартная библиотека
Новые пакеты
testing/synctest - для тестирования конкурентного кода
encoding/json/v2 - экспериментальная новая реализация JSON (быстрее декодирование)
Улучшения производительности
Компилятор чаще размещает слайсы на стеке
Параллельное выполнение cleanup-функций в runtime
>> Безопасность и исправления
Компилятор
Исправлена проверка nil-указателей (некоторый код может начать паниковать)
Генерация отладочной информации в формате DWARF 5
TLS
Запрещены SHA-1 алгоритмы подписи в TLS 1.2
Поддержка Encrypted Client Hello
🫥 Cross Join
⠀
Вот некоторые штуки, которые там есть:
>> Среда выполнения (Runtime)
GOMAXPROCS теперь учитывает контейнеры
На Linux автоматически ограничивается лимитами CPU в cgroup (важно для Kubernetes)
Динамически обновляется при изменении доступных CPU
Новый экспериментальный сборщик мусора
Включается через GOEXPERIMENT=greenteagc (описание GC)
Обещает снижение накладных расходов на 10-40%
>> Инструменты
Команда go
Новая директива ignore в go.mod для исключения каталогов
go doc -http запускает веб-сервер с документацией
Поддержка JSON в
go version -m -jsonНовые анализаторы в go vet
waitgroup - находит неправильное использование sync.WaitGroup.Add
hostport - предупреждает о проблемах с IPv6 в сетевых адресах
>> Стандартная библиотека
Новые пакеты
testing/synctest - для тестирования конкурентного кода
encoding/json/v2 - экспериментальная новая реализация JSON (быстрее декодирование)
Улучшения производительности
Компилятор чаще размещает слайсы на стеке
Параллельное выполнение cleanup-функций в runtime
>> Безопасность и исправления
Компилятор
Исправлена проверка nil-указателей (некоторый код может начать паниковать)
// этот код ошибочно не паниковал в случае ошибки,
// хотя f использовалось до проверки err != nil
package main
import "os"
func main() {
f, err := os.Open("nonExistentFile")
name := f.Name()
if err != nil {
return
}
println(name)
}
Генерация отладочной информации в формате DWARF 5
TLS
Запрещены SHA-1 алгоритмы подписи в TLS 1.2
Поддержка Encrypted Client Hello
⠀
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥19👍11❤2
Очень важную тему обсудили пацаны и пацанесы.
Вообще, это удивительно - я много раз был на менеджерских курсах разных видов, и прям очень редко там упоминали про системы, почти никогда. А ведь это слон в комнате.
Вообще, это удивительно - я много раз был на менеджерских курсах разных видов, и прям очень редко там упоминали про системы, почти никогда. А ведь это слон в комнате.
👍2❤1🤝1
Forwarded from Кода кода
Теория ограничений (ТОС): как работает на практике?
Тема нового эпизода — теория ограничений систем, также известная как теория ограничений (от англ. Theory of Constraints, ТОС).
Обсудим, почему ТОС — это не теория в прямом смысле слова, а вполне себе прагматичный подход: как это работает, в чём польза и в чём ограничения, почему важно выныривать из рутины и вспоминать о цели, зачем мы что-то делаем, и какие действия являются эффективными.
Будем выходить на уровень надсистемы, а ещё пофилософствуем, действительно ли всегда люди должны быть заняты и какой жизнью жить — лёгкой или полной?
Наш проводник в этой теме — Саша Брызгалова, практик, эксперт и немного фанатик ТОС.
Дискутируем, накидываем на вентилятор, приводим примеры, чтобы разобраться:
👉 Что есть теория, что система, а что — ограничение?
👉 В каких системах есть ограничения и чем они не являются?
👉 С какой целью создаются системы и как связаны цели личные и цели компании?
👉 Что является самым популярным ограничением в проектном управлении?
👉 Когда «упороться по-максимуму» сыграет злую шутку?
👉 Что такое локальная оптимизация и почему правила во имя неё губят систему?
👉 Почему незавершённые проекты и переключения — бич для эффективности?Никогда такого не было, и вот мы опять обсуждаем эту тему 🫠
👉 В каких ситуациях, работая работу, чувствуешь себя молодцом?
👉 Какие установки нам мешают достигать целей и чем вредны KPI?
👉 Почему аргумент «мы всегда так делали» aka «так исторически сложилось» не аргумент вовсе?
👉 Для каких проблем ТОС не подходит и в каких случаях инструменты не эффективны? Ещё больше примеров в докладе Саши.
👉 Какой вопрос из теории ограничений непременно стоит себе задать?
👉 Win-win решения — правда или вымысел?
👉 С чего же начать, чтобы внедрить теорию ограничений в свою работу?
Этот эпизод, как и весь сезон, выпускается при поддержке драйвовой команды инженеров — @AvitoTech. Ребята создают сервисы, которыми пользуется треть жителей России каждый месяц.
В июне знакомьтесь с ними лично: с 10 по 15 июня, Сочи, South Hub — встречайте активности от C-level, и 26-27 июня, Санкт-Петербург, Saint TeamLead Conf — заглядывайте в playbook lounge, чтобы понетворкаться и узнать ценности и принципы каждого тимлида в AvitoTech.
🎙Ведущие выпуска — Виктор Корейша, руководитель направления Managed Services в Ozon, и Евгений Антонов, ведущий технический менеджер в Yandex Infrastructure, автор канала «Тимлид Очевидность».
🎧 Слушайте подкаст «Кода кода» в Яндекс Музыке, Apple Podcasts, Spotify, VK и много ещё где по ссылке: https://kodakoda.mave.digital/ep-84
🐝 Пишите отзывы, предлагайте темы, спорьте или соглашайтесь с гостями и ведущими.
Внимательные слушатели, ставьте ⚡️к этому посту.
Нам важна ваша обратная связь!
Реклама. ООО «Авито Тех», ИНН 9710089440, erid: 2SDnjcQ4ZD7
Тема нового эпизода — теория ограничений систем, также известная как теория ограничений (от англ. Theory of Constraints, ТОС).
Обсудим, почему ТОС — это не теория в прямом смысле слова, а вполне себе прагматичный подход: как это работает, в чём польза и в чём ограничения, почему важно выныривать из рутины и вспоминать о цели, зачем мы что-то делаем, и какие действия являются эффективными.
Будем выходить на уровень надсистемы, а ещё пофилософствуем, действительно ли всегда люди должны быть заняты и какой жизнью жить — лёгкой или полной?
Наш проводник в этой теме — Саша Брызгалова, практик, эксперт и немного фанатик ТОС.
Дискутируем, накидываем на вентилятор, приводим примеры, чтобы разобраться:
👉 Что есть теория, что система, а что — ограничение?
👉 В каких системах есть ограничения и чем они не являются?
👉 С какой целью создаются системы и как связаны цели личные и цели компании?
👉 Что является самым популярным ограничением в проектном управлении?
👉 Когда «упороться по-максимуму» сыграет злую шутку?
👉 Что такое локальная оптимизация и почему правила во имя неё губят систему?
👉 Почему незавершённые проекты и переключения — бич для эффективности?
👉 В каких ситуациях, работая работу, чувствуешь себя молодцом?
👉 Какие установки нам мешают достигать целей и чем вредны KPI?
👉 Почему аргумент «мы всегда так делали» aka «так исторически сложилось» не аргумент вовсе?
👉 Для каких проблем ТОС не подходит и в каких случаях инструменты не эффективны? Ещё больше примеров в докладе Саши.
👉 Какой вопрос из теории ограничений непременно стоит себе задать?
👉 Win-win решения — правда или вымысел?
👉 С чего же начать, чтобы внедрить теорию ограничений в свою работу?
Этот эпизод, как и весь сезон, выпускается при поддержке драйвовой команды инженеров — @AvitoTech. Ребята создают сервисы, которыми пользуется треть жителей России каждый месяц.
В июне знакомьтесь с ними лично: с 10 по 15 июня, Сочи, South Hub — встречайте активности от C-level, и 26-27 июня, Санкт-Петербург, Saint TeamLead Conf — заглядывайте в playbook lounge, чтобы понетворкаться и узнать ценности и принципы каждого тимлида в AvitoTech.
🎙Ведущие выпуска — Виктор Корейша, руководитель направления Managed Services в Ozon, и Евгений Антонов, ведущий технический менеджер в Yandex Infrastructure, автор канала «Тимлид Очевидность».
🎧 Слушайте подкаст «Кода кода» в Яндекс Музыке, Apple Podcasts, Spotify, VK и много ещё где по ссылке: https://kodakoda.mave.digital/ep-84
🐝 Пишите отзывы, предлагайте темы, спорьте или соглашайтесь с гостями и ведущими.
Внимательные слушатели, ставьте ⚡️к этому посту.
Нам важна ваша обратная связь!
Реклама. ООО «Авито Тех», ИНН 9710089440, erid: 2SDnjcQ4ZD7
Please open Telegram to view this post
VIEW IN TELEGRAM
🤡12👍6💊2❤1🖕1
прикол.
Исследование LeadDev среди более чем 600 руководителей технических команд раскрыло интересную картину того, как изменилась индустрия за последний год.
Из интересного:
Отношение к искусственному интеллекту среди лидеров становится все более скептическим. Если в 2024 году 42% считали, что ИИ негативно влияет на индустрию, то в 2025 эта цифра выросла до 51%. Более того, 60% опрошенных не видят значительного роста продуктивности своих команд от внедрения ИИ-инструментов.
Основные проблемы с ИИ связаны с качеством результатов и сложностью интеграции в существующие процессы, особенно в крупных компаниях, где есть вопросы безопасности. Наиболее популярными остаются инструменты для кодирования, автоматической генерации кода и рефакторинга, но даже здесь результаты часто не оправдывают ожиданий.
🫥 Cross Join
⠀
Исследование LeadDev среди более чем 600 руководителей технических команд раскрыло интересную картину того, как изменилась индустрия за последний год.
Из интересного:
Отношение к искусственному интеллекту среди лидеров становится все более скептическим. Если в 2024 году 42% считали, что ИИ негативно влияет на индустрию, то в 2025 эта цифра выросла до 51%. Более того, 60% опрошенных не видят значительного роста продуктивности своих команд от внедрения ИИ-инструментов.
Основные проблемы с ИИ связаны с качеством результатов и сложностью интеграции в существующие процессы, особенно в крупных компаниях, где есть вопросы безопасности. Наиболее популярными остаются инструменты для кодирования, автоматической генерации кода и рефакторинга, но даже здесь результаты часто не оправдывают ожиданий.
⠀
Please open Telegram to view this post
VIEW IN TELEGRAM
👍11🤯8🔥1
Давайте поговорим. Я хз, заменит ли нас ИИ или нет, но определённые риски точно есть. Я, как отец троих детей, да еще и живущий в чужой стране, не могу просто игнорировать опасность. Например, уже в ближайшие годы зарплаты могут радикально сократиться во многих формошлёпских не очень сложных областях. Помните, раньше были такие "веб-мастера", потом их их заменила тильда и прочие автоматизации. Сейчас ии тоже многое перекосит, только гораздо быстрее и масштабнее.
Как вы планируете действовать? Усиливать экспертизу, чтобы победить роботов? Пробовать новые ии инструменты, чтобы быть эффективнее коллег? Напишите, короче, вдруг что-то я упускаю.
Пока что я для себя решил так, что в эту игру могут играть двое: предприниматели будут заменять программистов на ии, но и наоборот тоже можно: если наклепать серьёзное приложение можно будет без сбора большой команды и инвестиций, то на кой тогда эти предприниматели программистам будут нужны?
Очень многих останавливает сделать даже не очень сложный пет-проект то, что это может занять кучу времени без гарантии результата. Да и зачем, и так всё в целом норм.
Но с развитием прогресса затрачиваемое время на попытки будет неизбежно сокращаться, а "и так норм" будет неизбежно худеть.
Лично я, короче, буду делать какие-то эксперименты. Уже начал, точнее. Наверно, позже расскажу. Не получится это - попробую еще что-то. И т.д. Пока что без риска, без спешки, по выходным за пивком, но всё же надо уже лежать в этом направлении
🫥 Cross Join
⠀
Как вы планируете действовать? Усиливать экспертизу, чтобы победить роботов? Пробовать новые ии инструменты, чтобы быть эффективнее коллег? Напишите, короче, вдруг что-то я упускаю.
Пока что я для себя решил так, что в эту игру могут играть двое: предприниматели будут заменять программистов на ии, но и наоборот тоже можно: если наклепать серьёзное приложение можно будет без сбора большой команды и инвестиций, то на кой тогда эти предприниматели программистам будут нужны?
Очень многих останавливает сделать даже не очень сложный пет-проект то, что это может занять кучу времени без гарантии результата. Да и зачем, и так всё в целом норм.
Но с развитием прогресса затрачиваемое время на попытки будет неизбежно сокращаться, а "и так норм" будет неизбежно худеть.
Лично я, короче, буду делать какие-то эксперименты. Уже начал, точнее. Наверно, позже расскажу. Не получится это - попробую еще что-то. И т.д. Пока что без риска, без спешки, по выходным за пивком, но всё же надо уже лежать в этом направлении
⠀
Please open Telegram to view this post
VIEW IN TELEGRAM
Telegram
Cross Join - канал о разработке
Канал о разработке Антона Околелова. Тимлид Go, живу в Чехии. Мысли, новости, вопросы.
По вопросам рекламы @antonokolelov
По вопросам рекламы @antonokolelov
👍32💩9😁3
Интересная статья мне тут попалась. По сути она как бы косвенно обсирает язык Go :). Хотя код Go обычно абсолютно прост и понятен, но для беглого просмотра он не оч
Вот краткая выжимка:
Основная идея: Код чаще просматривают бегло, чем читают внимательно. Поэтому важно писать код, который можно понять с первого взгляда по его "форме" и структуре.
Ключевые принципы:
1. Форма кода имеет значение
Структура кода должна сразу показывать, что он делает
Связанный код должен выглядеть связанным, несвязанный — несвязанным
2. Избегать избыточной многословности
Слишком длинные имена переменных затрудняют понимание структуры
Пример: a * (x * x) + b * x + c читается лучше, чем a.multiply(x.pow(2)).plus(b.multiply(x.plus(c)))
3. Использовать контекст
В узкой области можно использовать короткие имена (get в HTTP-модуле)
В широком контексте нужны более описательные имена (Stripe.get)
4. Выделять "сантехнику" от логики
"Сантехника" — вспомогательный код (преобразования типов, обработка ошибок)
Логика — основная суть программы
Операторы и макросы помогают сделать "сантехнику" менее заметной
5. Минимизировать лишнюю информацию
Убирать ненужный boilerplate-код
Оставлять только существенную информацию для понимания
Аналогия с математикой: Математическая нотация — отличный пример читаемости "с первого взгляда". Интеграл ∫₀³(7x² + 3x + 7)dx понятен сразу, а его словесное описание требует полного прочтения.
Вывод: Хороший код должен быть "легким" для восприятия — его структура и назначение должны быть очевидны даже при беглом просмотре.
Вот краткая выжимка:
Основная идея: Код чаще просматривают бегло, чем читают внимательно. Поэтому важно писать код, который можно понять с первого взгляда по его "форме" и структуре.
Ключевые принципы:
1. Форма кода имеет значение
Структура кода должна сразу показывать, что он делает
Связанный код должен выглядеть связанным, несвязанный — несвязанным
2. Избегать избыточной многословности
Слишком длинные имена переменных затрудняют понимание структуры
Пример: a * (x * x) + b * x + c читается лучше, чем a.multiply(x.pow(2)).plus(b.multiply(x.plus(c)))
3. Использовать контекст
В узкой области можно использовать короткие имена (get в HTTP-модуле)
В широком контексте нужны более описательные имена (Stripe.get)
4. Выделять "сантехнику" от логики
"Сантехника" — вспомогательный код (преобразования типов, обработка ошибок)
Логика — основная суть программы
Операторы и макросы помогают сделать "сантехнику" менее заметной
5. Минимизировать лишнюю информацию
Убирать ненужный boilerplate-код
Оставлять только существенную информацию для понимания
Аналогия с математикой: Математическая нотация — отличный пример читаемости "с первого взгляда". Интеграл ∫₀³(7x² + 3x + 7)dx понятен сразу, а его словесное описание требует полного прочтения.
Вывод: Хороший код должен быть "легким" для восприятия — его структура и назначение должны быть очевидны даже при беглом просмотре.
👍22👎4
Короче, тут такое дело, каминаут. Я тут плагин к Intellij сделал для редактирования OpenAPI (GUI редактор для openapi доков). Плагин платный, и как ни странно, уже есть пара реальных обладателей лицензии (я и моя мама).
Он умеет редактировать 3.0 и 3.1. Наверно позже сделаю и для 2.0.
Почему я его сделал: вручную редактировать огроменные ямлы с десятерной вложенностью, даже с хорошим автокомплитом - это больно. Ямл вообще придумали странные люди.
Плагин местами сыроват, часть интерфейсов я переделаю потихоньку. Вообще, это MVP, чтобы понять, надо это кому-нибудь вообще или нет. Но, так как уже целых двое готовы за плагин платить, и это еще не было практически никакого маркетинга, значит надежда есть. Как минимум, пивом я обеспечен.
В общем, кто не под санкциями, попробуйте триалку. Если увидите, что что-то не нравится, раздражает, хочется выматериться - я буду счастлив услышать ваши трехэтажные маты и поправить. Прямо жду этого :)
https://plugins.jetbrains.com/plugin/27118-openapi-gui-editor
Он умеет редактировать 3.0 и 3.1. Наверно позже сделаю и для 2.0.
Почему я его сделал: вручную редактировать огроменные ямлы с десятерной вложенностью, даже с хорошим автокомплитом - это больно. Ямл вообще придумали странные люди.
Плагин местами сыроват, часть интерфейсов я переделаю потихоньку. Вообще, это MVP, чтобы понять, надо это кому-нибудь вообще или нет. Но, так как уже целых двое готовы за плагин платить, и это еще не было практически никакого маркетинга, значит надежда есть. Как минимум, пивом я обеспечен.
В общем, кто не под санкциями, попробуйте триалку. Если увидите, что что-то не нравится, раздражает, хочется выматериться - я буду счастлив услышать ваши трехэтажные маты и поправить. Прямо жду этого :)
https://plugins.jetbrains.com/plugin/27118-openapi-gui-editor
🔥23👍6❤5🤡4👎1💩1
Насчет редактирования openapi, по следам предыдущего поста
Многие в комментах писали, что лучше генерировать спеку из кода, это быстрее и проще.
Возможно, в некоторых языках - это просто, но вот в Go или PHP, например, код сильно засирается аннотациями, посмотрите на пример: https://github.com/swaggo/swag/blob/master/example/celler/controller/examples.go
Т.е. мало того, что код засирается, так еще и надо знать, как правильно срать :), т.е. по сути помимо знания об openapi надо еще знать этот псевдоязык и к каким элементам кода его применять.
Ну и, конечно же, самое главное, легко забыть поменять аннотацию, поменяв код. Не будет гарантии, что код и дока соответствуют друг другу.
В общем, большой разницы тут нет, что руками править openapi доку, что так.
Только если фреймворк какого-то язывка прям всё сам делает и выдаёт готовенький блестящий openapi. Я слышал, что в Java как-то с этим получше, но тоже сомневаюсь, что идеально
Ну и главное: подход API design first позволяет сначала согласовать апи (с другой командой, с архитектором, с фронтендерами, с другой компанией, с которой вы интегрируетесь), а потом только пилить сам код.
Многие в комментах писали, что лучше генерировать спеку из кода, это быстрее и проще.
Возможно, в некоторых языках - это просто, но вот в Go или PHP, например, код сильно засирается аннотациями, посмотрите на пример: https://github.com/swaggo/swag/blob/master/example/celler/controller/examples.go
Т.е. мало того, что код засирается, так еще и надо знать, как правильно срать :), т.е. по сути помимо знания об openapi надо еще знать этот псевдоязык и к каким элементам кода его применять.
Ну и, конечно же, самое главное, легко забыть поменять аннотацию, поменяв код. Не будет гарантии, что код и дока соответствуют друг другу.
В общем, большой разницы тут нет, что руками править openapi доку, что так.
Только если фреймворк какого-то язывка прям всё сам делает и выдаёт готовенький блестящий openapi. Я слышал, что в Java как-то с этим получше, но тоже сомневаюсь, что идеально
Ну и главное: подход API design first позволяет сначала согласовать апи (с другой командой, с архитектором, с фронтендерами, с другой компанией, с которой вы интегрируетесь), а потом только пилить сам код.
👍13❤1
https://metr.org/Early_2025_AI_Experienced_OS_Devs_Study.pdf
"...Несмотря на широкое распространение, влияние инструментов ИИ на разработку программного обеспечения в реальных условиях остается недостаточно изученным. Мы проводим рандомизированное контролируемое исследование (РКИ),
чтобы понять, как инструменты ИИ на рубеже февраля-июня 2025 года влияют на производительность опытных разработчиков ПО с открытым исходным кодом. 16 разработчиков со средним опытом работы с ИИ
выполняют 246 задач в зрелых проектах, в которых их средний опыт работы составляет 5 лет. Каждой задаче случайным образом назначается разрешение или запрет на использование инструментов ИИ начала 2025 года. Когда инструменты ИИ разрешены, разработчики
в основном используют Cursor Pro, популярный редактор кода, и Claude 3.5/3.7 Sonnet. Перед началом выполнения задач разработчики прогнозируют, что разрешение использования ИИ сократит время выполнения на 24%. После завершения исследования разработчики оценивают, что разрешение использования ИИ
сократило время выполнения на 20%. Удивительно, но мы обнаружили, что использование ИИ фактически
увеличивает время выполнения на 19% — инструменты ИИ замедляли разработчиков. Это
замедление также противоречит прогнозам экспертов в области экономики (на 39% короче)
и машинного обучения (на 38% короче). Чтобы понять этот результат, мы собираем и оцениваем данные по 20 свойствам нашей среды, которые априори могут способствовать наблюдаемому
эффекту замедления, например, размеру и стандартам качества проектов или предыдущему
опыту разработчиков с инструментами ИИ. Хотя влияние экспериментальных артефактов нельзя полностью исключить, устойчивость эффекта замедления в наших
анализах позволяет предположить, что он вряд ли в первую очередь является функцией нашего
экспериментального
дизайна...."
"...Несмотря на широкое распространение, влияние инструментов ИИ на разработку программного обеспечения в реальных условиях остается недостаточно изученным. Мы проводим рандомизированное контролируемое исследование (РКИ),
чтобы понять, как инструменты ИИ на рубеже февраля-июня 2025 года влияют на производительность опытных разработчиков ПО с открытым исходным кодом. 16 разработчиков со средним опытом работы с ИИ
выполняют 246 задач в зрелых проектах, в которых их средний опыт работы составляет 5 лет. Каждой задаче случайным образом назначается разрешение или запрет на использование инструментов ИИ начала 2025 года. Когда инструменты ИИ разрешены, разработчики
в основном используют Cursor Pro, популярный редактор кода, и Claude 3.5/3.7 Sonnet. Перед началом выполнения задач разработчики прогнозируют, что разрешение использования ИИ сократит время выполнения на 24%. После завершения исследования разработчики оценивают, что разрешение использования ИИ
сократило время выполнения на 20%. Удивительно, но мы обнаружили, что использование ИИ фактически
увеличивает время выполнения на 19% — инструменты ИИ замедляли разработчиков. Это
замедление также противоречит прогнозам экспертов в области экономики (на 39% короче)
и машинного обучения (на 38% короче). Чтобы понять этот результат, мы собираем и оцениваем данные по 20 свойствам нашей среды, которые априори могут способствовать наблюдаемому
эффекту замедления, например, размеру и стандартам качества проектов или предыдущему
опыту разработчиков с инструментами ИИ. Хотя влияние экспериментальных артефактов нельзя полностью исключить, устойчивость эффекта замедления в наших
анализах позволяет предположить, что он вряд ли в первую очередь является функцией нашего
экспериментального
дизайна...."
👍15🤯3❤1
Давайте поговорим про вред кофе, потому что айтишники его хлещут только так, чтобы подстегнуть соображалку
Когда-то давно, это было наверно больше 10 лет назад, я вдруг понял, что веду себя немного как зомби. Плоховато соображаю, у меня мало энергии, в общем хожу "как пыльным мешком по голове ударенный". При этом не сказать, чтобы мало часов выделял для сна, и здоровье в целом было в полном порядке.
И как-то случайно так получилось, что я несколько дней совсем не пил кофе - и, о чудо, всё внезапно прошло.
В голове появилась невероятная свежесть, как в детстве, много новых идей и так далее.
Потом я стал экспериментировать более осознанно, и пришел к выводу, что если пью больше одной чашки кофе в день на протяжении нескольких недель, то "пыльный мешок" в голове возвращается. Особенно четко это наблюдалось после рабочего дня: я мог только сидеть и тупить в сериал, энергии ни на что не оставалось, ни на какие пет проекты. А после перерыва в дней 5-7 - я свеж и бодр, готов херачить чуть ли не 24/7.
В общем, я погуглил и початжепетил, оказалось, что люди генетически имеют разую предрасположенность к кофе.
1) ген CYP1A2 отвечает за метаболизм кофеина
2) ген ADORA2A за то, насколько сильно херачит по нервной системе (тревожность, некачественный сон и т.д)
Я, конечно, тот еще генетик, но подозреваю, что у меня 2 в одном: кофе выводится медленно, а бьёт по голове сильно. Скорее всего из-за этого просто сон становится некачественным, и со временем это влияет на самочувствие.
Дополнительная ловушка состоит в том, что если ты сегодня плохо соображаешь, то хочется выпить кофе ещё - чтобы начать уже соображать. И всё идёт по кругу.
Так что экспериментально я выяснил, что мне лучше кофе вообще не пить, а если и пить, то одну чашку утром. Тогда типа норм.
Ну или, допустим, перед важными делами: собеседование/экзамен/и т.д (кстати, надо пить за 50-60 минут до события для максимальной концентрации).
В общем, тем, кто страдает такой вот отупелостью, советую попробовать сделать недельный перерыв в кофе (поддерживая качественный сон при этом) или же вообще нафиг сделать генетический тест.
🫥 Cross Join - канал о разработке
⠀
Когда-то давно, это было наверно больше 10 лет назад, я вдруг понял, что веду себя немного как зомби. Плоховато соображаю, у меня мало энергии, в общем хожу "как пыльным мешком по голове ударенный". При этом не сказать, чтобы мало часов выделял для сна, и здоровье в целом было в полном порядке.
И как-то случайно так получилось, что я несколько дней совсем не пил кофе - и, о чудо, всё внезапно прошло.
В голове появилась невероятная свежесть, как в детстве, много новых идей и так далее.
Потом я стал экспериментировать более осознанно, и пришел к выводу, что если пью больше одной чашки кофе в день на протяжении нескольких недель, то "пыльный мешок" в голове возвращается. Особенно четко это наблюдалось после рабочего дня: я мог только сидеть и тупить в сериал, энергии ни на что не оставалось, ни на какие пет проекты. А после перерыва в дней 5-7 - я свеж и бодр, готов херачить чуть ли не 24/7.
В общем, я погуглил и початжепетил, оказалось, что люди генетически имеют разую предрасположенность к кофе.
1) ген CYP1A2 отвечает за метаболизм кофеина
2) ген ADORA2A за то, насколько сильно херачит по нервной системе (тревожность, некачественный сон и т.д)
Я, конечно, тот еще генетик, но подозреваю, что у меня 2 в одном: кофе выводится медленно, а бьёт по голове сильно. Скорее всего из-за этого просто сон становится некачественным, и со временем это влияет на самочувствие.
Дополнительная ловушка состоит в том, что если ты сегодня плохо соображаешь, то хочется выпить кофе ещё - чтобы начать уже соображать. И всё идёт по кругу.
Так что экспериментально я выяснил, что мне лучше кофе вообще не пить, а если и пить, то одну чашку утром. Тогда типа норм.
Ну или, допустим, перед важными делами: собеседование/экзамен/и т.д (кстати, надо пить за 50-60 минут до события для максимальной концентрации).
В общем, тем, кто страдает такой вот отупелостью, советую попробовать сделать недельный перерыв в кофе (поддерживая качественный сон при этом) или же вообще нафиг сделать генетический тест.
⠀
Please open Telegram to view this post
VIEW IN TELEGRAM
👍45🔥4❤3🥴3
Forwarded from Эксплойт
Восстановление «Аэрофлота» может занять до ПОЛУГОДА — сообщают эксперты.
А если хакеры удалили резервные копии, то весь процесс может затянуться на год.
На картинке сравнение зарплат инфобезопасника в Аэрофлоте и кладовщика в супермаркете. Выводы делайте сами.
@exploitex
А если хакеры удалили резервные копии, то весь процесс может затянуться на год.
На картинке сравнение зарплат инфобезопасника в Аэрофлоте и кладовщика в супермаркете. Выводы делайте сами.
@exploitex
🔥16💩10❤7😁4😢1🕊1
Forwarded from do...while...ai (Gregory is typing...)
Почему важно разбираться в деталях
Независимо от того, над каким проектом автоматизации (хотя, не только автоматизации) я работаю, замечаю один и тот же паттерн: если я не разбираюсь в предметной области, получается ерунда, а не полезный тул. На самом деле такое я замечаю не только за собой. И это логично: когда нет понимания, как работают процессы, как и какие задачи решаются, что поступает на вход задач и какие ожидаемые результаты, невозможно нормально спроектировать систему (автоматизацию, тулзу, приложение, сервис), потому что не понятно, что важно, а что нет. При отсутствии фундаментальных знаний, совершенно неочевидно, как может выглядеть прототип решения, чтобы с одной стороны — не сильно заморачиваться с реализацией, а с другой — чтобы оно уже приносило ценность клиенту.
Получается, что если на проекте нет доменного эксперта (опытного спеца со знаниями и опытом), который активно участвует в дизайне системы, получится поделка и её никто не купит. Например, можно попробовать сделать систему подготовки заявок на тендер чисто по наитию. Вроде как понятно, что надо взять исходные документы, взять шаблон заявки на тендер, вытащить нужные данные из исходных документов и положить эти значения в шаблон заявки, и вуа ля, прототип готов, можно показывать клиентам (да ещё и сразу нескольким, потому что это вроде как многим компаниям нужно). Но после демонстрации оказывается, что исходные документы могут не содержать нужную информацию и их нужно вытаскивать из внутренней базы знаний, а перед отправкой на тендер важно сделать апрув у менеджмента, и потом ещё саму заявку зарегистрировать во внутренней системе учёта документов, и т.п. Всплывают те самые "маленькие нюансы", которые знает только специалист, занимающийся оформлением этих заявок. А если этих фич нет в продукте, он никому не нужен.
Поэтому, если я делаю проект, стараюсь
1. максимально разобраться, как в компании решают задачу сейчас (вручную);
2. найти специалиста в теме (обычно, это кто-то из компании, заинтересованный в автоматизации), чтобы приставать к нему с кучей вопросов о том, "что", "как" и "почему".
На последнем проекте мы с ребятами ездили к клиенту, сидели несколько часов с юристами, и втыкали в миллиард разных договоров, чтобы понять, откуда и куда переползают данные, какие есть типы шаблонов, где "узкое горлышко" в процессах. Всё это не про творчество и вайбкодинг, очень скучно и рутинно, но только так можно разобраться, где клиенту будет реальная ценность от нашей автоматизации, а где — это просто наши влажные фантазии.
Независимо от того, над каким проектом автоматизации (хотя, не только автоматизации) я работаю, замечаю один и тот же паттерн: если я не разбираюсь в предметной области, получается ерунда, а не полезный тул. На самом деле такое я замечаю не только за собой. И это логично: когда нет понимания, как работают процессы, как и какие задачи решаются, что поступает на вход задач и какие ожидаемые результаты, невозможно нормально спроектировать систему (автоматизацию, тулзу, приложение, сервис), потому что не понятно, что важно, а что нет. При отсутствии фундаментальных знаний, совершенно неочевидно, как может выглядеть прототип решения, чтобы с одной стороны — не сильно заморачиваться с реализацией, а с другой — чтобы оно уже приносило ценность клиенту.
Получается, что если на проекте нет доменного эксперта (опытного спеца со знаниями и опытом), который активно участвует в дизайне системы, получится поделка и её никто не купит. Например, можно попробовать сделать систему подготовки заявок на тендер чисто по наитию. Вроде как понятно, что надо взять исходные документы, взять шаблон заявки на тендер, вытащить нужные данные из исходных документов и положить эти значения в шаблон заявки, и вуа ля, прототип готов, можно показывать клиентам (да ещё и сразу нескольким, потому что это вроде как многим компаниям нужно). Но после демонстрации оказывается, что исходные документы могут не содержать нужную информацию и их нужно вытаскивать из внутренней базы знаний, а перед отправкой на тендер важно сделать апрув у менеджмента, и потом ещё саму заявку зарегистрировать во внутренней системе учёта документов, и т.п. Всплывают те самые "маленькие нюансы", которые знает только специалист, занимающийся оформлением этих заявок. А если этих фич нет в продукте, он никому не нужен.
Поэтому, если я делаю проект, стараюсь
1. максимально разобраться, как в компании решают задачу сейчас (вручную);
2. найти специалиста в теме (обычно, это кто-то из компании, заинтересованный в автоматизации), чтобы приставать к нему с кучей вопросов о том, "что", "как" и "почему".
На последнем проекте мы с ребятами ездили к клиенту, сидели несколько часов с юристами, и втыкали в миллиард разных договоров, чтобы понять, откуда и куда переползают данные, какие есть типы шаблонов, где "узкое горлышко" в процессах. Всё это не про творчество и вайбкодинг, очень скучно и рутинно, но только так можно разобраться, где клиенту будет реальная ценность от нашей автоматизации, а где — это просто наши влажные фантазии.
❤29👍9💯1
Послушал тут выпуск подкаста Кирилла Мокевнина про IQ. Лень сейчас искать, потом найду ссылку.
TLDR: Пришел какой-то специалист, который сказал, что IQ-тесты все хейтят, но это вполне нормальный показатель (в рамках небольшой погрешности), который способен показать, кто умный относительно заданной группы, а кто нет.
И типа это сохраняется с возрастом: если ты условно в школе был самым умным, то и дальше будешь на высоком счету. И есть некая корреляция между IQ и карьерными достижениями.
Хз, правда это или нет, мне почему-то всё равно кажется, что интеллект можно в какой-то степени развить (неужели я до конца жизни останусь тупым??). Но, допустим, поверим ученым.
Тогда получается, что лайвкодинг на тех-интервью имеет большой смысл: ты должен за короткий срок поместить некоторую модель задачи себе в мозг и быть способен решить её или предложить разумные попытки это сделать. Быстро понять подсказки интервьюера и тому подобное.
Ну т.е. реально, если ты сходу догадался, как обойти/перекрутить хитровыделанное дерево, то достаточно умный, чтобы справиться с любой практической задачей. А если нет - то еще неизвестно.
Но тут есть и проблемы.
IQ-тестам уже стопицот лет, они за годы претерпели много улучшений и вариаций с целью снизить зависимость от наличия у человека конкретных знаний и максимально проверить именно логику. В задачках с литкода такого нет. Многие вещи надо тупо знать, потому что на какие-то вещи времени не хватит никому. Кроме того, сам процесс не стандартизован: собеседующий может сам оказаться не очень-то разумным.
Я промолчу о практике писать программы маркером на вайтборде - тут точно никаким интеллектом не пахнет, чистый дебилизм.
Думаю, кстати, поэтому задачи от гугла "почему люки круглые" сошли на нет: они просто не стандартизованы, не откалиброваны. Отсебятина.
В общем, если вдруг это железно правда, что IQ-тест настолько проработан, что прям показывает ум, то надо делать какой-то программерский аналог, только не кустарного производства, а чтобы сели какие-то высоколобые учёные и его нормально откалибровали.
Можно, конечно, тупо IQ-тест юзать, но всё же надо (хз, надо или нет) и навык программирования проверять, потому что его долго нарабатывать, если его нет.
🫥 Cross Join - канал о разработке
⠀
TLDR: Пришел какой-то специалист, который сказал, что IQ-тесты все хейтят, но это вполне нормальный показатель (в рамках небольшой погрешности), который способен показать, кто умный относительно заданной группы, а кто нет.
И типа это сохраняется с возрастом: если ты условно в школе был самым умным, то и дальше будешь на высоком счету. И есть некая корреляция между IQ и карьерными достижениями.
Хз, правда это или нет, мне почему-то всё равно кажется, что интеллект можно в какой-то степени развить (
Тогда получается, что лайвкодинг на тех-интервью имеет большой смысл: ты должен за короткий срок поместить некоторую модель задачи себе в мозг и быть способен решить её или предложить разумные попытки это сделать. Быстро понять подсказки интервьюера и тому подобное.
Ну т.е. реально, если ты сходу догадался, как обойти/перекрутить хитровыделанное дерево, то достаточно умный, чтобы справиться с любой практической задачей. А если нет - то еще неизвестно.
Но тут есть и проблемы.
IQ-тестам уже стопицот лет, они за годы претерпели много улучшений и вариаций с целью снизить зависимость от наличия у человека конкретных знаний и максимально проверить именно логику. В задачках с литкода такого нет. Многие вещи надо тупо знать, потому что на какие-то вещи времени не хватит никому. Кроме того, сам процесс не стандартизован: собеседующий может сам оказаться не очень-то разумным.
Я промолчу о практике писать программы маркером на вайтборде - тут точно никаким интеллектом не пахнет, чистый дебилизм.
Думаю, кстати, поэтому задачи от гугла "почему люки круглые" сошли на нет: они просто не стандартизованы, не откалиброваны. Отсебятина.
В общем, если вдруг это железно правда, что IQ-тест настолько проработан, что прям показывает ум, то надо делать какой-то программерский аналог, только не кустарного производства, а чтобы сели какие-то высоколобые учёные и его нормально откалибровали.
Можно, конечно, тупо IQ-тест юзать, но всё же надо (хз, надо или нет) и навык программирования проверять, потому что его долго нарабатывать, если его нет.
⠀
Please open Telegram to view this post
VIEW IN TELEGRAM
Telegram
Cross Join - канал о разработке
https://habr.com/ru/companies/karuna/articles/725552/
👍10🤨4❤2🔥2🕊1
Вышел go 1.25
1. GOMAXPROCS стал «умнее» в контейнерах
Теперь GOMAXPROCS (количество потоков, используемых рантаймом) автоматически учитывает ограничения CPU в cgroup.
Например, если контейнер в Kubernetes получил лимит в 2 CPU, Go сам подстроится, даже если на узле 64 ядра.
Плюс, если лимиты или доступные ядра изменятся на лету, Go сможет обновить GOMAXPROCS без перезапуска.
2. Новый экспериментальный сборщик мусора
Добавили greenteagc — переработанный GC, который лучше работает с мелкими объектами и масштабируется на многоядерных системах.
В реальных проектах можно ожидать -10–40% накладных расходов на сборку мусора. Включается через:
GOEXPERIMENT=greenteagc
3. «Чёрный ящик» для редких багов
Появился Flight Recorder для трассировки исполнения. (можно записать в файл последние пару секунд runtime execution trace)
4. Новая JSON-библиотека (эксперимент)
Появился encoding/json/v2, в котором:
Декодирование стало заметно быстрее.
Есть новые опции настройки маршалинга/анмаршалинга.
Поведение при маршалинге совместимо с текущим пакетом, но тексты ошибок могут отличаться.
Включается так:
GOEXPERIMENT=jsonv2 (тогда encoding/json будет работать по-новому)
5. Инструменты разработки стали удобнее
go build -asan теперь по умолчанию ищет утечки памяти, выделенной через C.
Новый флаг go doc -http поднимет локальный сервер документации и откроет его в браузере.
Появилась директива ignore в go.mod для исключения каталогов из сборки.
go vet научился ловить ошибки в sync.WaitGroup и неправильно собранные адреса для IPv6.
6. Улучшения в тестировании конкурентного кода
Пакет testing/synctest теперь доступен без экспериментов — можно писать тесты для многопоточного кода с виртуальным временем, без ожидания в реальном времени.
А sync.WaitGroup получил метод .Go, который упрощает запуск горутин с подсчётом.
И многое другое
🫥 Cross Join - канал о разработке
1. GOMAXPROCS стал «умнее» в контейнерах
Теперь GOMAXPROCS (количество потоков, используемых рантаймом) автоматически учитывает ограничения CPU в cgroup.
Например, если контейнер в Kubernetes получил лимит в 2 CPU, Go сам подстроится, даже если на узле 64 ядра.
Плюс, если лимиты или доступные ядра изменятся на лету, Go сможет обновить GOMAXPROCS без перезапуска.
2. Новый экспериментальный сборщик мусора
Добавили greenteagc — переработанный GC, который лучше работает с мелкими объектами и масштабируется на многоядерных системах.
В реальных проектах можно ожидать -10–40% накладных расходов на сборку мусора. Включается через:
GOEXPERIMENT=greenteagc
3. «Чёрный ящик» для редких багов
Появился Flight Recorder для трассировки исполнения. (можно записать в файл последние пару секунд runtime execution trace)
4. Новая JSON-библиотека (эксперимент)
Появился encoding/json/v2, в котором:
Декодирование стало заметно быстрее.
Есть новые опции настройки маршалинга/анмаршалинга.
Поведение при маршалинге совместимо с текущим пакетом, но тексты ошибок могут отличаться.
Включается так:
GOEXPERIMENT=jsonv2 (тогда encoding/json будет работать по-новому)
5. Инструменты разработки стали удобнее
go build -asan теперь по умолчанию ищет утечки памяти, выделенной через C.
Новый флаг go doc -http поднимет локальный сервер документации и откроет его в браузере.
Появилась директива ignore в go.mod для исключения каталогов из сборки.
go vet научился ловить ошибки в sync.WaitGroup и неправильно собранные адреса для IPv6.
6. Улучшения в тестировании конкурентного кода
Пакет testing/synctest теперь доступен без экспериментов — можно писать тесты для многопоточного кода с виртуальным временем, без ожидания в реальном времени.
А sync.WaitGroup получил метод .Go, который упрощает запуск горутин с подсчётом.
И многое другое
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥13❤1
Что меня бесит в курсоре, что он как бы это сказать, устаёт. Ты ему говоришь: напиши к этому тесты, он пишет. Один тест не проходит. Он 10 раз пытается исправить, а потом пишет, что в принципе и 16 из 17 рабочих тестов - это норм.
Или: а давай я просто этот тест удалю, хер его знает, что там не работает.
Или: а давай я просто этот тест удалю, хер его знает, что там не работает.
🤣46😁9👍4🤝1