Ну во-первых, кэш — это не только Map, он реализует и другие интерфейсы.
Во-вторых, в гриде можно создавать объекты (наподобие распределенной Callable и Executor), которые принимают кэш в качестве аргумента и выполняют над ним какие-либо действия.
Это может быть просто изменение данных, соответствующих какому-то условию, либо это может быть Map Reduce, который позволит вам на основе существующих данных получить некий результат
Наверняка после того, как гугл обяжет всех пользователей своих сервисов регистрироваться в G+, начнут появляться сервисы, лишенные этого недостатка. Гугл просто откроет другим компаниям рынок
Нет, это не может являться критерием выбора типа запроса. PUT обязан быть идемпотентным!
Например, если вы будете делать инкремент счетчика просмотров существующего ресурса через PUT, то фактически каждый запрос будет изменять состояние этого ресурса, что не подразумевается семантикой PUT-запросов.
А нельзя ли немного конкретики? Например опубликуйте часть API, расскажите почему он именно такой.
И объясните пожалуйста, почему у вас операция заказа билета идет через POST, а не через PUT, ведь если через API передается запрос на заказ какого-то конкретного билета (с указанием ряда, места), то получается, что это идемпотентная операция (т.е. состояние системы не зависит от того, сколько раз была выполнена операция), и её следует проводить через PUT.
а кто такой бомж, если мы рассматриваем умного человека, который к чему-то стремится? Это тот, у кого на середине пути опустились руки, и он покатился по наклонной. У него не хватило стойкости, упорства, еще чего-нибудь.
Я лично разговаривал с одним из таких бомжей. Встречал жену на вокзале, стоял с цветами, а он сам ко мне подошел и заговорил про цветы. Оказался кандидатом технических наук, профессором, специалистом по проектированию климатических установок для всевозможных инкубаторов по выращиванию цветов!!! Знаете, как он оказался на улице? Жена просто выгнала из дома, и он сказал, что ему просто не захотелось больше ни к чему стремиться, поэтому он остался на улице.
Я отказываюсь верить в случайности, каждый САМ делает свою жизнь. Случайности возможны в эпизодах, но результат всегда закономерен!
Нет, не допускаю. Если под «изо всех сил работающими» вы подразумеваете НЕ тех, кто работает продавцом в евросети, то постоянные усилия и стремление к росту не могут пройти просто так. Сначала вы станете супер-мега экспертом и незаменимым сотрудником, а потом у вас появится выбор — продолжать карьерный рост, или стать предпринимателем и создавать «гугл».
И если выбор будет в сторону своего бизнеса, то вы опять будете постоянно обучаться и получать опыт (пусть и иногда негативный), который будет подсказывать вам, как делать правильно. Вы будете расти уже в другой области, и в конце-концов ваш личный гугл ждет вас.
«Не подражайте великим мастерам, а ищите то, что они искали» — восточная мудрость.
Не надо писать новый поисковик или впаривать псевдоэлитарную технику, создавая шумиху в прессе, потому что это и будет «подражанием великим мастерам», надо делать уникальные вещи, которые станут незаменимыми для множества людей.
Кто-то всю жизнь не сидит на месте, работает, занимается самообразованием. Он САМ себе создает ситуации, в которых он должен принять решение. И чем больше он таких ситуаций он себе создает, тем больше у него опыт в принятии таких решений и оценке их возможных последствий. Такие люди и добиваются успеха.
А кто-то сидит и ждет, когда ему повезет, а ему не повезет! У него нет шансов принять правильное решение, потому что он не создал себе возможность для принятия такого решения.
Вы сказали верную мысль, должна быть какая-то граница, глубже которой копать не имеет практического смысла. Но все люди разные, и каждый видит эту границу на разных уровнях погружения в предметную область. Так что наш с вами спор — это не очень-то и спор.
Ну вы же не изучаете архитектуру процессора и его набор микрокоманд для написания функции, которая что-нибудь пишет в сокет? И я тоже. И это не повод для того, чтоб всех считать тупыми и поверхностными. Давайте еще изучим ту математику, которая лежит под Computer Science, и физику процессов в микросхемах, кремниевых кристаллах и т.д.
Во всем надо знать меру, в том числе и в поиске в глубину.
Для каждой узкой области должны быть специалисты, которые должны выставлять некие абстракции, которыми другие специалисты могут пользоваться, не изучая мелочи реализации. Это же основа прогресса, без этих абстракций каждому человеку приходилось бы изучать всё, что известно человечеству на данный момент.
Такой абстракцией стала уход от натурального хозяйства к разделению труда. Теперь каждый может купить какой-то «продукт», не задумываясь о цикле его производства, доставки и продажи.
Так что «вред обучения на JAVA» и «дырявые абстракции» — это личное заблуждение тов.Спольски
Интересно, как же осваивали тот же Spring эти «претенденты»? Потому что в любой книжке по Spring первые несколько десятков страниц посвящены именно тому, зачем это все надо, для чего придумали Dependency Injection и т.д. Проблема с фреймворками надуманна, потому что когда вы их осваиваете, то читаете документацию, в которой написано, что как и зачем сделано в этом фреймворке.
Может, конечно, есть клинические случаи, когда человек изучает технологию не по доке, а по примерам кода, но не думаю, что так распространено.
Так что я считаю, что фреймворки не несут опасности отупления, они просто высвечивают тупость тех программистов, которые и без фреймворков писали бы плохой код, не понимая, что происходит в каждой строчке.
Не думаю, что отсутствие вытеснения данных можно считать признаком IMDG. В IMDG как раз тоже можно настроить expiration, eviction, passivation и т.д.
И еще раз заострю внимание на том, что IMDG существует внутри вашего приложения, тогда как все остальные решения — это standalone кластеры с доступом снаружи через какой-либо API.
Да и возможности memcached по работе с persistence хранилищами не позволяют его считать IMDG
понятие кэша просто предполагает хранение данных в памяти для быстрого доступа, при этом на актуальность данных это понятие никаких ограничений не накладывает.
Это только кэширующий кластер, но не NoSQL решение для постоянного хранения данных. Т.е. memcached хранит данные в памяти, следовательно если вы кладете кластер, то теряете все данные.
Во-вторых, в гриде можно создавать объекты (наподобие распределенной Callable и Executor), которые принимают кэш в качестве аргумента и выполняют над ним какие-либо действия.
Это может быть просто изменение данных, соответствующих какому-то условию, либо это может быть Map Reduce, который позволит вам на основе существующих данных получить некий результат
Например, если вы будете делать инкремент счетчика просмотров существующего ресурса через PUT, то фактически каждый запрос будет изменять состояние этого ресурса, что не подразумевается семантикой PUT-запросов.
И объясните пожалуйста, почему у вас операция заказа билета идет через POST, а не через PUT, ведь если через API передается запрос на заказ какого-то конкретного билета (с указанием ряда, места), то получается, что это идемпотентная операция (т.е. состояние системы не зависит от того, сколько раз была выполнена операция), и её следует проводить через PUT.
Я лично разговаривал с одним из таких бомжей. Встречал жену на вокзале, стоял с цветами, а он сам ко мне подошел и заговорил про цветы. Оказался кандидатом технических наук, профессором, специалистом по проектированию климатических установок для всевозможных инкубаторов по выращиванию цветов!!! Знаете, как он оказался на улице? Жена просто выгнала из дома, и он сказал, что ему просто не захотелось больше ни к чему стремиться, поэтому он остался на улице.
Я отказываюсь верить в случайности, каждый САМ делает свою жизнь. Случайности возможны в эпизодах, но результат всегда закономерен!
И если выбор будет в сторону своего бизнеса, то вы опять будете постоянно обучаться и получать опыт (пусть и иногда негативный), который будет подсказывать вам, как делать правильно. Вы будете расти уже в другой области, и в конце-концов ваш личный гугл ждет вас.
«Не подражайте великим мастерам, а ищите то, что они искали» — восточная мудрость.
Не надо писать новый поисковик или впаривать псевдоэлитарную технику, создавая шумиху в прессе, потому что это и будет «подражанием великим мастерам», надо делать уникальные вещи, которые станут незаменимыми для множества людей.
А кто-то сидит и ждет, когда ему повезет, а ему не повезет! У него нет шансов принять правильное решение, потому что он не создал себе возможность для принятия такого решения.
Во всем надо знать меру, в том числе и в поиске в глубину.
Для каждой узкой области должны быть специалисты, которые должны выставлять некие абстракции, которыми другие специалисты могут пользоваться, не изучая мелочи реализации. Это же основа прогресса, без этих абстракций каждому человеку приходилось бы изучать всё, что известно человечеству на данный момент.
Такой абстракцией стала уход от натурального хозяйства к разделению труда. Теперь каждый может купить какой-то «продукт», не задумываясь о цикле его производства, доставки и продажи.
Так что «вред обучения на JAVA» и «дырявые абстракции» — это личное заблуждение тов.Спольски
Может, конечно, есть клинические случаи, когда человек изучает технологию не по доке, а по примерам кода, но не думаю, что так распространено.
Так что я считаю, что фреймворки не несут опасности отупления, они просто высвечивают тупость тех программистов, которые и без фреймворков писали бы плохой код, не понимая, что происходит в каждой строчке.
И еще раз заострю внимание на том, что IMDG существует внутри вашего приложения, тогда как все остальные решения — это standalone кластеры с доступом снаружи через какой-либо API.
Да и возможности memcached по работе с persistence хранилищами не позволяют его считать IMDG
Википедия со мной согласна:)