> А вы разве предоставляете ТЗ на автомобиль, который заказываете в салоне?
Автомобиль — это готовый продукт общего применения (как Ворды/ексели). Т.З. на такие продукты прорабатываются маркетологами, психологами, социологами и другими специалистами.
На единичные или персонифицированные продукты ТЗ составляется самим заказчиком.
> Или может предоставляете ТЗ в ателье на пошив одежды для вас?
Тут тз составляет сам портной. В уме. Обмеряя «на глазок» или линейкой. При этом он учитывает пожелания клиента (тут жмёт… а тут хочу, чтобы оттопыривалось… а тут чтобы не оттопыривалось и т.д.)
> А, наверное вы предоставляете ТЗ на прическу и макияж в салоне красоты?
Да, ТЗ в устной форме. «По бокам снять с павным переходом вверх в „шапку“. Затылок визуальн приподнять. Виски прямые. Чёлка чуть ниже бровей, зачёс назад и немного вправо, без пробора. Сзади кантик не надо, плавный переход». Для професионала это достаточно подробное ТЗ. А вот в ответ на «тут подфуфырить… там отхесачить, а вот тут не трогайте, только повысяйните немного» любой профи просто впадёт в ступор. Нужен либо толковый клиент, который сможет объяснить, что ему нужно, либо переводчик между клиентом и профи, либо профи, который поймёт клиента. Проблема, когда клиент и профи говорят на разных языках, абсолютно не единична. Тут либо анкеты, либо ГОСТы.
>Сколько можно это обсуждать, если вы продаете продукт, то вся техническая документация к нему уже обязательно есть.
А если продукт изготавливается? Документация есть на составные части, но не на конечное изделие.
> Вы лишь должны доступно объяснить заказчику, что у него есть возможность изменить продукт под свои нужды и при этом необходимо изменить техническую документацию и подписать…
Т.З. (техническое задание) — это и есть доступное объяснение заказчику. Будь оно в устной или в письменной форме — не важно. В письменной форме Т.З. может быть в произвольной форме (портной ставит одному ему понятные закорючки) или в стандартизированной (фирма вырабатывает опросник анкету или просто берутся за основу ГОСТы).
Блин, человека заминусовали… Я так понимаю, что минуса ставятся за мат и откровенное хамство, но за противоположную точку зрения зачем в минуса загонять?
Плюсую, короче :)
А причём здесь домохозяйка? Историю про медицинского работника, вечерами и в свободное время написавшего альтернативный планировщик задач для ядра, слышали?
Опенсорс не делает выборок между пользователями. «Тебе низзя дизасебмлировать, давай бапки; тебе- можно чуть-чуть исходников, но за другие бапки и ни дай боже утечка будет» — это нормально? Одним одно, другим другое; причём выбор не за пользователем. Опенсорс же даёт выбор именно пользователю, что делать.
Если приведённая в примере домохозяйка вдруг заинтересуется, а что там внутрях, то ей за этот интерес никто EULA'ой по рогам не даст, никто не запретит скачать исходники. А если не захочет (много других дел) — да разве заставляет кто? Выбор и свобода у неё будет по-любому, воспользуется она ими или нет.
Вспомнился давнишний девиз: «Даёшь хорошей домохозяйке хорошего сисадмина (а сисадмину — квартал домохозяек) — и будет счастье и тем, и другим». :)
Гм… а будет ли иметь законную силу такая «приписка»?
У вас на руках старый договор. Подписан как вами, так и компанией. В договоре нет никаких европейских тарифов. И именно договор будет фигурировать в суде, а не распечатка таблицы тарифов. Если меняются условия договора, то для этого необходимо либо пересоставить договор, либо составить дополнение к договору (опять же — с двусторонними подписями).
ИМХО так.
P..S. Гляньте кто свои договора. есть ли там маленьким шрифтом «компания имеет право в одностороннем порядке изменить тарифы или условия договора»?
Голоса на сегодня кончились. Так бы плюсовал тут до потери пульса :)
Это точно: добавят пару бантиков и кричат о революционном прорыве.
Прорыв был бы, если:
— сделать чекбоксы/радиобатоны (как было озвучено)
— сделать поиск параметров или фильтр по мере набора (а-ля about:config в firerfox)
— хорошая контекстная справка, а не «enabled — включить параметр; disabled — выключить параметр». К.О. пробрался в БИОСы :(
вот это и будет прорыв и революция… только для такой революции графика и не нужна вовсе… :)
Ну как же не прорыв? В вашем БИОСе 98-го года не было градиентов. А тут есть… интересно, они от восторга запатентовали градиенты в БИОСе или нет? :)
Вообще, глупо это. Лично я в БИОС заглядываю очень редко. Вернее сказать — я забыл, как выглядит БИОС моего компа. И делать такие красивости… ну разве что
Press DEL for enter into BIOS setup
Press shift+DEL for enter into text-mode BIOS setup
Так уже есть такие проекты. Вшивают в CMOS linux+busybox+, браузер(не помню какой). Типа, пока не установлена полноценная операционка, пользователь может загрузиться с урезанного Линукса и потом через браузер посерфить по Инету… этакий Infokiosk :)
Не развеяли. МакОсь сносно работает на очень небольшом списке железа. То есть, нужно собрать специальную конфигурацию железа («хакинтош»), чтобы макось завелась на PC. А работать «нормально или даже удовлетворительно» оно начнёт, если производители железа станут выкладывать у себя драйвера под МакОсь наравне с драйверами под Windows. Пока этого нет и в ближайшее время не предвидится (из-за лицензионной политики Apple). Именно про это sidney3172 и написал. Собирать «хакинтош», если уже есть мощная железка на AMD64+8GbRAM+(некислое видео от ATI) — это просто глупо :(
Если Вам повезло с конфигурацией железа (или вы сами целенаправленно подбирали компоненты) — это частный случай.
> В худшем случае тратим час с перекурами.
Итого часа два-три на смену дизайна и час на добавление новой циферьки. А если таких «циферок» две появится? Три? десять? :)
Очень часто за фразой «а добавьте-ка такую-то фишку, я вижу, что это несложно» кроется некислая работа по добавлению этой фишки.
Но самое обидное не это :) Самое обидное после аврального штурма фишки услышать «а не, как раньше было лучше, возвращайте».
Спасение от такого — предварительное составление детального ТЗ. Но иногда ТЗ — это пушкой по воробьям, потому что проектик вроде небольшой, по работе баксов на 200-300 и на неделю максимум (буквально сайт-визитница), но перед самой сдачей начинаются «капризы-пожелашки» клиента :(.
В статье чётко разделены понятия «дизайн» и «интерфейс». Если надо поменять только дизайн, то да, всё быстро и практически безболезненно. Дизайн — это скин, по сути (skin).
А если на картинке с новым дизайном вдруг появилась маленькая циферька «количество непрочитанных сообщений», то это уже смена интерфейса. Ибо для арт-менеджера это «всего лишь одна цифра. Что там стоит её добавить в дизайн профессионалу?». А для этого профессионала новая цифра — это геморрой по составлению нового SQL-запроса, по вызову этого запроса и по отдаче результата Viewer'у. Хорошо, если SQL-запрос простенький… а если агрегирующий по нескольким таблицам?
Стоимость этих «циферок» (в часах в том числе) знают только программеры, но не арт-менеджеры :)
> Собственно, я сам и зафайлил эту проблему
О как! Приятно пообщаться «вживую» (интерактивно), а не по-английки через комменты :)
Спасибо за багрепорт.
> А под cygwin 1.7 он уже собирается (в cygwin`овских анонсах нет)? Когда я последний раз проверял в июне — не получалось. Впрочем, я забросил попытки как раз из-за переходного статуса самого Cygwin: там была кривизна с библиотеками, в частности, с s-lang.
Гм… в свете сказанного: можно ли закрыть тикет как 'wontfix'? Вроде проблема и не наша… я уже думал сделать --enable-ipv6, но лень было да и не хотелось лишние #ifdef...#endif плодить. :)
> Приоритеты предыдущей команды, насколько я понял: суперстабильность и суперпортируемость (с последним у текущего mc плоховато — слишком большие были изменения).
Плоховато или неизвестно? :)
Я знаю одну проблему: текущий mc не соберётся в текущем стабильном Cygwin из-за того, что в mc была добавлена поддержка IPv6 а в стабилном Цигвине её нет. Но и это решаемо в ближайшее время: mail.gnome.org/archives/mc-devel/2009-November/msg00048.html
На FreeBSD текущий мастер собирается, на [Open]Solaris тоже собирается (по мотивам https://www.midnight-commander.org/ticket/1749). Под Линукс — само собой.
Кто-то из нас вроде пробовал не так давно на OpenBSD собирать… или это была NetBSD? Не помню :)
За кадром AIX, HP/UX и т.д. Они «за кадром» не потому, что мы отказываетмся от их поддержки — были бы патчи :)
Простите, прочитал как «Какие предыдущие приоритеты команды были». :( Вот уж точно: каждый видит то, что хочет видеть. Приоритеты предыдущей команды описаны в TODO, линк на него есть в предыдущем посту.
Автомобиль — это готовый продукт общего применения (как Ворды/ексели). Т.З. на такие продукты прорабатываются маркетологами, психологами, социологами и другими специалистами.
На единичные или персонифицированные продукты ТЗ составляется самим заказчиком.
> Или может предоставляете ТЗ в ателье на пошив одежды для вас?
Тут тз составляет сам портной. В уме. Обмеряя «на глазок» или линейкой. При этом он учитывает пожелания клиента (тут жмёт… а тут хочу, чтобы оттопыривалось… а тут чтобы не оттопыривалось и т.д.)
> А, наверное вы предоставляете ТЗ на прическу и макияж в салоне красоты?
Да, ТЗ в устной форме. «По бокам снять с павным переходом вверх в „шапку“. Затылок визуальн приподнять. Виски прямые. Чёлка чуть ниже бровей, зачёс назад и немного вправо, без пробора. Сзади кантик не надо, плавный переход». Для професионала это достаточно подробное ТЗ. А вот в ответ на «тут подфуфырить… там отхесачить, а вот тут не трогайте, только повысяйните немного» любой профи просто впадёт в ступор. Нужен либо толковый клиент, который сможет объяснить, что ему нужно, либо переводчик между клиентом и профи, либо профи, который поймёт клиента. Проблема, когда клиент и профи говорят на разных языках, абсолютно не единична. Тут либо анкеты, либо ГОСТы.
>Сколько можно это обсуждать, если вы продаете продукт, то вся техническая документация к нему уже обязательно есть.
А если продукт изготавливается? Документация есть на составные части, но не на конечное изделие.
> Вы лишь должны доступно объяснить заказчику, что у него есть возможность изменить продукт под свои нужды и при этом необходимо изменить техническую документацию и подписать…
Т.З. (техническое задание) — это и есть доступное объяснение заказчику. Будь оно в устной или в письменной форме — не важно. В письменной форме Т.З. может быть в произвольной форме (портной ставит одному ему понятные закорючки) или в стандартизированной (фирма вырабатывает опросник анкету или просто берутся за основу ГОСТы).
Плюсую, короче :)
Опенсорс не делает выборок между пользователями. «Тебе низзя дизасебмлировать, давай бапки; тебе- можно чуть-чуть исходников, но за другие бапки и ни дай боже утечка будет» — это нормально? Одним одно, другим другое; причём выбор не за пользователем. Опенсорс же даёт выбор именно пользователю, что делать.
Если приведённая в примере домохозяйка вдруг заинтересуется, а что там внутрях, то ей за этот интерес никто EULA'ой по рогам не даст, никто не запретит скачать исходники. А если не захочет (много других дел) — да разве заставляет кто? Выбор и свобода у неё будет по-любому, воспользуется она ими или нет.
Вспомнился давнишний девиз: «Даёшь хорошей домохозяйке хорошего сисадмина (а сисадмину — квартал домохозяек) — и будет счастье и тем, и другим». :)
«Казалось бы: причём здесь Л...» (С) Доренко
У вас на руках старый договор. Подписан как вами, так и компанией. В договоре нет никаких европейских тарифов. И именно договор будет фигурировать в суде, а не распечатка таблицы тарифов. Если меняются условия договора, то для этого необходимо либо пересоставить договор, либо составить дополнение к договору (опять же — с двусторонними подписями).
ИМХО так.
P..S. Гляньте кто свои договора. есть ли там маленьким шрифтом «компания имеет право в одностороннем порядке изменить тарифы или условия договора»?
Опс, съело <username>
Должно быть /home/<username>
Добавь, плиз, что для начала работы понадобится установить следующие пакеты:
root@phantomazz ~]$ yum install yum-utils rpm-build
И эта…
> /home/root/rpmbuild
???
тут уж или /root, или /home/ :)
В целом статья хороша. Можно было бы упомянуть про mock, как про дополнительный гарант чистоты бинарной сборки :)
Да что Америка. Позитивно, что это у нас происходит.
Это точно: добавят пару бантиков и кричат о революционном прорыве.
Прорыв был бы, если:
— сделать чекбоксы/радиобатоны (как было озвучено)
— сделать поиск параметров или фильтр по мере набора (а-ля about:config в firerfox)
— хорошая контекстная справка, а не «enabled — включить параметр; disabled — выключить параметр». К.О. пробрался в БИОСы :(
вот это и будет прорыв и революция… только для такой революции графика и не нужна вовсе… :)
Вообще, глупо это. Лично я в БИОС заглядываю очень редко. Вернее сказать — я забыл, как выглядит БИОС моего компа. И делать такие красивости… ну разве что
Press DEL for enter into BIOS setup
Press shift+DEL for enter into text-mode BIOS setup
Тут ладно, смирюсь с бантиками :)
Если Вам повезло с конфигурацией железа (или вы сами целенаправленно подбирали компоненты) — это частный случай.
Итого часа два-три на смену дизайна и час на добавление новой циферьки. А если таких «циферок» две появится? Три? десять? :)
Очень часто за фразой «а добавьте-ка такую-то фишку, я вижу, что это несложно» кроется некислая работа по добавлению этой фишки.
Но самое обидное не это :) Самое обидное после аврального штурма фишки услышать «а не, как раньше было лучше, возвращайте».
Спасение от такого — предварительное составление детального ТЗ. Но иногда ТЗ — это пушкой по воробьям, потому что проектик вроде небольшой, по работе баксов на 200-300 и на неделю максимум (буквально сайт-визитница), но перед самой сдачей начинаются «капризы-пожелашки» клиента :(.
А если на картинке с новым дизайном вдруг появилась маленькая циферька «количество непрочитанных сообщений», то это уже смена интерфейса. Ибо для арт-менеджера это «всего лишь одна цифра. Что там стоит её добавить в дизайн профессионалу?». А для этого профессионала новая цифра — это геморрой по составлению нового SQL-запроса, по вызову этого запроса и по отдаче результата Viewer'у. Хорошо, если SQL-запрос простенький… а если агрегирующий по нескольким таблицам?
Стоимость этих «циферок» (в часах в том числе) знают только программеры, но не арт-менеджеры :)
О как! Приятно пообщаться «вживую» (интерактивно), а не по-английки через комменты :)
Спасибо за багрепорт.
> А под cygwin 1.7 он уже собирается (в cygwin`овских анонсах нет)? Когда я последний раз проверял в июне — не получалось. Впрочем, я забросил попытки как раз из-за переходного статуса самого Cygwin: там была кривизна с библиотеками, в частности, с s-lang.
Гм… в свете сказанного: можно ли закрыть тикет как 'wontfix'? Вроде проблема и не наша… я уже думал сделать --enable-ipv6, но лень было да и не хотелось лишние #ifdef...#endif плодить. :)
Плоховато или неизвестно? :)
Я знаю одну проблему: текущий mc не соберётся в текущем стабильном Cygwin из-за того, что в mc была добавлена поддержка IPv6 а в стабилном Цигвине её нет. Но и это решаемо в ближайшее время: mail.gnome.org/archives/mc-devel/2009-November/msg00048.html
На FreeBSD текущий мастер собирается, на [Open]Solaris тоже собирается (по мотивам https://www.midnight-commander.org/ticket/1749). Под Линукс — само собой.
Кто-то из нас вроде пробовал не так давно на OpenBSD собирать… или это была NetBSD? Не помню :)
За кадром AIX, HP/UX и т.д. Они «за кадром» не потому, что мы отказываетмся от их поддержки — были бы патчи :)
>— Поддержка UTF-8
>— Переопределение хоткеев
>— устранение утечек памяти.
>Устранение наиболее «болезненных» багов.
Простите, прочитал как «Какие предыдущие приоритеты команды были». :( Вот уж точно: каждый видит то, что хочет видеть. Приоритеты предыдущей команды описаны в TODO, линк на него есть в предыдущем посту.