Развитие ресурса — статьи о Java и не только
Заметки по поводу критики www.developers.org.ua/...2008/11/12/spring-vs-ejb
Facebook
Twitter
LinkedIn
Sergiy Movchan (COTOHA)
ну так это ж очевидно:) надо использовать бест-практисес от старших товарищей... ну там тот де dzone — всё категоризируется по основным направлениям и, что более важно, каждое направление имеет свой отдельный RSS. в идеале можно каждому юзеру дать возможность накликать какой контент именно ЕМУ будет в RSS или на главной странице.
Max Ischenko
Насчет разных разделов: как раз сегодня все утром над этим думал, до того как прочел этот тред. Эта идея уже несколько раз всплывала, похоже что она действительно востребована. Попробовать, во всяком случае стоит.
Вообще, мне кажется, нужно как-то сделать чтобы сам ДОУ стал менее заметным, а «выпятить» участников сообщества. Тематические разделы должны в этом помочь (как и Профили пользователей).
Anton Naumov
2Сергей Волошин, с новыми и неизвестными технологиями получается замкнутый круг. Аутсорсер-заказчик в 80% против, и я его понимаю — он не хочет инвестировать в чистый рисерч, он не хочет за свой счет повышать квалификацию сабконтрактеров. Заказчик хочет продукт, заказчик хочет продукт дешево, иначе бы он его разрабатывал дома. Так что заказы на новые и не известные технологии редки. С другой стороны невозможно приоткрыть завесу тайны над новй и не известной технологией, не разобравшись с ней, не используя в боевом проекте, чтобы посмотреть что эта технология может, чего не может, как у нее плюсы, какие минусы.
С удовольствием почитаю о GWT, что касается сборочных систем, то опять-таки Ant и Мaven2 удивительно просты в использовании. И там достаточно мануала. Доработка первого — это сама по себе джедайская практика, а второго — примерно также проста, как и использование. С другой стороны я за 8 лет работы написал всего один плагин для Maven2. В остальном хватает стандартных.
С удовольствием почитаю о GWT, что касается сборочных систем, то опять-таки Ant и Мaven2 удивительно просты в использовании. И там достаточно мануала. Доработка первого — это сама по себе джедайская практика, а второго — примерно также проста, как и использование. С другой стороны я за 8 лет работы написал всего один плагин для Maven2. В остальном хватает стандартных.
Я собственно к чему все начал-то:), проблема не в том, что Java-разработчики мечтают превратиться в закрытый клуб, гильдию и запечатывать знания в сундуки. Просто одним из плюсов Java лично для меня 10 лет назад стало именно то, что она просто, понятно и прозрачно документирована. Единственным полем для документирования является тот факт, что не все документированное работает, а кое-что работает не так, как описано, или начинает работать, как описано, после несколько танцев с бубном и камланий.:) Вот про па танцев, модель бубна и благовония для камланий можно и дОлжно писать.
Sergii Voloshyn
Теги появились сравнительно недавно (), но теперь они думаю станут одним из основных средств поиска, есть отдельная страница теги (http://www.developers.org.ua/blog/tags/), в конце статьи есть ссылки на теги этой статьи, и после статьи есть десяток похожих статей, отобранных на основе категорий и тегов. Это все я сделал меньше месяца назад.Я, к примеру, вообще раньше теги не замечал.
По поводу разделения чегото на главной и не на главной и в углу етс, это все не очень важно относительно того что все статьи и новости идут одним RSS потоком.
Denis
2Макс Ищенко, я тоже думал о том что лучше было бы сделать разделы, вроде Java,.NET, C++, Python
и публиковать туда статьи, а заголовки последних статей показывать где-нибудь в боковой панели.
Напрягаться искать, переходить на другие страницы — не все любят. Я, к примеру, вообще раньше теги не замечал. Потому что не понятно что я увижу, когда я кликну на тег Java.
Планета — это немножко не то: там люди в блогах иногда публикуют не очень интересный контент и нету группировки этого контента.
А так, если тема интересная — можно сразу на неё перейти. И так же в таких разделах можно публиковать статьи разных уровней, тем самым специализируя контент для конкретных людей.
Иначе, понятно, что если не повесить красивых скриншотов и не написать слов по последней моде в статье на главной странице, то статья большинству не понравится, потому что большинство — это или джава джуниоры/миддл или не знакомые с джавой вообще — и в данном случае, им легче поставить единицу или написать «что эта статья здесь делает? », потому что она может быть им вообще не интересна и не понятна.
и публиковать туда статьи, а заголовки последних статей показывать где-нибудь в боковой панели.
Напрягаться искать, переходить на другие страницы — не все любят. Я, к примеру, вообще раньше теги не замечал. Потому что не понятно что я увижу, когда я кликну на тег Java.
Планета — это немножко не то: там люди в блогах иногда публикуют не очень интересный контент и нету группировки этого контента.
А так, если тема интересная — можно сразу на неё перейти. И так же в таких разделах можно публиковать статьи разных уровней, тем самым специализируя контент для конкретных людей.
Иначе, понятно, что если не повесить красивых скриншотов и не написать слов по последней моде в статье на главной странице, то статья большинству не понравится, потому что большинство — это или джава джуниоры/миддл или не знакомые с джавой вообще — и в данном случае, им легче поставить единицу или написать «что эта статья здесь делает? », потому что она может быть им вообще не интересна и не понятна.
Поэтому, думаю, главная страница — для статей, которые охватывают разные уровни.
2Anton Naumov:
Да, наверное это самая благодатная почва.единственным вкладом в комьюинити я вижу джедайские технологии по “сращиванию” каких-то фрэймворков.
Вот Diyko начал заметку о GWT, где пересекается AJAX и Java (на след. неделе будет вторая часть, “GWT та системи управління проектами”). Там рассматривается работа с Ant и Maven.
Кроме технологий, которые вроде как извесны и широко описаны и используются, возможно есть инструменты о которых стоит написать, которые менее извесные, но полезные для многих разработчиков или для некоторых задач.
Возможно есть подходы, которые не так часто используются в повседневной аутсорс-разработке и не сильно описанны, но перспективные или прогрессивные.
Как-то я брал участие в проекте, где использовалась MDA, Java, Python, UML (ну и JSP, ejb и еще аббревиатуры наверное) в какой-то интересной комбинации (правда я в этом не разбираюсь).
джентельмены, как потенциальный автор статей по Java (не считая себя гиперпрофессионалом), позволю себе вставить свои пару центов.
самым главным вопросом для меня как был, так и остается один —, а о чем собственно писать? Java довольно стара, как технология, о ней уже написана не одна и не две статьи, обзора, форума, спецификации. единственным вкладом в комьюинити я вижу джедайские технологии по «сращиванию» каких-то фрэймворков. например давече я пытался интегрировать JPOX и Spring, положительного результата я пока не достиг. хотя официально именно JPOX приводиться в качестве примера интеграции Spring и JDO. вот об этом, буде у меня время продолжить эксперименты, я бы написал с удовольствием. расшифровывать термины JPOX, Spring, EJB — это бессмысленно на мой взгляд, достаточно взять книгу по соотвествующему фрэймворку уже переведенную.
еще один момент, мало кто из Java-разработчиков работает со Streamline технологиями, так уж повелось, что огромная часть аутсорсинга — это легаси., а там ничего нового нет, к чему говорить о том, что уже не раз и не два описано людьми, которые гораздо более сведущи в написанни статей и делают на этом деньги.
самым главным вопросом для меня как был, так и остается один —, а о чем собственно писать? Java довольно стара, как технология, о ней уже написана не одна и не две статьи, обзора, форума, спецификации. единственным вкладом в комьюинити я вижу джедайские технологии по «сращиванию» каких-то фрэймворков. например давече я пытался интегрировать JPOX и Spring, положительного результата я пока не достиг. хотя официально именно JPOX приводиться в качестве примера интеграции Spring и JDO. вот об этом, буде у меня время продолжить эксперименты, я бы написал с удовольствием. расшифровывать термины JPOX, Spring, EJB — это бессмысленно на мой взгляд, достаточно взять книгу по соотвествующему фрэймворку уже переведенную.
еще один момент, мало кто из Java-разработчиков работает со Streamline технологиями, так уж повелось, что огромная часть аутсорсинга — это легаси., а там ничего нового нет, к чему говорить о том, что уже не раз и не два описано людьми, которые гораздо более сведущи в написанни статей и делают на этом деньги.
и последнее, в планете я встечал пару довольно толковых постов. возможно имеет смысл связываться с авторами и делать авторскую «агрегацию» коротких заметок? коль скоро нет длинных?
Мне нравится идея «фильтрации», т.е. отбора статей которые попадают в основной блог. Они мне кажется за этот год более-менее сформировались. Это
а) интересное широкому кругу разработчиков и б) подробное освещение какой-то темы. Проблема в том, что сообщество разработчиков разнородно, у всех разный уровень подготовки и интересов. И сделать одну ленту материалов которая будет нравиться всем — невозможно.
Вопрос что делать со статьями на «узкую» тему, как например серия «Кунгфу» Сергея Щетинина.
С одной стороны, можно продолжать как есть, просто неинтересный материал читатели будут пропускать. Вроде бы не сложно «подписаться» только на интересное, тем более что все статьи уже разбиты по тегам и категориям.
а) интересное широкому кругу разработчиков и б) подробное освещение какой-то темы. Проблема в том, что сообщество разработчиков разнородно, у всех разный уровень подготовки и интересов. И сделать одну ленту материалов которая будет нравиться всем — невозможно.
Вопрос что делать со статьями на «узкую» тему, как например серия «Кунгфу» Сергея Щетинина.
С одной стороны, можно продолжать как есть, просто неинтересный материал читатели будут пропускать. Вроде бы не сложно «подписаться» только на интересное, тем более что все статьи уже разбиты по тегам и категориям.
С другой стороны, почему бы не поэкспериментировать с другими форматами, возможно найдем вариант получше. Можно попробовать сформировать вместо одной Планеты несколько тематических (напр. Питон, ФЯ, Джава,.NET). А чтобы увеличить «видимость» вывести эти планеты на главную. Авторский же блог имхо ценен именно за счет того, что у него есть редактор, который материалы отбирает.
2 I. Kovalchuk. Большое спасибо за конструктивную критику.
На самом деле перед тем как статья попадает на сайт практически всегда есть довольно много обработки. Практически во всех статьях исправляется довольно много грамматических ошибок и расставляется много запятых.Администрация сайта должна, обязана фильтровать контент основных статей — т.е. рекомендовать автору доработать статью и помочь в этом хотя-бы общими советами, и не публиковать статью до ее доработки.
Также я статаюсь давать какие-то рекомендации по улучшению содержания, например при подготовке статьи
http://www.developers.org.ua/archives/denys-bezsmertnyi/2008/11/10/java-ee-application-server/
в одном из писем Денису я написал:
Потом уже подобные замечания были и в комментариях:Я тут почитал статьи, и подумал, может стоить статью о серверах приложений дополнить хоть каким-то минимальным перечнем примеров этих самых серверов? Может так было бы и понятнее и нагляднее что ли. Скажем 3−4 самых популярных сервера с линками на их сайты и короткой характеристикой — пара слов о плюсах, минусах, для чего подходит лучше/хуже, платно/бесплатно етс. Конечно, это все можно наверное нагуглить и разобраться, но в одной статье с теоретической частью часть с приерами может быть полезной.
http://www.developers.org.ua/archives/denys-bezsmertnyi/2008/11/10/java-ee-application-server/#comments
А вообще я не считаю что на ДОУ 80% людей неадекватны, может разве что 0.08% (спаммеров не считаем). Просто читатели довольно требовательны (это плюс), часто эмоциональны и нередко категоричны.
В целом проблему думаю можно решить, не публикуя статьи, не подходящие по формату, который можно сказать сформирован лучшими статьями. А статьи неподходящие пойдут на доработку или в форум или в планету.
Возможно для комментариев нужно сделать так как в базе компаний, чтобы у каждого комментария был тоже рейтинг, и очень негативные (по рейтингу) комментарии отображались особым образом. Но вообще как показывает практика, если статья очень хорошая по мнению читателей, то плохих и неадекватных комментариев практически нет.
1. Написать серьезный профессиональный обзор как для «глянцевого журнала» — это не шутки, это масса (!!!) времени — даже такая небольшая статья как эта может занять часа 3 (для меня, например, это реально много), добавим сюда еще что каждый автор должен при этом отпахать, вымотаться 8−12 часов на основной работе в день, и это как самый самый минимум — мы же не компьютерами живем только, у нас же есть и другие обязанности и интересы в жизни, а писать такие статьи в рабочее время — это «не хорошо»... А потом, после того как ты написал, пусть даже небольшую статью, собирал информацию, даже что-то нашел новое для себя, с вдохновением, инициативно, но все-таки буквально оторвал от себя это время на создание контента — еще приходиться реагировать на негативные комментарии... и хорошо если автор опытен и не читает такие комментарии в рабочее время: -)
2. К сожалению, публиковать что-то через «планету разработчиков» на мой взгляд просто малоэффективно, поскольку она довольно-таки насыщена сообщениями. Если ты хочешь получить отклик от объемной аудитории, узнать точку зрения других людей или донести какую-то информацию объемной аудитории, то «планета» не лучьший выбор (но, классно что она есть), увы, я сам туда не всегда заглядываю. Есть рубрика основных статей, есть форум, планета, но нет раскрученного middle уровня — т.е. маленькие статьи для объемной аудитории, да и нужно ли такое не знаю — хотя, пожалуй, такие статьи больше все-таки относяться к форуму.
3. Действительно, хочеться видеть больше культуры и меньше «опускания» в отношениях среди разработчиков. Если ты профессионал и хорошо понимаешь тему — то дополни статью здесь же, на месте, сделай это профессионально. Или просто корректно взвешенно скажи — вот, я хотел бы видеть здесь то-то и то-то. Или добавьте еще одно «окошко», чтобы негативные отзывы попадали прямо к администрации, а не висели постоянно, или отдельную вкладку для критики как в Mediawiki (?). Действительно — с одной стороны мы хотим сказать что мы думаем, когда что-то не нравиться, это вполне нормально, с другой стороны — наши негативные отзывы просто могут завалить developers.org.ua, это ж не помойная яма. Ведь часть народа просто не будет ничего писать вообще, чтобы не разгребать потом кучи негатива после опубликования статьи. Разве что части народа не нужно такое украинское сообщество? По-моему, это здорово что оно есть!
4. Ну, видимо, не хотять гипер-профессионалы по Java писать статьи, или не могут, понимаете, нет у них на это времени, или не считают что широкий knowledge sharing имеет для них смысл в стратегическом плане (может они и правы), но это абсолютно не значит что эти гипер-профессионалы незаменимы. Возможно одна статья должна проходить какой-то умеренно «долгий» инкубационный период и готовиться одним автором при участии целой группы разработчиков — командная работа, профессиональная, и потом написать всех реально влиявших на контент участников в авторы статьи. У вас есть что-то такое, но это просто на сегодня не раскручено или функционал не позволяет еще такое (черновики в «панели приборов»). А потом выпустите книжку на разных языках, как Джоел Спольски: -)
5. Администрация сайта должна, обязана фильтровать контент основных статей — т.е. рекомендовать автору доработать статью и помочь в этом хотя-бы общими советами, и не публиковать статью до ее доработки.
Best regards!
10 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарів