" Фундаментальные знания по информатике с каждым месяцом становятся всё более бесполезными и узкоспециализированными."

Бугагашечки. Узкоспециализированные фундаментальные знания это чтото новое.

"Почему я так легкомысленно отношусь к фундаментальным знаниям? А очень просто. Я закончил 3й курс университета."

Ну это уж совсем бугагашечки. Я рыдалъ.

Не тупиковая — забить на чрезмерно узкую и однобокую специализацию, понять, что Java и технологии вокруг нее это всё мелочь, и развиваться как программист.

Большая читалка нужна, чтобы удобнее было читать статьи в pdf.

Гибкость нужна, чтобы ее нельзя было сломать.

Вот и ответ про «что будет, если школьники друг друга по головам лупить e-reader-ами станут?».

То есть вы не согласны, что чистый XXX-программист (вместо XXX подставить что угодно, начиная с Java) — это ни фига не специалист? Ну, чтобы иметь право быть несогласным с таким мнением, надо как минимум много лет как не быть джуниором.

После такого заголовка ожидал увидеть рассказ про перенос с x86_64 на sparc32…

Так же не ясно, на фига донора-то выключать? cpio или даже tar через netcat прекрасно справились бы. А вообще, практически во всех дистрибутивах есть и штатные средства для клонирования. Скорее всего, федора не исключение.

Ну, вот примерчик реализации (для Java и Clojure):

clojure101.blogspot.com/2009/05/creating-clojure-repl-in-your.html

Есть и вариант наоборот (для .NET и Java и вообще любой рефлексивной среды работает идеально) — встроить в приложение консоль для отладки. REPL какого либо скриптового языка, к которому можно подцепиться telnet-ом, и не прерывая работы выполнить произвольный код в контексте приложения.

Все эти симптомы говорят, что реальная ошибка где-то вовсе за пределами этого блока кода. Довольно редкий случай в .NET, правда, если unmanaged-вызовами особо не баловаться.

А вы лог флашили?

Вообще, первое правило — писать вывод логов и ассерты сразу и везде. Это, кроме всего прочего, еще и дополнительные аннотации к коду, проще читать потом будет. Нельзя проверки просто навешать потом на код вокруг подозрительного места — ведь реально ошибка может быть где-то еще, далеко от того, где все сломалось.

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

А свой код можно и нужно изначально писать так, чтобы пользоваться правильными техниками отладки. Без всяких там break points и прочего.

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

Для «вменяемой отладки» достаточно писать вменяемые логи и расставлять вменяемые ассерты.

О, поколение, испорченное дебаггерами…

Он в 88 году умер.

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

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

Если человек смеет повышать голос, то это паршивый человек, в общем и целом. Работать с паршивым человеком глупо — ничему хорошему у него не научишься, и следовательно никакого смысла оставаться на такой работе нет.

А на фига жить с начальником, который может себе позволить наорать на подчиненного? Странные вы советы даете. Типа, вас имеют, а вы терпите.

Ну, график несколько некорректный. Многочисленные измерения показывают, что средний инженер продуктивен в лучшем случае 4 часа в день. Остальное время он пинает балду, чаи гоняет, делает вид, что думает (без результата), интернет читает, журнальчики. Если всю эту деятельность исключить, то можно уходить домой и раньше.