При восходящей разработке (аджайлы — это bottom-up), функции добавляются инкрементально. После десятков итераций получается каша из взаимозависимостей, по-хорошему требующая работы предметных аналитиков по реструктуризации. Хотя, конечно, всегда есть опция «оставить как есть и жить с этим».
Т.е. по сути у вас 10-звенная система. Неужели нигде «не жмёт туфля» в плане производительности?
Обычные сервисы реализуют не строго одну «автономную» функцию (см.выше про кашу), а несколько тесно связанных (интегрированных), тем самым избавляя их от необходимости медленно взаимодействовать по сети.
Как решается вопрос функциональных зависимостей?
Сколько слоев из (микро)сервисов получется на данный момент?
Какова стоимость развертывания и управления зависимостями по сравнению с обычными сервисами?
Во «Многоруком боге далайна» финал, когда весь далайн трансформирован, похож на описанное превращение аналитика в overqualified «шамана». Перейдет ли он в итоге на «темную» сторону заказчика?
АЛМО все же не язык высокого уровня, а ассемблер для абстрактной машины. У американцев аналогичный проект Unicol в 1960-х не пошел, зато сейчас все это работает под брендом .NET в виде языка IL.
До семейства ПП-х уже существовал предтеча Фортрана — Speedcoding (примерно 1953 год) и даже Shortcode (примерно 1950).
При всем уважении к отечественным основоположникам, но теории грамматик (Хомский) и построения трансляторов (публикации в ACM, у нас распространились статьи Д.Гриса) тоже разрабатывались в США.
Эту по-настоящему крупную сумму вы платите людям за то, чтобы они просто присматривали за вашим программным обеспечением.
То есть, ДБА — это те, кто делает бэкапы?
Каким образом автономная СУБД будет исправлять плохое проектирование и запросы — основной источник головной боли?
Да, у меня уровень расчитан скорее на «ниже среднего» чтобы поднять до условно «среднего». Клеппман, похоже, расчитывает на «средний» --> «выше среднего». Обширная библиография, конечно — кладезь для исследований. В частности, вменяемой классификации моделей данных я не нашел (в классике их три: иерархическая, сетевая и реляционная), поэтому пришлось составлять свою (она есть во втором издании и на researchgate). Возможно кто-то из исследователей по ссылкам тоже озаботился темой.
Спасибо, судя по рецензии, книга тесно перекликается с "Programming with databases" (она же "СУБД для программиста" в первой редакции), но в DDIA больше рассказано о нереляционных подходах. Обязательно возьму на заметку.
Я все больше склоняюсь, что тимлид — лидер неформальный, как капитан команды в спорте. Руководитель группы — формальная должность, не всегда совпадающая с неформальным лидером.
Вроде бы «команда» пришла из спорта для замены «рабочей группы» в связи с затертостью и забюрокраченностью термина или нет? Я понимаю разницу между рабочей и проектными группами, а вот между группой и командой — не вполне.
Выводы интересные, непрофессионалу в ИИ вроде меня доступные, спасибо.
Большие данные на самом деле — начало 1980-х (см. VLDB), СУБД «Терадата» оттуда родом и до сих пор хорошо себя чувствует. Тогда же стартовал Пролог, компы 5-го поколения и прочая «вкалывают роботы — счастлив человек».
Что если провести аналогии с подьемом темы 40-летней давности?
"С К. Шенноном связана одна из самых удивительных историй в моей жизни. Меня с ним познакомили в 1980 году на чемпионате мира среди шахматных программ в Линце. Каждый чемпионат имеет своего почетного гостя, и в том году им был Клод. Услышав его имя, я подумал «Как! Он еще жив?». Ведь работы Шеннона по шахматному программированию относились к году моего рождения, то есть для меня он существовал в очень давней перспективе. Оказалось, что ему в год моего рождения было меньше тридцати, и в 1980м он был еще очень не старым человеком. Когда же пришла моя очередь быть почетным гостем чемпионата мира 1999 года в Падерборне, я прочел в глазах молодых шахматных программистов все тот же немой вопрос «Как! Он еще жив?». И, поняв, что с момента моих публикаций уже прошло больше двадцати лет, я вспомнил Шеннона и успокоился."
М.Донской, из статьи «Жизненный цикл программиста»
Метод серверных курсоров также описан в книге "СУБД для программиста" в сравнении с другими способами пакетного извлечения данных из больших таблиц (глава «Постраничые выборки»).
Т.е. по сути у вас 10-звенная система. Неужели нигде «не жмёт туфля» в плане производительности?
Обычные сервисы реализуют не строго одну «автономную» функцию (см.выше про кашу), а несколько тесно связанных (интегрированных), тем самым избавляя их от необходимости медленно взаимодействовать по сети.
Сколько слоев из (микро)сервисов получется на данный момент?
Какова стоимость развертывания и управления зависимостями по сравнению с обычными сервисами?
При всем уважении к отечественным основоположникам, но теории грамматик (Хомский) и построения трансляторов (публикации в ACM, у нас распространились статьи Д.Гриса) тоже разрабатывались в США.
То есть, ДБА — это те, кто делает бэкапы?
Каким образом автономная СУБД будет исправлять плохое проектирование и запросы — основной источник головной боли?
Также не хватает формального определения интеллекта.
Большие данные на самом деле — начало 1980-х (см. VLDB), СУБД «Терадата» оттуда родом и до сих пор хорошо себя чувствует. Тогда же стартовал Пролог, компы 5-го поколения и прочая «вкалывают роботы — счастлив человек».
Что если провести аналогии с подьемом темы 40-летней давности?
М.Донской, из статьи «Жизненный цикл программиста»