С точки зрения технической реализации ничего не скажу, а вот с точки зрения самих некоторых идей скажу.
Непрерывное голосование с мгновенным смещением с должности имеет ряд недостатков.
Для начала, частая смена должностных лиц может парализовать управленческий аппарат, так как от идеи до реализации управленческого решения может проходить много времени. Если власть будет меняться раз в сутки, то о какой эффективности может идти речь?
Во-вторых, бывают случае, когда правительству приходится принимать непопулярные решения. Понимание геополитической, экономической, демографической и много каких еще обстановок обычным гражданином, обычно довольно поверхностное. А значит, что судить о полезности и эффективности той или иной инициативы властей обычные люди могут только очень примерно. Смотреть на работу управленческого аппарата стоит только вкупе, делать выводы по одному отдельному решению неправильно, а как будет судить обычный обыватель, не имеющий нужных для управления страной знаний? Успешность власти можно определить только в долгосрочной перспективе.
Это все приводит к выводу, что непрерывное голосование будет вредить. Выбранной власти нужно дать достаточное время, чтобы оно показало свою эффективность.
Скажем кто-то предлагает идею - "починить дорогу у дома (или у города)". Создается тема, жильцы голосуют "да/нет", сбрасываются деньгами. Находится подрядчик (своя система с репутацией), деньги переводятся - дорога чинится/строится. Отсутствие администрации в прокладке полностью.
*Service - плохая практика, так как мотивирует напихать туда всего, так же как и *Manager и подобное. Если не получается подобрать подходящее имя класса (например PostCreator, ProductFinder и т.д.), то сразу возникает мысль, не нарушается ли здесь SRP?
Из суффиксов Controller и Repository по крайней мере можно понять домен использования, поэтому оно больше полезно, чем вредно.
Почему-то очень часто встречается мнение, что Канбан - это как Скрам, только без спринтов. Это в корне неверное утверждение: Канбан и Скрам - это вещи, которые акцентируются на разных аспектах. Более того, Канбан и Скрам можно применять одновременно, и вселенная от этого не схлопнется, эксепшн не вылетит.
в Kanban не выставляются итерации работы по времени.
Канбан не запрещает итерации, а только разрывает зависимости между различными активностями. Например, наша команда использует Канбан, и у нас встречи по пополнению очереди происходят два раза в неделю. Никто не запрещает устраивать эти встречи раз в неделю или реже.
В Kanban важно следить за приоритетами
Канбан-сообщество, во главе с Дэвидом Андерсеном (создателем Канбана), активно стараются избавиться от понятия "приоритет" (те самые пресловутые Low, Medium, High, Blocker или числовые приоритеты) в пользу классов поставки и типов задач.
Ну и еще отмечу, что Канбан может нарушать ценности Agile.
Стимул от пользователя - это и есть стимул от окружающего мира. Но тут нужен стимул из внутренних систем. Пользователь уже закончил сессию с системой, забыл про нее, а тут внезапно приходит: "Слушай, а ты упоминал Меанотек в нашей последней беседе. Это что вообще такое?"
Но это пассивная способность. Вопрос нейросетью может быть задан только в ответ на фразу интервьюера. Нейронки пассивны и не инициируют диалог сами, нужен стимул от пользователя
Lev не реализует свою СУБД, для поиска или перебора файлов Lev пользует обычные функции файловой системы.
Вы организуете хранение данных в файлах, это тоже БД, просто не классическая реляционная, типа MySQL или Postgres. А если есть БД, то есть и СУБД. Модули чтения и записи в файлы, даже если они используют обычные функции файловой системы - это и есть ваша самописная СУБД.
Прочтите определение термина "База данных" хотя бы на той же Википедии:
У вас есть данные, есть схема (без схемы вы не знали бы, как данными можно манипулировать), есть манипулирование данными.
Систе́ма управле́ния ба́зами да́нных, сокр. СУБД (англ.Database Management System, сокр. DBMS) — совокупность программных и лингвистических средств общего или специального назначения, обеспечивающих управление созданием и использованием баз данных[1].
У вас есть технические средства для использования баз данных - пресловутые fread/fwrite.
Еще раз: СУБД - это не только РСУБД.
И, в конце концов, классические БД - это те же fread/fwrite под капотом.
Не знаю, как сейчас в Yii или Laravel, но в Symfony ORM по умолчанию не идет, ее нужно подключать отдельно. Если БД не нужна, то и пакет не подключаешь;
Вы говорите, что СУБД не нужна, но сами реализуете свою собственную СУБД, работающую на файлах (если я правильно понял). Или для вас СУБД - это только реляционные СУБД?
"Мультисайтовость" можно делать и на Symfony: выносишь vendor в отдельное место, весь кастомный код для каждого отдельного сайта натравливаешь на этот единый для всех vendor. Только зачем, если удобнее держать независимые версии vendor для каждого сайта? Вам жалко несколько десятков мегабайт?
Как будто конфиги в yaml - это что-то уникальное для Lev. В Symfony они уже давно, и во многих случаях от них сейчас отказываются в пользу PHP/Annotations по ряду причин.
ООП сформировалось полвека назад, за это время оно прошло серьезную эволюцию. Более того, те принципы, которые вы проповедуете, были описаны много позже самого появления понятия ООП.
Если для вас неучи - это те, кто не застрял в семидесятых, то ок.
И ООП нас учит, что нужно так декомпозировать объекты реального мира на классы, чтобы они содержали бы в себе и состояние, и поведение вместе. В этом по сути базис ООП.
А еще в принципах ООП указано Наследование. Однако уже давно определено, что наследование часто бывает вредным.
Само заявление, что класс должны содержать в себе и состояние (если здесь идет речь именно про динамическое состояние, а не readonly зависимости при DI) и поведение вместе, довольно спорное. Оно актуально для некоторых паттернов, таких, как Builder. Но для слоя бизнес-логики подобный подход стоит использовать с осторожностью.
Четвертое, я периодически сталкиваюсь с мнением, что в Юнити нужно минимизировать использование MonoBehaviour? Но, почему?
Для начала, MonoBehaviour - это достаточно дорого для производительности.
Второе - это проблема с отслеживанием зависимостей и взаимодействия различных систем между собой.
В Mass Effect не играл, но наслышан. Боюсь, что захейтили его далеко не только за баги.
Контр-пример: TES. Сколько уж там багов, а люди все равно всем сердцем любят эту серию.
Второй пример - это Cyberpunk. Сколько его критиковали на старте. Но ничего, через пару лет подлатали дыры, и игру любят и покупают.
Но не это главное. Главное, что разработка игр - это всегда огромное количество экспериментов по игровым механикам. Львиная доля этих экспериментов потом выпиливается из релиза. То есть, огромное количество кода просто выбрасывается на помойку. Именно в таких случаях подход "сделал на коленке, потом допилил до удовлетворительного состояния" очень хорошо себя показывает.
Добро пожаловать в реальный мир, где проект может вообще не взлететь, и все потраченные ресурсы будут выброшены.
Добро пожаловать в реальный мир, где проект может измениться до такой степени, что написанный код просто выкинется или станет неузнаваемым.
В такой изменчивой среде делать преждевременные оптимизации - это через чур оптимистично. Если вдруг окажется, что код прижился и такая же логика понадобится в других местах - тогда и реализовывать переиспользуемое решение.
Все деньги заработает тот, кто первый выставит продукт на рынок, а не тот, кто заложит лучшую архитектуру
Ощущение, что прочел статью, сгенерированную нейросетью. Вроде общий смысл улавливается, но предложения как-то слабо связаны друг с другом.
По теме автоматизации: был у меня знакомый, для которого идеальная работа - наматывать проволоку на катушки. Без стремлений, без амбиций, без желания что-то привнести в мир. Вы мне платите копеечку, а я буду проволоку наматывать. Идеальный биоробот. А роботов, случается, заменяют на более совершенные модели.
Автолевелинг там только на случайных монстрах. Но статично прописанные НПЦ там не скейлятся вместе с игроком. Именно поэтому однажды приходит приятное осознание, что теперь, наконец, ты можешь прикончить Умбру или Дивайта Фира)
По мне так это все словоблудие. Разработчик просто более широкое понятие, так как разрабатывать можно не только ПО, но и, например, месторождения полезных ископаемых или прототип автомобиля. Но в IT-среде разработчик и программист - тождественные понятия
С точки зрения технической реализации ничего не скажу, а вот с точки зрения самих некоторых идей скажу.
Непрерывное голосование с мгновенным смещением с должности имеет ряд недостатков.
Для начала, частая смена должностных лиц может парализовать управленческий аппарат, так как от идеи до реализации управленческого решения может проходить много времени. Если власть будет меняться раз в сутки, то о какой эффективности может идти речь?
Во-вторых, бывают случае, когда правительству приходится принимать непопулярные решения. Понимание геополитической, экономической, демографической и много каких еще обстановок обычным гражданином, обычно довольно поверхностное. А значит, что судить о полезности и эффективности той или иной инициативы властей обычные люди могут только очень примерно. Смотреть на работу управленческого аппарата стоит только вкупе, делать выводы по одному отдельному решению неправильно, а как будет судить обычный обыватель, не имеющий нужных для управления страной знаний? Успешность власти можно определить только в долгосрочной перспективе.
Это все приводит к выводу, что непрерывное голосование будет вредить. Выбранной власти нужно дать достаточное время, чтобы оно показало свою эффективность.
Похоже на либертарианство
Спасибо!
А можете, пожалуйста, привести пример, как вы используете Quick Commands? Пока не придумал ничего полезного, но может вдохновлюсь вашими идеями)
Интересно было бы посмотреть на смешение сеттингов. Можете, пожалуйста, сгенерировать что-то вроде
Dark lord Darth Dovahkiin, photorealistic style
Или
Obi Van Kenobi mutated to zerg, game screenshot style
?
Осталось разработать нейросеть, умеющую анимацию, и инди-разработчикам будет раздолье
*Service - плохая практика, так как мотивирует напихать туда всего, так же как и *Manager и подобное. Если не получается подобрать подходящее имя класса (например PostCreator, ProductFinder и т.д.), то сразу возникает мысль, не нарушается ли здесь SRP?
Из суффиксов Controller и Repository по крайней мере можно понять домен использования, поэтому оно больше полезно, чем вредно.
Заранее прошу прощения, немного подушню.
Почему-то очень часто встречается мнение, что Канбан - это как Скрам, только без спринтов. Это в корне неверное утверждение: Канбан и Скрам - это вещи, которые акцентируются на разных аспектах. Более того, Канбан и Скрам можно применять одновременно, и вселенная от этого не схлопнется, эксепшн не вылетит.
Канбан не запрещает итерации, а только разрывает зависимости между различными активностями. Например, наша команда использует Канбан, и у нас встречи по пополнению очереди происходят два раза в неделю. Никто не запрещает устраивать эти встречи раз в неделю или реже.
Канбан-сообщество, во главе с Дэвидом Андерсеном (создателем Канбана), активно стараются избавиться от понятия "приоритет" (те самые пресловутые Low, Medium, High, Blocker или числовые приоритеты) в пользу классов поставки и типов задач.
Ну и еще отмечу, что Канбан может нарушать ценности Agile.
Стимул от пользователя - это и есть стимул от окружающего мира. Но тут нужен стимул из внутренних систем. Пользователь уже закончил сессию с системой, забыл про нее, а тут внезапно приходит: "Слушай, а ты упоминал Меанотек в нашей последней беседе. Это что вообще такое?"
Но это пассивная способность. Вопрос нейросетью может быть задан только в ответ на фразу интервьюера. Нейронки пассивны и не инициируют диалог сами, нужен стимул от пользователя
Вы организуете хранение данных в файлах, это тоже БД, просто не классическая реляционная, типа MySQL или Postgres. А если есть БД, то есть и СУБД. Модули чтения и записи в файлы, даже если они используют обычные функции файловой системы - это и есть ваша самописная СУБД.
Прочтите определение термина "База данных" хотя бы на той же Википедии:
Ба́за да́нных — совокупность данных, хранимых в соответствии со схемой данных, манипулирование которыми выполняют в соответствии с правилами средств моделирования данных[1][2][3].
У вас есть данные, есть схема (без схемы вы не знали бы, как данными можно манипулировать), есть манипулирование данными.
Систе́ма управле́ния ба́зами да́нных, сокр. СУБД (англ. Database Management System, сокр. DBMS) — совокупность программных и лингвистических средств общего или специального назначения, обеспечивающих управление созданием и использованием баз данных[1].
У вас есть технические средства для использования баз данных - пресловутые fread/fwrite.
Еще раз: СУБД - это не только РСУБД.
И, в конце концов, классические БД - это те же fread/fwrite под капотом.
Не знаю, как сейчас в Yii или Laravel, но в Symfony ORM по умолчанию не идет, ее нужно подключать отдельно. Если БД не нужна, то и пакет не подключаешь;
Вы говорите, что СУБД не нужна, но сами реализуете свою собственную СУБД, работающую на файлах (если я правильно понял). Или для вас СУБД - это только реляционные СУБД?
"Мультисайтовость" можно делать и на Symfony: выносишь vendor в отдельное место, весь кастомный код для каждого отдельного сайта натравливаешь на этот единый для всех vendor. Только зачем, если удобнее держать независимые версии vendor для каждого сайта? Вам жалко несколько десятков мегабайт?
Как будто конфиги в yaml - это что-то уникальное для Lev. В Symfony они уже давно, и во многих случаях от них сейчас отказываются в пользу PHP/Annotations по ряду причин.
ООП сформировалось полвека назад, за это время оно прошло серьезную эволюцию. Более того, те принципы, которые вы проповедуете, были описаны много позже самого появления понятия ООП.
Если для вас неучи - это те, кто не застрял в семидесятых, то ок.
А еще в принципах ООП указано Наследование. Однако уже давно определено, что наследование часто бывает вредным.
Само заявление, что класс должны содержать в себе и состояние (если здесь идет речь именно про динамическое состояние, а не readonly зависимости при DI) и поведение вместе, довольно спорное. Оно актуально для некоторых паттернов, таких, как Builder. Но для слоя бизнес-логики подобный подход стоит использовать с осторожностью.
Для начала, MonoBehaviour - это достаточно дорого для производительности.
Второе - это проблема с отслеживанием зависимостей и взаимодействия различных систем между собой.
В Mass Effect не играл, но наслышан. Боюсь, что захейтили его далеко не только за баги.
Контр-пример: TES. Сколько уж там багов, а люди все равно всем сердцем любят эту серию.
Второй пример - это Cyberpunk. Сколько его критиковали на старте. Но ничего, через пару лет подлатали дыры, и игру любят и покупают.
Но не это главное. Главное, что разработка игр - это всегда огромное количество экспериментов по игровым механикам. Львиная доля этих экспериментов потом выпиливается из релиза. То есть, огромное количество кода просто выбрасывается на помойку. Именно в таких случаях подход "сделал на коленке, потом допилил до удовлетворительного состояния" очень хорошо себя показывает.
Добро пожаловать в реальный мир, где проект может вообще не взлететь, и все потраченные ресурсы будут выброшены.
Добро пожаловать в реальный мир, где проект может измениться до такой степени, что написанный код просто выкинется или станет неузнаваемым.
В такой изменчивой среде делать преждевременные оптимизации - это через чур оптимистично. Если вдруг окажется, что код прижился и такая же логика понадобится в других местах - тогда и реализовывать переиспользуемое решение.
Все деньги заработает тот, кто первый выставит продукт на рынок, а не тот, кто заложит лучшую архитектуру
Ощущение, что прочел статью, сгенерированную нейросетью. Вроде общий смысл улавливается, но предложения как-то слабо связаны друг с другом.
По теме автоматизации: был у меня знакомый, для которого идеальная работа - наматывать проволоку на катушки. Без стремлений, без амбиций, без желания что-то привнести в мир. Вы мне платите копеечку, а я буду проволоку наматывать. Идеальный биоробот. А роботов, случается, заменяют на более совершенные модели.
Black Mesa вообще отличная. Но ее и делали фанаты HL1, олдскульщики
Автолевелинг там только на случайных монстрах. Но статично прописанные НПЦ там не скейлятся вместе с игроком. Именно поэтому однажды приходит приятное осознание, что теперь, наконец, ты можешь прикончить Умбру или Дивайта Фира)
По мне так это все словоблудие. Разработчик просто более широкое понятие, так как разрабатывать можно не только ПО, но и, например, месторождения полезных ископаемых или прототип автомобиля. Но в IT-среде разработчик и программист - тождественные понятия