Да тут не в "нормальности" вопрос, я думаю, а скорее в том, что они все "на одной волне", и эта волна сильно не твоя, и ты там постоянно ощущаешь себя случайным гостем. Разово такое бывает прикольно, а вот для постоянной совместной работы может оказаться не очень. Это не о том, что кто-то лучше, кто-то хуже. Это о том, что люди просто разные.
Всё же у людей с возрастом (несколько) меняются и манера общения, и восприятие окружающих (в т.ч. восприятие чужой манеры общения). У кого сильнее, у кого слабее, всё индивидуально и зависит от множества личных "настроек", которые уже так просто не "перепрошьёшь". При чём когда коллектив разновозрастный, трудностей обычно меньше. А вот если весь коллектив заметно младше (достаточно может быть и 10 лет разницы) и при этом они между собой очень удачно "на одной волне", то даже при хорошей адаптивности (у меня, в целом, нет проблем общаться с теми, кто младше) всё равно можно постоянно ощущать себя случайным гостем на чужой вечеринке. И, кстати, такое может случаться не только из-за разницы в возрасте. Так что не стоит торопиться лепить модные ярлыки, не зная особенностей конкретного случая.
Парсинг языка давно не является проблемой. И это уже давно позволяет в проектировании языков думать о других, более важных, аспектах.
Когнитивная перегрузка инженеров -- это вопрос не столько к языку (хотя и к нему), сколько к коллегам-инженерам и к самому себе. Ну а про языки: идея нанизывания суффиксов скорее породит ад, где надо, читая, удерживать в голове всю цепочку. Плюс длинную цепочку сложно понять "одним взглядом". А чтение слева направо не избавит от необходимости помнить контекст.
Единый протокол невозможен, потому что перед разными протоколами стоят разные задачи. И попытка впихнуть всё это в один создаст такой безумный перегруз, что никто не будет в достаточно мере знать этот протокол, чтобы с ним работать. Вы тут противоречите сами себе. Только что восхваляли unix-стиль, где много мелких простых утилит можно сплести вместе для решения более сложной задачи. Но каждая такая утилита -- это свой "протокол". Единый протокол для всего будет неудобен для всего.
А вот эту последнюю длинную схему проверить пред тем, как выкладывать, идеи не возникло? Скажем, обратили бы внимание, что 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 и мотивирует на вакансию. А кто-то терпеть его не может, и, увидев эти слова, резонно сэкономит время и себе, и компании.
Развёртываение серверов с подготовленныъ конфигураций было и тогда.
Разница лишь в том, что сейчас это куда чаще используется, а тогда чаще требовалась уникальная кастомизация настроек (которая и сейчас тоже есть, никуда не делась, но на общем фоне менее заметна).
Да тут не в "нормальности" вопрос, я думаю, а скорее в том, что они все "на одной волне", и эта волна сильно не твоя, и ты там постоянно ощущаешь себя случайным гостем. Разово такое бывает прикольно, а вот для постоянной совместной работы может оказаться не очень. Это не о том, что кто-то лучше, кто-то хуже. Это о том, что люди просто разные.
Всё же у людей с возрастом (несколько) меняются и манера общения, и восприятие окружающих (в т.ч. восприятие чужой манеры общения). У кого сильнее, у кого слабее, всё индивидуально и зависит от множества личных "настроек", которые уже так просто не "перепрошьёшь". При чём когда коллектив разновозрастный, трудностей обычно меньше. А вот если весь коллектив заметно младше (достаточно может быть и 10 лет разницы) и при этом они между собой очень удачно "на одной волне", то даже при хорошей адаптивности (у меня, в целом, нет проблем общаться с теми, кто младше) всё равно можно постоянно ощущать себя случайным гостем на чужой вечеринке.
И, кстати, такое может случаться не только из-за разницы в возрасте.
Так что не стоит торопиться лепить модные ярлыки, не зная особенностей конкретного случая.
Парсинг языка давно не является проблемой. И это уже давно позволяет в проектировании языков думать о других, более важных, аспектах.
Когнитивная перегрузка инженеров -- это вопрос не столько к языку (хотя и к нему), сколько к коллегам-инженерам и к самому себе. Ну а про языки: идея нанизывания суффиксов скорее породит ад, где надо, читая, удерживать в голове всю цепочку. Плюс длинную цепочку сложно понять "одним взглядом". А чтение слева направо не избавит от необходимости помнить контекст.
Единый протокол невозможен, потому что перед разными протоколами стоят разные задачи. И попытка впихнуть всё это в один создаст такой безумный перегруз, что никто не будет в достаточно мере знать этот протокол, чтобы с ним работать. Вы тут противоречите сами себе. Только что восхваляли unix-стиль, где много мелких простых утилит можно сплести вместе для решения более сложной задачи. Но каждая такая утилита -- это свой "протокол". Единый протокол для всего будет неудобен для всего.
Сдаётся мне, тут по ошибке пропал кусок текста.
Машинный перевод, и никому из знающих русский язык на проверку не отдавали? Понимать некоторые случайные комбинации слов очень затруднительно.
А вот эту последнюю длинную схему проверить пред тем, как выкладывать, идеи не возникло? Скажем, обратили бы внимание, что setBeanFactory() вызывается раньше, чем setApplicationContext().
Не говоря уж о том, что и эта схема неполна. Скажем, нет в ней BeanClassLoaderAware.setBeanClassLoader() .
Один мой старый знакомый, где-то году в 99-м присутствовал при (да, именно так, сам не он в том проектене кодил) при начале разработки некоего сетевого игрового проекта (который так ине взлетел, но то другая история). Протокол сочиняли сами, ну и команды, посылаемые клиентом, были там просто словами, т.е. короткими строками. Тот мой знакомый, как программист старой (уже на тот момент - "старой") закалки, глядя на это, предложил сделать все строки 4-символьными, чтобы их можно было сравнивать, как 32-битовые целые, что ускорило бы разбор сервером входящих пакетов (вместо сравнений строк и if-else-if..., сделать просто switch по этим числам). Ну и сделал пробный пример. Сравнил скорости. И был очень удивлён отсутствием сколько-то осмысленного выигрыша у своего варианта. Это было на процессорах, которые в 99-м были уже уровня "доступно для маленького стартапа".
Хотя, да, я сам ещё помню времена, когда деление было действительно более дорогой по тактам процессора операцией, чем инкремент.
Ну ведь ничего ж вообще про hibernate по существу (ну кроме пары азацев маркетоидных песен в начале). Ни примера программы, ни слова о том, как к нему подступиться тому, кто привык, скажем, к jdbc.
Не-не, «панк не умер, он просто так пахнет».
Вообще слова про «хорошую обучаемость» в резюме — просто красивый фантик, если не подкреплены сходным опытом, всякий может такое написать, и сходу такое не проверишь. ;)
Ну и далее, имея скромный бюджет и нанимая «готового быстро обучиться» сотрудника, уж вашей задачей будет построить процесс так, чтобы хоть какой-то фидбек от него пошёл достаточно рано, а вашего времени он отнимал не так уж много.
Да, скорее всего, отдача на рубль потраченных средств от него будет куда меньше, чем от «готового и с опытом». Но и это вполне логично, что нанимать «готового и с опытом» эффективнее. Но раз уж бюджет не позволяет, то у вас есть выбор только в найме низкоэффективного падавана или ненайме вообще никого.
Вроде ж банальности, но если они вам самим давно известны, то мне несовсем понятны ваше недовольство.
Разница лишь в том, что сейчас это куда чаще используется, а тогда чаще требовалась уникальная кастомизация настроек (которая и сейчас тоже есть, никуда не делась, но на общем фоне менее заметна).