Журнал Витуса

уже по первой его строчке видно, что вы не пытались обдумывать мои комментарии в ветке, я подумал, что невежливо будет ответить вам чем-то другим : )

From:

Ну хорошо, для тупых.

Вот это вот:
"шансы нормально развиваться с двумя пользователями есть, но они заметно меньше, чем при большем числе пользователей"
В общем случае неверно просто потому, что вместо воплощения нормального, самосогласованного набора фич придется угождать ...дцати несовместимым точкам зрения. Просто потому, что двоих пользователей можно столкнуть лбами и объяснить им, что и как, попросив договориться, либо просто сделать два независимых набора фич, но вот с тремя десятками пользователей это уже не так просто.

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

From:

как-то в этой теме понятие пользователя плавает. Вначале Витус говорит, что пользователь — это программист. Потом я говорю про количество программистов, нужных для развития проекта в развивающемся мире. Потом Циречной почему-то аргументирует мне про количество пользователей. Теперь вы вначале тоже про пользователей, потом считаете множество людей в институте одним пользователем, а потом снова предлагаете пользователям дописывать проект самостоятельно.

давайте теперь я тоже объясню на уровне «для тупых» ту мысль, которую пытаюсь донести с первого комментария.

в мире сейчас тонны open-source проектов, которые вроде бы и выложены в открытый доступ, но интересны только своим авторам (один человек на один проект). Когда авторам они перестанут быть интересны по любой причине, начиная с автобуса и заканчивая новым увлечением, случится смерть этих проектов. Часто бывает и так, что два-три друга вместе написали проект, выложили его в open-source, и он тоже никому, кроме них не нужен. Они повозятся с ним, по очереди сменят интересы, и он тоже умрёт.

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

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

крайние случаи возможны, я их не отрицаю, но я говорю про шансы, про статистику, про вероятности, поэтому единичные примеры ничего не доказывают

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

так что, пожалуйста, когда я говорю про успешность в одном смысле, не возражайте мне про успешность в другом смысле

From:

Конечно. Потому что у меня пользователь это user, то есть человек, которому работа с программой дана в непосредственных ощущениях. А у Циречного - customer, то есть тот, кто тем или иным способом мотивирует программиста продолжать разработку.

Мой пойнт заключается в том, что проргаммист - всегда тоже пользователь. И не имеет смысла участвововать в разработке open source проектов, которыми сам не пользуешься.

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

From:

спасибо за пояснение, но ваша точка зрения достаточно хорошо ясна из текста поста

я на неё возражаю мыслью, что слишком строгое следование собственным убеждениям об удобстве может чрезмерно затруднить сотрудничество с другими программистами. Многие же интересные задачи в одиночку решать очень сложно, а для сотрудничества приходится иногда идти на жертвы. И чем больше задача, тем больше ей требуется труда программистов, и тем на большие жертвы приходится идти каждому из них, чтобы она вообще была реализована

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

Edited Date: 2011-03-31 12:37 pm (UTC)

From:

слишком строгое следование собственным убеждениям об удобстве может чрезмерно затруднить сотрудничество с другими программистами.

А это может быть только если неправильно выбрана архитектура системы.
Система с правильной архитектурой должна легко адаптироваться под представления об удобстве любого человека, который правильно понимает предметную опбласть данной системы.

From:

я вкладываю в слово «удобство» более широкий смысл, вплоть до расстановки кнопок в GUI и понимания собственно задач проекта. Такое хорошей архитектурой не исправить, но у каждого есть своё мнение об этом, и каждому хочется пользоваться тем, что удобно именно ему.

From:

Э, какие-такие "задачи проекта"? Какого хрена ПОЛЬЗОВАТЕЛЮ знать "задачи проекта"? У пользователя есть свои задачи, которые он с помощью данной программы решает. И проект это сущность исключительно инструментальная, помогающая ему решать эти задачи.

О понимании задач может идти речь только в том контексте, что пользователю должно быть достаточно легко понять, какую терминологию для предметной области использует данная программа, и как с помощью этой терминологии сформулировать его, пользовательские, задачи.

И я не знаю для этой цели более мощного средства, чем хорошая архитектура (терминология которой совпадает с наработанной веками в данной предметной области). Как правило, хорошая архитектура позволяет четко ограничить кусок, которого данной программе не хватает для решения данной задачи, и легко его дописать таким образом, что остальные пользователи данной программы не возмутятся тем, как это туда вкручено, и включать этот кусок в общий репозиторий кода.

А вот задачу расположения кнопок в GUI правильная архитектура должна решать. Поскольку должна позволять легко перелопатить GUI с трудозатратами на несколько порядков меньшими, чем написание основной фукнциональнсти.

From:

я сейчас написал пространный ответ, но понял, что тема уходит куда-то в сторону. Возвращаясь к истокам: можно делать GUI настроек сети, понятный совсем тупому, а можно не делать, обойдясь очень удобным текстовым конфигом, но тогда зарабатывающая на совсем тупых компания не проспонсирует такой форк. Когда таких отличий от дистриба «для тупых» станет слишком много, подтягивать из него полезные изменения станет совсем трудно. Если же плюнуть и не брать из него эти изменения, есть риск через пять лет не найти железа, на котором запустится свой удобный, логичный и стройный дистриб.

From:

xarkonnen.livejournal.com

Мой пойнт заключается в том, что проргаммист - всегда тоже пользователь. И не имеет смысла участвововать в разработке open source проектов, которыми сам не пользуешься.

тогда ряд приложений просто никогда не обретёт опенсорсную инкарнацию.

пример из моей профессиональной сферы: спуск полос. у простых приложений (например, плагин для Adobe Acrobat QI Plus, весит около полмегабайта) ценник стартует примерно с тысячи евро. более развесистые приложения (например, PrePS) в зависимости от могут стоить как автомобиль представительского класса. и это при том, что собственно алгоритм спуска полос весьма несложен по сравнению, скажем, с алгоритмом веб-сервера.

однако Apache есть, а вот опенсорсного аналога даже не препса, а хотя бы квайт импозинга нет..

From:

Ну почему никогда? До тех пор пока кто-то из тех, кому нужно этой функциональность пользоваться, не соберется ее запрограммировать.

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

Написал же Кнут ТеХ. Ровно для того чтобы самому верстать в нем свои математические работы.

Хотя в данном случае, может быть и никогда. Просто бумажная публикация отомрет раньше. Ну и хрен бы с ней.

From:

Честно говоря, у меня создалось впечатление, что лучше бы не писал. Проект явно пережил своё время и отмирать не собирается - а зря.

From:

d4s.livejournal.com

честно говоря, пройдя эволюцию от plain text до всяких WYSIWYG текстовых редакторов, сейчас жутко хочу перейти на tex.
пока задерживают только сотни страниц текстов, написанных во всяких опенофисах за последние лет 7 :(

From:

Wysiwyg я тоже презираю. В техе
1) убогая модель верстки (коробки - это, конечно хорошо, но мало и неудобно. А более сложных фигур не завезли)
2) подлежащий язык императивный (латех эту проблему частично решает, но все же одна команда может сказаться аж в другом включенном файле)
3) верстка восходящая (сверстали абзац... страницу... А надо перебирать варианты и выбирать первый, укладывающийся в некую метрику)

А замены адекватной нет и не предвидится. Не считаться же таковой xsl:fo

From:

Пользователь - это потребитель продукта. Он может в одном лице (физическое лицо) и во многих (юридическое лицо). Важно, что по отношению к производителю продукта он выступает как единое целое.

> Им важно, что проект не тухнет на хостинге, в буквальном смысле никому не нужный при всей своей самосогласованности.

Если вы вкладываете в понятие 'успешно развиваться' смысл 'иметь много коммитов и иметь перспективу иметь много коммитов', то это метрика к метрикам успешности, и, особенно, качества проекта ортогональная. И, к слову, эти коммиты отнюдь не обязательно будут вести изменение функционала в сторону, удобную конечному пользователю. Что несколько противоречит моему пониманию 'успешного развития'.

From:

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

более того, весь тред я пытаюсь показать, что не умереть в развивающемся и меняющемся мире — это уже хорошо, немногие проекты способны хотя бы на такое развитие. Правильность и удобство тут вообще ни при чём.

From:

>не умереть в развивающемся и меняющемся мире — это уже хорошо, немногие проекты способны хотя бы на такое развитие.

Вовремя умереть способно ещё меньшее количество проектов. БОльшая часть либо откровенно не нужна, либо пережили свое время и должны умереть - но живут по иннерции.

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

From:

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

From:

Я, в общем, тоже. Но живой проект - это тот, который запускается на моей машине. Коммитов в него может не быть уже не один год - если он запускается и работает, то все хорошо.

Т.е. живому проекту развиваться не обязательно. Необходимо обновление конфиг-файлов и иногда портирование на новые архитектуры/релизы библиотек, что в грамотно сделанном проекте занимает ничтожное время и может быть сделано любым мало-мальски заинтересованным человеком.

From:

…если этот человек программист

не знаю, меняются библиотеки, меняются даже стандартные библиотеки языков, какие-то библиотеки забрасываются — риск всё-таки заметный. Впрочем, это моя субъективная оценка, на которую повлияло то, что я пользуюсь как минимум одним заброшенным проектом — Revelation. Форкать его форкают, но разбираться, который из форков нужен, дело долгое. Думаю, заменять пакеты в дистрибах на форки — дело ещё более долгое.

From:

Можно линк на сайт программы?

From: