Это хорошо, когда человек готов сказать «я не знаю». Но гораздо важнее, если затем следует не точка, а запятая.
«я не знаю, но я бы сделал так...»
Пример вопроса: 'что будет, если вызвать метод new File(«foo.txt»).delete()' для залоченного файла?"
«Я не знаю» — достойный ответ, 3 балла.
«Я не знаю, но думаю, что возникнет исключение» — неправильный ответ, но 5 баллов, поскольку именно так и должен был бы вести себя метод, если бы не головотяпство разработчиков из Sun.
Просто незнание — хреново. Незнание + честность — приемлемо. Незнание + мышление — то, что нужно. Доучить — не проблема.
Могу про хардкорные задачки сказать, часто их задают не для того, чтобы получить правильный ответ, а чтобы посмотреть, как кандидат может размышлять и искать решения.
… и если он начинает при этом вставать в позу «да как вы вообще посмели спрашивать меня про виртуальные функции и вообще ваш COM давно устарел» — это самый лучший момент напомнить себе, что дешевле не брать, чем потом увольнять.
Есть у меня, к примеру, в арсенале типовые вопросы про JDBC. И есть опыт принятия на работу двух человек, которые не стали про него рассказывать — первый сходу сказал, что это устаревшая фигня, а второй честно сказал, что никогда с JDBC не работал и использовал только iBATIS. Первый был уволен через 3 месяца ко всеобщей радости (оказалось, что кроме изучения новых технологий ничего делать не может), второй работает уже больше двух лет.
ИМХО это правильно, если конечно тот, кто дает такие задания, сам понимает их цель, а не ждет всегда правильного и точного ответа.
Эт' да, самый страшный кретинизм интервьюера — жесткое бездумное сравнение с эталонными ответами. Написано у него в опроснике, что правильной оценкой для функции вычисления факториала int f(int n) будет O(n) и за решение с O(1) сразу ставит минус. К сожалению, встречается такое сплошь и рядом.
клиентов, жалующихся на то что в каких-то магазинах не работают их карты все больше.
Это решается выставлением штрафных санкций. Если они не предусмотрены договором — это вина вашего коммерческого директора, а не тупой девушки.
звонит и просит выслать копию за вчерашний-позавчерашний день, т.к. кто-то удалил и она не успела выслать. Лезу в базу и выдергиваю вручную, что поделать.
Дополнительная платная услуга. Если вы оказываете ее задарма — объясните опять же своему коммерческому директору, где он облажался. А то, что вы вручную выдергиваете данные — это облажались вы сами.
Вообще, в данном случае больше некомпетентности проявлено со стороны вашего руководства, чем со стороны странной девушки.
Если не упрощенно, то ответ такой: как и везде при проектировании все определяется тем, как планируется эту константу использовать.
Если НУЖНО, чтобы она была заинлайнена — тогда делаем литералом. И пишем комментарий с причиной. Это может иметь смысл, когда мы намеренно требуем обеспечить синхронную пересборку нескольких отдельных единиц деплоймента. Либо если мы ТОЧНО знаем, что эта константа НИКОГДА не может измениться. К примеру, нет причин запрещать инлайнинг константы MONTHS_PER_YEAR.
Во всех остальных случаях безопаснее блокировать инлайнинг.
Т.е. мы имеем два случая:
1. private и package private — пусть инлайнятся.
2. public и protected — разрешаем инлайнинг только если к тому есть явные показания.
(далее — отход от основной темы)
Что до ответственности за продукт — архитектор не должен мыслить категориями «вряд ли». Именно из соображений ответственности.
К примеру, если мы используем как уникальный идентификатор домен сайта компании, то обоснование «он вряд ли изменится» является признаком безответственности. Поскольку после ребрендинга или слияния домен может поменяться, а старый — освободиться и достаться другой конторе. Или его могут тупо продать за стопиццот тыщщ баксов.
Соответственно, вменяемый архитектор хотя бы опишет неизменность домена как assumption в проектных документах. А совсем умный (таких пока не встречал даже в зеркале) не забудет про раздел «управление рисками».
Друзья мои, нехрена столько комментировать мозговой понос журналистов, которым тупо нечего было написать в новостной ленте?
Иногда нам расскажут, что в в нигерии корову смыло в реку, иногда что-нибудь животрепещущее об очередном «обществе полой земли». Незачем тратить время на знакомство с этими отбросами ньюсмэйкинга.
А уж зачем это запощено на хабр — вообще глубокая загадка.
К сожалению, наездом на Xerces автор статьи показал не крутое знание intern, а плохое знание того, как работают константы в Java.
Вопрос о том, зачем в Xerces так написали, задавался неоднократно. И на него есть простой ответ:
It prevents the field being a compile time constant.
References to final String fields which are compile time constants are compiled as a literal, not as an access to the field.
In the example, if there was no .intern(), anything referencing the library would have to be recompiled when the value of the schema namespace is updated. So the authors added 'intern()', making the value not a compile time constant, so the client code desn't have to be rebuilt whhen the library is updated.
Недостаток данной строки в Xerces состоит в том, что не написан комментарий, объясняющий смысл этой операции. А сам код — правильный.
В течении прошлого года я 4 раза убеждался, что даже Senior Java Developer с опытом работы 5-6 лет может не подозревать о механизме инлайнинга констант и о том, какой геморрой это создает в продакшене при выпуске обновлений.
Совершенно стандартный элемент фотооборудования, совершенно неясно, причем здесь гики.
Тем более, что такой мелкий покупать особого смысла нет — оно делается на коленке за 10-15 минут. В пределе — из листа ватмана, табуретки и скотча (3 минуты на сборку).
Прикол в другом: Core wars, на тему которой бредит автор статьи, не требует многозадачности: VM в Core Wars имеет жесткие правила, по которым строго последовательно исполняются инструкции соревнующихся программ. Которые, кстати, вирусами не являются. :)
Зарядное устройство для мобильников, основанное на этом принципе, сделали примерно 7-8 лет назад. Не как концепт, а как промышленный продует. Просто дизайнер не в курсе.
Востребованность этого прибора легко определить, посетив любой магазин, торгующий телефонами и аксуссуарами для них.
Кстати, очень здравая идея: если заказчик осознанно соглашается на то, что его проект будут использовать для обучения — он это указывает и к проекту получают доступ «учебные» исполнители.
«я не знаю, но я бы сделал так...»
Пример вопроса: 'что будет, если вызвать метод new File(«foo.txt»).delete()' для залоченного файла?"
«Я не знаю» — достойный ответ, 3 балла.
«Я не знаю, но думаю, что возникнет исключение» — неправильный ответ, но 5 баллов, поскольку именно так и должен был бы вести себя метод, если бы не головотяпство разработчиков из Sun.
Просто незнание — хреново. Незнание + честность — приемлемо. Незнание + мышление — то, что нужно. Доучить — не проблема.
… и если он начинает при этом вставать в позу «да как вы вообще посмели спрашивать меня про виртуальные функции и вообще ваш COM давно устарел» — это самый лучший момент напомнить себе, что дешевле не брать, чем потом увольнять.
Есть у меня, к примеру, в арсенале типовые вопросы про JDBC. И есть опыт принятия на работу двух человек, которые не стали про него рассказывать — первый сходу сказал, что это устаревшая фигня, а второй честно сказал, что никогда с JDBC не работал и использовал только iBATIS. Первый был уволен через 3 месяца ко всеобщей радости (оказалось, что кроме изучения новых технологий ничего делать не может), второй работает уже больше двух лет.
Эт' да, самый страшный кретинизм интервьюера — жесткое бездумное сравнение с эталонными ответами. Написано у него в опроснике, что правильной оценкой для функции вычисления факториала int f(int n) будет O(n) и за решение с O(1) сразу ставит минус. К сожалению, встречается такое сплошь и рядом.
Это решается выставлением штрафных санкций. Если они не предусмотрены договором — это вина вашего коммерческого директора, а не тупой девушки.
Дополнительная платная услуга. Если вы оказываете ее задарма — объясните опять же своему коммерческому директору, где он облажался. А то, что вы вручную выдергиваете данные — это облажались вы сами.
Вообще, в данном случае больше некомпетентности проявлено со стороны вашего руководства, чем со стороны странной девушки.
Если НУЖНО, чтобы она была заинлайнена — тогда делаем литералом. И пишем комментарий с причиной. Это может иметь смысл, когда мы намеренно требуем обеспечить синхронную пересборку нескольких отдельных единиц деплоймента. Либо если мы ТОЧНО знаем, что эта константа НИКОГДА не может измениться. К примеру, нет причин запрещать инлайнинг константы MONTHS_PER_YEAR.
Во всех остальных случаях безопаснее блокировать инлайнинг.
Т.е. мы имеем два случая:
1. private и package private — пусть инлайнятся.
2. public и protected — разрешаем инлайнинг только если к тому есть явные показания.
(далее — отход от основной темы)
Что до ответственности за продукт — архитектор не должен мыслить категориями «вряд ли». Именно из соображений ответственности.
К примеру, если мы используем как уникальный идентификатор домен сайта компании, то обоснование «он вряд ли изменится» является признаком безответственности. Поскольку после ребрендинга или слияния домен может поменяться, а старый — освободиться и достаться другой конторе. Или его могут тупо продать за стопиццот тыщщ баксов.
Соответственно, вменяемый архитектор хотя бы опишет неизменность домена как assumption в проектных документах. А совсем умный (таких пока не встречал даже в зеркале) не забудет про раздел «управление рисками».
А вот всякие «вряд ли» есть грех.
Что же до «вряд ли будет изменяться» — это из серии «фразы, которые не должен говорить вслух вменяемый архитектор».
Иногда нам расскажут, что в в нигерии корову смыло в реку, иногда что-нибудь животрепещущее об очередном «обществе полой земли». Незачем тратить время на знакомство с этими отбросами ньюсмэйкинга.
А уж зачем это запощено на хабр — вообще глубокая загадка.
Вопрос о том, зачем в Xerces так написали, задавался неоднократно. И на него есть простой ответ:
Недостаток данной строки в Xerces состоит в том, что не написан комментарий, объясняющий смысл этой операции. А сам код — правильный.
В течении прошлого года я 4 раза убеждался, что даже Senior Java Developer с опытом работы 5-6 лет может не подозревать о механизме инлайнинга констант и о том, какой геморрой это создает в продакшене при выпуске обновлений.
Тем более, что такой мелкий покупать особого смысла нет — оно делается на коленке за 10-15 минут. В пределе — из листа ватмана, табуретки и скотча (3 минуты на сборку).
Что касается холивара, то он легко разрешается любым валидирующим парсером и является, в сущности, холиваром за и против чтения спецификаций.
Конкретно о порядке следования см. раздел 3.2
В последних редакциях текст существенных изменений не претерпел.
Не поверите — с версии 1.0. Текстом стандарта интересоваться не пробовали?
А работает оно практически на всем, что шевелится. И, кстати, не многозадачное в классическом смысле.
Востребованность этого прибора легко определить, посетив любой магазин, торгующий телефонами и аксуссуарами для них.