да о чем говорить, если даже программа, скопированная из книги, редко работает с первого раза (почитайте stack overflow, там постоянно такое встречается)
А зачем тогда страховые занимаются этим «убыточным» бизнесом? И еще рекламируют свои услуги, призывая покупать ОСАГО у них? Наверное у них калькулятор не работает.
«У каждого <div/> есть координаты, которые надо просто поменять, и кнопка переедет в другое место. Это займёт 10 минут.»
Я не прикидываюсь дурачком, просто как человек, который разбирается в своей области (нет, к верстке я не имею отношения), могу сказать, что любое дилетантское мнение может не учитывать огромное количество нюансов, поэтому апелляции к школьному учебнику некорректны (ведь например в школьном учебнике по алгебре написано, что если у квадратного уравнения дискриминант равен нулю, то у уравнения 1 корень, хотя на самом деле их два, просто они одинаковые)
не являюсь противником гмо, но что там такого написано в учебнике, что может доказать безвредность именно гмо?
И вообще, такая фраза некорректна. Я могу много таких фраз составить, от которых у специалистов глаз задергается, например:
«что вы сделали с учебником информатики в школе? Этой книги достаточно, чтобы помножить на 0 все доводы противников перемещения кнопки на сайте в другое место экрана по требованию заказчика в течение 30 минут»
Я думаю, что дело здесь не в конкуренции, а бизнес-модели. Пока твой главный актив — люди, то ты за них борешься, отсюда и плюшки, и человеческое отношение, а когда мир меняется, конкуренция возрастает, главным активом становятся связи во власти (способность получить самые выгодные контракты), хорошие продажники, etc, то отношение к персоналу становится как к «необходимому злу».
При чем здесь он? Они всем коллективом (страной) решили поставить условие перед начальством (внешним врагом), что если им не повысят зарплату, то они все уйдут (объявят войну). Когда начальство (внешний враг) сказало, что повышать зарплату не будет, то войну почему-то объявил только Сталин, а народ струсил и сдался в плен. Вот если бы все объявили войну, то исход был бы совсем иной.
Я, кстати, склонен считать, что это не старческое брюзжание, а просто раз в 3-4 поколения молодежь действительно вырастает никудышная, теряет большинство достижений своих предшественников, которые создали им благоприятную среду, наслаждается жизнью, плюет на сложившиеся порядки, а следующие поколения, попавшие в более тяжелые условия, двигают общество вперед.
От угонов хорошо помогла бы единая база сочетаний номеров двигателей и кузовов, которые произведены в стране, либо официально ввезены. Тогда трудно будет продать краденную машину, потому что либо сразу станет понятно, что она в угоне (если в базе есть такая пометка, а номера не перебивались), либо вам откажут в постановке на учет, потому что такого сочетания номеров в базе нет (если угонщик перебил номера). Но уже очень много лет эту меру под разными предлогами отказываются внедрить.
Да, потому что в случае головы — все события проходят через кеш, поэтому нет проблемы с актуализацией его состояния. И если посмотрите мой коммент ниже, то я там как раз описывал такие кеши, которые не нуждаются в актуализации.
Неправда. Кэш — это возможность не производить вычисления, если результат заранее известен. Вы не знакомитесь с коллегами на работе каждый день, потому что уже знаете как их зовут и кем они здесь работают, и вы закешировали у себя в голове эту информацию.
То, что вы денормализовали данные (раз всё, что вам нужно — это только обращение просто по ключу), не означает, что вы побороли все проблемы, потому что теперь вы усложнили обновление данных в БД, т.к. денормализация данных ведет к их дублированию, а значит обновлять их придется в разных таблицах в рамках одной транзакции, так что вы просто сменили проблему чтения на проблему записи.
Частью этой архитектуры был Ehcache
Раз уж вы использовали мощные кластерные кэши на Java, то могли бы использовать read-through — механизм, который позволяет кэшу самому сходить в базу, если при запросе оказалось, что в кэше нет нужных данных. Не знаю насчет EhCache, но в Infinispan и в Apache Ignite, которые бесплатные и open source, такая функциональность есть, не говоря уже о коммерческих решениях, таких как Oracle Coherence и т.д. А если еще использовать и write-through/write-behind, которые позволяют пробрасывать в базу всё, что пишется в кэш (write-through — синхронная запись, write-behind — асинхронная), то вы можете вообще забыть о такой проблеме, как инвалидация кэша, потому что если всю работу с данными проводить через кэш, то это будет и быстро, и консистентно, и масштабируемо, а сама БД будет выполнять только роль persistent storage, который нужен чтобы прогреть кэш при холодном старте.
Я не прикидываюсь дурачком, просто как человек, который разбирается в своей области (нет, к верстке я не имею отношения), могу сказать, что любое дилетантское мнение может не учитывать огромное количество нюансов, поэтому апелляции к школьному учебнику некорректны (ведь например в школьном учебнике по алгебре написано, что если у квадратного уравнения дискриминант равен нулю, то у уравнения 1 корень, хотя на самом деле их два, просто они одинаковые)
И вообще, такая фраза некорректна. Я могу много таких фраз составить, от которых у специалистов глаз задергается, например:
«что вы сделали с учебником информатики в школе? Этой книги достаточно, чтобы помножить на 0 все доводы противников перемещения кнопки на сайте в другое место экрана по требованию заказчика в течение 30 минут»
Раз уж вы использовали мощные кластерные кэши на Java, то могли бы использовать read-through — механизм, который позволяет кэшу самому сходить в базу, если при запросе оказалось, что в кэше нет нужных данных. Не знаю насчет EhCache, но в Infinispan и в Apache Ignite, которые бесплатные и open source, такая функциональность есть, не говоря уже о коммерческих решениях, таких как Oracle Coherence и т.д. А если еще использовать и write-through/write-behind, которые позволяют пробрасывать в базу всё, что пишется в кэш (write-through — синхронная запись, write-behind — асинхронная), то вы можете вообще забыть о такой проблеме, как инвалидация кэша, потому что если всю работу с данными проводить через кэш, то это будет и быстро, и консистентно, и масштабируемо, а сама БД будет выполнять только роль persistent storage, который нужен чтобы прогреть кэш при холодном старте.