Правда в том, что все очень условно. В одной компании - 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 надо уметь готовить, и он не для банков.
@SpringBootTest
class PrimaryExampleApplicationTests {
@Autowired
BankService messageService;
@Test
public void testing(){
Bank newBank1 = messageService.getNewBank();
Bank newBank = messageService.getNewBank(); // <- Это здесь не нужно. getNewBank() возвращает всегда один и тот же прокси объект. А вот при обращении к прокси объекту внутри него идет создание каждый раз нового прототипа.
System.out.println(newBank.getInput());
System.out.println(newBank1.getInput());
}
}
Такой код даст такой же результат:
@SpringBootTest
class PrimaryExampleApplicationTests {
@Autowired
BankService messageService;
@Test
public void testing(){
Bank newBank = messageService.getNewBank();
System.out.println(newBank.getInput());
System.out.println(newBank.getInput());
}
}
Подход может подойти для обработкчиков каких-нибудь, чтобы в них можно было хранить состояния на время выполнения обработки. Ну а вообще подход извращенный, гораздо проще через контекст доставать бины прототипа.
EPAM никого никуда не перевозил, до последнего не было точности, а был посыл переезжать за свой счёт, причем условия компенсации не озвучивались четко. Ещё говорили, что сроки на программу релокации сохраняются, многие вообще надеялись, что получится раньше релоцироваться, а по итогу, на сколько мне потом стало известно из чатов, все сроки обнулились, так как смена компании на компанию в другой стране. У меня оставалось 6 месяцев до поездки в штаты, но я не стал дёргаться, как выяснилось не зря.
Прошло почти 10 лет, idea таки сильно потеснила eclipse. Но теперь idea бесит тем, что за деньги получаешь баги, которые долго исправляются, после обновлений порой бывают тормоза. Периодически приходится перезапуска сбрасывая кеш. Использую очень активно на порядка 50 отдельных проектах (микросервисы).
Не исключено, что в будущем нас ждут общественные квадрокоптеры, которые будут летать по строгим траекториям. Возможно технически это реализовать ещё проще, чем беспилотные автомобили, ведь тут будут две площадки, между которыми он будет курсировать. Хотя отсутствие засилия служб доставок квадрокоптерами наталкивает на смысл, что не все так гладко в этой области.
Это не старая школа, а классические определения, не привязанные к языку или семейству языков типа «C++ образных».
Большая часть продуктов все равно на них, а опыт был получен в резальтате их использования.
В массивах нет методов, можно функции в них хранить, не более. И да, ООП именно для организации вместе данных и подпрограмм их обработки, а сокрытие ему ортогонально. Например, в некоторых языках есть сокрытие уровня модуля или сборки, никак к ООП не относящееся.
Но ООП без сокрытия это сущий ад.
Status: Implemented (in PHP 7.4)
Но релиз-то еще только в конце 2019 и оно еще может быть перенесен. А пока повсеместно начнут использовать, так появится еще куча кода в старом стиле.
Количественные оценки этого «гораздо больше» есть? Они учитывают возможность использования магического метода __set(), если вот прямо срочно нужно?
А разыскивать где атрибут изменился вроде ничуть не сложнее, чем разыскивать где же сеттер вызвался.
А вот тут мы идем как раз по типичной дорожке к запутанному коду. Magic методы вообще губительны как для проекта, так и для ООП. В этом случае предполагается, что вы знаете код, и как там работают эти магические методы. Об автокомплите тоже можно забыть, так как «Метод __set() будет выполнен при записи данных в недоступные свойства. », т.е. придется сначала убарть атрибут, чтобы заработал методы, а значит пропадет автокомплит. Ну и искать где он там меняется все же сложнее, чем искать вызовы метода.
В 4-й версии модификаторов доступа не было, все члены класса были публичными.
Ну вы вспомнили. Даже 5 уже устарел. Меня смущает упоминание 4 версии. Если у вас старая школа, я вас не переубежу.
К чему вы будете $this привязывать?
Так, тут вообще зарулили не туда, изначально суть была вообще в другом. ООП позволяет хорошо организовать, массивы позволяют хранить все те же переменные и методы, но без всякой структуры. Ограничение доступа — один из инструментов сохранения этой структуры.
Можно конечно поизвращаться:
<?php
$a = [
'value' => 1,
];
$a['this'] = function () use ($a) {
return $a;
};
var_dump($a['this']()['value']);
но в PHP тайпхинтинг и для свойств завезли
Серьезно? Похоже, что еще только в проекте. Если разработчик не использует типы, то это уже на его совести.
А практика показывает, что в 99% случаев геттеры/сеттеры так и остаются тупыми, по факту не делая никакого сокрытия, но понимание кода усложняя.
Зато в том 1% случаев вы выиграете гораздо больше чем потеряете, если не будете рефакторить код по всему проекту переводя атрибут на метод, или разыскивая где-эже этот атрибут изменился.
Авторы (навскидку) python, javascript, php (4) решили, что и без сокрытия имеет смысл объединять данные и методы, их обрабатывающие.
PHP то вы зачем сюда приплели, у него с инструментами сокрытия все впорядке.
Будет. К массивам нельзя методы прикрутить, конструкторы, использовать в тайпхинтинге нормально и в инстансоф
Что мешает запихать методы в массив.
Именно. Если делаю публичные геттеры-сеттеры, то только когда понимаю зачем я их делаю. И обычно для меня такие «тупые» геттеры-сеттеры маркер плохого проектирования: если они ничего не делают, кроме сокрытия ради сокрытия, то нет смысла их использовать, это нарушение KISS и YAGNI.
Все с точность до наоборот, они позволяют в момент ограничить входные данные, повзволяют быть уверенным в том, что на входе именно то что ожидаешь, повзволяют расширять код в будущем (к слову о плохой архитектуре). Не раз приходилось сталкиваться с ситуацией, когда было крайне необходимо добавить дополнительную обработку в setter, отловить входной параметр при бебаге, или преобразовать данные при входе/выходе. KISS и YAGNI тут вообще не причем, генерация методов идет на уровне IDE и ничего не усложняет.
Правда в том, что все очень условно. В одной компании - 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 надо уметь готовить, и он не для банков.
Компания на букве E сегодня сообщила, что позавчера ты уже не на проекте. А до этого всем предлага совершить прыжок веры без гарантий за свой счет.
Такой код даст такой же результат:
Подход может подойти для обработкчиков каких-нибудь, чтобы в них можно было хранить состояния на время выполнения обработки. Ну а вообще подход извращенный, гораздо проще через контекст доставать бины прототипа.
EPAM никого никуда не перевозил, до последнего не было точности, а был посыл переезжать за свой счёт, причем условия компенсации не озвучивались четко. Ещё говорили, что сроки на программу релокации сохраняются, многие вообще надеялись, что получится раньше релоцироваться, а по итогу, на сколько мне потом стало известно из чатов, все сроки обнулились, так как смена компании на компанию в другой стране. У меня оставалось 6 месяцев до поездки в штаты, но я не стал дёргаться, как выяснилось не зря.
Кажется можно без metric
management.endpoints.web.exposure.include=prometheus,health,infoПрошло почти 10 лет, idea таки сильно потеснила eclipse. Но теперь idea бесит тем, что за деньги получаешь баги, которые долго исправляются, после обновлений порой бывают тормоза. Периодически приходится перезапуска сбрасывая кеш. Использую очень активно на порядка 50 отдельных проектах (микросервисы).
Не исключено, что в будущем нас ждут общественные квадрокоптеры, которые будут летать по строгим траекториям. Возможно технически это реализовать ещё проще, чем беспилотные автомобили, ведь тут будут две площадки, между которыми он будет курсировать. Хотя отсутствие засилия служб доставок квадрокоптерами наталкивает на смысл, что не все так гладко в этой области.
Большая часть продуктов все равно на них, а опыт был получен в резальтате их использования.
Но ООП без сокрытия это сущий ад.
Но релиз-то еще только в конце 2019 и оно еще может быть перенесен. А пока повсеместно начнут использовать, так появится еще куча кода в старом стиле.
А вот тут мы идем как раз по типичной дорожке к запутанному коду. Magic методы вообще губительны как для проекта, так и для ООП. В этом случае предполагается, что вы знаете код, и как там работают эти магические методы. Об автокомплите тоже можно забыть, так как «Метод __set() будет выполнен при записи данных в недоступные свойства. », т.е. придется сначала убарть атрибут, чтобы заработал методы, а значит пропадет автокомплит. Ну и искать где он там меняется все же сложнее, чем искать вызовы метода.
Ну вы вспомнили. Даже 5 уже устарел. Меня смущает упоминание 4 версии. Если у вас старая школа, я вас не переубежу.
Так, тут вообще зарулили не туда, изначально суть была вообще в другом. ООП позволяет хорошо организовать, массивы позволяют хранить все те же переменные и методы, но без всякой структуры. Ограничение доступа — один из инструментов сохранения этой структуры.
Можно конечно поизвращаться:
Серьезно? Похоже, что еще только в проекте. Если разработчик не использует типы, то это уже на его совести.
Зато в том 1% случаев вы выиграете гораздо больше чем потеряете, если не будете рефакторить код по всему проекту переводя атрибут на метод, или разыскивая где-эже этот атрибут изменился.
PHP то вы зачем сюда приплели, у него с инструментами сокрытия все впорядке.
Что мешает запихать методы в массив.
Все с точность до наоборот, они позволяют в момент ограничить входные данные, повзволяют быть уверенным в том, что на входе именно то что ожидаешь, повзволяют расширять код в будущем (к слову о плохой архитектуре). Не раз приходилось сталкиваться с ситуацией, когда было крайне необходимо добавить дополнительную обработку в setter, отловить входной параметр при бебаге, или преобразовать данные при входе/выходе. KISS и YAGNI тут вообще не причем, генерация методов идет на уровне IDE и ничего не усложняет.