Здравствуйте, kittown, Вы писали:

K>У нас — возможно. Меж тем, как минимум в java тусовке UBS уже постепенно перестает быть обязательным, так как уже не первый год считается безусловным моветоном. Нужен больше для разгребания legacy проектов, которые раньше действительно делались на spring.
Можно спросить, что же сейчас является хорошим тоном? А то как последний индус все на spring да на spring, и к своему ужасу даже доволен. Какая нидь хрень типа вебсферы чтоль является рулезом сейчас ?

Здравствуйте, zealot111, Вы писали:

Z>Если вам приходится сортировать в 100,000,000 Integer значит у вас ошибка в проектировании приложения. Sad but true. В нормальном JavaEE приложении все это должно делаться на стороне сервера, он и создан для больших объемов информации.
Z>И тем более умение ставить такого рода костыли и подпорки не может считаться признаком высокой квалификации. Поэтому аргументом не является.

Чисто практические соображения. Импорт и экспорт данных в "большой сервер" занимает неприемлемо много времени. Это и был первоначальный вариант, сделано, заоптимизаровано, протестировано, отброшено. Вы мне нарисуете замечательный j2ee сервер, который вчитает этот большой обьем информации минут за 10, а потом выдаст мне его минуты за три (время уйдет в основном на передачу данных). А мне надо за две-три минуты на все. Лучше за одну. Вы только на чтение результатов из сервака потратите больше, поскольку он тупо не сможет разместить все в памяти при его оверхеде на хранение данных, а следовательно, будет подчитывать откуда-нибудь.

Вы не учитываете, что j2ee технологии подразумевают, что обращаться клиенты будут к ограниченному подмножеству данных. Мне же нужны на выходе все сразу. Причем в Java даже массив с таким числом обьектов надорвешься инициализировать — даже если хватит нескольких десятков гигов памяти, сборщик мусора очень сильно расстроится.

За соседним столом люди суют данные для обработки в map/reduce кластер, потому что никакой j2ee такой обьем не проглотит и за подобные потуги на вас посмотрят как на дебила.

K>>На другом проекте народ упорно посылает 100500 пакетов-запросов и тратит полчаса, в то же время пакетная отправка всего этого добра сразу занимает одну секунду. Где тут фреймворки помогут ? Тут нужно, как минимум, общее понимание понятия оверхед. Чтобы он никогда не упускался из виду, т.к. иначе непонятно, допустим он, или нет.

Z>Общее понятие — вещь субъективная. Любой может в этом разобраться если жизнь припрет. Тут нужна только мотивация. В любом случае, заранее узнать какие именно проблемы вылезут в работе на собеседовании невозможно, соответственно невозможно протестировать умение кандидата справляться с такими задачами.
Z>А знание фреймворков проверить легко, и знание это может быть очень полезно в практической работе, когда за считанные дни нужно получить прототип чтобыбыло что показать заказчику.

"Показать прототип заказчику" — это из другой вселенной. У нас скорее показать результат работы прототипа в каком-нибудь csv или excel.

Я успеваю забыть толком большинство фреймворков, с которыми работаю, посколько непосредственно соприкасаюсь с ними несколько раз за время работы над проектом. Первый раз в начале года, когда изучаю приложение с нуля, и в дальнейшем раз-два в квартал, когда что-то из указанных в конфигурации классов перетрясается и надо эти изменения отразить. Речь про spring и прочие файлы конфигурации. Некоторые используют spring больше чем для конфигурации, но таких фанатов надо обходить стороной — мозг целее будет.

K>>На третьем я уже пришел к моменту, когда была порешена одна большая проблема. Состояла в том, что сборщику мусора требовалось убирать очень много мусора и это мешало работе real-time системы. Максимально порезали создание копий тех обьектов, которые наиболее многочисленны, и подобные аналогичные изменения. Какой в такой задаче толк от специалиста по библиотекам?

