Иван, без обид, но лучше бы ты своим студентам объяснял чем Set от List отличается. И можно ли про Set утверждать что там нет дубликатов, если это интерфейс, который на реализацию ограничений не накладывает (да? нет? почему?).
Про кодировки интернам/джунам достаточно знать что они вообще разные есть.

Может, дело вот в этом:
docs.spring.io/...ble-default-key
?

Вообще штрафы — не редкость в договорах с СПД. Вносят их туда специально, чтобы «отношения не носили характер трудовых». Другое дело что цифры там обычно порядка 0,01% — 0,1%, и я никогда не слышал чтобы эти пункты реально работали.

Выходит, что правильно обратиться к такому филду просто невозможно, и это собственно и есть то самое «почему» его нельзя объявить.

А чего это ты через инстанс обращаешься? Обратись через класс!

В жаве членом класса может (кроме полей и методов) быть еще и класс (внутренний). И он, как и другие члены класса, может быть статическим или не статическим.

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

Попробуй написать обращение к такому полю, и ты сам сразу увидишь почему нельзя.

Ну и с JBoss’ом я бы посоветовал быть осторожным) Запросто можно при попытке написать что-то простое нарваться на «а, не, это мы еще не заимлементили, запланировано на релиз X.Y.zz»

Hadoop подходит для ситуации «много данных — простые вычисления». То есть у тебя есть 100500 террабайт данных, которые рассеяны по 1050 серверам, и тебе надо посчитать сколько раз там встречается слово «fcuk». Он не для построения классических бизнес-приложений.

Какое-то оочень сильное предположение, которое с реальностью не вяжется. Руки у всех разные, с разной кривизной. Если взять «в среднем», то они будут отнюдь не идеальной прямоты, и следование DRY все-таки приведет к более сложному с точки зрения организации коду, нежели KISS.

Потому что отсутсвие повторения [кода] ведет совсем не к simple&stupid решениям, а к сложным абстракциям с кучей слоев и т.д. Не, конечно лучше быть богатым и здоровым чем бедным и больным, но в реальности в лучшем случае можно выбрать что-то одно.

Дарова!)

тяжело сказать т.к. я не знаю структуру компании

В смысле ты спрашиваешь пойти ли на собеседование? Конечно пойти. А там и сам мнение составишь.

Про какую именно часть CS интересны отзывы? Это конечно не гигант-аутсорсер, где каждый проект это отдельный мир со своими законами, но все же. Я работал в iFOBS, нравилось.

Я конечно не самоубийца делать что либо подобное

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

Конечно в разные. В первом случае при открытой критике во время будущих поисков работы он рискует что его резюме окажется в самом низу стопки, поэтому лучше бы ему молчать. А во втором случае — он может спокойно сказать «как есть». Какой из вариантов полезнее? Ааа, сори, вы представитель лагеря работодателей.. тогда да, конечно, полезнее первый)

Макс «не хочет принципиально» анонимных комментов. Ок, в таком случае неанонимные — это какие? Или об этом никто не думал, потому что включать их обратно не планировалось?

Ну и кроме того, «деанонимизация» конечно классное слово, но как вы РЕАЛЬНО собираетесь этого добиться? Регистрация на линкед-ине ничем не сложнее регистрации на ДОУ. Или для того чтобы комментарий к компании написать нужно будет нотариально заверенный скан трудовой/договора администрации выслать?

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