Из личного опыта советую в качестве учебных тасков давать ребятам задачи из реальных проектов. Например, в рамках opensource.
На нашей практике по Java студенты, к примеру, занимаются расширением Checkstyle и связанных с ним проектов с открытыми исходниками
Согласен, в свои 23 с улыбкой часто ловлю себя на том, что использую знания, добытые еще в дестве за чтением «детских энциклопедий», лет эдак в 8-10 :)
Хорошо написано. Отдельное спасибо за видео «космос: пространство и время». Смотрю запоем :)
Я рос когда-то на чудесных детских энциклопедиях «Росмэн». До сих пор храню для нового поколения почти полное собрание… такие книги никогда не устаревают и, разумеется, их никак не заменишь ни читалкой, ни любым другим электронным аналогом )
Массивной логике на PL\SQL часто присущи проблемы с тестированием и дальнейшей поддержкой, однако, в любом случае, разработчики Oracle — молодцы, возможности этой СУБД поражают.
А нас (Checkstyle) в этом году таки приняли, может, теперь наши посты начнут потихоньку из sandbox «в люди» вытаскивать :)
В прошлом году выставляли на GSOC менее крупный проект (основной проект Checkstyle в прошлом году мы не успели полностью перенести на GitHub, да и не до того было) — и не прошли. Так что на этот раз все сложилось намного удачнее )
Проблема с @Autowired в следующем. Представьте, что вы написали код, просетив в нем значения филдов через @Autowired на самих private — филдах. Следующий человек вполне может прийти в тот же код после вас и дописать свои сеттеры для тех же филдов (это может быть, например, необходимо для Unit — тестов, либо такое происходит, если функционал класса изменяется и get/set — методы становятся результатом рефакторинга). И в результате пересетить ваши значения, что иногда может вести к весьма странным ситуациям. Если класс больших размеров, то такую ситуацию несложно не заметить. Плюс существует правило, говорящее, что любой field, участвующий в логике, должен иметь паблик-сеттер/геттер для того, что программист мог видеть, что необходимо для работы с данным классом. Плюс декларирования одинакового стиля инжектирования зависимостей для всего проекта, что может быть полезным с точки зрения стиля кода. Поэтому вполне стоит с помощью Checkstyle запретить @Autowired на private — филдах и разрешить @Autowired только на соответствующих сеттерах. В случае исключений можно отключить чекстайл напрямую для участка кода (методов или филдов) с помощью комментария вида:
// SUPPRESS CHECKSTYLE <Имя чека> <Комментарий>
Конечно, мы предлагаем многие чеки, написанные нами, в качестве патчей к основному проекту Checkstyle. Их легко можно найти на патч-трекере Checkstyle. Но пока чеки еще не приняты, или если они не приняты вообще — мы легко можем все равно (никому не мешая =) ) использовать их в разработке, добавляя в наше дополнение.
Все чеки, внесенные в наше дополнение (как, собственно, тут и сказано), объединены в отдельный проект. Этот проект является «плагином к плагину» для eclipse-cs. Собирается проект в jar-файл, содержащий только наши дополнительные чеки с необходимыми конфигурационными файлами. Благодаря сотрудничеству со стороны держателей проекта Eclipse-cs (за что мы им очень благодарны), данный jar подхватывается Eclipse Checkstyle плагином, но только совместно с официальной библиотекой Checkstyle. Таким образом, при добавлении своих чеков, мы всегда обходимся без изменения исходного кода основной библиотеки Checkstyle. Насчет лицензии: Checkstyle распространяется по GNU LGPL, со всеми вытекающими.
Flammar, поясните, пожалуйста, подробнее. Есть ли конкретный пример кода, на котором в Checkstyle следует подавлять ворнинги в случаях с дженериками и вараргами?
Полностью согласен с knekrasov, переписыванием лишь кода класса TreeWalker и подменой ANTLR-грамматики изменение кода Checkstyle под новый язык явно не обойдется. Игра не стоит свеч. Возможно, именно поэтому мы до сих пор не увидели разновидностей движка Checkstyle, написанных под языки, отличные от Java.
Чекстайл полностью завянан на Java. Поэтому, на мой взгляд, врядли удастся использовать код его движка для работы с другими языками программирования, отличными от Java. По затраченным усилиям это будет практически равноценно переписыванию всего проекта с нуля, но уже для других языков
На нашей практике по Java студенты, к примеру, занимаются расширением Checkstyle и связанных с ним проектов с открытыми исходниками
Я рос когда-то на чудесных детских энциклопедиях «Росмэн». До сих пор храню для нового поколения почти полное собрание… такие книги никогда не устаревают и, разумеется, их никак не заменишь ни читалкой, ни любым другим электронным аналогом )
В прошлом году выставляли на GSOC менее крупный проект (основной проект Checkstyle в прошлом году мы не успели полностью перенести на GitHub, да и не до того было) — и не прошли. Так что на этот раз все сложилось намного удачнее )
// SUPPRESS CHECKSTYLE <Имя чека> <Комментарий>