Z>В такой задаче вообще специалист не нужен. Нужен Кумар, который быстро зароется в гугл и специфическую литературу по проблеме. В оутсорсерских фирмах таких людей много: они сделают специальный логер на аннотациях, разгребут все 100 Мб логов, которые записались за 1с до падения интерпрайс-системы, интегрируют какую-нибудь систему сбора статистики и в конце концов продебажив сурсы SDKшных либ пофиксят проблему. Но можно ли их назвать JavaEE профессионалами? Или это просто очень мотивированные разгребальщики техномусора?

А ничего не падает. Просто к системе предъявляются крайне высокие данные по производительности. У нее вообще не должно было быть заметных остановок на сборку мусора. Биржевая торговля. Хочешь посмешить тех людей, скажи им слово j2ee. Понятно, что большинство что-то в прошлой жизни на j2ee писали, но так же для всех понятно, что кроме jdbc из него ничего в таком проекте в дело не пойдет. Даже мысли такой не возникнет, потому что очевидный бред.

K>>Дойти до данного уровня не очень трудно, но доходят до него редко, и насыщение специалистами, способными решать эти проблемы, точно никогда не наступит. Так что можно на париться. А спецы по библиотекам — 5 рублей пучок.

Z>До уровня проставляльщика подпорок и рогаток? Не смешите публику, это вовсе не умение.

До уровня специалиста по доведению текущих характеристик работы программы, которые при замечательном на бумаге дизайне не решают в конечном счете поставленной задачи. В посещенных мной аутсорсах таких один человек на полсотни. У остальных мозги обладают нормальным IQ, но испорчены детскими представлениями о роли красивого дизайна и архитектуры. Оно конечно вещи хорошие и нужные, но нельзя ставить телегу впереди лошади. Эти вещи вторичны, и если программа с текущим дизайном не выдает нужных показателей, то этот дизайн, вне зависимости от его устройства, заведомо кривее любого другого дизайна, невзирая на его кажущуюся кривость, при котором нужные показатели достигаются.

Здравствуйте, elmal, Вы писали:

E>Здравствуйте, kittown, Вы писали:

K>>У нас — возможно. Меж тем, как минимум в java тусовке UBS уже постепенно перестает быть обязательным, так как уже не первый год считается безусловным моветоном. Нужен больше для разгребания legacy проектов, которые раньше действительно делались на spring.
E>Можно спросить, что же сейчас является хорошим тоном? А то как последний индус все на spring да на spring, и к своему ужасу даже доволен. Какая нидь хрень типа вебсферы чтоль является рулезом сейчас ?

У нас в выборе языков и инструментов гораздо чаще ориентируются на моду и на понты, чем "там". В частности, в тех же банках народ не парится писать свои велосипеды, если они обьективно лучше "общепринятых" библиотек. Больше ориентация на полезность, меньше на моду и понты. Вопрос "что является рулезом сейчас" многие просто не поймут. Обьективно spring в большом числе проектов оказался использован ровно для того, что можно было прекрасно написать и на обычном java коде — типа, сделать пяток обьектов, и передать их для инициализации шестого. Из других заметных фич, кроме инициализации, вспоминается только поддержка jdbc транзакций, но и эта штука ограниченной полезности. Предыдущий проект обращался к 3-4 разным источникам данных без какой-либо поддержки транзакционности с их стороны. Как раз пример, где spring не давал вообще ничего.

Но в РФ своя специфика. тут он моден.

Здравствуйте, zealot111, Вы писали:

Z>Редкие фреймворки представляют из себя сложность, но каждый фреймворк или либа — это определенное время потраченное на их изучение. Если человек знает фреймворки, то влиться в работу команды, которая разрабатывает приложение с их использованием он сможет почти сразу. А если нет — то ему понадобится время на их освоение. Если количество либ, которые нужно освоить велико — проект в который его набирают может закончиться раньше чем он разберется. А это время и деньги.

