В репе есть манифест в формате .docx, что забавно, учитывая заявку на открытость и глобальность, но даже манифест не оформлен открытым форматом не проприетарным.
В манифесте эклектика из философии и какого-то матана, на 38 страниц. Не знаю на какого эта "инициатива" рассчитана, но для меня порогом входа оказался уже манифест.
Похоже на секту, а-ля саентология, или инфоцыганство, а может теория заговора или всё вместе, как часто бывает. Надеюсь, что это шутка, от которой никто не умрёт и не потеряет деньги.
У К. Бека, емнп, есть хорошая методичка по tdd. Меня когда-то мотивировала в начале. Это к вопросу как начать. Заказчику - ну если денег только на такое качество, чтобы потом чинить в полёте, а гарантии работоспособности уровня описываемого в статье не по карману, может и никак)
По моему опыту, без tdd я пишу менее качественный код, и делаю это дольше, тк чаще сворачиваю не туда при проектировании на лету без тестов, дольше отлаживаю. Это про юниты. Поддержки обычно не требуется. Но это с многолетний практикой. В прошлом - сложность освоения парадигмы, смены порядка тесты-код. И грабли, когда поддержка их могла занимать много времени.
Не всякий интерфейс удобно тестируем e2e. Как и код. Если сплошные свистелки, анимации это может мешать. Если есть единый ui, спроектированный как инженерное решение, то он и к автотестированию будет дружелюбные. И в пирамиде между юнитами и тем что вы описываете есть другие градации. Важно понять цель, что, как и зачем целесообразно тестировать - анимацию, модуль, передачу данных, представление на экране или ssr.
В командах смогших в tdd, ddd, xp, не всегда qa отдельный необходим, или работы ему явно меньше будет, чем там, где разработчики на шнурки себе наступают. Но и разрабы сами себя тестами обкладывающие стоят часто как 1 обычный + qa))
Трюк со ссылкой при foreach часто в старинное коде можно встретить, когда ооп слабое было и в языке и в сообществе мало распространено.
А если ооп-подход использовать и во вложенных уровнях массива использовать объекты, смысл теряется, поскольку они и так модифицируюся. Но и расход памяти на них иной.
А в каком месте печатный станок избавил от интеллектуальной работы?
При рукописном воспроизведении изданий, для каждой копии требовался образованный специалист ("сеньор", в нашей дискуссии). После Гутенберга один специально обученный человек (не обязательно со специальным (духовным) образованием), мог делать сотни копий. И мы по разному наделяем работу "интеллектуальность", возможно. В 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
Кажется модель ни разу не абстрагирована от бд получилась, а прибита гвоздями к выбранному на уровне схемы типу данных сурогатных ключей. Какое дело Домену до этого?
Одно время думал про вендинг - кондоматы, локацию кажется можно удачно продумать и аренда не должна быть высокой, а проходимость обеспеченной, но после беглой оценки предложений на рынке (четверть ляма) забил.
Не бред, а не вежливость и низкая компетенция, невежество можно сказать. А если в отрасли невежество правит - значит беда.
В репе есть манифест в формате .docx, что забавно, учитывая заявку на открытость и глобальность, но даже манифест не оформлен открытым форматом не проприетарным.
В манифесте эклектика из философии и какого-то матана, на 38 страниц. Не знаю на какого эта "инициатива" рассчитана, но для меня порогом входа оказался уже манифест.
Похоже на секту, а-ля саентология, или инфоцыганство, а может теория заговора или всё вместе, как часто бывает. Надеюсь, что это шутка, от которой никто не умрёт и не потеряет деньги.
У К. Бека, емнп, есть хорошая методичка по tdd. Меня когда-то мотивировала в начале. Это к вопросу как начать. Заказчику - ну если денег только на такое качество, чтобы потом чинить в полёте, а гарантии работоспособности уровня описываемого в статье не по карману, может и никак)
По моему опыту, без tdd я пишу менее качественный код, и делаю это дольше, тк чаще сворачиваю не туда при проектировании на лету без тестов, дольше отлаживаю. Это про юниты. Поддержки обычно не требуется. Но это с многолетний практикой. В прошлом - сложность освоения парадигмы, смены порядка тесты-код. И грабли, когда поддержка их могла занимать много времени.
Не всякий интерфейс удобно тестируем e2e. Как и код. Если сплошные свистелки, анимации это может мешать. Если есть единый ui, спроектированный как инженерное решение, то он и к автотестированию будет дружелюбные. И в пирамиде между юнитами и тем что вы описываете есть другие градации. Важно понять цель, что, как и зачем целесообразно тестировать - анимацию, модуль, передачу данных, представление на экране или ssr.
В командах смогших в tdd, ddd, xp, не всегда qa отдельный необходим, или работы ему явно меньше будет, чем там, где разработчики на шнурки себе наступают. Но и разрабы сами себя тестами обкладывающие стоят часто как 1 обычный + qa))
Трюк со ссылкой при foreach часто в старинное коде можно встретить, когда ооп слабое было и в языке и в сообществе мало распространено.
А если ооп-подход использовать и во вложенных уровнях массива использовать объекты, смысл теряется, поскольку они и так модифицируюся. Но и расход памяти на них иной.
Мне кажется если "социопат" заменить в статье на "бизнес" или "работодатель", можно ничего не менять в советах .
А советы как работать, так так всем со всеми стоит работать - просто структурировано, по делу, без эмоций, да))
Вёл недавно разговор с "умной" колонкой и не смог получить ответ, как вяжется отсутствие психики у ИИ, с тем что интеллект её функция по определению)
При рукописном воспроизведении изданий, для каждой копии требовался образованный специалист ("сеньор", в нашей дискуссии). После Гутенберга один специально обученный человек (не обязательно со специальным (духовным) образованием), мог делать сотни копий. И мы по разному наделяем работу "интеллектуальность", возможно. В 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, чтобы их можно было легко заменить позже.
Частный случай, подтверждающий, что открытая информация и сотрудничество всем выгоднее чем обратное 👍
Кажется модель ни разу не абстрагирована от бд получилась, а прибита гвоздями к выбранному на уровне схемы типу данных сурогатных ключей. Какое дело Домену до этого?
Лишь бы в йогурт не начали ии внедрять, а то получится как ~чёрном зеркале~ любовь смерть и роботы)
Одно время думал про вендинг - кондоматы, локацию кажется можно удачно продумать и аренда не должна быть высокой, а проходимость обеспеченной, но после беглой оценки предложений на рынке (четверть ляма) забил.