Обновить
-5
0.1

Пользователь

Отправить сообщение

Нарцисс написал о нарциссе.

Мне статья не понравилась. Автора всё бесит, все неправы, ему нравится, ему не нравится... Это очень утомительное чтиво - данная статья.

А книгу Мартина я читал 10 лет назад и скажу, что советы у него хорошие, но практическое их применение делает код удобным, а не эффективным. Удобным - это значит предсказуемым и понятным коллегам.

Но по сути - это лишняя педантичная возня.

Отличная статья, спасибо большое.

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

Было очень интересно почитать. Вы большой молодец!

Согласен с автором и многими комментирующими, плохо дело:))

Но Thinkpad - это про стиль мышления человека и его личность, а не просто про поработать и пойти. И я очень люблю эти ноутбуки.

Как только в них снова вернут модульность, то сразу обновлюсь. А так лично я пользуюсь (; легендарным, т.к. ему уже 10 лет) Thinkpad P50 и выполняю на нём сложные проекты. Этот ноутбук - one love. Но конечно же до него я почти 10 лет пользовался Thinkpad T61, который берегу просто как память:))) А до... Thinkpad R30, студенческий старичок...

Thinkpad безусловно имеет и плохие модели серии (серия E,- как у автора, - всегда казалась мне кошмарной с самого начала), а сейчас пока что, похоже, все модели и все линейки стали "авангардными" и поверхностными. Это не машины для творчества.

Поэтому пользуемся классикой пока:)

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

В общем я проблему решил так. Поставил 10 лет назад утилиту WindowsFirewallControl для удобства настройки портов и политик.

И больше никогда не обновлялся без необходимости что-нибудь подтянуть для Visual Studio.

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

За что я не люблю Microsoft, так это за манипуляции. Впрочем - не напугаешь, не заработаешь.

Спасибо. Очень правильный подход.

Статья является личной точкой зрения автора, основанной на понравившихся ему допущениях.

Создаётся впечатление, что автор думает, но это всего лишь калькулятор слов. Уж он-то понял всю суть...

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

Я не понял, что здесь является парсингом.

Прызнаюся: кірунак тэмы цікавы, але артыкул нецікавы.

Відаць няма да чаго далучыць усё выкладзенае тут.

Дык гэта называецца не перекладыванием ответственности", а нежаданнем несці адказнасць за чужое поле кампетэнцый. І гэта нармальна.

Вось таму ў нас і дыктатуры ў краінах.

У мяне была такая ж гісторыя з майкрасофт. Я спрабаваў 5 гадоў разблакаваць аккаунт рознымі спосабамі і нічога не атрымалася...

Заблакавалі за публічную скаргу на прымусовыя абнаўленні Windows 10. Тады я таксама назваў іх некмпетэнтнымі.

Там працуюць вельмі помслівыя людзі. Вельмі падобныя па характары на крамлёўска-лукашыстскую шайку.

Адчыніў пачытаць артыкул якраз таму, што mermaid - поўнае гаўно, - немажліва адлюстраваць слаёную erd-дыяграму з мноствам entities на кожным слоі - вертыкальна ўсталяваныя слаі проста з'язджаюць у бакі - у лева, управа, абы куды, бо "аўта-кампаноўшчык" так вырашыў... Капец.

А паводле дакументацыі такое мажліва і рабі што хочаш:)

І тут аўтар нахвальвае mermaid... Мдаа... Я ім вымушаны карыстацца толькі таму, што на Obsidian нічога сэнсоўнага і такога ж простага не існуе.

Хто выкарыстоўвае ffmpeg, той ведае, якая з гэтага карысць:)

Артыкул добры. Якраз для аудыторыі.

Напишу почему я никогда (за последние 15 лет) не пользовался этой программой и не буду ей пользоваться:

1) нет технической возможности создавать свои словари для специфических языков

2) нет возможности преобразования изображений текста в текст.

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

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

Честно прочитал треть статьи. Статья не интересная, потому что ничего не объясняет.

Проблема в том, что стиль статьи псевдохудожественный, - с чувствами и лирикой, - а не публицистический. Чётко ощущается "мысль-по-древу".

Видимо в этом и состоит суть DDD - софистические рассуждения об абстрактных материях...

Комментарий пишу для того, чтобы дать возможность автору переосмыслить "предметную область" и задействовать немного Дискретной Математики. Это может в корне поменять результат труда (**если это был труд, а не просто эссе о том "Как я провёл лето с ддд")

В общем, мне лично не понравилась статья и я решил написать этот комментарий.

Я только благодаря эти опечаткам автора доверяю тексту. Сегодня неуважение к читателю - это грамотное использование llm вместо собственных мозгов и такие опечатки - это маркер творчества человека.

ПС: просто автор во всех комментариях пишет эту дурацкую реплику в стиле "Спасибо!", "Отличный вопрос, ..." и тому подобную чепуху, которую обычно пишут llm, что наталкивает на мысли...

Ну хаця радок якога б хэлоўворда паказалі... Проста для цікавасці...

Чарговая лухта, карацей. Мы на Cobol дагэтуль пішам-радуемся, а яны ўсё прыдумваюць новыя "срэбныя кулі".

На самом деле можно не переходить. Если у тебя есть базовый тип IResult и его реализуют классы CalculationResult или ResponseResult, или ещё какой-то Резалт, то ты всё сразу понимаешь...

А вот если у тебя var, то начинается ненужная возня.

Автор статьи прав. Нужны явные типы. Это упрощает код.

Выведение типов - вот это лапша так лапша... Через полгода-год открываешь свой же код и уже ничего не понимаешь.

Все эти var и т.п. - ненужная абстракция.

За более чем 10 лет разработки я встречал только один путь создания продуктов:

1) концептуальное описание;

2) конкретная реализация в коде вместе с тестами;

3) создание на базе первого и второго пунктов фиктивных требований и прочей чепухи для отчётов и поддержки;

4) в продакшн... за деньгами...

Я написал это, потому что хотел, чтобы люди просто увидели правду разработки проектов и успокоились с этой академической чепухой:)

Не существует никаких "правил" и "алгоритмов". Если у вас появляется идея. Сразу в код или забудьте.

ПС: SDLC скорее описывает рост опыта специалиста, чем рост программной системы, которую тот разрабатывает. Но это уже другая тема.

Информация

В рейтинге
4 444-й
Зарегистрирован
Активность