Да, поэтому предпочтительнее, чтобы человек уже знал либы. Но если не знает те, что нужны здесь и сейчас, но во всем остальном очень хорош, то можно запросто взять. Конечно, зависит от проекта и стадии, на которой он находится. Но в целом у нас как-то так.

Z>Это та задача где нужно догадаться, что вызовется перегруженный метод для нижайшего по иерархии класса? Такие задачи вообще по-моему неуместны на собеседованиях.

ОМГ. Уже сам базис ООП не уместен при собеседовании ява-программиста. Что тогда уместно? Достаточно, чтобы слюна не капала и пузыри из носа не пускал? Или опыт работы с библиотекой Dozer является достаточным для приема на работу?

Z>Потому что ответ или не ответ на них не дает никакой информации собеседующему, только время зря тратится.

Поверь, это не так. Причем могу заметить, что если человек лажал с этим простым тестом, то он лажал и по всем остальным вопросам тоже. Мог отлично справиться с этим тестом, но провалить остальные вопросы. Мог все ответить и там, и там. Но ни разу, чтобы провалить тест, но быть хотя бы средним в остальных темах собеседования.

Z>Есть мнение, что в ООП ничего понимать и не нужно, главное при проектировании насоздавать побольше классов.

Интересное мнение. Надеюсь, у нас оно не приживется.

Z>Да, так ли уж неправы те, кто считает знание сложности алгоритмов академическим знанием? Насколько часто оно используется? Мне, честно говоря, оно пригождается только для прохождения собеседований.

И снова одно и то же...
Да, оно используется не так часто, как создание пожо-объектов. Но, как и огнетушитель, который не нужен в 99% времени, без подобных знаний бывает никуда в какой-то момент времени.

Z>Эффект давно описан и относится это не только к Яве, но и к Це++ и пр.

Это даже не только к разработке относится, а вообще к отношению человека к работе.
Кстати, не дашь ссылку, где можно почитать?

Здравствуйте, kittown, Вы писали:

K>>>У нас — возможно. Меж тем, как минимум в java тусовке UBS уже постепенно перестает быть обязательным, так как уже не первый год считается безусловным моветоном. Нужен больше для разгребания legacy проектов, которые раньше действительно делались на spring.

UBS тусовка — это что, если не секрет?

K>У нас в выборе языков и инструментов гораздо чаще ориентируются на моду и на понты, чем "там". В частности, в тех же банках народ не парится писать свои велосипеды, если они обьективно лучше "общепринятых" библиотек. Больше ориентация на полезность, меньше на моду и понты. Вопрос "что является рулезом сейчас" многие просто не поймут. Обьективно spring в большом числе проектов оказался использован ровно для того, что можно было прекрасно написать и на обычном java коде — типа, сделать пяток обьектов, и передать их для инициализации шестого.

У нас — это где? Сижу над проектам европейского банка. Везде Spring. Но, думаю, все-таки не потому, что он "моден", а потому что ведущие разработчики в курсе про IoC паттерн.

K>Но в РФ своя специфика. тут он моден.

Ага. И спецификацию на CDI в Оракле тоже чертовы русские протащили

Здравствуйте, Donz, Вы писали:

D>Да, поэтому предпочтительнее, чтобы человек уже знал либы. Но если не знает те, что нужны здесь и сейчас, но во всем остальном очень хорош, то можно запросто взять. Конечно, зависит от проекта и стадии, на которой он находится. Но в целом у нас как-то так.

Чего в этом спринге-то знать, его за дня три — четыре можно вдоль и поперёк освоить, я главы 4-6 мануала за три дня прочитал.

D>ОМГ. Уже сам базис ООП не уместен при собеседовании ява-программиста. Что тогда уместно? Достаточно, чтобы слюна не капала и пузыри из носа не пускал? Или опыт работы с библиотекой Dozer является достаточным для приема на работу?

