Примерно раз в год наступает этот overqualified, при этом в прежней компании никто тут же не стремится поднять тебе ЗП, для них мы ещё тот же минус грейд, который только вчера пришёл.
Особенно доставляют "эффективные" коллеги, быстро выпускающие новые фичи, которые потом приходится допиливать мне багфиксами. У меня это вызывает ассоциацию с попыткой убраться в комнате, по которой кто-то бегает и мусорит, а призывы убирать за собой не работают.
Всегда удивляло, почему им дают новое, пока они свое старое не довели до ума. У меня было несколько человек в подчинении, они поняли, что новых задач могут и не увидеть и стали делать нормально. Так что, видимо, и это можно списать на плохое управление.
Правда в том, что все очень условно. В одной компании - senior, в другой - практически junior. А с учётом зарплат, так главный язык в программировании - английский. Зарплата в одном "грейде" может отличаться в 4 раза, у всех компаний свои заплаты и ожидания. Все такие оценки очень сильно привязаны к определенной компании.
Хорошие сотрудники действительно стоят дорого. Но мы ошибочно полагаем, что нужно заранее приготовить много денег, чтобы привлечь талантливого сотрудника. На самом деле, хороший сотрудник, нанятый вовремя, всегда окупается. Именно этим он и отличается от посредственных.
Решение с разделяемой памятью довольно странное. Может это связано с датой публикации статьи, но, вроде бы, уже тогда был докер и k8s. Это какой-то антипаттерн, или я ненравильно понял идею.
Где вы обвинение увидели, что решили щедро бросить минус?)
Речь про "почему нельзя было обойтись без break и использовал if else вместо switch". А точнее "использовал if else вместо switch". Логика все же немного другая.
Hibernate требует его знания и мышления в его стиле. Прежде чем на нем писать, про него нужно читать, чтобы потом не было откровением, что при merge Hibernate делает select. В транзакциях объекты достаются один раз из БД и больше в БД приложение за ними не лезет, но вот проектировать эти транзакции нужно аккуратно, знать, например, про OSIV.
Под Hibernate нужно писать и проектировать в определенном стиле, чтобы не возникало ситуации ON CONFLICT. Но банках обычно тебе дают БДшники таблицу и ты уже с ней ковыряешься, т.е. разработка идеи не от Entity к таблицам, а от таблиц к Entity, в результате проще взять JdbcTemplate и абстрактные DTO без relations.
Ну и ещё надо уметь criteria API, иначе выигрыш незначителен.
Короче Hibernate надо уметь готовить, и он не для банков.
... к успеху шел... не фартануло...
Прочитал статью - решил больше никогда не тратить время на хабр
Бинго, не дочитал статью, но полез искать этот комментарий)
Выдуманная статья про собирательный образ гадкого я, который вдруг изменился.
GraalVM для отдельных случаев вполне себе
"Лох - не мамонт, лох - не вымрет." Историческая вечная база для определенного рода бизнеса.
Плюсую
Не факт
Примерно раз в год наступает этот overqualified, при этом в прежней компании никто тут же не стремится поднять тебе ЗП, для них мы ещё тот же минус грейд, который только вчера пришёл.
А нельзя для аналитики взять ещё один сервис и дать ему доступ к репликам нужных бд? И сервис отдельный и статистика тянется с бд которых не жалко.
Особенно доставляют "эффективные" коллеги, быстро выпускающие новые фичи, которые потом приходится допиливать мне багфиксами. У меня это вызывает ассоциацию с попыткой убраться в комнате, по которой кто-то бегает и мусорит, а призывы убирать за собой не работают.
Всегда удивляло, почему им дают новое, пока они свое старое не довели до ума. У меня было несколько человек в подчинении, они поняли, что новых задач могут и не увидеть и стали делать нормально. Так что, видимо, и это можно списать на плохое управление.
Правда в том, что все очень условно. В одной компании - senior, в другой - практически junior. А с учётом зарплат, так главный язык в программировании - английский. Зарплата в одном "грейде" может отличаться в 4 раза, у всех компаний свои заплаты и ожидания. Все такие оценки очень сильно привязаны к определенной компании.
Хочется дополнить цитатой)
Интересное замечание про голод. В конечном счёте я бы поставил на голод.
Звучит так, как-будто это был бот для слива бюджета.
Решение с разделяемой памятью довольно странное. Может это связано с датой публикации статьи, но, вроде бы, уже тогда был докер и k8s. Это какой-то антипаттерн, или я ненравильно понял идею.
Кажется там ошибка по коду перенаправления, мелочь, но все же: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/302 - Found, а не Moved Permanently
Интересно, а не 307 сюда лучше брать (если не только для GET запросов) https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/307
Есть ощущение, что контекстная реклама вообще уже помирает как формат.
Где вы обвинение увидели, что решили щедро бросить минус?)
Речь про "почему нельзя было обойтись без break и использовал if else вместо switch". А точнее "использовал if else вместо switch". Логика все же немного другая.
Может стоило все же разобраться? Без brake в switch можно выполнить несколько секций:
Hibernate требует его знания и мышления в его стиле. Прежде чем на нем писать, про него нужно читать, чтобы потом не было откровением, что при merge Hibernate делает select. В транзакциях объекты достаются один раз из БД и больше в БД приложение за ними не лезет, но вот проектировать эти транзакции нужно аккуратно, знать, например, про OSIV.
Под Hibernate нужно писать и проектировать в определенном стиле, чтобы не возникало ситуации ON CONFLICT. Но банках обычно тебе дают БДшники таблицу и ты уже с ней ковыряешься, т.е. разработка идеи не от Entity к таблицам, а от таблиц к Entity, в результате проще взять JdbcTemplate и абстрактные DTO без relations.
Ну и ещё надо уметь criteria API, иначе выигрыш незначителен.
Короче Hibernate надо уметь готовить, и он не для банков.