Ни один выпускник вуза не заменит "ботаника" без ВО, с 13 лет "ковыряющегося" в компьютере. Или вы хотите сказать, что человек с ВО лучше понимает, что происходит при выполнении функции strncpy?
Человек с техническим ВО, впервые увидевший компьютер и программирование в универе, будет весьма посредственным специалистом. Потому что база у него не та. Потому что образование не то.
Ну давайте, научитесь писать за 2 вечера на Haskell. А через 2 недели сделайте качественную реализацию компилятора JS на том же Haskell. Фигли!
Любой серьезный язык программирования требует модификации мышления программиста, а это минимум 3 месяца активной практики с языком. И примерно через год практики можно условно говорить, что вы знаете как правильно применять данный язык.
В ситуации, когда страница отдана в браузер в UTF-8, и по действию пользователя с нее делается AJAX-запрос методом GET, в какой кодировке браузер должен отправлять данные?
А заметьте, что 90% комментариев подразумевают использование PHP на стороне сервера. Это при том, что в соседних топиках идет флуд aka PHP suxx. Однако, парадокс..
По теме: все в курсе про баг в IE на тему UTF-8 кодировки при AJAX-запросе? Или дополнить этот пробел в комменте?
XML+XSLT в PHP работают с любыми кодировками, потому что под ними лежит libxml + libxslt. Другое дело, что если работать с XML через DOM в PHP, то надо данные ручками конвертировать в UTF-8.
Путин не дурак. В отличие от Лукашенко, он на 3-й срок не пойдеть. Ну потусуется в тени 4 года в должности какого-нибудь Главного Советника Президента, а в 2012 снова вернется. Че вы паритесь, господа хорошие?
Наблюдал неоднократно, только обычно все дискуссии сводились к тому, что предоставленное клиентом ТЗ не является полноценным и мы настаивали на создании нового ТЗ. Это так же как с кодом как ни крути, а рано или поздно придется переписывать.
Описанная Вами ситуация говорит об отсутствии нормального процесса внутри компании.
1. Программист сопровождает 10 проектов.
Выделите саппортеров, из тех же программистов. Пусть каждый программист работает в саппорте в течение 1-2 недель с ротацией, но не вешайте саппортные работы программисту в "фоновом режиме".
2. А то он реализует мегафичу, которой не было в эстимейте.
Это вопрос планирования. Если вы высыпаете программисту пачку тасков с одинаковым приоритетом и дедлайном через 3 месяца, разумеется он может увлечься и отклониться от цели. Малые итерации с небольшим набором задач исправят положение.
3. Упс.
4. Если свободное время есть - пусть переписывает.
Рефакторинг необходимо закладывать в бюджет проекта. Отсутствие рефакторинга - смерть для саппорта, багфиксинга и модификации системы в будущем.
5. Положение может исправить TDD. Идеальный вариант после реализации фичи через TDD за код садится другой разработчик и пытается придумать варианты как сломать реализацию не выходя за рамки поставленной задачи. См также пункт 4.
6. А если дэдлайн через 2 дня, а на проект выделено 100 часов?
Привлечение доп. программистов задержит выход системы еще больше (с) Брукс. От себя: не нужно браться за те задачи, которые вы не в силах потянуть маленькой командой в оговоренный срок.
7. упс.
8. Каким боком программист связан с прототипом??
Самым прямым боком. Имеется ввиду не "прототип в Visio", а рабочий прототип части проекта, который можно потыкать и оценить насколько созданное решение в прототипе подходит для поставленной задачи.
Эм... Неверно, потому что прикидывая объем девелопер изначально предполагает минимально необходимую реализацию. Заказчик - наоборот - старается выжать максимум из поставленной задачи.
Вы никогда не сталкивались с фразой "ну это же стандартная фича" или "ну это же очевидно", "это предполагалось"?
Банальный пример: нужно совместить логин для форума phpBB с некой кастомной системой, например xcart. Ваш вариант оценки трудозатрат и стоимости такой задачи?
Не являясь дизайнером, осмелюсь предположить, что дизайн заказывается на основании некой работающей системы (будь то сайт, портал, блог - не суть), которая есть у клиента в распоряжении.
Основные моменты, которые я бы выделил:
1. Дизайнер является последней (пред-)инстанцией, следовательно всегда можно пощупать и обсудить, что именно нужно дизайнить.
2. Дизайнить можно итерационно, например, логотип -> шапка, футер -> шрифты -> цвета -> картинки -> нюансировка.
3. Дизайнить нужно не статику, а динамику. Не поверхность листа А4, а сущности системы.
4. совместная интерактивная работа дизайнера и заказчика: гораздо быстрее, легче и продуктивнее работа будет протекать, если заказчик присядет рядом на стульчик и вместе с дизайнером найдет оптимальный вариант.
Практика показывает, что даже 200-баксовая задача может вырасти до неимоверных размеров. Вопрос в том, будете ли вы на протяжении 2 месяцев корячиться за 200 баксов. Трейнинг клиента - инвестиции в будущее сотрудничество.
Господа, вы перетираете следствия проблемы, которая была успешно решена 7 лет назад. Проблема осталась в головах людей; в неверном представлении о том, что такое разработка программного обеспечения на самом деле.
В первом разговоре с клиентом следует говорить не столько о проекте, сколько о методологии, разложить по полочкам риски проекта и показать как методология разработки помогает уменьшить или исключить тот или иной риск. Из-за неразруленых рисков вытекает недоверие, неуверенность, сокрытие деталей о проекте клиентом, со всеми вытекающими.
Вообщем, перечитайте Кента Бека, пропагандируйте agile software development и будет вам счастье ;-)
Человек с техническим ВО, впервые увидевший компьютер и программирование в универе, будет весьма посредственным специалистом. Потому что база у него не та. Потому что образование не то.
Любой серьезный язык программирования требует модификации мышления программиста, а это минимум 3 месяца активной практики с языком. И примерно через год практики можно условно говорить, что вы знаете как правильно применять данный язык.
По теме: все в курсе про баг в IE на тему UTF-8 кодировки при AJAX-запросе? Или дополнить этот пробел в комменте?
1. Программист сопровождает 10 проектов.
Выделите саппортеров, из тех же программистов. Пусть каждый программист работает в саппорте в течение 1-2 недель с ротацией, но не вешайте саппортные работы программисту в "фоновом режиме".
2. А то он реализует мегафичу, которой не было в эстимейте.
Это вопрос планирования. Если вы высыпаете программисту пачку тасков с одинаковым приоритетом и дедлайном через 3 месяца, разумеется он может увлечься и отклониться от цели. Малые итерации с небольшим набором задач исправят положение.
3. Упс.
4. Если свободное время есть - пусть переписывает.
Рефакторинг необходимо закладывать в бюджет проекта. Отсутствие рефакторинга - смерть для саппорта, багфиксинга и модификации системы в будущем.
5. Положение может исправить TDD. Идеальный вариант после реализации фичи через TDD за код садится другой разработчик и пытается придумать варианты как сломать реализацию не выходя за рамки поставленной задачи. См также пункт 4.
6. А если дэдлайн через 2 дня, а на проект выделено 100 часов?
Привлечение доп. программистов задержит выход системы еще больше (с) Брукс. От себя: не нужно браться за те задачи, которые вы не в силах потянуть маленькой командой в оговоренный срок.
7. упс.
8. Каким боком программист связан с прототипом??
Самым прямым боком. Имеется ввиду не "прототип в Visio", а рабочий прототип части проекта, который можно потыкать и оценить насколько созданное решение в прототипе подходит для поставленной задачи.
P.S. Вы случайно не в Viaden Media работаете? ;-)
Вы никогда не сталкивались с фразой "ну это же стандартная фича" или "ну это же очевидно", "это предполагалось"?
Банальный пример: нужно совместить логин для форума phpBB с некой кастомной системой, например xcart. Ваш вариант оценки трудозатрат и стоимости такой задачи?
Основные моменты, которые я бы выделил:
1. Дизайнер является последней (пред-)инстанцией, следовательно всегда можно пощупать и обсудить, что именно нужно дизайнить.
2. Дизайнить можно итерационно, например, логотип -> шапка, футер -> шрифты -> цвета -> картинки -> нюансировка.
3. Дизайнить нужно не статику, а динамику. Не поверхность листа А4, а сущности системы.
4. совместная интерактивная работа дизайнера и заказчика: гораздо быстрее, легче и продуктивнее работа будет протекать, если заказчик присядет рядом на стульчик и вместе с дизайнером найдет оптимальный вариант.
P.S. Не путать freelance с outsourcing services.
В первом разговоре с клиентом следует говорить не столько о проекте, сколько о методологии, разложить по полочкам риски проекта и показать как методология разработки помогает уменьшить или исключить тот или иной риск. Из-за неразруленых рисков вытекает недоверие, неуверенность, сокрытие деталей о проекте клиентом, со всеми вытекающими.
Вообщем, перечитайте Кента Бека, пропагандируйте agile software development и будет вам счастье ;-)