ООП конечно знать нужно, но знание ООП это такая мелочь на фоне всего того объёма материла который нужно знать, что я бы даже не упоминал бы тут ООП.

Z>>Да, так ли уж неправы те, кто считает знание сложности алгоритмов академическим знанием? Насколько часто оно используется? Мне, честно говоря, оно пригождается только для прохождения собеседований.

Вот из-за такого отношения к алгоритмам наблюдаю истории когда парсер парсит по два часа. Полез в код, а там vector удаляет элемент в позиции отличной от конечной, что вызывает на каждой итерации перемещение элементов вектора в памяти, поправил, в итоге отрабатывает за пару минут. Ещё примеры полезности знания временной сложности алгоритмов нужны?

Здравствуйте, Donz, Вы писали:

D>ОМГ. Уже сам базис ООП не уместен при собеседовании ява-программиста. Что тогда уместно? Достаточно, чтобы слюна не капала и пузыри из носа не пускал? Или опыт работы с библиотекой Dozer является достаточным для приема на работу?

Там было написано не про это, но вы удивитесь. (с) Принцип инкапсуляции — всех волнует, а вот остальное — бывает по-разному... Где-то открыто запрещают пользоваться наследованием.

Z>>Да, так ли уж неправы те, кто считает знание сложности алгоритмов академическим знанием? Насколько часто оно используется? Мне, честно говоря, оно пригождается только для прохождения собеседований.

D>И снова одно и то же...
D>Да, оно используется не так часто, как создание пожо-объектов. Но, как и огнетушитель, который не нужен в 99% времени, без подобных знаний бывает никуда в какой-то момент времени.

Я как-то раз пытался пояснить крепкому знатоку дотнета, почему нельзя очищать массив/вектор/список и тому подобные структуры методом collection.removeAll(collection). Не почему плохо и глупо, это всем понятно, а почему вообще нельзя. Вопрос об алгоритмической сложности сразу привел бы человека в чувство.

Здравствуйте, Donz, Вы писали:

D>UBS тусовка — это что, если не секрет?

Банк такой.

D>У нас — это где? Сижу над проектам европейского банка. Везде Spring. Но, думаю, все-таки не потому, что он "моден", а потому что ведущие разработчики в курсе про IoC паттерн.

Он широко применялся некоторое время назад. Сейчас все, с кем пересекался, уже наелись и стараются искоренять. У нас еще не наелись, у нас (под российским менеджментом) — рост. Под тем же флагом отделения конфигурации от кода, хотя реально это ближе к коду на птичьем языке, чем к конфигурации.

Здравствуйте, sysenter, Вы писали:

S>Чего в этом спринге-то знать, его за дня три — четыре можно вдоль и поперёк освоить, я главы 4-6 мануала за три дня прочитал.

Кроме Spring Beans там много еще чего полезного. И прочитать != понять. Не хочу сказать, что конкретно ты ничего не понял, но делать подобные утверждения надо с аргументацией. Трехдневное обучение Spring Core не просто так стоит около трех килобаксов. И не просто из-за моды Spring является стандартом де-факто, а также катализатором для выпуска CDI.

S>ООП конечно знать нужно, но знание ООП это такая мелочь на фоне всего того объёма материла который нужно знать, что я бы даже не упоминал бы тут ООП.

Арифметика тоже мелочь, но без нее даже шаурмой торговать не получится.

S>Вот из-за такого отношения к алгоритмам наблюдаю истории когда парсер парсит по два часа. Полез в код, а там vector удаляет элемент в позиции отличной от конечной, что вызывает на каждой итерации перемещение элементов вектора в памяти, поправил, в итоге отрабатывает за пару минут. Ещё примеры полезности знания временной сложности алгоритмов нужны?

Поддерживаю. Только этот абзац написан не по адресу.

Здравствуйте, kittown, Вы писали:

