Конечно исправление в журнале ловится, потому что у каждого преподавателя есть свой личный журнал-блокнот, который он никогда не выпускает из рук. И даже если школа сгорит, на следующий день коллектив восстановит всю историю за текущий учебный год по личным записям (кроме, наверное, физкультуры).
Насчет ноль полезности, это вы смотрите с точки зрения учителей, а для родителей электронные дневники очень полезны.
При обнаружении уязвимости следует сообщить владельцу ресурса, а не трезвонить в интернете. Опубликовать статью об этом можно будет тогда, когда разработчики сообщат о том, что они все пофиксили. Если же вендор проигнорировал сообщение об уязвимости, то сначала его следует уведомить о своем намерении опубликовать информацию о дыре, и только потом можно писать. Именно такое поведение отличает специалиста по информационной безопасности от хакера-хулигана.
В Weblogic точно так же в xml файлах лежат открытые пароли. Так гораздо честнее, чем делать вид, что пароли якобы защищены. Администратор знает, какие файлы надо беречь от посторонних глаз. А системы, где пароли как бы зашифрованы, дают ложное ощущение безопасности. Владелец ресурса думает, что пароли посторонним недоступны, а взломщик, который знает детали реализации, достает их в два счета.
Единственный вариант безопасного хранения паролей — шифровать их ключом, который запрашивается при запуске. В этом случае пароль будет лежать в открытом виде только в памяти. Но тогда теряется возможность автоматического перезапуска сервера в случае аппаратных или системных сбоев.
Возвращать надо не java.sql.Connection, а обертку, у которой метод close() возвращает соединение в пул. Ведь Connection у нас реализует интерфейс AutoCloseable.
Я очень быстро разобрался с такими мыслями. Код я пишу так:
1. Подумал о правах доступа? — Пишу в комментарии: «Файлы создаются с правами доступа по умолчанию. Желающие изменить права доступа на особые призываются сделать это после вызова данного метода».
2. Подумал о занятии файла другим приложением? — Пишу в комментарии: «Класс рассчитывает на то, что другие приложения не будут открывать указанный файл во время выполнения данного метода».
3. Подумал о многопоточности? — Пишу: «Внимание! Класс не thread-safe».
4. Пришла мысль об атомарных операциях? — См. пункт 3.
5. О фреймворках? — Завожу тикет в джире на будущий рефакторинг.
6. О разных файловых системах за меня подумали разработчики виртуальной машины Java.
7. О количестве файлов в директории пусть думают сисадмины.
8. О предсказуемых названиях временных файлов я уже заранее подумал, поэтому у меня есть проверенные заготовки.
9. Появились сомнения качестве моего ГСПЧ? — // TODO использовать безоспасный Random.
10. Нормальная документация? Да вот же она. Уже готова.
Данная проблема называется «увеличения скоупа работ». Это стандартный проектный риск. Существует несколько способов управления данным риском. То, что я описал, это самый универсальный метод, остальные желательно согласовывать с заказчиком.
Насчет ноль полезности, это вы смотрите с точки зрения учителей, а для родителей электронные дневники очень полезны.
1. Подумал о правах доступа? — Пишу в комментарии: «Файлы создаются с правами доступа по умолчанию. Желающие изменить права доступа на особые призываются сделать это после вызова данного метода».
2. Подумал о занятии файла другим приложением? — Пишу в комментарии: «Класс рассчитывает на то, что другие приложения не будут открывать указанный файл во время выполнения данного метода».
3. Подумал о многопоточности? — Пишу: «Внимание! Класс не thread-safe».
4. Пришла мысль об атомарных операциях? — См. пункт 3.
5. О фреймворках? — Завожу тикет в джире на будущий рефакторинг.
6. О разных файловых системах за меня подумали разработчики виртуальной машины Java.
7. О количестве файлов в директории пусть думают сисадмины.
8. О предсказуемых названиях временных файлов я уже заранее подумал, поэтому у меня есть проверенные заготовки.
9. Появились сомнения качестве моего ГСПЧ? — // TODO использовать безоспасный Random.
10. Нормальная документация? Да вот же она. Уже готова.
Данная проблема называется «увеличения скоупа работ». Это стандартный проектный риск. Существует несколько способов управления данным риском. То, что я описал, это самый универсальный метод, остальные желательно согласовывать с заказчиком.
<habracut/>
Я, пожалуй, с вами соглашусь. Лучше сделать код понадежнее, чем потом отлавливать неочевидные эффекты многопоточности.