Кстати насчёт паттерна Command и Factory и замены их на лямбды: при усложнении сценариев использования всё равно удобнее переходить на реализацию с интерфейсами и прочим. Во-первых упрощается поиск в коде, можно быстро найти все места, где создаётся и где используется. И удобнее в отладке или логах видеть объект типа “CreateUnitCommand”, вместо непонятной лямбды. Особенно актуально, если там какие-нибудь коллбеки без аргументов и возвращаемых значений - их вообще легко перепутать друг с другом.
А экран так и будет с низким разрешением и монохромным? На флиппере зеро оно логично для микроконтроллера, а с начинкой как в первом кажется что экран на энергопотребление и цену не сильно повлияет.
P.S. за количество и выбор портов для подключения респект, действительно для всего :)
Кстати, а что вы думаете про архитектуры типа apple m5 и ryzen ai, где память общая для всего? И в стимдеке тоже так.
Там, с одной стороны, процессор, gpu и npu могут конкурировать за память, а с другой - шина памяти более широкая и в итоге и процессору веселее, и необходимость перекладывать данные между gpu и cpu пропадает, только синхронизацию сделал и читай?
Так для справки - у райзена память 8 Ггц и 4 канала (в сумме вроде 256 ГБ/сек), у маков зависит от объёма оперативки (у модели на 128 ГБ вроде 600 ГБ/сек).
Мне кажется, из английского. Русского языка в обучающей выборке мало, и вдобавок токенизатор заточен под английский, многие слова идут одним токеном, а на русском буквально по слогам. И как будто построение предложений протекает из английского в русский.
Из моделей ещё интересная GLM-flash - она чуть побольше, но с экспертами, и из-за этого работает сильно шустрее. На видеокарте 4080 я видел скорость генерации больше ста токенов в секунду.
Не совсем, надо не только выбрать по возможности лучшего, но и не потратить время на 100 кандидатов. Если каждому устраивать по 4 часа собеседований, то в сумме 400 рабочих часов - 10 рабочих недель, потраченных собеседующими.
Раньше до ИИ было, что изменения в код добавлялись медленнее, и в найтли сборке было легче заметить изменения и найти причину.
Вдобавок людям лень писать повторяющийся код, и они начинают его как-то реорганизовывать и более лаконично писать, а ИИ это чуждо и он может однотипных изменений хоть на тысячу строк сделать. И, к сожалению, как будто теперь вместо простого и организованного кода, его теперь просто больше и он хуже качеством.
Получается что-то вроде трагедии общин - каждому разработчику проще нагенерить код ценой потери качества, но в итоге получается раздутый проект с техдолгом, в котором всё перманентно разломано и все страдают.
P.S. А про слои ревью - полностью согласен. В предыдущей команде можно было влить изменения в мастер и потом создать ревью - было очень удобно. Сейчас требуется обязательный аппрув ревью человеком + долгое и очень нестабильное CI, в сумме это ад. Сначала ждёшь ревью от человека, потом он просит что-нибудь поправить (один слой), потом CI перезапускает тесты и зачастую падает. И эти тесты - ещё один слой, причём там бывают и тесты нестабильные, и просто поломанные кем-то другим, когда только ребейз поможет. Всякие мелочи даже исправлять не хочется, код пишется за минуты и потом тратятся дни, чтобы его влить.
В сумме вроде 550 строчек, я про их количество вообще не думал. Что меня впечатлило - в отличие от самбы и прочих штук, за несколько лет использования на домашнем сервере проблем вообще не было и скорость приличная (упирается в скорость локальной сети). И ещё приятный момент, что написал сам и сам же использую.
Нет, скалу я и так использую, её к счастью ждать не надо. А вот именно value классы на уровне JVM мне бы очень хотелось увидеть из соображений производительности. GC и JIT компиляция с инлайнингом в каких-то случаях хорошо работают, но к сожалению не всегда.
При СДВГ ещё есть гиперфокус. Например, когда садишься поиграть часик вечером, потом смотришь на часы - а там шесть утра. Всё внимание ушло в игру, на окружающую действительность ничего не осталось. Влияние от "интересно-неинтересно" на продуктивность при СДВГ более выражено. Всякие "надо" и "где сила воли" ведут к выгоранию и депрессии, чисто на них далеко не уйдёшь.
Я как-то раз на силе воли на сильно не нравящейся задаче загнал себя до того, что утром не мог вспомнить пароль от компьютера, который до этого несколько лет вводил каждый день. Потом дошёл до психотерапевта и узнал и про депрессию и про то, что она сильно влияет на когнитивные способности.
Ниже как оно у меня (надеюсь кому-то помогу и буду рад ещё что-нибудь узнать в ответ):
Я бы не сказал, что компилируемые языки сами по себе дают долгую обратную связь. Пишу на Scala, Kotlin, C++. Как будто важнее то, как организована разработка, а не язык.
Помогает то, что ide подсвечивает ошибки ещё до компиляции + статическая типизация помогает про часть вещей не думать (например, nullability в котлине не даст передать null если функция его не ждёт, или заставит проверить на null если объект может быть нулём). Если система типов достаточно мощная и код компилируется, то как будто часть проблем снимает.
Ещё люблю делать простые классы на 20-100 строк и давать им и переменным в нормальные имена, не упарываясь в то, чтобы упихать всё состояние в один гига-класс или в функцию на тысячу строк. Вообще в программировании предполагается что так и надо, но как будто некоторым людям огромные классы или функции доставляют меньше неудобств.
Время обратной связи и начилие посторонних факторов сильно влияют.
Я обращал внимание, что в моих пет-проектах, где компиляция и тесты занимают меньше минуты, писать код в разы проще и я как будто сильно продуктивнее.
И ещё очень сильно вымораживает, если сборка делается не одной кнопкой, а требует к себе много внимания - ломается инкрементальная компиляция в рандомные моменты и приходится пересобирать с нуля, для запуска приходится выставить какие-нибудь переменные среды или закинуть константы, если тесты рандомно падают и приходится смотрять я виноват или нет, или если код падает где-то на сервере и надо потыкать кучу кнопочек, чтобы добраться до логов с ошибкой - это намного хуже, чем просто подождать.
Ещё обращал внимание, что если какие-нибудь тесты идут полчаса-час, то на другие задачи с кодом лучше не переключаться - контекст вылетит из головы и при возврате начну ошибаться.
И ещё просто сложно вести разработку одновременно над чем-то одним в нескольких ветках. Как будто всё сделанное (например, переименование класса) сохраняется в долговременную память, и когда в другой ветке этих изменений ещё нет (а они допустим нужны), получается сильный дискомфорт и каша в голове. Намного удобнее trunk-based development и вливать изменения в мастер как можно чаще.
Ещё (опять же не знаю как у других) сильно мешает, если что-то работает медленно или нестабильно. Если какой-нибудь сайт типа трекера задач грузит страницу десять секунд или вообще лежит - это боль, и желание с ним что-то делать пропадает.
Ещё, как ни странно, мне очень нравится Linux. Потому что он после настройки предсказуемо работает, не занимается никакой самодеятельностью и не отвлекает. Шлю лучи ненависти майрософту, которые в пуск пихают рекламу, курс акций, погоду, показывают какие-то уведомления в углу, пихают в центр экрана окна с вопросами типа "не хотите ли включить one drive" или начинает что-нибудь сканировать в фоне или искать вирусы. И лазить по куче менюшек и тыкать всякие кнопки, чтобы поменять настройку или поставить софт, тоже сильно менее удобно, чем написать команду в консоли типа "sudo apt install gcc" (сравните это с установкой msvc). (Уведомления винды в неподходящие моменты это тоже ужас)
Как будто получается, что если много хаоса и он требует каких-то активных действий, то этот хаос сильно мешает.
Удобнее работать на нескольких мониторах, а не переключаться через alt+tab на одном. Перевести взгляд или подвинуть мышку сильно проще, чем в alt tab крутиться до нужного приложения.
Очень помогают музыка (тут надо подобрать, от разной по разному) и наушники с шумоподавлением (особенно в open space, люди вокруг сильно мешают). Из того что недавно включал - https://www.youtube.com/watch?v=qObvGNVLNfg
Скорее всего и с обычным мозгом так же, только влияние сильно меньше выражено.
Соответственно, если какой-то пользователь возглавляет рейтинг, значит читателям нравятся его материалы. Или может вы считаете, что администрация должна блокировать и исключать из рейтинга всех в кого ткнут пальцем и обзовут неблагонадежным? Это неправовое решение.
Моя последняя статья была с очень высоким рейтингом, но это не помешало администрации подвинуть её в чулан, убрав из ленты и рекомендаций. Вы этим "рейтингом статьи" прикрываетесь только когда он на вашей стороне, а когда нет - блокируете.
И не надо отождествлять абстрактную группу "читателей" с теми кто ставит оценки - от того, что условные 50 человек поставили плюс, не следует что статья хорошая и понравится остальным. Например, потому что у корпоративных блогов бывает по 50-100 сотрудников, они могут нарисовать любой рейтинг.
Ну мне кстати нравится, что в отличие от человека ревью не надо ждать, и часть замеченных проблем всё-таки реальные. Я могу упустить какую-нибудь деталь, и смотрю на нейронку как на возможность найти что-то такое.
Перешёл на переключение раскладки по caps lock. Потому что всё равно капс лок почти не использую, и если вдруг понадобится, то нажму shift+caps. Намного удобее, чем нажимать две клавиши. Теперь мне такой возможности люто не хватает в винде.
Двоичный поиск занимает O(log n), что теоретически хуже, чем O(1). Так написано в учебниках. Мой преподаватель алгоритмов был бы разочарован. ... Они подразумевают, что все операции доступа к памяти стоят одинаково. Они подразумевают, что операции выполняются изолированно. Они подразумевают работу на идеальном компьютере, которого не существует.
Конечно преподаватель будет разочарован, у O-нотации другой смысл. Она ничего не подразумевает. Она описывает асимптотику и не говорит про реальное время. Она отвечает на вопрос "как изменится вычислетельная сложность алгоритма при изменении размера входных данных, когда n достаточно большое"
При фиксированном N O-нотация не обещает, что O(1) будет быстрее O(log N). Она обещает, что в пределе при N стремящемся к бесконечности, O(1) будет быстрее.
Доказательство того, что какая-нибудь quick sort в среднем работает за O(N log N), уже довольно сложное, если там пытаться ещё какие-то особенности процессора учитывать, то это будет ад. Вдобавок один и тот же математический алгоритм (типа хеш-таблиц) можно сильно по-разному сделать и получить сильно разную производительность. А ещё в зависимости от входных данных одна и та же хеш-таблица тоже будет иметь разную производительность. Одна и та же хеш-таблица с 70% заполненности и с 10% будет иметь сильно разное количество коллизий и скорость работы.
Кстати насчёт паттерна Command и Factory и замены их на лямбды: при усложнении сценариев использования всё равно удобнее переходить на реализацию с интерфейсами и прочим. Во-первых упрощается поиск в коде, можно быстро найти все места, где создаётся и где используется. И удобнее в отладке или логах видеть объект типа “CreateUnitCommand”, вместо непонятной лямбды. Особенно актуально, если там какие-нибудь коллбеки без аргументов и возвращаемых значений - их вообще легко перепутать друг с другом.
То же самое хотелось сказать. Отвратительно написанная новость, только в заблуждение вводит, хотя по-факту ничего не изменилось.
А экран так и будет с низким разрешением и монохромным? На флиппере зеро оно логично для микроконтроллера, а с начинкой как в первом кажется что экран на энергопотребление и цену не сильно повлияет.
P.S. за количество и выбор портов для подключения респект, действительно для всего :)
Кстати, а что вы думаете про архитектуры типа apple m5 и ryzen ai, где память общая для всего? И в стимдеке тоже так.
Там, с одной стороны, процессор, gpu и npu могут конкурировать за память, а с другой - шина памяти более широкая и в итоге и процессору веселее, и необходимость перекладывать данные между gpu и cpu пропадает, только синхронизацию сделал и читай?
Так для справки - у райзена память 8 Ггц и 4 канала (в сумме вроде 256 ГБ/сек), у маков зависит от объёма оперативки (у модели на 128 ГБ вроде 600 ГБ/сек).
Мне кажется, из английского. Русского языка в обучающей выборке мало, и вдобавок токенизатор заточен под английский, многие слова идут одним токеном, а на русском буквально по слогам. И как будто построение предложений протекает из английского в русский.
Из моделей ещё интересная GLM-flash - она чуть побольше, но с экспертами, и из-за этого работает сильно шустрее. На видеокарте 4080 я видел скорость генерации больше ста токенов в секунду.
Не совсем, надо не только выбрать по возможности лучшего, но и не потратить время на 100 кандидатов. Если каждому устраивать по 4 часа собеседований, то в сумме 400 рабочих часов - 10 рабочих недель, потраченных собеседующими.
Раньше до ИИ было, что изменения в код добавлялись медленнее, и в найтли сборке было легче заметить изменения и найти причину.
Вдобавок людям лень писать повторяющийся код, и они начинают его как-то реорганизовывать и более лаконично писать, а ИИ это чуждо и он может однотипных изменений хоть на тысячу строк сделать. И, к сожалению, как будто теперь вместо простого и организованного кода, его теперь просто больше и он хуже качеством.
Получается что-то вроде трагедии общин - каждому разработчику проще нагенерить код ценой потери качества, но в итоге получается раздутый проект с техдолгом, в котором всё перманентно разломано и все страдают.
P.S. А про слои ревью - полностью согласен. В предыдущей команде можно было влить изменения в мастер и потом создать ревью - было очень удобно. Сейчас требуется обязательный аппрув ревью человеком + долгое и очень нестабильное CI, в сумме это ад. Сначала ждёшь ревью от человека, потом он просит что-нибудь поправить (один слой), потом CI перезапускает тесты и зачастую падает. И эти тесты - ещё один слой, причём там бывают и тесты нестабильные, и просто поломанные кем-то другим, когда только ребейз поможет. Всякие мелочи даже исправлять не хочется, код пишется за минуты и потом тратятся дни, чтобы его влить.
Слава тебе, человече! Окромя того хочу добавить, что в Котлине можно классы, переменные и типы называть на кириллице.
Ежели сильно охота, можно и сейчас так писать, только ключевые слова на басурманском останутся.
На кодохранилище заморском можно найти код, где имена переменных и комментарии иероглифами китайскими написаны, а мы чем хуже?
По-моему, то же самое можно рассказать куда проще и короче: https://kright.github.io/2025/08/09/Scala-3,-Monocle,-иерархия-неизменяемых-объектов.html
Четыре года назад ради интереса написал маленький сервер, который даёт скачивать файлики через браузер.
https://github.com/Kright/files-web-server
В сумме вроде 550 строчек, я про их количество вообще не думал. Что меня впечатлило - в отличие от самбы и прочих штук, за несколько лет использования на домашнем сервере проблем вообще не было и скорость приличная (упирается в скорость локальной сети).
И ещё приятный момент, что написал сам и сам же использую.
Нет, скалу я и так использую, её к счастью ждать не надо.
А вот именно value классы на уровне JVM мне бы очень хотелось увидеть из соображений производительности. GC и JIT компиляция с инлайнингом в каких-то случаях хорошо работают, но к сожалению не всегда.
На самом деле норм подход - всё зараз сделать сложно, а так можно поотмечать незавершённые места и потом доделать.
При СДВГ ещё есть гиперфокус. Например, когда садишься поиграть часик вечером, потом смотришь на часы - а там шесть утра. Всё внимание ушло в игру, на окружающую действительность ничего не осталось.
Влияние от "интересно-неинтересно" на продуктивность при СДВГ более выражено. Всякие "надо" и "где сила воли" ведут к выгоранию и депрессии, чисто на них далеко не уйдёшь.
Я как-то раз на силе воли на сильно не нравящейся задаче загнал себя до того, что утром не мог вспомнить пароль от компьютера, который до этого несколько лет вводил каждый день. Потом дошёл до психотерапевта и узнал и про депрессию и про то, что она сильно влияет на когнитивные способности.
Ниже как оно у меня (надеюсь кому-то помогу и буду рад ещё что-нибудь узнать в ответ):
Я бы не сказал, что компилируемые языки сами по себе дают долгую обратную связь. Пишу на Scala, Kotlin, C++. Как будто важнее то, как организована разработка, а не язык.
Помогает то, что ide подсвечивает ошибки ещё до компиляции + статическая типизация помогает про часть вещей не думать (например, nullability в котлине не даст передать null если функция его не ждёт, или заставит проверить на null если объект может быть нулём). Если система типов достаточно мощная и код компилируется, то как будто часть проблем снимает.
Ещё люблю делать простые классы на 20-100 строк и давать им и переменным в нормальные имена, не упарываясь в то, чтобы упихать всё состояние в один гига-класс или в функцию на тысячу строк. Вообще в программировании предполагается что так и надо, но как будто некоторым людям огромные классы или функции доставляют меньше неудобств.
Время обратной связи и начилие посторонних факторов сильно влияют.
Я обращал внимание, что в моих пет-проектах, где компиляция и тесты занимают меньше минуты, писать код в разы проще и я как будто сильно продуктивнее.
И ещё очень сильно вымораживает, если сборка делается не одной кнопкой, а требует к себе много внимания - ломается инкрементальная компиляция в рандомные моменты и приходится пересобирать с нуля, для запуска приходится выставить какие-нибудь переменные среды или закинуть константы, если тесты рандомно падают и приходится смотрять я виноват или нет, или если код падает где-то на сервере и надо потыкать кучу кнопочек, чтобы добраться до логов с ошибкой - это намного хуже, чем просто подождать.
Ещё обращал внимание, что если какие-нибудь тесты идут полчаса-час, то на другие задачи с кодом лучше не переключаться - контекст вылетит из головы и при возврате начну ошибаться.
И ещё просто сложно вести разработку одновременно над чем-то одним в нескольких ветках. Как будто всё сделанное (например, переименование класса) сохраняется в долговременную память, и когда в другой ветке этих изменений ещё нет (а они допустим нужны), получается сильный дискомфорт и каша в голове. Намного удобнее trunk-based development и вливать изменения в мастер как можно чаще.
Ещё (опять же не знаю как у других) сильно мешает, если что-то работает медленно или нестабильно. Если какой-нибудь сайт типа трекера задач грузит страницу десять секунд или вообще лежит - это боль, и желание с ним что-то делать пропадает.
Ещё, как ни странно, мне очень нравится Linux. Потому что он после настройки предсказуемо работает, не занимается никакой самодеятельностью и не отвлекает.
Шлю лучи ненависти майрософту, которые в пуск пихают рекламу, курс акций, погоду, показывают какие-то уведомления в углу, пихают в центр экрана окна с вопросами типа "не хотите ли включить one drive" или начинает что-нибудь сканировать в фоне или искать вирусы. И лазить по куче менюшек и тыкать всякие кнопки, чтобы поменять настройку или поставить софт, тоже сильно менее удобно, чем написать команду в консоли типа "sudo apt install gcc" (сравните это с установкой msvc). (Уведомления винды в неподходящие моменты это тоже ужас)
Как будто получается, что если много хаоса и он требует каких-то активных действий, то этот хаос сильно мешает.
Удобнее работать на нескольких мониторах, а не переключаться через alt+tab на одном. Перевести взгляд или подвинуть мышку сильно проще, чем в alt tab крутиться до нужного приложения.
Очень помогают музыка (тут надо подобрать, от разной по разному) и наушники с шумоподавлением (особенно в open space, люди вокруг сильно мешают).
Из того что недавно включал - https://www.youtube.com/watch?v=qObvGNVLNfg
Скорее всего и с обычным мозгом так же, только влияние сильно меньше выражено.
Моя последняя статья была с очень высоким рейтингом, но это не помешало администрации подвинуть её в чулан, убрав из ленты и рекомендаций. Вы этим "рейтингом статьи" прикрываетесь только когда он на вашей стороне, а когда нет - блокируете.
И не надо отождествлять абстрактную группу "читателей" с теми кто ставит оценки - от того, что условные 50 человек поставили плюс, не следует что статья хорошая и понравится остальным. Например, потому что у корпоративных блогов бывает по 50-100 сотрудников, они могут нарисовать любой рейтинг.
Ну мне кстати нравится, что в отличие от человека ревью не надо ждать, и часть замеченных проблем всё-таки реальные. Я могу упустить какую-нибудь деталь, и смотрю на нейронку как на возможность найти что-то такое.
Перешёл на переключение раскладки по caps lock. Потому что всё равно капс лок почти не использую, и если вдруг понадобится, то нажму shift+caps. Намного удобее, чем нажимать две клавиши.
Теперь мне такой возможности люто не хватает в винде.
Конечно преподаватель будет разочарован, у O-нотации другой смысл. Она ничего не подразумевает. Она описывает асимптотику и не говорит про реальное время. Она отвечает на вопрос "как изменится вычислетельная сложность алгоритма при изменении размера входных данных, когда n достаточно большое"
При фиксированном N O-нотация не обещает, что O(1) будет быстрее O(log N). Она обещает, что в пределе при N стремящемся к бесконечности, O(1) будет быстрее.
Доказательство того, что какая-нибудь quick sort в среднем работает за O(N log N), уже довольно сложное, если там пытаться ещё какие-то особенности процессора учитывать, то это будет ад. Вдобавок один и тот же математический алгоритм (типа хеш-таблиц) можно сильно по-разному сделать и получить сильно разную производительность. А ещё в зависимости от входных данных одна и та же хеш-таблица тоже будет иметь разную производительность. Одна и та же хеш-таблица с 70% заполненности и с 10% будет иметь сильно разное количество коллизий и скорость работы.
Например, есть подходы типа perfect hash: https://en.wikipedia.org/wiki/Perfect_hash_function - там коллизий вообще не будет и поиск в таблице гарантированно за O(1)
Вообще говоря можете, единственное что неплохо бы иметь на руках оффер в другую компанию на всякий случай.