D>>ОМГ. Уже сам базис ООП не уместен при собеседовании ява-программиста. Что тогда уместно? Достаточно, чтобы слюна не капала и пузыри из носа не пускал? Или опыт работы с библиотекой Dozer является достаточным для приема на работу?
K>Там было написано не про это, но вы удивитесь. (с) Принцип инкапсуляции — всех волнует, а вот остальное — бывает по-разному... Где-то открыто запрещают пользоваться наследованием.

Наследование и полиморфизм — одни из краеугольных камней ООП. Их и проверяет этот простейший тест. Где-то кто-то может быть и запрещает пользоваться наследованием, но мы набираем народ к себе, а не к кому-то. Но я бы с удовольствием глянул код на Java, в котором запрещено наследование и полиморфизм.

K>Я как-то раз пытался пояснить крепкому знатоку дотнета, почему нельзя очищать массив/вектор/список и тому подобные структуры методом collection.removeAll(collection). Не почему плохо и глупо, это всем понятно, а почему вообще нельзя. Вопрос об алгоритмической сложности сразу привел бы человека в чувство.

Ну что ты так сразу. Надо же сначала провести профилирование, обозначить узкие места в проекте, выяснить, является ли эта операция узким место, и только после этого может быть включить мозг. А если вдруг надо проект срочно заканчивать, то однозначно мозг включать не нужно, потому что "купить более дорогие сервера дешевле, чем нанять нормального специалиста". Но если на самом деле этот кусок кода не является самым узким местом, то однозначно хрен бы с ним. Работает "равнение на помойку" — у нас воняет не так противно, как у соседей.
Печально, конечно.

Здравствуйте, Donz, Вы писали:

D>Кроме Spring Beans там много еще чего полезного. И прочитать != понять. Не хочу сказать, что конкретно ты ничего не понял, но делать подобные утверждения надо с аргументацией. Трехдневное обучение Spring Core не просто так стоит около трех килобаксов. И не просто из-за моды Spring является стандартом де-факто, а также катализатором для выпуска CDI.

Всё что читаю понимаю т.к. читаю по несколько раз пока понимать не начинаю.)
Трёх дневное обучение Spring Core может стоить и пять килобаксов пока есть люди которые не верят в свои силы самостоятельно овладеть этой технологией. По факту в спринге нет вообще ничего сложного, нужен только английский и небольшое знание джавы.
Кстати прикол, я саму джаву очень не плохо освоил вот только опыта работы у меня с ней нету и на собеседования не зовут. Полагаю именно для этого в том числе и придуманы все эти платные курсы, чтобы денег заработать на соискателях и отучить думать самостоятельно)
Насчёт отучить думать самостоятельно я говорю вполне серьёзно, после С++ тот же Хостман оба тома читаются дня за четыре — пять в лёгкую. + неделя на освоение Servlets, JSP, JSTL по спецификациям c jcp.org и день/пол дня на tomcat, вот и всё время которое нужно потратить на освоение джавы, за что платит деньги не понятно.

Здравствуйте, kittown, Вы писали:

D>>UBS тусовка — это что, если не секрет?
K>Банк такой.

Объявить аспекты разработки одной организации трендом всего прогрессивного рассудительного ява-сообщества — это, конечно, сильно.

D>>У нас — это где? Сижу над проектам европейского банка. Везде Spring. Но, думаю, все-таки не потому, что он "моден", а потому что ведущие разработчики в курсе про IoC паттерн.
K>Он широко применялся некоторое время назад. Сейчас все, с кем пересекался, уже наелись и стараются искоренять. У нас еще не наелись, у нас (под российским менеджментом) — рост. Под тем же флагом отделения конфигурации от кода, хотя реально это ближе к коду на птичьем языке, чем к конфигурации.

Если выбирать между предложенной тобой явной инициализацией в яве и спринговым xml'ем или аннотациями, то однозначно лучше последнее. Потому что IoC, как уже упоминал.
Меня тоже напрягают простыни из XML, но какова реальная альтернатива Spring'у или CDI? Только чур опять не предлагать вручную создавать объекты в яве. Или как минимум аргументированно объяснить, почему IoC не нужен.

