заметим что идеи Цузе повлияли и на послевоенные работы,
Полностью с вами могласен. Например концепт сохранения числа с плавающей запятой, который впоследствии как стандарт IEEE754 принят был - его рук дело. Он был очень гениальным инженером, но немного фортуна обошла его и огромного успеха не имел . Хотя в историю он всё равно вошёл.
Спасибо за статью, хотя всё равно наверное буду считать, что первым создавшим компьютер на базе 0 и 1 был Кондрад Цузе. В 1938 году он закончил свою первую машину. Чтобы её закончить, а делал он её без какой-либо большой поддержки, то начал он её концепцию задолго до 1938 года. Проблемы его заключались в ом, что ни он не особо знал о существовании других, которые работали в этом направлении, ни тем боллее о его существование никто не знал. Только после второй мировой мир узнал, что такой инженер был и что он изобретал.
могли бы Вы написать ссылку на алгоритм Дейкстры который максимально оптимизирован или есть готовая быстрая библиотека на php или golang?
Не совсем понимаю, вы просите ссылку на алгоритм, в тексте указываете на его не-профпригодность...
Я рад представить вам алгоритм, который разработал для решения задачи нахождения кратчайших путей в графе, когда использование алгоритма Дейкстры было неэффективно из-за ограничений по памяти.
вы хорошо пошутили. Первая база данных NoSQL была в конце 90-х создана, NoSQL движение в 2009 пошло в массы. Многие концепты, например в BigData сегодня имеют корни в сетевых базах данных, например как распределённая обработка и сохранение данных, поэтому не стоит ни здесь, ни вообще о победах или поражениях говорить, а исторический подход есть лучшая альтернатива. Успеха вам!
У меня такое ощущение, что вы в историю с соревнованием скомковали лет 20. Сетевые базы данных повились в 50-годах, в 60-х в среде COBOL создались концепты баз данных в виде схем. А в начале 1970-х появились реляционные модели данных, благодаря работам Эдгара Кодда. Кодд ввёл в оборот термин OLAP и написал 12 законов аналитической обработки данных. В его честь названа одна из нормальных форм 1NF. И только в начале 80-х реляционная модель начала входить в моду.
Т.е. вы как-бы литературно в один исторический момент поместили и динозавров и людей. Литературно - можно. Потому чо такие истории всегда возникают на стыке новых технологий, когда создатель новой технологии "доказывает" право на существование и дальнейшее финансирование в его "бэби".
Но вот что бросается в глаза в вашем тексте, так это отсутствие какого-нибудь обьяснения сетевых баз данных. Ведь из двух рисунков ну вообще не понять в чём сложность обслуживания таких систем, и какое упрощение в этом в реляционых базах?
PS. Также интересно, что все создатели как сетевых, схемных, так и реляционных баз данных получили премию Тьюринга.
Каждое движение и каждый выстрел с гео-координатами и со снятым видео с наведения будет скорее всего отправлятся 'домой' в компанию и конечно-же будет 'гарантировано', что данные будут под замком и никогда и никем и ни при каких условиях не будут взломаны...
Вот мне интересно. В принципе использовать 'помощников' в виде chatGPT - никто не запрещает, но ведь надо понимать, что статья - не за три минуты пишется. Где уважение к читателям?
Куча повторений 'масло-масленное' - типичная фишка у chatGPT:
Integrated Architecture Framework (IAF) - это методология для разработки архитектуры предприятия, разработанная компанией Capgemini. IAF является открытым фреймворком, и поэтому может использоваться любой компанией в любой отрасли.
IAF включает в себя набор моделей, методов и инструментов, которые позволяют разработчикам создавать комплексные и эффективные системы.
Описание архитектуры в IAF в целом затрагивает многие аспекты, связанные как с бизнес-процессами организации, так и с деталями технической реализации и моделями данных.
В конце статьи предложения поставлены так, как будто обой описания фраймворка до этого не было..
IAF является комплексной методологией для разработки архитектуры предприятия, которая охватывает весь жизненный цикл системы и помогает создавать комплексные и эффективные системы, которые могут адаптироваться к новым условиям и изменениям в бизнес-требованиях и технологических трендах.
IAF состоит из нескольких ключевых элементов, включая описание бизнес-архитектуры, информационной архитектуры, приложений и технологической архитектуры, а также управление рисками и управление изменениями
Таким образом, IAF является мощным инструментом для разработки архитектуры предприятия, который помогает создавать комплексные и эффективные системы, которые могут адаптироваться к изменяющимся условиям бизнеса и технологии.
Я понимаю что в статье не о фраймворке идёт разговор, а о рекламе курса, но ведь люди по другую сторону монитора тоже ведь не дураки сидят.
Может быстрее наверное, но едет машина скорее всего медленно. Потому что водитель в этот момент более счастливее чем вообще. Поэтому чуточку спокойнее и жалеюче свою только что вымытую красавицу - машину.
Вклад такого человека, который в принципе занимался любимым делом - огромный. У меня был похожий учитель-инженер, который мою жизнь в эту область направил.
Немного хочу затронуть не его вклад, а то как это описано в статье.
Главным отличием Лексикона от языков программирования должна была стать его открытость для других разработчиков. Ему не нужно было транслироваться в машинную программу, но при этом любую машинную программу можно было бы выразить в Лексиконе.
Не совсем понятно, о какой закрылоси других языков программирования идёт речь. Вроде все языки были не по замком. Или в это слово вкладывался другой смысл? И ещё- как что-то написанное не транслировать в машинный код, если ты хочешь, чтобы машина это выполнила?
К сожалению, идея так и осталась идеей. Но Ершов задал направление для других учёных на десятки лет вперёд.
В чем заключалось задавание направления не совсем понятно. Или это выражение для красного словца.
Я понимаю что это перевод, но решение в общем-то сильно ограничивает то, что можно назвать "распределённой системой" -- это всё должно быть внутри одного датацентра,
Так многое, что под распределением понимается в BigData вообще на один шкаф ориентировано. Ведь только так самую маленькую латенц можно получить при передаче данных между отдельными машинами. Во многих фраймворках rack id для кластеров наиважнейшая вещь.
Попытаюсь вначале дать сравнение. Представьте цель - участие в олимпиаде. И под вопросом, кто поедет туда участвовать даётся ответ - спортсмен, хорошо подготовленный, занимающий в секциях, соблюдающий режим еды итд.. Вроде-бы всё правильно, но как-бы это всё - второстепенно. Самое важное, что спортсмен или систем-архитектор - умеет делать то, для чего он нужен - так, чтобы добиться результата. Будет-ли при тренировки красивый стадион или SAFe - думаю важно, но не настолько как первое.
А в статье первое берётся как данность и разговор идёт о втором. В жизни много раз наяву видел реализацию басни Крылова с животными и музыкальными инструментами. Так и с проектами - концентрация шла на методологию, а потом выяснилось, что наархитектовали так, что после 3-5 лет проекта его заменили на новый проект. И самое печальное - те-же самые архитекторы уже под другой методологией 'создавали' следующие шедевры.
Я понимаю, что в рамках такой статьи поднять этот вопрос нелегко. Мне хотелось просто об этом напомнить.
Подход TOGAF, на сегодня - наиболее распространенный подход к реализации и поддержанию архитектуры или архитектур решений в компаниях. Он включает в себя наиболее важные вехи, которые необходимо учитывать при работе над информационными продуктами. Он не требует сильной адаптации. Этап может быть сколь угодно мал, но он обязан быть. Иначе бардак, хаос, размытие ответственности.
Вроде всё правильно, но в последнее время всё больше и больше убеждаюсь, что чем громче кто-то меня пугает хаосом и предлагает против какие-то решения или методологии как например SAFe или SCRUM, то понимаю, что хаоса будет в два раза больше. А затрат раз в пять больше. Но - это моё личное мнение.
Сравниваю программистов одиночек, которые создают успешные и красивые Apps (чаще games or frameworks) с корпоротивными программами и понимаю, что разница как между небом и землёй. В пользу одиночек. А почему? Потому что у них есть возможность, но самое главное желание - вначале продумать, потом только начинать. В корпоративах всегда начинают, в надежде когда-нибудь найти время для обдумывания, но так никогда его и не найдя. И хаос, который они должны были вроде обуздать (потому что ведь у них правильная методология) - переполнил все борта.
Об отсутствии какой-либо ответственности я вообще молчу. Сложные проекты расчитаны на мин.3-5 лет (например миграция soft- или it-инфраструктуры в Cloud). Среднее время между переходами манагеров среднего звена 2-3 года. И какую понесёт отвественность архитектор-манагер, если через какое-то время огрехи в архитектуре начнуть всё больше и больше о себе знать, когда этого манагера уже нет поблизости?
Диаграмму деятельности со спокойной совестью можно поменять на BPMN
Я сам обожаю BPMN, но убеждаюсь, что в большинстве своём - если что и пишется с помощью BPMN, то только в архив. Почти никто с этими диаграммами не работает, а делают их или просто из спортивного интереса, тк. кто-то для себя это открывает в первый раз или для лицензирования ISO 9000 или ISO 9001. И каждый раз, как только приходят аудиторы, то достаются из ящиков диаграммы, которые с реальностью ну вообще ничего не имеют общего уже много лет. Но выглядят они убедительно.
А всё почему? Да потому что один из тезисов агильного манифеста гласит - работающая система стоит выше чем документация о системе.
Те. с Вашими словами я соглащаюсь, но в реальности вижу совсем не то. Надо реальность наверное поменять :)
Есть другая притча, что Бог дал глупцам язык, чтобы они им чушь мололи.
Вы шуток не понимаете? Я вас не обижал, а Вы себе это позволили. У вас что, каждое слово - взвешенная мысль, что меня глупцом, а мою шутку - чушью называете. Сама автор в тексте в полу-шуточной форме спросила "Можно ли намазать уши «Звёздочкой», чтобы перестал болеть зуб?"
Полностью с вами могласен. Например концепт сохранения числа с плавающей запятой, который впоследствии как стандарт IEEE754 принят был - его рук дело. Он был очень гениальным инженером, но немного фортуна обошла его и огромного успеха не имел . Хотя в историю он всё равно вошёл.
Спасибо за статью, хотя всё равно наверное буду считать, что первым создавшим компьютер на базе 0 и 1 был Кондрад Цузе. В 1938 году он закончил свою первую машину. Чтобы её закончить, а делал он её без какой-либо большой поддержки, то начал он её концепцию задолго до 1938 года. Проблемы его заключались в ом, что ни он не особо знал о существовании других, которые работали в этом направлении, ни тем боллее о его существование никто не знал. Только после второй мировой мир узнал, что такой инженер был и что он изобретал.
Думаю, это не только Аэрофлот в силе решать. Ситуация немного поменялась.
Не совсем понимаю, вы просите ссылку на алгоритм, в тексте указываете на его не-профпригодность...
вы хорошо пошутили. Первая база данных NoSQL была в конце 90-х создана, NoSQL движение в 2009 пошло в массы. Многие концепты, например в BigData сегодня имеют корни в сетевых базах данных, например как распределённая обработка и сохранение данных, поэтому не стоит ни здесь, ни вообще о победах или поражениях говорить, а исторический подход есть лучшая альтернатива. Успеха вам!
У меня такое ощущение, что вы в историю с соревнованием скомковали лет 20. Сетевые базы данных повились в 50-годах, в 60-х в среде COBOL создались концепты баз данных в виде схем. А в начале 1970-х появились реляционные модели данных, благодаря работам Эдгара Кодда. Кодд ввёл в оборот термин OLAP и написал 12 законов аналитической обработки данных. В его честь названа одна из нормальных форм 1NF. И только в начале 80-х реляционная модель начала входить в моду.
Т.е. вы как-бы литературно в один исторический момент поместили и динозавров и людей. Литературно - можно. Потому чо такие истории всегда возникают на стыке новых технологий, когда создатель новой технологии "доказывает" право на существование и дальнейшее финансирование в его "бэби".
Но вот что бросается в глаза в вашем тексте, так это отсутствие какого-нибудь обьяснения сетевых баз данных. Ведь из двух рисунков ну вообще не понять в чём сложность обслуживания таких систем, и какое упрощение в этом в реляционых базах?
PS. Также интересно, что все создатели как сетевых, схемных, так и реляционных баз данных получили премию Тьюринга.
Выживает
сильнейшийинформированый - дополнительный критерий в современной эволюции человека.Конкуренция - двигатель прогресса. Нет конкуренции - не будет и прогресса. Затишье - да, застой - да, но не прогресс. И ваши доводы не работают.
Думаю и камасутра не помешает. Ведь размножаться придётся сильнее чем обычно, а для этого желание, опыт и техника никогда лишними не будут ?
Каждое движение и каждый выстрел с гео-координатами и со снятым видео с наведения будет скорее всего отправлятся 'домой' в компанию и конечно-же будет 'гарантировано', что данные будут под замком и никогда и никем и ни при каких условиях не будут взломаны...
Не буду спорить, просто и начало статьи и подача информации оставляют много открытых вопросов. Особенно меня удивило ваше выражение
Те. все остальные фраймворки так снбе, а вот ЭТОТ - решение всех-привсех проблем...
Вот мне интересно. В принципе использовать 'помощников' в виде chatGPT - никто не запрещает, но ведь надо понимать, что статья - не за три минуты пишется. Где уважение к читателям?
Куча повторений 'масло-масленное' - типичная фишка у chatGPT:
В конце статьи предложения поставлены так, как будто обой описания фраймворка до этого не было..
Я понимаю что в статье не о фраймворке идёт разговор, а о рекламе курса, но ведь люди по другую сторону монитора тоже ведь не дураки сидят.
Может быстрее наверное, но едет машина скорее всего медленно. Потому что водитель в этот момент более счастливее чем вообще. Поэтому чуточку спокойнее и жалеюче свою только что вымытую красавицу - машину.
Вклад такого человека, который в принципе занимался любимым делом - огромный. У меня был похожий учитель-инженер, который мою жизнь в эту область направил.
Немного хочу затронуть не его вклад, а то как это описано в статье.
Не совсем понятно, о какой закрылоси других языков программирования идёт речь. Вроде все языки были не по замком. Или в это слово вкладывался другой смысл? И ещё- как что-то написанное не транслировать в машинный код, если ты хочешь, чтобы машина это выполнила?
В чем заключалось задавание направления не совсем понятно. Или это выражение для красного словца.
Так многое, что под распределением понимается в BigData вообще на один шкаф ориентировано. Ведь только так самую маленькую латенц можно получить при передаче данных между отдельными машинами. Во многих фраймворках rack id для кластеров наиважнейшая вещь.
Не могу ни плюсовать ни минусовать, использую свой один-часовой комментарий как оценку Вашим словам - соглашусь с Вами полностью!
Перечитал вновь и появился доп. вопрос к теме
Попытаюсь вначале дать сравнение. Представьте цель - участие в олимпиаде. И под вопросом, кто поедет туда участвовать даётся ответ - спортсмен, хорошо подготовленный, занимающий в секциях, соблюдающий режим еды итд.. Вроде-бы всё правильно, но как-бы это всё - второстепенно. Самое важное, что спортсмен или систем-архитектор - умеет делать то, для чего он нужен - так, чтобы добиться результата. Будет-ли при тренировки красивый стадион или SAFe - думаю важно, но не настолько как первое.
А в статье первое берётся как данность и разговор идёт о втором. В жизни много раз наяву видел реализацию басни Крылова с животными и музыкальными инструментами. Так и с проектами - концентрация шла на методологию, а потом выяснилось, что наархитектовали так, что после 3-5 лет проекта его заменили на новый проект. И самое печальное - те-же самые архитекторы уже под другой методологией 'создавали' следующие шедевры.
Я понимаю, что в рамках такой статьи поднять этот вопрос нелегко. Мне хотелось просто об этом напомнить.
Вроде всё правильно, но в последнее время всё больше и больше убеждаюсь, что чем громче кто-то меня пугает хаосом и предлагает против какие-то решения или методологии как например SAFe или SCRUM, то понимаю, что хаоса будет в два раза больше. А затрат раз в пять больше. Но - это моё личное мнение.
Сравниваю программистов одиночек, которые создают успешные и красивые Apps (чаще games or frameworks) с корпоротивными программами и понимаю, что разница как между небом и землёй. В пользу одиночек. А почему? Потому что у них есть возможность, но самое главное желание - вначале продумать, потом только начинать. В корпоративах всегда начинают, в надежде когда-нибудь найти время для обдумывания, но так никогда его и не найдя. И хаос, который они должны были вроде обуздать (потому что ведь у них правильная методология) - переполнил все борта.
Об отсутствии какой-либо ответственности я вообще молчу. Сложные проекты расчитаны на мин.3-5 лет (например миграция soft- или it-инфраструктуры в Cloud). Среднее время между переходами манагеров среднего звена 2-3 года. И какую понесёт отвественность архитектор-манагер, если через какое-то время огрехи в архитектуре начнуть всё больше и больше о себе знать, когда этого манагера уже нет поблизости?
Я сам обожаю BPMN, но убеждаюсь, что в большинстве своём - если что и пишется с помощью BPMN, то только в архив. Почти никто с этими диаграммами не работает, а делают их или просто из спортивного интереса, тк. кто-то для себя это открывает в первый раз или для лицензирования ISO 9000 или ISO 9001. И каждый раз, как только приходят аудиторы, то достаются из ящиков диаграммы, которые с реальностью ну вообще ничего не имеют общего уже много лет. Но выглядят они убедительно.
А всё почему? Да потому что один из тезисов агильного манифеста гласит - работающая система стоит выше чем документация о системе.
Те. с Вашими словами я соглащаюсь, но в реальности вижу совсем не то. Надо реальность наверное поменять :)
Вы шуток не понимаете? Я вас не обижал, а Вы себе это позволили. У вас что, каждое слово - взвешенная мысль, что меня глупцом, а мою шутку - чушью называете. Сама автор в тексте в полу-шуточной форме спросила "Можно ли намазать уши «Звёздочкой», чтобы перестал болеть зуб?"
Есть такая притча, что Бог дал роженицам боли, чтобы они хоть малую часть того почувствовали, что испытывает мужчина, когда у него насморк.