а почему речь только о дизайне? на техническом уровне все везде ок? не работающие менюшки, неудобная структура, форма обратной связи, которую нельзя отправить — ни разу не сталкивались?
в том и суть: «сделать хорошо клиентам клиента» не только что нужно клиентам клиента, это еще и производственный процесс, это как делать. Вы же говорите о том, что заказчик диктует «как делать» — в таком случае «сделать хорошо клиентам клиента» не получится, потому что «как делать» заказчик знает чуже разработчика по определению.
или я не правильно понял фразу: «Пусть они сами и решают, как будет максимально удобно их клиентам»?
золотые слова, если автомобили продавать. сайт делается для посетителей (сайта), но ни как ни для того, чтобы Ларису Ивановну удовлетворить. если же сайт делается для заказчика, то это интранет; и делается он, кстати, для всех сотрудников компании.
сайты, даже шаблонные, продукт штучный, индивидуальный. Лариса Ивановна знает (и то не всегда), что нужно её клиентам/партнерам, разработчик — как это высветить на сайте (да, тоже не всегда). иными словами: пациент знает, что болит, доктор знает, как это исправить.
когда сторона, которая знает «как» надо, пытается указывать «что» надо — редко получается что-то хорошее. и наоборот.
подход «главное, чтоб денег дали» применим, когда нет возможности повлиять на товар, то бишь, продажи чего-то сделанного до тебя. если Лариса Ивановна хочет, чтобы внутри багажника лебедь плавал в авто-салоне — конечно, очень разумное требование, если она хочет того же в конструкторском бюро… ну, мягко говоря, не прокатит.
html-верстальщик — конвертация psd в html
front-end developer — создание сайтов (не xml-сервисов) с использованием чужих серверных разработок
разработчик интерфейсов — client-side-разработка страниц веб-приложений
web-технолог — разработка всего, чего угодно, это даже не client-side-технолог, но обязательно иметь проф. уровень выше разработческого
и что, к сожалению, это значит на практике:
html-верстальщик — front-end developer без знания jquery
front-end developer — html-верстальщик со знанием jquery + красивое название
разработчик интерфейсов — front-end developer + 10k к зарплате
web-технолог — front-end developer + 10k к зарплате
найти чистую client-side работу в рунете невозможно, обязательно 3/4 времени «html-верстальщика» уходит на фронт-энд, оставшаяся четверть на подправку php и верстку. по-этому у нас и хороших верстальщиков почти нету, и переход в php-программисты считается карьерным ростом.
фактически, получается, что разницы нет — все это разные названия web-мастера, рядом с которым сидят php'шник и диз. а еще есть такая специализация, как js-developer, на практике это (скоро будет) html-верстальщик с хорошим знанием jquery. покуда server-side'ом будут заниматься не только php-кодеры, но и все остальные, вопрос бессмысленный.
помню-помню :) только тут проблема в другом. такой же коммент, который ты text/plain написал, любая секретарша раскрасит всеми цветами мира и «оформит» пятью разными шрифтами, чтобы было прикольно и красиво.
поборникам открытого веба? где web forms и svg-анимация? да будет, обычное сообщество, которое надеется получить кусочек ие6-пирога — а тут такая подстава. думается, что людям, которые не хотят узнавать, что такое браузер куда легче согласиться на некое дополнение, в котором что-то будет (быстрее) работать.
внутреннее состояние, оно не само по себе, на него можно влиять: узнавать, чем хочет заниматься человек и ставить ему подходящие задачки — человек будет заниматься тем, чем хотел бы; привлекать человека к проектированию — признавать его значимость; просто премии выписывать. не хотят работать все ресурсы, но не все люди.
в целом я с Вами солидарен, но вот в деталях — вовсе нет. я ни коим образом не гос. работник :)
> Вот уж если брать возможности коробок то вы меня простите, но фреймворки то погибче в разы будут
людям, особенно которые за конкретный продукт платят, от абстрактной гибкости толку мало. им нужно: то, это, пятое и десятое — и чтобы потом поменять/дописать что-нибудь было реально.
> ТЗ не должно навязывать конкретную КМС
а что оно должно описывать в плане работы с сайтом? требования к cms? если написать их в виде брифа, любое говнецо формально прокатит; а детальное описание требований с ноля, без оглядки на что-то уже существующее, требует очень продолжительного интервала времени и очень грамотных специалистов — никто не будет с чистого листа, причем не ошибаясь, клепать требования к «закладке» загрузки файлов, а на практике процесс скатится до копипасты уже существующего ТЗ на какую-либо cms. и, в любом случае, 90% существующих систем под самопальное описание идеальной коробки не подойдут.
> Требований к языкам программирования
вот у Вас требуется HTML технолог, и ему «желателен опыт работы с Javascript-фреймворком JQuery» — как же так!? почему Вы считаете, что в праве выдвигать требование по привязке к конкретному фреймворку, а Вам должны писать: «знание js-фреймворка, умеющего работать с dom, ajax...»? правильно, у Вас принято работать с этим фреймворком — а у гос. заказчика есть люди, которые уже умеют работать с вот этой системой, Вы вкладывали в смету обучение персонала заказчика?
> вопрос конктретной коробки и вопрос выбора подрядчика — это вообще вещи слабосвязанные
тоже самое: у Вас есть опыт с jQuery, а с сайтом на Dojo лучше справятся люди, знающие Dojo. абстрактные кони в вакууме возможны только для первого сайта, но как только первый же сайт принят и оплачен, у взаимоотношений компании с сетью появляются исторически сложившиеся факты и контекст.
ну не знаю :) как по мне, так раз мы что-то удалили — оно должно взять, да удалиться и нигде больше не учитываться.
сделал у Event'а firedFor, массив оповещенных слушателей и метод, возвращающий следующего слушателя:
this.getNextListener = function(listeners) {
// не экономно, зато написал быстро :)
for (var i=0, l=listeners.length; i<l; i++) {
if (!indexOf(this.firedFor, listeners[i])) return listeners[i];
}
};
function indexOf(array, search) {
for (var i=0, l=array.length; i<l; i++) {
if (array[i]==search) return true;
}
}
соответственно, поменялся и fireEvent:
var evt = new Event(type, data);
var listener = true, listenersType=listeners[type];
while(listener) {
if (evt.stoped) break;
listener = evt.getNextListener(listenersType);
if (!listener) break;
evt.firedFor.push( listener );
evt.lastRet.push( listener.fire(evt) );
}
return !evt.stoped;
спасибо, не подумал о такой ситуации. правда, в сий раз, я вообще об удалении не задувылся :)
тут есть момент один: если листенер удаляется в процессе выполнения это одна бага, а если массив просчитан заранее (и не изменяется), то бага получится, если удалить один из следующих листенеров, т.к. в массиве-то он останется и зафайрится… получается, что нужна или умная крутилка, или перед исполнением функции проверять существование листенера…
или я не правильно понял фразу: «Пусть они сами и решают, как будет максимально удобно их клиентам»?
сайты, даже шаблонные, продукт штучный, индивидуальный. Лариса Ивановна знает (и то не всегда), что нужно её клиентам/партнерам, разработчик — как это высветить на сайте (да, тоже не всегда). иными словами: пациент знает, что болит, доктор знает, как это исправить.
когда сторона, которая знает «как» надо, пытается указывать «что» надо — редко получается что-то хорошее. и наоборот.
подход «главное, чтоб денег дали» применим, когда нет возможности повлиять на товар, то бишь, продажи чего-то сделанного до тебя. если Лариса Ивановна хочет, чтобы внутри багажника лебедь плавал в авто-салоне — конечно, очень разумное требование, если она хочет того же в конструкторском бюро… ну, мягко говоря, не прокатит.
front-end developer — создание сайтов (не xml-сервисов) с использованием чужих серверных разработок
разработчик интерфейсов — client-side-разработка страниц веб-приложений
web-технолог — разработка всего, чего угодно, это даже не client-side-технолог, но обязательно иметь проф. уровень выше разработческого
и что, к сожалению, это значит на практике:
html-верстальщик — front-end developer без знания jquery
front-end developer — html-верстальщик со знанием jquery + красивое название
разработчик интерфейсов — front-end developer + 10k к зарплате
web-технолог — front-end developer + 10k к зарплате
найти чистую client-side работу в рунете невозможно, обязательно 3/4 времени «html-верстальщика» уходит на фронт-энд, оставшаяся четверть на подправку php и верстку. по-этому у нас и хороших верстальщиков почти нету, и переход в php-программисты считается карьерным ростом.
фактически, получается, что разницы нет — все это разные названия web-мастера, рядом с которым сидят php'шник и диз. а еще есть такая специализация, как js-developer, на практике это (скоро будет) html-верстальщик с хорошим знанием jquery. покуда server-side'ом будут заниматься не только php-кодеры, но и все остальные, вопрос бессмысленный.
переписка ученых умов выглядит довольно-таки сурово)
> Вот уж если брать возможности коробок то вы меня простите, но фреймворки то погибче в разы будут
людям, особенно которые за конкретный продукт платят, от абстрактной гибкости толку мало. им нужно: то, это, пятое и десятое — и чтобы потом поменять/дописать что-нибудь было реально.
> ТЗ не должно навязывать конкретную КМС
а что оно должно описывать в плане работы с сайтом? требования к cms? если написать их в виде брифа, любое говнецо формально прокатит; а детальное описание требований с ноля, без оглядки на что-то уже существующее, требует очень продолжительного интервала времени и очень грамотных специалистов — никто не будет с чистого листа, причем не ошибаясь, клепать требования к «закладке» загрузки файлов, а на практике процесс скатится до копипасты уже существующего ТЗ на какую-либо cms. и, в любом случае, 90% существующих систем под самопальное описание идеальной коробки не подойдут.
> Требований к языкам программирования
вот у Вас требуется HTML технолог, и ему «желателен опыт работы с Javascript-фреймворком JQuery» — как же так!? почему Вы считаете, что в праве выдвигать требование по привязке к конкретному фреймворку, а Вам должны писать: «знание js-фреймворка, умеющего работать с dom, ajax...»? правильно, у Вас принято работать с этим фреймворком — а у гос. заказчика есть люди, которые уже умеют работать с вот этой системой, Вы вкладывали в смету обучение персонала заказчика?
> вопрос конктретной коробки и вопрос выбора подрядчика — это вообще вещи слабосвязанные
тоже самое: у Вас есть опыт с jQuery, а с сайтом на Dojo лучше справятся люди, знающие Dojo. абстрактные кони в вакууме возможны только для первого сайта, но как только первый же сайт принят и оплачен, у взаимоотношений компании с сетью появляются исторически сложившиеся факты и контекст.
сделал у Event'а firedFor, массив оповещенных слушателей и метод, возвращающий следующего слушателя:
this.getNextListener = function(listeners) { // не экономно, зато написал быстро :) for (var i=0, l=listeners.length; i<l; i++) { if (!indexOf(this.firedFor, listeners[i])) return listeners[i]; } }; function indexOf(array, search) { for (var i=0, l=array.length; i<l; i++) { if (array[i]==search) return true; } }соответственно, поменялся и fireEvent:
var evt = new Event(type, data); var listener = true, listenersType=listeners[type]; while(listener) { if (evt.stoped) break; listener = evt.getNextListener(listenersType); if (!listener) break; evt.firedFor.push( listener ); evt.lastRet.push( listener.fire(evt) ); } return !evt.stoped;тут есть момент один: если листенер удаляется в процессе выполнения это одна бага, а если массив просчитан заранее (и не изменяется), то бага получится, если удалить один из следующих листенеров, т.к. в массиве-то он останется и зафайрится… получается, что нужна или умная крутилка, или перед исполнением функции проверять существование листенера…