Здравствуйте, Donz, Вы писали:

D>Меня тоже напрягают простыни из XML, но какова реальная альтернатива Spring'у или CDI? Только чур опять не предлагать вручную создавать объекты в яве. Или как минимум аргументированно объяснить, почему IoC не нужен.

Не так уж и сложно самому инициализировать объекты, по времени это не на много более затратно. А вот hibernate штука полезная в плане быстрой инициализации объекта данными их БД, только опять же отучает думать и писать SQL запросы.

Здравствуйте, Donz, Вы писали:

D>Здравствуйте, kittown, Вы писали:

D>>>ОМГ. Уже сам базис ООП не уместен при собеседовании ява-программиста. Что тогда уместно? Достаточно, чтобы слюна не капала и пузыри из носа не пускал? Или опыт работы с библиотекой Dozer является достаточным для приема на работу?
K>>Там было написано не про это, но вы удивитесь. (с) Принцип инкапсуляции — всех волнует, а вот остальное — бывает по-разному... Где-то открыто запрещают пользоваться наследованием.

D>Наследование и полиморфизм — одни из краеугольных камней ООП. Их и проверяет этот простейший тест. Где-то кто-то может быть и запрещает пользоваться наследованием, но мы набираем народ к себе, а не к кому-то. Но я бы с удовольствием глянул код на Java, в котором запрещено наследование и полиморфизм.

Хороший код. Но если бы правила не придерживались последовательно везде и всюду — был бы, наверно, отстойный.

Про краеугольный камень в курсе. Мой главный пойнт в этой дискуссии — что бы вам не казалось, все наверняка чудесатее, чем вам кажется.

K>>Я как-то раз пытался пояснить крепкому знатоку дотнета, почему нельзя очищать массив/вектор/список и тому подобные структуры методом collection.removeAll(collection). Не почему плохо и глупо, это всем понятно, а почему вообще нельзя. Вопрос об алгоритмической сложности сразу привел бы человека в чувство.

D>Ну что ты так сразу. Надо же сначала провести профилирование, обозначить узкие места в проекте, выяснить, является ли эта операция узким местом

N^2 — почти всегда является, если элементов много. Профилирование только подтверждает диагноз и позволяет найти менее очевидные места.

D>А если вдруг надо проект срочно заканчивать, то однозначно мозг включать не нужно, потому что "купить более дорогие сервера дешевле, чем нанять нормального специалиста". Но если на самом деле этот кусок кода не является самым узким местом, то однозначно хрен бы с ним. Работает "равнение на помойку" — у нас воняет не так противно, как у соседей.
D>Печально, конечно.

Данные списки содержали что-то вроде строчек таблицы в excel. Зачищались при переходе на другой таб и наполнялись потом снова. И народ, действительно, терпеливо ждал открытия нового таба до получаса.

Здравствуйте, Donz, Вы писали:

D>>>UBS тусовка — это что, если не секрет?
K>>Банк такой.

D>Объявить аспекты разработки одной организации трендом всего прогрессивного рассудительного ява-сообщества — это, конечно, сильно.

Дело в кадрах, которые они набирают. В c++ группе, помню, был один из разработчиков стандарта оного языка. В oracle и java группах состав не слабее. Организации организациям рознь.

D>Если выбирать между предложенной тобой явной инициализацией в яве и спринговым xml'ем или аннотациями, то однозначно лучше последнее. Потому что IoC, как уже упоминал.

Не однозначно. Когда-то так, когда-то иначе. Если инициализация в xml меняется с той же частотой, с какой менялась бы инициализация непосредственно в коде, то профит неясен.

D>Меня тоже напрягают простыни из XML, но какова реальная альтернатива Spring'у или CDI? Только чур опять не предлагать вручную создавать объекты в яве. Или как минимум аргументированно объяснить, почему IoC не нужен.

