5. Дарон Аджемоглу, Джим Робинсон «Почему одни страны богатые, а другие бедные»
по-моему эта книга — не более чем мнение, а вовсе не стройная экономическая теория. Реальный ответ почему например британцы стали столь успешны в своё время не может дать никто.
Если бы инвестировать «в сумме» было невыгодно, то никто бы этим не занимался и биржы бы давно позакрывались
вы повторяетесь. Я уже сказал что я этого не отрицаю. Я говорю о том что имеет значение соотношение затрат и прибыли. Иначе можно по инерции говорить о том что всё классно даже уже находясь в мыльном пузыре.
А рекламу кто у них заказывает? И зачем? :)
давайте-ка без снисходительных улыбок. Реклама работает и активно используется не потому что она очень необходима промышленности. Вернее не только потому. У этого есть вторая (или может быть первая?), куда более прозаическая причина. Достаточно посмотреть на хомячков, которые фоткают на выставке подставку от Эпла за конские деньги. И уж точно реклама — это не «автоматизация промышленности». ПО для управления предприятиями, бухучета, управления цепочками поставок и контейнерами — это автоматизация, да
ИТ — это часть постиндустриальной экономики. И основная ниша ИТ — это сфера обслуживания и интертейнмента, а не промышленность.
Но грубо говоря для того чтобы выиграть в лотерее нужно купить как минимум один лотерейный билет. И точно так же и с инвестициями: если не инвестируешь, то и не заработаешь.
я этого и не отрицал, а какраз попросил сравнить сколько денег вкладывается и сколько получается. Это как минимум корректно — упоминать о затратах.
Также почему-то когда идёт обоснование полезности ИТ отрасли, говорят прежде всего о какой-то автоматизации промышленности. При этом ни Фейсбук ни Гугл не особенно связаны с промышленностью — доход этих компаний основан на рекламе.
Короче говоря, при том что я сам программист, меня достал этот самольстивый пафос о том что мы какие-то уникальные и пуп земли. Это не так. И причина проста — 90% самозащитных механизмов психики основаны на самообмане. Нам всем очень приятно врать себе что мы якобы очень полезны и гораздо полезнее тех же врачей. youtu.be/G65AUOLfGzg?t=22
Венчурный капитализм ничего не просирает. Все очень даже посчитано: один найденный фейсбук отбивает 100 сгоревших стартапов.
тот факт что статистический баланс положительный, не отменяет факта что эти деньги были потрачены впустую. И они могли быть потрачены на что-то другое. Если я потерял 100 баксов, но нашел на дороге 200, факт находки не отменяет факта потери.
Утрируя, человек, который пишет программы позволяющие экономить на ФОТ сотни миллионов тугриков или минимизирующий ошибки на предприятии, суммарный эффект от которых сравним с миллионными значениям вправе претендовать на з/п в рублях сотни тысяч рублей
может тогда стоит ещё сравнить с миллионами долларов которые просирают каждый год стартапы? 90% которых в итоге провалятся
Да, но тут скорее что бы заставить из коробки работать gRPC нужно потратить больше времени и сил
ну может обычно выходит что замеряется сколько времени потратит человек у которого уже есть опыт в REST но нет опыта в rRPC?
насколько я знаю, уже есть curl для gRPC, postman, и расширения для браузера для облегчения отладки с gRPC. А у Гугла кажется и лоад балансеры уже могут в gRPC. Основная проблема с gRPC мне кажется именно в повседневной рутине — написал rpc вызов, потом надо затестить, отладиться. И вот это вероятно удобнее в REST.
Но.
1) те же строгие контракты из коробки — великое дело. То что энфорсится на проектах бест-практиками, соглашениями, гайдлайнами — очень часто не работает. Попробуйте например обеспечить единый codestyle форматирования на 10 разных команд. И попробуйте нарушить форматирования если gofmt сразу даст по рукам. Большая разница. Тоже самое про контракты апи и их проверку.
2) Тоже самое по части обработки ошибок — частая ситуация когда микросервис получает 500 Error «что-то пошло не так», и не может дальше решить что с этим делать — http статусы малополезны для обработки ошибок, потому что для 500ки может быть просто ворох различных ошибок бизнес-логики, и это можно отразить только в теле запроса каким-то выработанным стандартом обработки ошибок. Опять таки, да, можно сделать библиотеки и тд. но нужно ещё заэнфорсить это по всей компании. Если же обработка ошибок органично ложится на структуру обмена сразу — это намного лучше.
3) обработка таймаутов. Ошибки в конфигурации таймаутов — частое явление. Итого выходит что вы даёте POST запрос, который добавляет сущность, и получаете скажем 503, но на деле он выполнился, просто один сервис в цепочке имел допустимый таймаут обработки запроса ниже чем следующий
4) как отменить запрос в REST? Сделать компенсирующий? Например истёк дедлайн на обработку запроса, и значит нужно обезопаситься от ситуации когда этот запрос всё-таки будет успешно обработан, а мы собираемся вернуть клиенту ошибку. В gRPC отмена запросов есть сразу как встроенный механизм
По словам Руана Фернандо, внедрение простой службы gRPC занимает около 45 минут. Реализация веб-API или REST API занимает всего около 10 минут
это мне кажется некорректное сравнение — примерно как сравнивать языки программированию по эффективности написать Hello World. Тут не учитывается стоимость и потраченное время на поддержку и изменение. В REST с точки зрения использования есть проблемы с обработкой ошибок, таймаутов, отмены запросов, нет валидации контрактов из коробки. И сверху всего этого — нередко REST api является по факту грязной реализацией RPC
я вижу только один плюс REST — текущая поддержка инструментов и легкость создания. Но вот лучше ли это в поддержке и эволюции — вот тут сомневаюсь.
а почему вы не пломбируете себе зубы сами? Не можете разобраться в этом? Лень? А почему вы не выращиваете пшеницу самостоятельно, потом делаете из неё муку, а потом печёте хлеб сами? Тоже лень? )
лень — это двигатель прогресса. Те кому не лень, мыслят обычно непрактично сложно.
Воткнуть внешний диск по USB? Есть готовые решения от Synology, QNAP и прочих.
как это работает? Нужно купить несколько дисков (для избыточности), и потом вручную периодически перегонять данные на них? Ну как максимум наверное есть готовое ПО от вендоров для синхронизации. Но придётся повторить операцию для нескольких дисков.
Бекапы сейчас делать очень просто. Есть куча удобного софта, всё легко и просто масштабируется. Даже если нужно поставить сотню дисков, то б/у серверы и дисковые полки стоят копейки (полки на 15 дисков покупал по 2 тыс. руб., даже сейчас сервер или полку на 12-15 дисков можно найти за 4..12 тыс.), есть ящики от Supermicro, куда можно запихать тихие вентиляторы, БП от seasonic и иметь дома компактное тихое хранилище приличного объёма. Для мелких частных хранилищ на десяток-другой терабайт вообще достаточно десктопа и 2-4 диска в zmirror. Сами диски, конечно, подорожали, это печально. Остаться без значимых данных тоже печально. Даже одна «лишняя» offline-копия на дешёвом диске лучше её отсутствия.
конечно легко и просто. Каждый фотограф или домохозяйка с этим легко справятся. Купят полки, сотню дисков, бу серверы. Им-то всё-равно скучно и нечем заняться
(Промахнулись веткой) Это, кстати, вариант идеальный. Для пользователя — скорость и комфорт локальных данных + сохранность ценных (да хоть выборочно, по фильтру), а для компании — плавный переход на SaaS.
А минусовать того не надо, дело говорит. Только настроить всё это дело — отдельная песня.
не минусую. Но эти мысли похожи на удивление фермера о том почему каждый не может держать козу и получать с неё молоко вместо того чтобы ходить в супермаркет. Если это фэйл WD то как-то неправильно говорить «виноват ты, юзер, потому что не сделал бэкап т.к. диск мог бы вообще посыпаться». Вот если бы он посыпался — тогда ок. Но он не посыпался, его запорол сам WD
хм, я опять веткой не туда. Вроде нажимал «ответить»
Если у тебя 80,000 дорогих тебе фото находятся лишь на одном девайсе, который и без хакерской атаки может сам по себе кирдыкнуться, то что-то не так с твоей бекап стратегией. Особенно, во времена дешевых облаков.
ну может тогда WD пора предоставлять синхронизацию с облаком для надёжности. Пусть даже за доп. плату как опцию. Многие пользователи не очень опытны чтоб настраивать бэкапы.
забавно. Что-то мне это напоминает) Я общался с ними однажды и понял что там нечего ловить т.к. там дали много полномочий совсем юнцам
вполне закономерный итог. Поставили у руля детей — получите-распишитесь.
т.е. вам лень загуглить и подтвердить собственные слова, а я должен вам что-то тут рассказывать? Назвался груздем — полезай в ящик. Не я утверждал что есть якобы валом возможностей, и надо просто стараться и всё будет.
Без призывов гуглить — дайте, пожалуйста, пример из медицины, как человек старался, переехал из маленького города в большой, поменял специализацию, сменил несколько клиник, в итоге — устроился в платную клинику пластическим хирургом (или стоматологом), но почему у него всё равно з/п низкая
что сложного в том чтобы понять что если хороших оплачиваемых зарплат в отрасли только жалкий процент, то эти конкретные примеры личных историй ничего не дадут? Вы в состоянии понять что в отрасли не может быть 90% аутсайдеров и неудачников? 10% — ладно, 20% — тоже ладно. Но 90% — это как? Вы сейчас требуете предоставить какие-то «неуспешные кейсны» с обоснованием. Но тут нечего обосновывать. Просто пойдите и посмотрите на статистику. Если есть только 3 нормально оплачиваемых работы из 100, то сказать что эти 97 человек — просто жалкие неудачники — это же бред.
но почему у него всё равно з/п низкая
потому что во всей отрасли низкие зп, очевидно же.
Со своей стороны я выложился
нет. Не было предоставлено никаких доказательств. Не было приведено ни одного доказательства что проблемных отраслях типа медицины якобы есть море возможностей и масса ленивых людей. Сплошные голословные заявления, самовосхваления и фантазии.
я-то думал что проблема в том что кассир в Москве получает мало ) А оно вона как…
по-моему эта книга — не более чем мнение, а вовсе не стройная экономическая теория. Реальный ответ почему например британцы стали столь успешны в своё время не может дать никто.
вы повторяетесь. Я уже сказал что я этого не отрицаю. Я говорю о том что имеет значение соотношение затрат и прибыли. Иначе можно по инерции говорить о том что всё классно даже уже находясь в мыльном пузыре.
давайте-ка без снисходительных улыбок. Реклама работает и активно используется не потому что она очень необходима промышленности. Вернее не только потому. У этого есть вторая (или может быть первая?), куда более прозаическая причина. Достаточно посмотреть на хомячков, которые фоткают на выставке подставку от Эпла за конские деньги. И уж точно реклама — это не «автоматизация промышленности». ПО для управления предприятиями, бухучета, управления цепочками поставок и контейнерами — это автоматизация, да
ИТ — это часть постиндустриальной экономики. И основная ниша ИТ — это сфера обслуживания и интертейнмента, а не промышленность.
я этого и не отрицал, а какраз попросил сравнить сколько денег вкладывается и сколько получается. Это как минимум корректно — упоминать о затратах.
Также почему-то когда идёт обоснование полезности ИТ отрасли, говорят прежде всего о какой-то автоматизации промышленности. При этом ни Фейсбук ни Гугл не особенно связаны с промышленностью — доход этих компаний основан на рекламе.
Короче говоря, при том что я сам программист, меня достал этот самольстивый пафос о том что мы какие-то уникальные и пуп земли. Это не так. И причина проста — 90% самозащитных механизмов психики основаны на самообмане. Нам всем очень приятно врать себе что мы якобы очень полезны и гораздо полезнее тех же врачей.
youtu.be/G65AUOLfGzg?t=22
тот факт что статистический баланс положительный, не отменяет факта что эти деньги были потрачены впустую. И они могли быть потрачены на что-то другое. Если я потерял 100 баксов, но нашел на дороге 200, факт находки не отменяет факта потери.
может тогда стоит ещё сравнить с миллионами долларов которые просирают каждый год стартапы? 90% которых в итоге провалятся
ну может обычно выходит что замеряется сколько времени потратит человек у которого уже есть опыт в REST но нет опыта в rRPC?
насколько я знаю, уже есть curl для gRPC, postman, и расширения для браузера для облегчения отладки с gRPC. А у Гугла кажется и лоад балансеры уже могут в gRPC. Основная проблема с gRPC мне кажется именно в повседневной рутине — написал rpc вызов, потом надо затестить, отладиться. И вот это вероятно удобнее в REST.
Но.
1) те же строгие контракты из коробки — великое дело. То что энфорсится на проектах бест-практиками, соглашениями, гайдлайнами — очень часто не работает. Попробуйте например обеспечить единый codestyle форматирования на 10 разных команд. И попробуйте нарушить форматирования если gofmt сразу даст по рукам. Большая разница. Тоже самое про контракты апи и их проверку.
2) Тоже самое по части обработки ошибок — частая ситуация когда микросервис получает 500 Error «что-то пошло не так», и не может дальше решить что с этим делать — http статусы малополезны для обработки ошибок, потому что для 500ки может быть просто ворох различных ошибок бизнес-логики, и это можно отразить только в теле запроса каким-то выработанным стандартом обработки ошибок. Опять таки, да, можно сделать библиотеки и тд. но нужно ещё заэнфорсить это по всей компании. Если же обработка ошибок органично ложится на структуру обмена сразу — это намного лучше.
3) обработка таймаутов. Ошибки в конфигурации таймаутов — частое явление. Итого выходит что вы даёте POST запрос, который добавляет сущность, и получаете скажем 503, но на деле он выполнился, просто один сервис в цепочке имел допустимый таймаут обработки запроса ниже чем следующий
4) как отменить запрос в REST? Сделать компенсирующий? Например истёк дедлайн на обработку запроса, и значит нужно обезопаситься от ситуации когда этот запрос всё-таки будет успешно обработан, а мы собираемся вернуть клиенту ошибку. В gRPC отмена запросов есть сразу как встроенный механизм
docs.microsoft.com/en-us/aspnet/core/grpc/comparison?view=aspnetcore-5.0
devblogs.microsoft.com/aspnet/grpc-vs-http-apis
это мне кажется некорректное сравнение — примерно как сравнивать языки программированию по эффективности написать Hello World. Тут не учитывается стоимость и потраченное время на поддержку и изменение. В REST с точки зрения использования есть проблемы с обработкой ошибок, таймаутов, отмены запросов, нет валидации контрактов из коробки. И сверху всего этого — нередко REST api является по факту грязной реализацией RPC
я вижу только один плюс REST — текущая поддержка инструментов и легкость создания. Но вот лучше ли это в поддержке и эволюции — вот тут сомневаюсь.
фотки могут весить много. Ну наверное даже терабайты. Но сколько это должно быть данных чтоб покупать полки, б.у. сервера и вот это всё?
по простым прикидкам 100 тысяч фоток по 10Мб каждая будут ~1Тб
но это уже дохрена фоток, столько может быть у фотографов
ну круто конечно. А что у вас за данные? Просто интересно что такое важное что стоит такой мороки)
облако проще. А NAS вот уже есть примерчик) Если все NAS-ы так будут работать то бэкапов не настачишься.
а почему вы не пломбируете себе зубы сами? Не можете разобраться в этом? Лень? А почему вы не выращиваете пшеницу самостоятельно, потом делаете из неё муку, а потом печёте хлеб сами? Тоже лень? )
лень — это двигатель прогресса. Те кому не лень, мыслят обычно непрактично сложно.
как это работает? Нужно купить несколько дисков (для избыточности), и потом вручную периодически перегонять данные на них? Ну как максимум наверное есть готовое ПО от вендоров для синхронизации. Но придётся повторить операцию для нескольких дисков.
конечно легко и просто. Каждый фотограф или домохозяйка с этим легко справятся. Купят полки, сотню дисков, бу серверы. Им-то всё-равно скучно и нечем заняться
не минусую. Но эти мысли похожи на удивление фермера о том почему каждый не может держать козу и получать с неё молоко вместо того чтобы ходить в супермаркет. Если это фэйл WD то как-то неправильно говорить «виноват ты, юзер, потому что не сделал бэкап т.к. диск мог бы вообще посыпаться». Вот если бы он посыпался — тогда ок. Но он не посыпался, его запорол сам WD
хм, я опять веткой не туда. Вроде нажимал «ответить»
я покупаю место у Google Drive но только 100Гб и бэкаплю самое важное. Дисковое место дешевое как для компаний, но не как для отдельного юзера.
ну может тогда WD пора предоставлять синхронизацию с облаком для надёжности. Пусть даже за доп. плату как опцию. Многие пользователи не очень опытны чтоб настраивать бэкапы.
вполне закономерный итог. Поставили у руля детей — получите-распишитесь.
т.е. вам лень загуглить и подтвердить собственные слова, а я должен вам что-то тут рассказывать? Назвался груздем — полезай в ящик. Не я утверждал что есть якобы валом возможностей, и надо просто стараться и всё будет.
что сложного в том чтобы понять что если хороших оплачиваемых зарплат в отрасли только жалкий процент, то эти конкретные примеры личных историй ничего не дадут? Вы в состоянии понять что в отрасли не может быть 90% аутсайдеров и неудачников? 10% — ладно, 20% — тоже ладно. Но 90% — это как? Вы сейчас требуете предоставить какие-то «неуспешные кейсны» с обоснованием. Но тут нечего обосновывать. Просто пойдите и посмотрите на статистику. Если есть только 3 нормально оплачиваемых работы из 100, то сказать что эти 97 человек — просто жалкие неудачники — это же бред.
потому что во всей отрасли низкие зп, очевидно же.
нет. Не было предоставлено никаких доказательств. Не было приведено ни одного доказательства что проблемных отраслях типа медицины якобы есть море возможностей и масса ленивых людей. Сплошные голословные заявления, самовосхваления и фантазии.
выскажу наблюдение: чем глупее человек, тем больше он раздаёт «мудрых» советов другим о том как жить