Да, действительно, вполне уместное замечание. Дело в том, что мы следуем каноническому подходу, который принят у Oracle и к которому все давно привыкли (кстати, в декабре прошлого года Oracle сертифицировал миллионного разработчика). Сертификационный экзамен традиционно не предполагает, в частности, каких-либо сценариев с компиляторной оптимизаций, поэтому, к примеру, ключевое слово volatile вообще не вынесено на тестирование. Точно так же экзамен не углубляется в специфику Java Memory Model. Набор предложенных вариантов ответа ограничивает набор сценариев, в которых теоретически способен работать код в вопросах.
В контексте плана развития мы действуем следующим образом: сотрудник сам высказывает свою карьерную «хотелку», а наша цель эту самую «хотелку» воплотить в жизнь таким образом, чтобы по итогу все остались в выигрыше. Если же сотрудник не знает чего он хочет, то РП (в данном случае я) отдельно общается с заказчиком на проекте, с самим сотрудником, привлекает технических специалистов, менторов из отдела, к которому сотрудник относится, анализирует все перспективы и старается предложить сотруднику на выбор ряд четких вариантов развития, а сотрудник уже сам выбирает что ему ближе. Тут так же важно проговорить, что в план развития могут входить далеко не только карьерные планы по горизонтальному и вертикальному росту, а так же менее масштабные вещи, такие как изучение новых технологий, приобретение новых скиллов и т.п. Касаемо вашего комментария о моем личном опыте работы в компании без перфоманс ревью, к сожалению или счастью, любые человеческие коммуникации – двухсторонний и абсолютно взаимный процесс, если одна сторона чего-то не хочет, то подойти/написать/поговорить за кофе даже при максимальном уровне софт скиллов не поможет добиться нужного результата.
Абсолютно с вами согласны, ни в коем случае нельзя допускать, чтобы такие мероприятия как перфоманс ревью были «просто чтобы были», у этого должна быть четкая цель и не менее четкий результат. Также важно помнить, что в этом вопросе как минимум две заинтересованные стороны, а не одна: сотрудник и компания, перфоманс ревью призваны как раз удовлетворить и помочь им обеим. А случай, когда как вы сказали «с точки зрения работодателя все как раз наоборот», является ничем иным как «выстрелом в колено».
Наша компания придерживается следующей идеологии в этом вопросе: все должно быть максимально справедливо. Если сотрудник выполняет все поставленные цели и получает хорошую обратную связь от заказчика, то мы только рады замотивировать и повысить его, по достоинству оценив все результаты и успехи. Мне кажется, в этом вопросе необходимо придерживаться гибкости, не каждый перфоманс ревью приводит к повышению и не каждое повышение должно происходить строго накануне/после перфоманс ревью. Однако, финансовый вопрос действительно не был затронут в статье и это прекрасная мотивация начать думать над второй частью и поделиться своими мыслями и опытом с вами в следующий раз. Спасибо за комментарий!
С нашей бизнес-моделью все в порядке, мы всего лишь следуем устоявшейся, канонической практике. Точно такой же подход принят и у Oracle: в частности, сигнатуры популярных методов надо знать. Как и всякую материальную часть своей предметной области. Тем более в классах из пакета java.lang.
В Java 4000+ классов, в каждом по доброму десятку методов, поэтому никто не требует полного знания.
Но рассматриваемый случай особенный: речь идет про т.н. «классы-оболочки», которые крайне популярны и полезны. Вот их надо бы знать на память, причем и тут объем совсем не такой большой. В частности, в каждом из них есть по 3 метода, которые и называются примерно одинаково, и работу выполняют похожую. Метод из примера, т.е.valueOf() по принятой конвенции ВСЕГДА принимает подстилающий примитив, а вовсе не строковый литерал, как в задаче. Для работы со строковыми литералами есть другой метод, parseXXX(), где XXX может означать Int, Boolean и проч. А можно еще взять конструктор, который умеет работать и так, и эдак… Одним словом, есть единый подход, эдакая конвенция, знание которой стократно облегчает жизнь кодера и позволяет ему делать меньше ошибок.
Так что в данном конкретном случае… Да, тут конвенцию надо знать наизусть, ничего не попишешь. Вообще говоря, Java-кодер средней руки должен неплохо знать специфику нескольких сотен классов и, соответственно, их методов. C’est la vie…
Если имеется в виду «результат» как ответ на вопрос, например, «скомпилируется ли данный код», то, вообще говоря, да: это зависит от компилятора, потому что всякий компилятор привязан к конкретной версии Java, вот почему код с новейшими фичами попросту не скомпилируется на древних версиях. Но отметим, что наши сертификационные экзамены совершенно строго «заточены» под 11-ю версию (причем об этом, конечно же, объявлено открыто), поэтому вопросы категорически не будут содержать что-то чересчур новое. Что касается IDE, то они никак не влияют на результат (за исключением экзотических ситуаций, но такие ситуации на экзамене гарантированно не встретятся).
Спасибо за оценку, попросили автора ответить на ваши замечания: "Сразу уточню, что статья больше составлялась для разработчиков, которые еще не сталкивались с BPMN и которым было бы интересно попробовать их поизучать. Диаграмма была реализована для MVP-проекта и подтверждения определенных гипотез, т.е. на каноничность она не претендует.
В данной статье рассматриваются именно системы исполнения BPMN-диаграмм. Среди них можно выделить условные "движки" и целые системы, предоставляющие полный функционал работы с BPMN на уровне пользовательского интерфейса - BPM Suite (BPMS). Отдельной аббревиатуры для движков я найти не смог, поэтому в качестве альтернативы BPMS движки были сокращены до BPMN.
Ромб с Х - такое описание сделано для простоты понимания схемы, так как не все читатели могут быть знакомы с нотацией. Но чуть выше указанного места я писал, что ромб — это развилка. Боюсь, что объяснить полно и точно назначение всех элементов у меня бы не получилось без потери интереса к материалу.
Некий скрытый процесс. "Некий" он потому, что в рамках диаграммы данный элемент подразумевает разные действия, что нельзя сказать, к примеру, про "Отправку запроса", который всегда выполняет одну и ту же задачу. "Скрытым" он является ввиду специфики реализации - при настройке диаграммы нет возможности как-то изменить логику работы. Если бы мы говорили про "Подпроцесс", который ссылается на другую диаграмму, то там все элементы нам видны и доступны для модификации.
"Колдовство" разработчиков. BPMN-движок является инструментом для работы с BPMN. Он может встраиваться в уже реализованный продукт, либо быть отдельным сервисом. В обоих случаях разработчики принимают участи в этом процессе, так как решение "из коробки" мало когда устраивает. BPMS предоставляет полный набор функций и сервисов, чтобы интегрироваться с системами. Большинство возможностей и кастомизации также могут быть настроено через интерфейс BPMS. Поэтому в сравнении этих двух решений подход через BPMN-движки для стороннего наблюдателя по большей части скрыт".
Вот так ответил нам Александр: "Были такие здоровенные устройства считывания с перфокарт. Они еще иногда в качестве бонуса разбрасывали введенные перфокарты по всему машинному залу 150-200 м2. При этом перфокарты не были пронумерованы".
Наши представления о среднем программисте основаны на результате анализа текущих запросов в российской IT-отрасли на уровень квалификации сотрудников. Мы проверяем компетенции и навыки, которые востребованы на рынке.
> Как именно осуществляется экспорт будущих интерактивных объектов? Куда при этом деваются аттрибуты, которые мы задавали в мета-данных.
Все данные, нанесенные в Visio, через самописный конвертер укладываются в базу. Так атрибуты графического объекта visio попадают в объект базы. При работе пользователя в веб-интерфейсе определяются координаты клика, и если клик пришелся в границы «интерактивного» объекта, вызываются соответствующие параметры его отображения.
> Как осуществляется привязка этих объектов к растровой подложке
По координатам. Каждая карта имеет нулевую точку, начало координатной системы, относительно которой считается вся геометрия. Дальше алгоритм: клик по карте – определение координат клика – смотрим что под этой координатой – если задано свойство выводить по клику то выводим какую-то карточку.
Да, действительно, вполне уместное замечание. Дело в том, что мы следуем каноническому подходу, который принят у Oracle и к которому все давно привыкли (кстати, в декабре прошлого года Oracle сертифицировал миллионного разработчика). Сертификационный экзамен традиционно не предполагает, в частности, каких-либо сценариев с компиляторной оптимизаций, поэтому, к примеру, ключевое слово volatile вообще не вынесено на тестирование. Точно так же экзамен не углубляется в специфику Java Memory Model.
Набор предложенных вариантов ответа ограничивает набор сценариев, в которых теоретически способен работать код в вопросах.
В контексте плана развития мы действуем следующим образом: сотрудник сам высказывает свою карьерную «хотелку», а наша цель эту самую «хотелку» воплотить в жизнь таким образом, чтобы по итогу все остались в выигрыше. Если же сотрудник не знает чего он хочет, то РП (в данном случае я) отдельно общается с заказчиком на проекте, с самим сотрудником, привлекает технических специалистов, менторов из отдела, к которому сотрудник относится, анализирует все перспективы и старается предложить сотруднику на выбор ряд четких вариантов развития, а сотрудник уже сам выбирает что ему ближе. Тут так же важно проговорить, что в план развития могут входить далеко не только карьерные планы по горизонтальному и вертикальному росту, а так же менее масштабные вещи, такие как изучение новых технологий, приобретение новых скиллов и т.п. Касаемо вашего комментария о моем личном опыте работы в компании без перфоманс ревью, к сожалению или счастью, любые человеческие коммуникации – двухсторонний и абсолютно взаимный процесс, если одна сторона чего-то не хочет, то подойти/написать/поговорить за кофе даже при максимальном уровне софт скиллов не поможет добиться нужного результата.
Абсолютно с вами согласны, ни в коем случае нельзя допускать, чтобы такие мероприятия как перфоманс ревью были «просто чтобы были», у этого должна быть четкая цель и не менее четкий результат. Также важно помнить, что в этом вопросе как минимум две заинтересованные стороны, а не одна: сотрудник и компания, перфоманс ревью призваны как раз удовлетворить и помочь им обеим. А случай, когда как вы сказали «с точки зрения работодателя все как раз наоборот», является ничем иным как «выстрелом в колено».
Наша компания придерживается следующей идеологии в этом вопросе: все должно быть максимально справедливо. Если сотрудник выполняет все поставленные цели и получает хорошую обратную связь от заказчика, то мы только рады замотивировать и повысить его, по достоинству оценив все результаты и успехи. Мне кажется, в этом вопросе необходимо придерживаться гибкости, не каждый перфоманс ревью приводит к повышению и не каждое повышение должно происходить строго накануне/после перфоманс ревью. Однако, финансовый вопрос действительно не был затронут в статье и это прекрасная мотивация начать думать над второй частью и поделиться своими мыслями и опытом с вами в следующий раз. Спасибо за комментарий!
С нашей бизнес-моделью все в порядке, мы всего лишь следуем устоявшейся, канонической практике. Точно такой же подход принят и у Oracle: в частности, сигнатуры популярных методов надо знать. Как и всякую материальную часть своей предметной области. Тем более в классах из пакета java.lang.
Вот здесь довольно подробно расписан весь процесс: https://ibs-training.ru/certification/java/rules/
К сожалению, пока сертификация доступна только в офлайн-формате. Но мы обязательно донесем до коллег интерес и к онлайн-формату.
И да, и нет. Как всегда в жизни, увы-увы :((
В Java 4000+ классов, в каждом по доброму десятку методов, поэтому никто не требует полного знания.
Но рассматриваемый случай особенный: речь идет про т.н. «классы-оболочки», которые крайне популярны и полезны. Вот их надо бы знать на память, причем и тут объем совсем не такой большой. В частности, в каждом из них есть по 3 метода, которые и называются примерно одинаково, и работу выполняют похожую. Метод из примера, т.е.valueOf() по принятой конвенции ВСЕГДА принимает подстилающий примитив, а вовсе не строковый литерал, как в задаче. Для работы со строковыми литералами есть другой метод, parseXXX(), где XXX может означать Int, Boolean и проч. А можно еще взять конструктор, который умеет работать и так, и эдак… Одним словом, есть единый подход, эдакая конвенция, знание которой стократно облегчает жизнь кодера и позволяет ему делать меньше ошибок.
Так что в данном конкретном случае… Да, тут конвенцию надо знать наизусть, ничего не попишешь. Вообще говоря, Java-кодер средней руки должен неплохо знать специфику нескольких сотен классов и, соответственно, их методов. C’est la vie…
Если имеется в виду «результат» как ответ на вопрос, например, «скомпилируется ли данный код», то, вообще говоря, да: это зависит от компилятора, потому что всякий компилятор привязан к конкретной версии Java, вот почему код с новейшими фичами попросту не скомпилируется на древних версиях.
Но отметим, что наши сертификационные экзамены совершенно строго «заточены» под 11-ю версию (причем об этом, конечно же, объявлено открыто), поэтому вопросы категорически не будут содержать что-то чересчур новое.
Что касается IDE, то они никак не влияют на результат (за исключением экзотических ситуаций, но такие ситуации на экзамене гарантированно не встретятся).
Спасибо! Поправили, действительно, в процессе верстки закрался лишний ноль.
Спасибо за оценку, попросили автора ответить на ваши замечания:
"Сразу уточню, что статья больше составлялась для разработчиков, которые еще не сталкивались с BPMN и которым было бы интересно попробовать их поизучать. Диаграмма была реализована для MVP-проекта и подтверждения определенных гипотез, т.е. на каноничность она не претендует.
В данной статье рассматриваются именно системы исполнения BPMN-диаграмм. Среди них можно выделить условные "движки" и целые системы, предоставляющие полный функционал работы с BPMN на уровне пользовательского интерфейса - BPM Suite (BPMS). Отдельной аббревиатуры для движков я найти не смог, поэтому в качестве альтернативы BPMS движки были сокращены до BPMN.
Ромб с Х - такое описание сделано для простоты понимания схемы, так как не все читатели могут быть знакомы с нотацией. Но чуть выше указанного места я писал, что ромб — это развилка. Боюсь, что объяснить полно и точно назначение всех элементов у меня бы не получилось без потери интереса к материалу.
Некий скрытый процесс. "Некий" он потому, что в рамках диаграммы данный элемент подразумевает разные действия, что нельзя сказать, к примеру, про "Отправку запроса", который всегда выполняет одну и ту же задачу. "Скрытым" он является ввиду специфики реализации - при настройке диаграммы нет возможности как-то изменить логику работы. Если бы мы говорили про "Подпроцесс", который ссылается на другую диаграмму, то там все элементы нам видны и доступны для модификации.
"Колдовство" разработчиков. BPMN-движок является инструментом для работы с BPMN. Он может встраиваться в уже реализованный продукт, либо быть отдельным сервисом. В обоих случаях разработчики принимают участи в этом процессе, так как решение "из коробки" мало когда устраивает. BPMS предоставляет полный набор функций и сервисов, чтобы интегрироваться с системами. Большинство возможностей и кастомизации также могут быть настроено через интерфейс BPMS. Поэтому в сравнении этих двух решений подход через BPMN-движки для стороннего наблюдателя по большей части скрыт".
Будем стараться, чтобы через 5 лет был повод для статьи "Как мы написали свой BPM-движок без мама, пап, регистрации и смс" :)
Вот так ответил нам Александр: "Были такие здоровенные устройства считывания с перфокарт.
Они еще иногда в качестве бонуса разбрасывали введенные перфокарты по всему машинному залу 150-200 м2. При этом перфокарты не были пронумерованы".
А можем даже и ссылку на нее дать: https://www.semanticscholar.org/paper/Programming-language-standardisation-Hill-Meek/530e9b358ccf72712725ae0b8593e2512b305931
Спасибо за Ваш вопрос, внесли также ссылку и уточнения по ней в текст поста.
По теме стандартизации языков программирования.
Мы ввели запрос "человек, собака и кошка гуляют по снегу". Нейросети лучше всего удался снег
Наши представления о среднем программисте основаны на результате анализа текущих запросов в российской IT-отрасли на уровень квалификации сотрудников. Мы проверяем компетенции и навыки, которые востребованы на рынке.
Информацию о ценах можно найти на сайте проекта: https://ibs-training.ru/certification/java/#mainInfo Посмотрите, пожалуйста.
> Как именно осуществляется экспорт будущих интерактивных объектов? Куда при этом деваются аттрибуты, которые мы задавали в мета-данных.
Все данные, нанесенные в Visio, через самописный конвертер укладываются в базу. Так атрибуты графического объекта visio попадают в объект базы. При работе пользователя в веб-интерфейсе определяются координаты клика, и если клик пришелся в границы «интерактивного» объекта, вызываются соответствующие параметры его отображения.
> Как осуществляется привязка этих объектов к растровой подложке
По координатам. Каждая карта имеет нулевую точку, начало координатной системы, относительно которой считается вся геометрия. Дальше алгоритм: клик по карте – определение координат клика – смотрим что под этой координатой – если задано свойство выводить по клику то выводим какую-то карточку.