Обьясните лучше, для чего он нужен, на примере, когда отличия всех конфигураций сведены в properties файлы, autowire не используется, а транзакционность не нужна.

Здравствуйте, kittown, Вы писали:

K>Обьясните лучше, для чего он нужен, на примере, когда отличия всех конфигураций сведены в properties файлы, autowire не используется, а транзакционность не нужна.
Чем я пользуюсь:
Как минимум аспекты. Аспектами можно прозрачно выполнять асинхронные задачи, логировать, кешировать, лочить по составным ключам параметров. И я подохреваю, что я еще не очень сильно аспекты применяю по сравнению с другими. Система событий в спринге тоже довольно неплохая.Тоже пользуюсь без фанатизма, но очень доволен.
Дополнительно тестировать очень неплохо получается, хоть и не фанат я этого дела. Автоматом генерятся моки и я могу легко протестировать, что такой то сервер действительно дернулся и именно с такими параметрами.
Если что, у меня тоже отличие всех конфигураций сведены в properties файлы. Транзакуионность мне тоже не нужна. Вот только autowire очень активно использую.
Если что, у меня мозгов хватит написать то, чем пользуюсь в спринге самостоятельно. Вопрос только нахрена мне это? В реальной работе не требуется, а чтоб собеседования проходить лучше — нахрен мне это надо, пусть лучше субеседующим сделаю приятное и они смогут порадоваться своей высочайшей квалификации на моем фоне, что постоянно пишут свои реализации строк, XML парсеры и тому подобное.

Здравствуйте, elmal, Вы писали:

E>Здравствуйте, kittown, Вы писали:

K>>Обьясните лучше, для чего он нужен, на примере, когда отличия всех конфигураций сведены в properties файлы, autowire не используется, а транзакционность не нужна.
E>Чем я пользуюсь:
E>Как минимум аспекты. Аспектами можно прозрачно выполнять асинхронные задачи, логировать, кешировать, лочить по составным ключам параметров. И я подохреваю, что я еще не очень сильно аспекты применяю по сравнению с другими. Система событий в спринге тоже довольно неплохая.Тоже пользуюсь без фанатизма, но очень доволен.
E>Дополнительно тестировать очень неплохо получается, хоть и не фанат я этого дела. Автоматом генерятся моки и я могу легко протестировать, что такой то сервер действительно дернулся и именно с такими параметрами.

А. Видел такое. Это серьезно отличающаяся от привычных мне сред и мне эти вещи не нужны. Другие аспекты на первом плане (в обычном смысле слова аспект). Я бы добавил в этот список еще шедулинг.

В общем, сдам немного назад — в отдельных анклавах (необязательно маленьких) инструмент применим. Но во многих других — как говорится, ненужен.

E>Если что, у меня мозгов хватит написать то, чем пользуюсь в спринге самостоятельно. Вопрос только нахрена мне это? В реальной работе не требуется, а чтоб собеседования проходить лучше — нахрен мне это надо, пусть лучше субеседующим сделаю приятное и они смогут порадоваться своей высочайшей квалификации на моем фоне, что постоянно пишут свои реализации строк, XML парсеры и тому подобное.

Я пишу свое не из желание написать что-то этакое — наоборот, обожаю удалять нафиг свой код и заменять чем-то, написанным более умными людьми. Просто это удается все реже и реже; регулярно попадаю на задачи, где этим не обойдешься.

Здравствуйте, kittown, Вы писали:

K>Я как-то раз пытался пояснить крепкому знатоку дотнета, почему нельзя очищать массив/вектор/список и тому подобные структуры методом collection.removeAll(collection). Не почему плохо и глупо, это всем понятно, а почему вообще нельзя. Вопрос об алгоритмической сложности сразу привел бы человека в чувство.

И почему?
В джаве что, очистка коллекции требует прохода по всей этой коллекции?

Фреймворк, где вообще нельзя очищать массивы\векторы\списки это

