тут явная подмена декларируемой и реальной целей. люди хотят писать на Rust, он им нравится ) но они не могут написать "вот мы решили написать свое ядро на Rust, потому что Rust выбросили из ядра", это же никому кроме них самих интересно не будет )
то что безопасность не сводится к безопасному управлению памятью, и в целом к использованию везде паттерна RII, они скромно умалчивают, хотя, конечно могут и добросовестно заблуждаться...
>> Я надеюсь что и правда все понятно, потому что из текста не могу считать сарказм это или нет :) Лучше уточнить
Нет, все и правда понятно. Спасибо за ссылку.
>> Вы сейчас описываете аналитический сценарий.
Ну почему же "аналитический" , вот возьмем eCom, есть роль кастомера и его заказы, и есть роль менеджера который обрабатывает заказы. Предположим заказы шардированы по регионам (как я писал выше на самый идеальный выбор, но тут идеального вообще не может быть) и у пользователя в профиле выбран какой-то регион. Значит для отображения списка его заказов вы всегда знаете ключ шардирования, но вот для менеджера магазина который обрабатывает заказы (не анализирует а именно что-то с ними делает, то есть это именно OLTP) и которому нужно отобразить ленту заказов отсортированных по дате (последние выше) ключ шардирования по региону вообще не подходит потому ему нужно видеть заказы сделанные в любом регионе. Не согласны?
1) Ммм, ... Шаг 1 - поделить общую схему БД на логически замкнутые подсхемы (нет запросов в join-ами) выходящими за подмножесто таблиц входящих в подсхему. (И да потребуется легкая доработка Data access layer в приложении), в общем выполнить то что иначе называется вертикальным партиционированием. Очень часто этого шага уже хватает и вы можете использовать паралельно два / три HA кластера серверов СУБД
Шаг 2 - если после шага 1 все еще остались таблички которые с трудом ворочаются имеющимися в наличии серверами БД, выполнить шардинг (или горизонтальное партиционирование) поделить тяжелые таблички (со своим чайлд табличками) по серверам таким образом что данные одного типа (например заказы) хранятся сразу на нескольких серверах каждый из которых является мастером и хранит данные в единственном экземпляре (на другие мастера не реплицируется). И вот тут да, доработки DAL чуть чуть посложнее и возникает идея про прокси. Отсюда растут Azure SQL, Greenplum, Citus, MySQL Proxy ну и все что возникло позже включая видимо и SPQR) Проблема в том что очень часто на шаге #1 можно остановится и/или на шаге 2 выбрать какой-то NoSQL (Mango, Cassanra)
2) Все понятно
3) Может ведь быть (и часто бывает) что природа запроса такова что данные невозможно отнести к какому-то шарду. Например у вас есть сущность "Заказы" и вы выбрали ключ шардирования - "регион" (сомнительный выбор, но допустим) и вам (по бизнес требованиям) нужно найти все заказы за последние 5 минут с сортировкой по дате и пейджингом. Очевидно чтобы это сделать потребуется сходить во все шарды получить заказы за последние 5 минут, обьеденить в общий список, заново отсортировав его по дате, вырезать из него заказанную страницу и вернуть на фронт; Помогает ли SPQR решать такую задачу?
Если вы смотрите на это именно так то выбирать разумеется нужно надежные и прибыльные профессии ) для разработчиков это не только профессия но и увлечение, а для увлечения чем не пожертвуешь
Я бы суммировал прочитанное так: у компаний в условиях кризиса снизился горизонт планирования и они пытаются решать только проблемы которые возникают здесь и сейчас. Сейчас нет ресурсов чтобы заниматься RnD (учить джунов ) и это в перспективе 2-3 лет снова приведет к недоступности квалифицированных ресурсов для внутреннего рынка труда.
На моей памяти это было уже три раза (((
ЗЫ : Только скорее всего яма будет в это раз побольше, из за разрушения текущих завышенных ожиданий от ИИ.
Если суммировать смысл статьи, то остается только преимущество по стоимости и оно действительно есть, даже с учетом использования платной версии PostgreSQL Pro.
Вроде получается что статья не совсем техническая? )
P.S. И честно говоря хранения в колонках JSON / BSON и всякого другого текста содержащего частично структурированные данные - это разумеется анти-паттерн, особенно в PostgreSQL из за особенностей его реализации (https://www.postgresql.org/docs/current/storage-toast.html)
Легко понять что преждевременная оптимизация приводит к таким же результатам как отсутствие оптимизации, для этого достаточно вспомнить что ресурсы используемые для создания программы всегда ограниченны.
Начали оптимизировать до того как поняли где же находятся ботлнеки системы — потратили время бесполезно. Пришло время релиза и откладывать уже ничего нельзя, система выходит как есть.
Речь не о том чтобы модифицировать стандартный класс или дописывать в него метод, а о том что необязательно составлять название метода из 9 слов, чтобы сделать его информативным.
Эмм… все перечисленное безусловно про деньги. То что это не про деньги Вас могут лечить добрые дяди с толстыми кошельками которые «от души» вынимают малую копеечку из своего кошелёчка и подают Вам на пропитание пока вы занимаетесь тем что Вам нравится. А вот когда из Вашего проекта что-то получится, ну может не из вашего а из проекта вашего товарища вот тогда они с удовольствием на этом проекте заработают денежку, причём так что Вы лично будете думать что осчастливили человечество.
Это всего лишь означает что у StreamReader неудачное API.
А то что в документации не слова про неявную функциональность как раз доказывает то что наличие документации и комментариев не обязательно делает код понятнее.
Как написано у Роберта Мартина в Clean code, ошибка может быть как в коде так и в комментариях.
Причём при исправлении бага или при добавлении новых функций комментарий может остаться не исправленным или не дополненным как видимо подучилось с методом Peek()
Вообще то что хороший код не нуждается в комментариях это цитирование одного из тезисов из книжки Clean code за авторством Robert Martin человека весьма уважаемого и без всякого сомнения зрелого.
По моему, проекты это прежде всего про людей и только во вторую очередь про технические сложности.
Если проект становится не успешным, это не потому что команда встретилась с технической сложностью. Но различное понимание ключевыми стэйкхоледами функциональности будущей системы вполне может к этому привести. Перфекционизм и стремление разработчиков сделать все по правилам может значительно отложить запуск. Карьерные амбиции вновь назначенного менеджера проекта могут привести к тому что ничего не будет готово даже за втрое больший срок.
Стремление молодого и талантливого архитектора опробовать новые модные технологии может привести к неожиданно резкому увеличению бюджета вместо ожидаемой экономии.
Тихий саботаж со стороны сотрудников которых планируется уволить после запуска системы, и которых кто-то додумался включить в проектную команду, может привести к тому система вообще никогда не будет запущена.
В целом практики аджайл преследуют ровно две цели обьединить участников проекта общей целью и жестко контролировать расходы (на выходе из каждой итерации всегда есть шанс бросить вкладывать деньги в гнилое дело).
Интересно Zabbix каким именно критериям Gartner не отвечает?
Мне лично чаще всего приходилось сталкиваться в поддержке именно с ним, если у конечно у заказчика не было лишних пары мегабаксов на Dynatrace )
А происходит это… нечасто.
«Преимущество Vim» в статье не перечислены ) На мой вкус они следующие:
— это редактор который работает в текстовой консоли через ssh)
— Им действительно можно пользоваться когда у вас плохая связь с удаленным узлом где вы пытаетесь поправить конфигурационный файлик или посмотреть логи) все вот эти странные команды: типа перейти на 5 слов вперёд или на четыре строки вниз — помогают )
— VIMом можно открыть на редактирование текстовый файлик размером 1Gb )
… откровенно говоря не знаю чем ещё можно.
Конечно команды VIM это суровое легаси, но просто дизайн и идеология в нем от VI который в свою очередь задумывался во времена зелёных терминалов и тогда видеть на экране текст который ты редактируешь это было высшим достижением человеческой мысли)
Тогда VI конкурировал по юзаблити с перфокартами)
Нет, в данном случае именно принцип «платите за то что используете». У разработчиков C++ были такие понятия что инициализация занимает время и жрет ресурсы. Зачем вам инициализация в 0 для всех целых чисел по умолчанию вы ведь наверняка собираетесь присвоить им какие-то другие значения?
Например в Java, которую разрабочики тогда противопоставляли именно C++ сразу же был сделан противоположный выбор)))
Инициализировано всегда и все)))
Второй выбор, сделанный с той же целью, со сборкой мусора вместо ручного управления памятью более известен публике )
На Lehman brothers слишком много налипло плохих долгов. Зато другие банки вроде Merrill lynch или Bank of America активно спасали. Помню было забавно читать новости в то время, если бы не риск увольнения ))) Колбасило не по детски не толко банки, а вообще всю экономику глобально.
тут явная подмена декларируемой и реальной целей. люди хотят писать на Rust, он им нравится ) но они не могут написать "вот мы решили написать свое ядро на Rust, потому что Rust выбросили из ядра", это же никому кроме них самих интересно не будет )
то что безопасность не сводится к безопасному управлению памятью, и в целом к использованию везде паттерна RII, они скромно умалчивают, хотя, конечно могут и добросовестно заблуждаться...
>> Я надеюсь что и правда все понятно, потому что из текста не могу считать сарказм это или нет :) Лучше уточнить
Нет, все и правда понятно. Спасибо за ссылку.
>> Вы сейчас описываете аналитический сценарий.
Ну почему же "аналитический" , вот возьмем eCom, есть роль кастомера и его заказы, и есть роль менеджера который обрабатывает заказы. Предположим заказы шардированы по регионам (как я писал выше на самый идеальный выбор, но тут идеального вообще не может быть) и у пользователя в профиле выбран какой-то регион. Значит для отображения списка его заказов вы всегда знаете ключ шардирования, но вот для менеджера магазина который обрабатывает заказы (не анализирует а именно что-то с ними делает, то есть это именно OLTP) и которому нужно отобразить ленту заказов отсортированных по дате (последние выше) ключ шардирования по региону вообще не подходит потому ему нужно видеть заказы сделанные в любом регионе. Не согласны?
1) Ммм, ... Шаг 1 - поделить общую схему БД на логически замкнутые подсхемы (нет запросов в join-ами) выходящими за подмножесто таблиц входящих в подсхему. (И да потребуется легкая доработка Data access layer в приложении), в общем выполнить то что иначе называется вертикальным партиционированием. Очень часто этого шага уже хватает и вы можете использовать паралельно два / три HA кластера серверов СУБД
Шаг 2 - если после шага 1 все еще остались таблички которые с трудом ворочаются имеющимися в наличии серверами БД, выполнить шардинг (или горизонтальное партиционирование) поделить тяжелые таблички (со своим чайлд табличками) по серверам таким образом что данные одного типа (например заказы) хранятся сразу на нескольких серверах каждый из которых является мастером и хранит данные в единственном экземпляре (на другие мастера не реплицируется). И вот тут да, доработки DAL чуть чуть посложнее и возникает идея про прокси. Отсюда растут Azure SQL, Greenplum, Citus, MySQL Proxy ну и все что возникло позже включая видимо и SPQR) Проблема в том что очень часто на шаге #1 можно остановится и/или на шаге 2 выбрать какой-то NoSQL (Mango, Cassanra)
2) Все понятно
3) Может ведь быть (и часто бывает) что природа запроса такова что данные невозможно отнести к какому-то шарду. Например у вас есть сущность "Заказы" и вы выбрали ключ шардирования - "регион" (сомнительный выбор, но допустим) и вам (по бизнес требованиям) нужно найти все заказы за последние 5 минут с сортировкой по дате и пейджингом. Очевидно чтобы это сделать потребуется сходить во все шарды получить заказы за последние 5 минут, обьеденить в общий список, заново отсортировав его по дате, вырезать из него заказанную страницу и вернуть на фронт; Помогает ли SPQR решать такую задачу?
1) поясните пожалуйста все же про миграции, как ваше решение их упрощает?
2) как решается задача с lookup таблицам содержимое которых на всех шардах должно быть идентичным?
3) как решается задача с запросами в которых нет ключа шардирования?
Если вы смотрите на это именно так то выбирать разумеется нужно надежные и прибыльные профессии ) для разработчиков это не только профессия но и увлечение, а для увлечения чем не пожертвуешь
Я бы суммировал прочитанное так: у компаний в условиях кризиса снизился горизонт планирования и они пытаются решать только проблемы которые возникают здесь и сейчас. Сейчас нет ресурсов чтобы заниматься RnD (учить джунов ) и это в перспективе 2-3 лет снова приведет к недоступности квалифицированных ресурсов для внутреннего рынка труда.
На моей памяти это было уже три раза (((
ЗЫ : Только скорее всего яма будет в это раз побольше, из за разрушения текущих завышенных ожиданий от ИИ.
Если суммировать смысл статьи, то остается только преимущество по стоимости и оно действительно есть, даже с учетом использования платной версии PostgreSQL Pro.
Вроде получается что статья не совсем техническая? )
P.S. И честно говоря хранения в колонках JSON / BSON и всякого другого текста содержащего частично структурированные данные - это разумеется анти-паттерн, особенно в PostgreSQL из за особенностей его реализации (https://www.postgresql.org/docs/current/storage-toast.html)
Начали оптимизировать до того как поняли где же находятся ботлнеки системы — потратили время бесполезно. Пришло время релиза и откладывать уже ничего нельзя, система выходит как есть.
Хотя в случае С#, как раз есть extension methods…
docs.microsoft.com/ru-ru/dotnet/csharp/programming-guide/classes-and-structs/extension-methods
А то что в документации не слова про неявную функциональность как раз доказывает то что наличие документации и комментариев не обязательно делает код понятнее.
Как написано у Роберта Мартина в Clean code, ошибка может быть как в коде так и в комментариях.
Причём при исправлении бага или при добавлении новых функций комментарий может остаться не исправленным или не дополненным как видимо подучилось с методом Peek()
Если проект становится не успешным, это не потому что команда встретилась с технической сложностью. Но различное понимание ключевыми стэйкхоледами функциональности будущей системы вполне может к этому привести. Перфекционизм и стремление разработчиков сделать все по правилам может значительно отложить запуск. Карьерные амбиции вновь назначенного менеджера проекта могут привести к тому что ничего не будет готово даже за втрое больший срок.
Стремление молодого и талантливого архитектора опробовать новые модные технологии может привести к неожиданно резкому увеличению бюджета вместо ожидаемой экономии.
Тихий саботаж со стороны сотрудников которых планируется уволить после запуска системы, и которых кто-то додумался включить в проектную команду, может привести к тому система вообще никогда не будет запущена.
В целом практики аджайл преследуют ровно две цели обьединить участников проекта общей целью и жестко контролировать расходы (на выходе из каждой итерации всегда есть шанс бросить вкладывать деньги в гнилое дело).
Мне лично чаще всего приходилось сталкиваться в поддержке именно с ним, если у конечно у заказчика не было лишних пары мегабаксов на Dynatrace )
А происходит это… нечасто.
— это редактор который работает в текстовой консоли через ssh)
— Им действительно можно пользоваться когда у вас плохая связь с удаленным узлом где вы пытаетесь поправить конфигурационный файлик или посмотреть логи) все вот эти странные команды: типа перейти на 5 слов вперёд или на четыре строки вниз — помогают )
— VIMом можно открыть на редактирование текстовый файлик размером 1Gb )
… откровенно говоря не знаю чем ещё можно.
Конечно команды VIM это суровое легаси, но просто дизайн и идеология в нем от VI который в свою очередь задумывался во времена зелёных терминалов и тогда видеть на экране текст который ты редактируешь это было высшим достижением человеческой мысли)
Тогда VI конкурировал по юзаблити с перфокартами)
Например в Java, которую разрабочики тогда противопоставляли именно C++ сразу же был сделан противоположный выбор)))
Инициализировано всегда и все)))
Второй выбор, сделанный с той же целью, со сборкой мусора вместо ручного управления памятью более известен публике )