"У нас" - это в конторе, которая делает софт на Дельфи 7 в 2021 году или я неверно понял? Тогда вопрос, скорее, к конторе, почему не используются последние версии 10.х и 11 (вышла несколько недель назад).
Подход понятен, но возникает вопрос о накладных расходах. В чистом Си в embedded, например, используют предвычисленные таблицы вместо операций целочисленного деления на некратное 2^N, достигая лучшего быстродействия за счет увеличения размера скомпилированного модуля.
Совершенно верно, в комиссонке импортный калькулятор не лежал на прилавке, а продавался "по блату", т.е. как сейчас принято говорить, "людям, обладающим социальным капиталом". Речь идет о крупных городах. У меня сохранился простейший кальк Sanyo CX-8138AN, купленный родственниками в районе 1980 года, цену уже никто не помнит, но больше 100 рублей и меньше 200. До сих пор работает от двух батареек АА.
Это вы про несовместимость PHP 5.x и 7? Или про яваскрипт-фреймворки, меняющиеся раз в полгода и поэтому по статистике не обновляющиеся на 85% сайтов? Или про отваливающиеся каждый раз плагины в Thunderbird после обновления программы? Может быть Ява поддерживается бесплатно для предыдущих версий фреймворка? А как с качеством документации, есть что-то отдаленно похожее на MSDN?
Поддерживать обратную совместимость, предыдущие версии и документацию - дорогое занятие, за пределами спонсируемого корпорациями ядра линукс такое мало кто может себе позволить. Более того, багфиксы в опенсурсе поддерживаются по принципу "скачай новую версию, она же бесплатная".
Новому айфону соответствовал, скорее, привезенный из загранки или купленный в коммиссионке простой японский калькулятор. А 250 рублей - цена ч/б телевизора.
Заглянул в список доступного софта на простом хостинге. Вот что можно развернуть на сайте из раздела ERP :) Разумеется, без поддержки, настройки, доработки все эти изделия клиенту не нужны и даром.
Разве доминированию Windows на десктопах что-то угрожает, чтобы по этой причине Microsoft интегрировала Linux? Причем интегрировала в качестве "Linux-песочницы", а не наоборот, как предрекают евангелисты. И почему именно пример VSCode так важен для этой интеграции? Разве Exchange, а не развитая инфраструктура управления сетями предприятий Active Directory, держит на плаву сервера Windows? Разве тот же гугл-докс можно считать а) альтернативой и б) свободной для MS Office? Разве Edge, использующий движок от Chrome, можно считать "браузером от Microsoft"? Разве опыт мюнхенского "перехода" на линукс и отката обратно ничему не учит других? Разве экономия на лицензиях не может многократно перекрываться расходами на поддержку в т.ч. собственных дистрибутивов вроде "линукс ФСИН" или "линукс французской жандармерии"?
Ситуация вовсе не такая однозначная, как может представляться при поверхностном чтении. Microsoft раньше выигрывала на том, что предлагала разработчиками лучшие инструменты, платформы, SDK, чем конкуренты. Посмотрим, что выйдет сейчас.
Нечеткие цели и требования. Если есть такие задачи, то их отправляем на проработку и исключаем из Backlog. После детальной проработки задача может быть снова помещена в Backlog.
В одной фразе масса неувязок:
постановка задачи выносится за рамки процесса разработки.
и тем самым отрывается от ограничений реализации
где-то там, вне процесса есть супермозг, способный ставить задачи
проработка задачи при разработке "снизу-вверх" хорошо если не наполовину связана с увязыванием других задач в некий общий фреймворк
потому что не только код должен рефакториться, но и фугкциональная архитектура
Многое встает на места, если представлять облако, как глобальный логический "мейнфрейм". У мейнфремов по объективным причинам исторически не сложилось с отвязкой софта от платформы, поэтому до сих пор 50 млрд. финансовых транзакций в день обрабатывается на иерархической СУБД 1968 года выпуска на "железе" того же производителя. Несмотря на круг децентрализации, переходов на открытые системы и клиент-сервер. Пока глобальных "мейнфреймов" несколько, они старательно делят рынок, огораживая своих клиентов, посмотрим, во что это выльется.
Автору благодарность за понимание, переводчику — за труд. «Масала» на русский, видимо, лучше переводить как «солянка» или «винегрет». Для тех, кто как и я пользовался «до UML-ными» SADT/IDEF, ситуация выглядит неважно.
Подкину по теме "Несеребряные пули или кратко про методы софтостроения"
Предметная область (Domain) – это то, что делает организация, и среда, в которой она это делает.
Это шутка, я надеюсь?
Даже в небольшом производственном предприятии имеются минимум несколько «предметных областей» (снабжение, сбыт, производство, финансы, кадры, менеджмент), оказывающихся, даже при поверхностном рассмотрении, контекстами и областями знаний/деятельности. Предметная область — это бухгалтерский учет, логистика или металлообработка. Программирование, кстати, тоже.
В реализацию квадрата и теста закралась маленькая неточность, которая создает иллюзию «опровержения принципа» и хрупкости механизма наследования реализации.
Итак, квадрат — это прямугольник, у которого стороны равны, тем не менее, код квадрата:
а/ вместо выдачи ошибки почему-то позволяет задавать разные длины сторон и
б/ тайно «под капотом» их меняет, т.е. set несимметричен с get
Тест на непонятных основаниях считает, что:
а/ у прямоугольника set-ы детерминированы (не меняют состояние других элементов) и
б/ не отлавливает ошибку задания длины
А если задать нулевую или отрицательную? А если завтра наледником будет не просто Square, а Square4x4?
Мораль: функция, принимающая наследников базового класса, должна следовать контракту базового класса, а не придумывать свой.
Просьба привести цитату где я предлагаю нечто подобное (хотя это технически несложно и давно реализовано в том же Оракле).
Обсуждаемый концепт реализован во множестве проектов «двухзвенок» с толстым клиентом, причем как концепт он обсуждался лет 20 назад.
Для данной архитектуры специфично то, что ей нужен именно пароль. Не хэш, не токен — только и исключительно пароль, причем пароль от пользователя в БД.
Хмм… Представим себе типовое хранение хешей паролей в БД, проверкой которых занимается соответствующий сервис, напрямую соединяющийся с БД. Пусть длина цепочки передачи пароля до сервиса равна N. Теперь совместим сервис с СУБД. Длина цепочки остается N.
Не забываем учесть необходимую дополнительную авторизацию самого сервиса в СУБД, получаем две цепочки уязвимости вместо одной.
Ваш опыт сомнению не подлежит, но я бы не хотел переходить от обсуждений концептов к их реализациям.
Замечание про дырки в цепочках TLS правильное, но, к сожалению, не специфичное для данной архитектуры. Вопрос неустойчивости SSO несколько субъективный, у меня был позитивный опыт (крупная supply chain система).
Полностью с вами согласен, что масштабирование пары СУБД+СП имеет больше степеней свободы, чем СУБД со встроенным СП. Но как выше уже заметили, клиенту нужны не степени, а «чтобы работало по надежному сценарию, пусть даже одному».
Разумеется, процедурное расширение SQL может показаться менее подходящим языком реализации бизнес-логики, тут есть и плюсы (встроенный интегрированный SQL, высокая производительность связанного с СУБД кода, отсутствие перегонки данных между процессами), так и минусы (как правило слабая организация модульности, СУБД vendor lock, отсутствие ООП, более сложное тестирование). Это все понятно, остается выбрать баланс соответствия конкретному случаю.
"У нас" - это в конторе, которая делает софт на Дельфи 7 в 2021 году или я неверно понял? Тогда вопрос, скорее, к конторе, почему не используются последние версии 10.х и 11 (вышла несколько недель назад).
Если неважно, что пойдет в эксплуатацию, то можно и так и даже круче с использованием одного m4.
"Ирония - дочь бессилия" (с)
Подход понятен, но возникает вопрос о накладных расходах. В чистом Си в embedded, например, используют предвычисленные таблицы вместо операций целочисленного деления на некратное 2^N, достигая лучшего быстродействия за счет увеличения размера скомпилированного модуля.
Совершенно верно, в комиссонке импортный калькулятор не лежал на прилавке, а продавался "по блату", т.е. как сейчас принято говорить, "людям, обладающим социальным капиталом". Речь идет о крупных городах. У меня сохранился простейший кальк Sanyo CX-8138AN, купленный родственниками в районе 1980 года, цену уже никто не помнит, но больше 100 рублей и меньше 200. До сих пор работает от двух батареек АА.
Это вы про несовместимость PHP 5.x и 7? Или про яваскрипт-фреймворки, меняющиеся раз в полгода и поэтому по статистике не обновляющиеся на 85% сайтов? Или про отваливающиеся каждый раз плагины в Thunderbird после обновления программы? Может быть Ява поддерживается бесплатно для предыдущих версий фреймворка? А как с качеством документации, есть что-то отдаленно похожее на MSDN?
Поддерживать обратную совместимость, предыдущие версии и документацию - дорогое занятие, за пределами спонсируемого корпорациями ядра линукс такое мало кто может себе позволить. Более того, багфиксы в опенсурсе поддерживаются по принципу "скачай новую версию, она же бесплатная".
Новому айфону соответствовал, скорее, привезенный из загранки или купленный в коммиссионке простой японский калькулятор. А 250 рублей - цена ч/б телевизора.
Заглянул в список доступного софта на простом хостинге. Вот что можно развернуть на сайте из раздела ERP :) Разумеется, без поддержки, настройки, доработки все эти изделия клиенту не нужны и даром.
Разве доминированию Windows на десктопах что-то угрожает, чтобы по этой причине Microsoft интегрировала Linux? Причем интегрировала в качестве "Linux-песочницы", а не наоборот, как предрекают евангелисты. И почему именно пример VSCode так важен для этой интеграции? Разве Exchange, а не развитая инфраструктура управления сетями предприятий Active Directory, держит на плаву сервера Windows? Разве тот же гугл-докс можно считать а) альтернативой и б) свободной для MS Office? Разве Edge, использующий движок от Chrome, можно считать "браузером от Microsoft"? Разве опыт мюнхенского "перехода" на линукс и отката обратно ничему не учит других? Разве экономия на лицензиях не может многократно перекрываться расходами на поддержку в т.ч. собственных дистрибутивов вроде "линукс ФСИН" или "линукс французской жандармерии"?
Ситуация вовсе не такая однозначная, как может представляться при поверхностном чтении. Microsoft раньше выигрывала на том, что предлагала разработчиками лучшие инструменты, платформы, SDK, чем конкуренты. Посмотрим, что выйдет сейчас.
В одной фразе масса неувязок:
постановка задачи выносится за рамки процесса разработки.
и тем самым отрывается от ограничений реализации
где-то там, вне процесса есть супермозг, способный ставить задачи
проработка задачи при разработке "снизу-вверх" хорошо если не наполовину связана с увязыванием других задач в некий общий фреймворк
потому что не только код должен рефакториться, но и фугкциональная архитектура
Вспомнилось, как разные WYSIWYG для верстки HTML типа Dreamweaver или FrontPage "лёгким движением руки" разворачивали сайт на серверах.
Многое встает на места, если представлять облако, как глобальный логический "мейнфрейм". У мейнфремов по объективным причинам исторически не сложилось с отвязкой софта от платформы, поэтому до сих пор 50 млрд. финансовых транзакций в день обрабатывается на иерархической СУБД 1968 года выпуска на "железе" того же производителя. Несмотря на круг децентрализации, переходов на открытые системы и клиент-сервер. Пока глобальных "мейнфреймов" несколько, они старательно делят рынок, огораживая своих клиентов, посмотрим, во что это выльется.
Не совсем ясно, создание стены из кусочков - это microservices to monolith?
Подкину по теме "Несеребряные пули или кратко про методы софтостроения"
Это шутка, я надеюсь?
Даже в небольшом производственном предприятии имеются минимум несколько «предметных областей» (снабжение, сбыт, производство, финансы, кадры, менеджмент), оказывающихся, даже при поверхностном рассмотрении, контекстами и областями знаний/деятельности. Предметная область — это бухгалтерский учет, логистика или металлообработка. Программирование, кстати, тоже.
Итак, квадрат — это прямугольник, у которого стороны равны, тем не менее, код квадрата:
а/ вместо выдачи ошибки почему-то позволяет задавать разные длины сторон и
б/ тайно «под капотом» их меняет, т.е. set несимметричен с get
Тест на непонятных основаниях считает, что:
а/ у прямоугольника set-ы детерминированы (не меняют состояние других элементов) и
б/ не отлавливает ошибку задания длины
А если задать нулевую или отрицательную? А если завтра наледником будет не просто Square, а Square4x4?
Мораль: функция, принимающая наследников базового класса, должна следовать контракту базового класса, а не придумывать свой.
Обсуждаемый концепт реализован во множестве проектов «двухзвенок» с толстым клиентом, причем как концепт он обсуждался лет 20 назад.
Хмм… Представим себе типовое хранение хешей паролей в БД, проверкой которых занимается соответствующий сервис, напрямую соединяющийся с БД. Пусть длина цепочки передачи пароля до сервиса равна N. Теперь совместим сервис с СУБД. Длина цепочки остается N.
Не забываем учесть необходимую дополнительную авторизацию самого сервиса в СУБД, получаем две цепочки уязвимости вместо одной.
Ваш опыт сомнению не подлежит, но я бы не хотел переходить от обсуждений концептов к их реализациям.
Полностью с вами согласен, что масштабирование пары СУБД+СП имеет больше степеней свободы, чем СУБД со встроенным СП. Но как выше уже заметили, клиенту нужны не степени, а «чтобы работало по надежному сценарию, пусть даже одному».
Разумеется, процедурное расширение SQL может показаться менее подходящим языком реализации бизнес-логики, тут есть и плюсы (встроенный интегрированный SQL, высокая производительность связанного с СУБД кода, отсутствие перегонки данных между процессами), так и минусы (как правило слабая организация модульности, СУБД vendor lock, отсутствие ООП, более сложное тестирование). Это все понятно, остается выбрать баланс соответствия конкретному случаю.