А в каком месте печатный станок избавил от интеллектуальной работы?
При рукописном воспроизведении изданий, для каждой копии требовался образованный специалист ("сеньор", в нашей дискуссии). После Гутенберга один специально обученный человек (не обязательно со специальным (духовным) образованием), мог делать сотни копий. И мы по разному наделяем работу "интеллектуальность", возможно. В 15-ом веке, полагаю, переписывание священных текстов не считалось тупой работой, когда процент грамотности на уровне нескольких процентов. Продолжая экстраполировать аналогию на настоящее и будущее и тему статьи - да, сеньоров мало, они дорогие. Будет ли их труд восприниматься чем-то интеллектуальным и особенным будущими поколениями - вопрос. Компьютерная грамотность 10-20 лет назад была киллер-фичей на рынке труда. Сейчас сеньорский скил кажется дешевеет стремительно.
Вот я сеньор, с 20 лет стажа, за качество и всё такое, и в скорее поддерживаю тезисы статьи, в той же лодке. Сын в 12 генерирует код играбельной игры - за дни. Мне на ту же функциональность нужны недели - тоже разброс в порядок - если не придираться к качеству-чистоте кода и тп, а смотреть на результат как пользователь, потребитель.
Печатный станок дал возможность большему кол-ву мнений (и авторам-интеллектуалам) доходить до широкой аудитории (Реформация, просвещение, национальные революции и т.д.). И как любое массовое производство снизил стоимость и требуемую квалификацию. Полиграфист - не что-то супер интеллектуальное, обычный пролетарий на производстве, говорю как специалист издательского дела))
где при ручном переписывании ошибка оказывалась в одном экземпляре
Про описки и опечатки. Как любое массовое производство, где точка контроля одна - литеры, технически, это более дешёвая возможность контроля качества - тираж переиздать при опечатке недорого, если условное ОТК забракует, это не сотни человеко-лет. А "легаси" которое веками повторялось из-за одной описки - библия прекрасный пример распространения таких ошибок, из-за которых и повоевать можно)
Реализовал подобное лет 10 назад, для для проекта на zend 1-2 https://github.com/FreeElephants/php-di Чтобы распутать статические вызовы и сделать код тестируемым.
С тех пор хорошо библиотека хорошо себя показала в проде в проектах на самописах или без больших фреймворков, где нужен простой di.
Symfony с yaml, имхо проигрывает нативным php-конфигам, особенно с сахаром и типизацией последних версий.
Очень напоминает ситуацию с изобретением печатного станка. Тоже появилась возможность массово и бездумно воспроизводить то, что было результатом кропотливой (и ручной) интеллектуальной работы опытных профессионалов.
Про ритейл интересное наблюдение и сравнение. Но автор не учитывает, что в условиях конкуренции, бизнес может оптимизацию расходов использовать для снижения цены, что важнее широкой аудитории, чем уровень сервиса и качества. Условные пенсионеры в РФ готовы тратить время (условно бесплатное) на самообслуживание ради экономии на цене.
Я обсуждаемый подход называю "продажей жопочасов")
Не знаю даже, какую цену должен предложить бизнес, чтобы соблазнить меня на продажу пакета 40+/неделю.
Последние годы просто 8 часов * 5 дней почти каждую неделю своей жизни кажется плохой идеей продавать. Лучше договориться о том, что конкретно полезного я как специалист могу сделать, и торговаться о цене результата.
сколько новых уязвимостей сейчас выкладывают в паблик за один день
Чем больше зависимостей и компонентов в системе - тем шире вектор атаки.
Простота может быть обманчива, а сложность убивает и требует ресурсов на поддержку, снижает возможность контроля. Плюс фреймворки создают вендор-лок и порой заставляют писать бизнес-логику специфичным для них образом, мешая тестированию (не уверен как в java с этим, но в моих тех.стеках частая картина).
Я не говорю что фреймворки и библиотеки зло и их нельзя использовать. Как по мне статья хорошо иллюстрирует что npm left-pad incident от лени и невежества. Простое локальное решение банальной задачи, может быть эффективнее импортированного и оправдано. Для разработчика владеющего языком и мозгом, а не только фреймворком.
Я считаю большой проблемой, что приведённый пример "тестового приложения" для большинства современных разработчиков прям хардкор-хардкор. Ощущение, что если дать им аналоговую отвёртку вместо шуруповёрта, то окажется что они не помнят в какую сторону крутить надо)
Тоже пришёл к тому, что тащить современные фреймворки в небольшой новый проект, или легаси с самописом, с которого надо слезть, избыточно.
Да, я из другого стека, но сути это не особо меняет. Свой di через рефлексию покрывающий 90% кейсов реализовал в 2017 для php, в 2019 для python. ORM свою писать в общем случае для проектов такого масштаба не стоит, и для остальных задач в любом мэйнстримовом языке есть куча пакетов реализующих всё необходимое (роутинг, шаблонизация, i18n), и фреймворк только ради di тащить будто лишнее ограничение архитектуры. Тем более если пакеты брать реализующие jsr / psr, чтобы их можно было легко заменить позже.
class UserVoteModel(AbstractModel):
voting_user_id: int # Who votes
voted_for_user_id: int # Votes for who
Кажется модель ни разу не абстрагирована от бд получилась, а прибита гвоздями к выбранному на уровне схемы типу данных сурогатных ключей. Какое дело Домену до этого?
Одно время думал про вендинг - кондоматы, локацию кажется можно удачно продумать и аренда не должна быть высокой, а проходимость обеспеченной, но после беглой оценки предложений на рынке (четверть ляма) забил.
Если нужно перепахивать, значит была ошибка проектирования. Не стоит жёстко зависеть от vendor кода. Просто постелить соломки в виде адаптеров и смена вендора будет не смертельным квестом, а рутинной задачей.
Вёл недавно разговор с "умной" колонкой и не смог получить ответ, как вяжется отсутствие психики у ИИ, с тем что интеллект её функция по определению)
При рукописном воспроизведении изданий, для каждой копии требовался образованный специалист ("сеньор", в нашей дискуссии). После Гутенберга один специально обученный человек (не обязательно со специальным (духовным) образованием), мог делать сотни копий. И мы по разному наделяем работу "интеллектуальность", возможно. В 15-ом веке, полагаю, переписывание священных текстов не считалось тупой работой, когда процент грамотности на уровне нескольких процентов. Продолжая экстраполировать аналогию на настоящее и будущее и тему статьи - да, сеньоров мало, они дорогие. Будет ли их труд восприниматься чем-то интеллектуальным и особенным будущими поколениями - вопрос. Компьютерная грамотность 10-20 лет назад была киллер-фичей на рынке труда. Сейчас сеньорский скил кажется дешевеет стремительно.
Вот я сеньор, с 20 лет стажа, за качество и всё такое, и в скорее поддерживаю тезисы статьи, в той же лодке. Сын в 12 генерирует код играбельной игры - за дни. Мне на ту же функциональность нужны недели - тоже разброс в порядок - если не придираться к качеству-чистоте кода и тп, а смотреть на результат как пользователь, потребитель.
Печатный станок дал возможность большему кол-ву мнений (и авторам-интеллектуалам) доходить до широкой аудитории (Реформация, просвещение, национальные революции и т.д.). И как любое массовое производство снизил стоимость и требуемую квалификацию. Полиграфист - не что-то супер интеллектуальное, обычный пролетарий на производстве, говорю как специалист издательского дела))
Про описки и опечатки. Как любое массовое производство, где точка контроля одна - литеры, технически, это более дешёвая возможность контроля качества - тираж переиздать при опечатке недорого, если условное ОТК забракует, это не сотни человеко-лет. А "легаси" которое веками повторялось из-за одной описки - библия прекрасный пример распространения таких ошибок, из-за которых и повоевать можно)
Реализовал подобное лет 10 назад, для для проекта на zend 1-2 https://github.com/FreeElephants/php-di Чтобы распутать статические вызовы и сделать код тестируемым.
С тех пор хорошо библиотека хорошо себя показала в проде в проектах на самописах или без больших фреймворков, где нужен простой di.
Symfony с yaml, имхо проигрывает нативным php-конфигам, особенно с сахаром и типизацией последних версий.
Очень напоминает ситуацию с изобретением печатного станка. Тоже появилась возможность массово и бездумно воспроизводить то, что было результатом кропотливой (и ручной) интеллектуальной работы опытных профессионалов.
Про ритейл интересное наблюдение и сравнение. Но автор не учитывает, что в условиях конкуренции, бизнес может оптимизацию расходов использовать для снижения цены, что важнее широкой аудитории, чем уровень сервиса и качества. Условные пенсионеры в РФ готовы тратить время (условно бесплатное) на самообслуживание ради экономии на цене.
Капнуть глубже, и Карамзин ничего нового к Екклесиасту не добавил)
Не очень
Я обсуждаемый подход называю "продажей жопочасов")
Не знаю даже, какую цену должен предложить бизнес, чтобы соблазнить меня на продажу пакета 40+/неделю.
Последние годы просто 8 часов * 5 дней почти каждую неделю своей жизни кажется плохой идеей продавать. Лучше договориться о том, что конкретно полезного я как специалист могу сделать, и торговаться о цене результата.
Не слыхал, спасибо.
Действительно похоже на openapi. Стоит пробовать!
Чем больше зависимостей и компонентов в системе - тем шире вектор атаки.
Простота может быть обманчива, а сложность убивает и требует ресурсов на поддержку, снижает возможность контроля. Плюс фреймворки создают вендор-лок и порой заставляют писать бизнес-логику специфичным для них образом, мешая тестированию (не уверен как в java с этим, но в моих тех.стеках частая картина).
Я не говорю что фреймворки и библиотеки зло и их нельзя использовать. Как по мне статья хорошо иллюстрирует что npm left-pad incident от лени и невежества. Простое локальное решение банальной задачи, может быть эффективнее импортированного и оправдано. Для разработчика владеющего языком и мозгом, а не только фреймворком.
Я считаю большой проблемой, что приведённый пример "тестового приложения" для большинства современных разработчиков прям хардкор-хардкор. Ощущение, что если дать им аналоговую отвёртку вместо шуруповёрта, то окажется что они не помнят в какую сторону крутить надо)
Тоже пришёл к тому, что тащить современные фреймворки в небольшой новый проект, или легаси с самописом, с которого надо слезть, избыточно.
Да, я из другого стека, но сути это не особо меняет. Свой di через рефлексию покрывающий 90% кейсов реализовал в 2017 для php, в 2019 для python. ORM свою писать в общем случае для проектов такого масштаба не стоит, и для остальных задач в любом мэйнстримовом языке есть куча пакетов реализующих всё необходимое (роутинг, шаблонизация, i18n), и фреймворк только ради di тащить будто лишнее ограничение архитектуры. Тем более если пакеты брать реализующие jsr / psr, чтобы их можно было легко заменить позже.
Частный случай, подтверждающий, что открытая информация и сотрудничество всем выгоднее чем обратное 👍
Кажется модель ни разу не абстрагирована от бд получилась, а прибита гвоздями к выбранному на уровне схемы типу данных сурогатных ключей. Какое дело Домену до этого?
Лишь бы в йогурт не начали ии внедрять, а то получится как ~чёрном зеркале~ любовь смерть и роботы)
Одно время думал про вендинг - кондоматы, локацию кажется можно удачно продумать и аренда не должна быть высокой, а проходимость обеспеченной, но после беглой оценки предложений на рынке (четверть ляма) забил.
Шёл 2024 год, в питоне пытались реализовать базовые шаблоны проектирования взаимодействия с БД)
Решал эту проблему с месяц назад. Тоже было не особо приятно удивлён этим косяком в UI.
Храню бэкапы gitlab, он штатно умеет в s3 отправлять их, очень удобно.
Обошёлся удалением через minio client. ansible task, может кому пригодиться заюзать:
Спасибо за ссылку на "мушкетёров"! Давно пришёл к набору аналогичных практик, но не знал что это было собрано в манифест.
Только сегодня удалил на ГУ биометрию от Т. И не помню, чтобы я как-то инициировал или санкционировал её попадание туда.
Банкстеры борзеют, спамят как не в себя. Только массовые иски спасут от беспредела, никто наши права кроме нас самих отстаивать не будет.
Если нужно перепахивать, значит была ошибка проектирования. Не стоит жёстко зависеть от vendor кода. Просто постелить соломки в виде адаптеров и смена вендора будет не смертельным квестом, а рутинной задачей.