А вот эту последнюю длинную схему проверить пред тем, как выкладывать, идеи не возникло? Скажем, обратили бы внимание, что setBeanFactory() вызывается раньше, чем setApplicationContext().
Не говоря уж о том, что и эта схема неполна. Скажем, нет в ней BeanClassLoaderAware.setBeanClassLoader() .
Один мой старый знакомый, где-то году в 99-м присутствовал при (да, именно так, сам не он в том проектене кодил) при начале разработки некоего сетевого игрового проекта (который так ине взлетел, но то другая история). Протокол сочиняли сами, ну и команды, посылаемые клиентом, были там просто словами, т.е. короткими строками. Тот мой знакомый, как программист старой (уже на тот момент - "старой") закалки, глядя на это, предложил сделать все строки 4-символьными, чтобы их можно было сравнивать, как 32-битовые целые, что ускорило бы разбор сервером входящих пакетов (вместо сравнений строк и if-else-if..., сделать просто switch по этим числам). Ну и сделал пробный пример. Сравнил скорости. И был очень удивлён отсутствием сколько-то осмысленного выигрыша у своего варианта. Это было на процессорах, которые в 99-м были уже уровня "доступно для маленького стартапа".
Хотя, да, я сам ещё помню времена, когда деление было действительно более дорогой по тактам процессора операцией, чем инкремент.
Так и надо было назвать статью: «Как я настраиваю hibernate под платной IDEA».
Ну ведь ничего ж вообще про hibernate по существу (ну кроме пары азацев маркетоидных песен в начале). Ни примера программы, ни слова о том, как к нему подступиться тому, кто привык, скажем, к jdbc.
С созданием pull request аналогично. Создаётся, пропадает. Порой некоторое время «мелькает» — то есть, то нет. Порой при создании нового на том же месте пишет, что уже есть реквест.
Согласно новым требованиям закона. Телефон — средство идентификации. (А если у тебя телефон на другое имя, и ты, зарегав его там, начнёшь со своего аккаунта, например, писать террористические призывы, то у номинального владельца номера случатся проблемы.)
Хе… Попробовал зайти в свой старый аккаунт ***@nm.ru, восстановил пароль (вау! я вспомнил ответ на контрольный вопрос!), просят подтвердить телефон… Ввожу в формате 8xxx… — ругаются на формат но принимают. СМС нет. Возвращаюсь, снова ввожу уже в виде +7xxx… — приняли, сижу жду — СМС всё нет.
Не-не, «панк не умер, он просто так пахнет».
А, ну так-то да. Сорри, впечатление иное сначала создалось.
Вообще слова про «хорошую обучаемость» в резюме — просто красивый фантик, если не подкреплены сходным опытом, всякий может такое написать, и сходу такое не проверишь. ;)
А теперь вернёмся к вашим же словам: "… но бюджет был прямо скажем не очень велик..." — и всё встаёт на свои места. Да, «готовый всему быстро обучиться» сотрудник менее полезен, но и бюджета на него хватит более скромного. А нужен уже готовый с опытом — нужен и бюджет соответствующий.
Ну и далее, имея скромный бюджет и нанимая «готового быстро обучиться» сотрудника, уж вашей задачей будет построить процесс так, чтобы хоть какой-то фидбек от него пошёл достаточно рано, а вашего времени он отнимал не так уж много.
Да, скорее всего, отдача на рубль потраченных средств от него будет куда меньше, чем от «готового и с опытом». Но и это вполне логично, что нанимать «готового и с опытом» эффективнее. Но раз уж бюджет не позволяет, то у вас есть выбор только в найме низкоэффективного падавана или ненайме вообще никого.
Вроде ж банальности, но если они вам самим давно известны, то мне несовсем понятны ваше недовольство.
Но, заметим, какой из вариантов скрывается за строчкой в описании вакансии, не узнаешь, пока туда не попадёшь. Хотя тому, кто сам в agile понимает (даже если не любит его), это даст повод заранее подумать, что спросить, чтобы понять, что там. Так что, выходит, строчка всё же скорее не лишняя.
Про agile может быть и просто информированием об условиях работы. Кому-то нравится agile и мотивирует на вакансию. А кто-то терпеть его не может, и, увидев эти слова, резонно сэкономит время и себе, и компании.
Развёртываение серверов с подготовленныъ конфигураций было и тогда.
Разница лишь в том, что сейчас это куда чаще используется, а тогда чаще требовалась уникальная кастомизация настроек (которая и сейчас тоже есть, никуда не делась, но на общем фоне менее заметна).
Машинный перевод, и никому из знающих русский язык на проверку не отдавали? Понимать некоторые случайные комбинации слов очень затруднительно.
А вот эту последнюю длинную схему проверить пред тем, как выкладывать, идеи не возникло? Скажем, обратили бы внимание, что setBeanFactory() вызывается раньше, чем setApplicationContext().
Не говоря уж о том, что и эта схема неполна. Скажем, нет в ней BeanClassLoaderAware.setBeanClassLoader() .
Один мой старый знакомый, где-то году в 99-м присутствовал при (да, именно так, сам не он в том проектене кодил) при начале разработки некоего сетевого игрового проекта (который так ине взлетел, но то другая история). Протокол сочиняли сами, ну и команды, посылаемые клиентом, были там просто словами, т.е. короткими строками. Тот мой знакомый, как программист старой (уже на тот момент - "старой") закалки, глядя на это, предложил сделать все строки 4-символьными, чтобы их можно было сравнивать, как 32-битовые целые, что ускорило бы разбор сервером входящих пакетов (вместо сравнений строк и if-else-if..., сделать просто switch по этим числам). Ну и сделал пробный пример. Сравнил скорости. И был очень удивлён отсутствием сколько-то осмысленного выигрыша у своего варианта. Это было на процессорах, которые в 99-м были уже уровня "доступно для маленького стартапа".
Хотя, да, я сам ещё помню времена, когда деление было действительно более дорогой по тактам процессора операцией, чем инкремент.
Ну ведь ничего ж вообще про hibernate по существу (ну кроме пары азацев маркетоидных песен в начале). Ни примера программы, ни слова о том, как к нему подступиться тому, кто привык, скажем, к jdbc.
Не-не, «панк не умер, он просто так пахнет».
Вообще слова про «хорошую обучаемость» в резюме — просто красивый фантик, если не подкреплены сходным опытом, всякий может такое написать, и сходу такое не проверишь. ;)
Ну и далее, имея скромный бюджет и нанимая «готового быстро обучиться» сотрудника, уж вашей задачей будет построить процесс так, чтобы хоть какой-то фидбек от него пошёл достаточно рано, а вашего времени он отнимал не так уж много.
Да, скорее всего, отдача на рубль потраченных средств от него будет куда меньше, чем от «готового и с опытом». Но и это вполне логично, что нанимать «готового и с опытом» эффективнее. Но раз уж бюджет не позволяет, то у вас есть выбор только в найме низкоэффективного падавана или ненайме вообще никого.
Вроде ж банальности, но если они вам самим давно известны, то мне несовсем понятны ваше недовольство.
Разница лишь в том, что сейчас это куда чаще используется, а тогда чаще требовалась уникальная кастомизация настроек (которая и сейчас тоже есть, никуда не делась, но на общем фоне менее заметна).