Z>И тем более умение ставить такого рода костыли и подпорки не может считаться признаком высокой квалификации. Поэтому аргументом не является.

А что, по-вашему, является признаком высокой квалификации?

Z>Общее понятие — вещь субъективная. Любой может в этом разобраться если жизнь припрет. Тут нужна только мотивация. В любом случае, заранее узнать какие именно проблемы вылезут в работе на собеседовании невозможно, соответственно невозможно протестировать умение кандидата справляться с такими задачами.
Z>А знание фреймворков проверить легко, и знание это может быть очень полезно в практической работе, когда за считанные дни нужно получить прототип чтобыбыло что показать заказчику.

Вы сами себе противоречите. С одной стороны, вы пишете, мол, что умение быстро поставить костыль и подпорку не является признаком квалификации. В то же время, знание фреймворков для установки этих костылей — вроде как и признак Вы определитесь, какая польза от знания фреймворков, и с каких пор фреймворки стали важнее основ?

Z>В такой задаче вообще специалист не нужен. Нужен Кумар, который быстро зароется в гугл и специфическую литературу по проблеме.

Кумар — профессионал или нет? Он знает фреймворк, умеет гуглить.

Z>Есть даже профессия специальная — С++ программист, вся работа которого и заключается в том чтобы вставлять хаки и подпорки. Но к профессионализму это тоже имеет весьма опосредованное отношение, увы.

О-о-о, как вы хорошо по С++ программистам
Вас они чем-то обидели? Или просто ваше кунг-фу (на каком языке, простите?) лучше их?

Здравствуйте, Donz, Вы писали:

Z>>Это та задача где нужно догадаться, что вызовется перегруженный метод для нижайшего по иерархии класса? Такие задачи вообще по-моему неуместны на собеседованиях.

D>ОМГ. Уже сам базис ООП не уместен при собеседовании ява-программиста. Что тогда уместно? Достаточно, чтобы слюна не капала и пузыри из носа не пускал? Или опыт работы с библиотекой Dozer является достаточным для приема на работу?

Причем здесь базис? Скорее тонкости реализации ООП в Джава.

Z>>Есть мнение, что в ООП ничего понимать и не нужно, главное при проектировании насоздавать побольше классов.
D>Интересное мнение. Надеюсь, у нас оно не приживется.

Особенность ООП в том, что это не какая-то научная теория у которой разночтений быть не может, а скорее полуфилософская доктрина, которая утверждает что создавать классы хорошо и если так делать, то во всем мире наступит счастье. И которую каждый понимает немного по-своему, отсюда кстати и такое количество споров по ООП. Спорная концепция рождает споры, да. Является ли ремесло ООП подлинным профессиональным знанием — предмет дискуссии.

Z>>Да, так ли уж неправы те, кто считает знание сложности алгоритмов академическим знанием? Насколько часто оно используется? Мне, честно говоря, оно пригождается только для прохождения собеседований.
D>И снова одно и то же...
D>Да, оно используется не так часто, как создание пожо-объектов. Но, как и огнетушитель, который не нужен в 99% времени, без подобных знаний бывает никуда в какой-то момент времени.
Так это про любые знания из учебника можно сказать, нет? Обычно люди на собеседованиях спрашивают только ту теорию которая им лично в жизни хоть раз пригодилась, а всю остальную почему-то игнорируют. Как вы сами отнесетесь например к тому, что на собеседовании вас попросят написать реализацию решения дифф. ур-я методом Рунге-Кутта?

Z>>Эффект давно описан и относится это не только к Яве, но и к Це++ и пр.
D>Это даже не только к разработке относится, а вообще к отношению человека к работе.
D>Кстати, не дашь ссылку, где можно почитать?
К сожалению, конкретных ссылок предоставить не могу. Но любая нытик-тема на скл.ру плавно переходит в эту плоскость, давая пищу размышлениям о человеческой природе.