Если заказчик говорит: «хочу всё круто, но тормознуто — деньги не вопрос», то пожалуйста.
ДА!!! Три тысячи раз ДА!!! ОН ТАК И ГОВОРИТ!!!
Здравый же смысл говорит использовать современные технологии, а для IE в режиме показать страничку.
Здравый смысл говорит заказчику, что он продает холодильники по 200 тысяч за штуку. И один лишний проданный холодильник все окупит, а второй принесет ему прибыль!
Или вы считаете, что отказаться от покупателя правильней?
Во-первых, я где-то упомянул технические детали своей практики? По-моему речь шла исключительно об экономическом аспекте, и не надо играть в Вангу.
Во-вторых, *достойная* оплата — по-моему достаточно серьезный повод для создания той самой «особой необходимости».
Еще раз повторюсь, моя личная практика показывает, что серьезные клиенты с продающими сайтами готовы платить хорошие деньги за поддержку устаревших технологий на своих сайтах, и не готовы отказываться от IE6. Т.к. 1-2 заказа у них способны перекрыть всю разницу в цене разработки, и только упертый дурак будет экономить на сайте, чтобы потом за год потерять в разы, а порой и в десятки раз больше на недополученной прибыли.
От IE6 можно было бы начинать отказываться — на непродающих сайтах типа хабра. Эй, хабр, ты отказываешься от IE6?
Вы то что там пишите сначала на практике примените, а потом рассуждайте. Я уже пробовал, сделал 2 вывода:
1) Приятный вывод — клиенты готовы платить двойную/тройную цену за верстку под IE6+, и я смог заработать больше.
2) Неприятный вывод — заказчик не готов отказаться от IE6, т.к. по его счетчику ливинтернет до 50-70 посетителей в день это IE6. А даже один удачный посетитель, ставший клиентом, с лихвой окупит всю эту тройную цену.
Единственные кто отказались от повышения цены — мелкие и бесперспективные проекты, где в общем-то и так не слишком денежно было. Говорю вам из реальной практики, а не теоретических изысков.
Вы меня не совсем поняли. Я нигде не сказал, что на них не стоит обращать внимания.
Я скажу очевидную вещь, но специфика разработки любого коммерческого софта — в получении денег. При этом идеальная ситуация — когда делать ничего не надо, а деньги идут. Что мы на данный момент и видим.
Чтобы сдвинуть ситуацию с мертвой точки — в идеале нужен толчок экономический (чтобы все резко перестали делать сайты под ИЕ), но этого пока не предвидится. Либо толчок формальный, в виде принятых индустриальных стандартов, которые ими не поддерживаются, но этого тоже не предвидится. Так по какой же причине тогда IE должен идти в ногу с прогрессом? Ему гораздо выгодней лежать в своем болоте и тихо зарабатывать свое бабло. Это просто бизнес, и все… А писать три тысячи топиков на хабре тут бесполезно.
Либо надо начинать делать сайты без поддержки IE, либо принимать стандарт. Первое — малореально, а второе — почему, собственно, бы и нет?!
Если вы помните историю, то «специфика» мира браузеров началась еще в годы существования netscape, когда каждый из браузеров добавлял в свой движок свои «уникальные и неповторимые фичи», которые отсутствовали в другом, и продвигал это как конкурентное преимущество. В итоге сообщество верстальщиков обрело такую головную боль, что только W3C как-то смогло разрулить ситуацию и привести все к общему знаменателю (хотя и тогда на них M$ плевал, но хоть как-то обращал внимание).
Сейчас мы видим по сути второй виток этой гонки — игроки другие, но принципы те же. Причем сценарий до боли похож на первый — снова идет лавина новых фич, которые продвигаются как конкурентные преимущества своего браузера, снова пошло писькомерство «кто круче». И снова вся маркетинговая пыль остается после громких рекламных речей на голове и плечах простых верстальщиков.
Всем очевидно, что только стандартизация может спасти ситуацию, но где же тот самый живительный стандарт HTML5/CSS3, которому все должны следовать? А нет его! Между «почти стандартом» и «стандартом» целая пропасть, и лишь ребенок не видит ее. «Почти стандарт» — это такая же фикция, как беременность наполовину. Вот и получается, что на данный момент HTML5 — не более чем рекламный трюк в погоне за пользователем.
Да всем понятно что не предвидится, всем понятно что надо, но ОФИЦИАЛЬНО этих вещей нет. То, что они там «кандидаты в рекомендацию», «супер-пупер-почти-отполировали-еще-чуточку рекомендация» — это в упрек не поставишь. Нет спецификации — нет продукта.
Нормальные фирмы сначала выпускают спецификацию, потом ждут ~1-2 года реализацию (зависит от объема спецификаций), и только потом используют. У нас же телега вперед кобылы идет, и все делают вид, что так и надо.
Это столь же абсурдно как, скажем, начать сажать в тюрьму по новому, еще не принятому закону, мотивируя это тем, что закон уже прошел 2 чтения и серьезных изменений быть не должно.
P.S: еще раз подчеркиваю — я понимаю всю необходимость стандарта HTML5, который назрел еще черт знает когда. Я не понимаю лишь того, какого хрена тянут с его принятием.
Так, то оно так, но не забывайте, что большинство неподдерживаемых фич — черновики и будущие стандарты, еще не принятые официально.
То, что они нужны и важны — не вызывает сомнения. Но тогда какого же рожна W3C тянет с принятием? Если бы они были приняты — то аргументы были бы куда более весомые чем «вот есть хороший черновик стандартна, он правда полезный и правда хороший, почему же вы его не поддерживаете?»
Я с вами полностью согласен. И в общем-то считаю что ПДД составлены достаточно грамотно (хотя, например, за пьянство можно было бы и уголовную давать — тут уж никакой светофор не при чем).
Но когда, скажем, человек украл через софта на 100 тысяч рублей — ну дайте вы ему штаф на 200 тысяч чтобы не повадно было. Но наравне с убийцами-то зачем?!
Поддерживаю пункт 2: по сути я не хочу подписываться на блоги, а хочу иметь возможность от них отписываться.
Поясню: попав на хабр, я хочу видеть максимум информации по интересующей меня тематике. Порой, она попадает в совершенно чудные блоги, которые поиском среди тысяч других блогов я бы самостоятельно никогда не нашел. Например, новости о HTML5/CSS3 можно с равным успехом искать как в блогах CSS, так и в блогах HTML, верстки, фриланса, «будущее здесь», веб, блогах оперы/ФФ, гугля, да еще где только не найдешь (порой, диву даешься, сколько же разных мест может найтись для новости на хабре). Притом информация интересная и актуальная.
Так вот — хочу возможность быть автоматически подписанным на все блоги хабра, и потом уже руками от ненужных отписаться, а не тыкать остервенело в зеленый плюсик для подписки.
Т. е. на встрече разработчик не видит ни одной причины отказываться от проекта, но в процессе разработки всплывает очень много неприятных вещей.
Бывает, не спорю, причем бывает нередко. Но тут стоит отметить 2 момента:
1) Количество таких ситуаций обратно пропорционально вашему опыту. Т.е. когда вы разрабатываете десятый подобный заказ, вы уже насквозь видите основные трудности и сложности, и способны быть на шаг впереди и предугадывать «больные места», своевременно поднимая вопрос (в идеале — на стадии согласования), и обходя его.
2) Те случаи, когда избежать не удалось — это ваши риски. Бизнеса без риска не бывает! И, хоть и невозможно понять заранее какой из проектов «скосячит», с опытом вы наверняка будете знать, что неудачных проектов у вас бывает, скажем, 20%. После чего эти 20% закладываются как надбавка во все проекты, и когда наступает критический момент, и вы не сможете выправить ситуацию «по-хорошему» — вы всегда свободны отказаться, заплатить неустойку и пойти работать дальше, а не вкладывать неоправданные усилия в «плохой» проект.
ИМХО именно непонимание природы рисков и неумение их планировать косит добрую половину фрилансеров, превращая их в фатальных нытиков. А в жизни всегда чем больше потенциальный выигрыш, тем выше потенциальный риск :-)
P.S: товарищ Guderian, эта ваша статья просто шикарна. Вы не хотите продолжить ее статьей про управление рисками во фрилансе? С удовольствием бы почитал, т.к. сам еще не достиг достаточного просветления в этом вопросе, но чувствую, что здесь очень важная собака зарыта.
Не обязательно кричать о своих ошибках. Главное чтобы вы сами их видели, признавали и исправляли. Т.е. косячит — исправьте, нападать на заказчика при этом не надо, но и приносить публичное покаяние с самобичеванием тоже вовсе не обязательно.
К тому же первый пункт — уметь отказываться от плохих клиентов. Если вам попался такой индивид, то ваша ошибка хотя бы в том, что вы от него не отказались. И эту ошибку никогда не поздно исправить ;-)
От О до 5 Гб данных — скорость до З Мбит/с;
От 5 Гб до 10 Гб данных — скорость до 156 Кбит/с (с 08:00 до 24:00);
От 5 Гб до 10 Гб данных — скорость до 1 Мбит/с (с 00:00 до 08:00);
От 10 Гб и выше — скорость до 128 Кбит/с (действует 24 часа в сутки).
Аналогично и во всех остальных тарифах. Если вы не сотрудник мегафона, который пришел нам пудрить мозг, то будьте добры уже указывать реальные условия, а эту маркетинговую замануху, которую вы тут написали.
В тарифах все самое интересное именно в этих ограничениях, а не в том, что «в первые два дня, пока луна находится в нужной фазе и если день ясный, а курс доллара повышается — вы можете воспользоваться фантастической скоростью».
Документация хорошая — никогда даже мысли не было что-то спрашивать — все находил пока гуглем, хотя пишу на питоне много (зарабатываю этим на хлеб с маслом).
Ну мы же про него начали:) Не я начал, я лишь поддерживаю разговор;)
Функции типа [:], in, List Comprehensions — это из разряда того, что единожды учится при изучении нового языка. Такие фичи есть в любом языке — что те же доллары перед переменной, что === и тому подобные конструкции.
Конечно, идеально чтобы их было бы по-меньше, но одно дело изучить какой-то небольшой объем вначале и дальше работать свободно, другое дело — когда процесс обучения нужен постоянно. Из ряда языков, на которых мне приходится работать — C#, Java, Python, PHP, C++ (Qt) — в PHP эта проблема выражена ярче всего (в C тоже много такого, но там Qt спасает). Т.е. в процессе работы на PHP надо постоянно следить за порядком параметров, искать функции с далеко не очевидными названиями и следить даже за их написанием, т.к. часть из них написана без "_" в имени, а часть с ним.
> Я замечу, ни в pyqt4 ни в opencv эта проблема не решена и решается она как б-г на душу положит.
Да, тут вы правы. Но тут скорей проблема в том, что и Qt и Python написаны по четким Code Conventions и написаны хорошо и качественно. Но эти конвенции, увы, не сходятся. И потому местами получается ядреный микс, от которого может потянуть на тошноту. Для этого приходится перетягивать GUI в отдельный модуль или пакет.
С другой стороны неизвестно что было бы лучше — оставить чистый код, но заставить людей изучать Qt дважды (с оригинальным написание и без), либо попустится чистотой. Для такой большой библиотеки, возможно, их решение оптимально т.к. позволяет использовать те тысячи готовых в сети примеров на C++ практически без портирования. А вот более мелкие библиотеки надо было бы писать в «питонячьем» синтаксисе.
ДА!!! Три тысячи раз ДА!!! ОН ТАК И ГОВОРИТ!!!
Здравый смысл говорит заказчику, что он продает холодильники по 200 тысяч за штуку. И один лишний проданный холодильник все окупит, а второй принесет ему прибыль!
Или вы считаете, что отказаться от покупателя правильней?
Во-вторых, *достойная* оплата — по-моему достаточно серьезный повод для создания той самой «особой необходимости».
Еще раз повторюсь, моя личная практика показывает, что серьезные клиенты с продающими сайтами готовы платить хорошие деньги за поддержку устаревших технологий на своих сайтах, и не готовы отказываться от IE6. Т.к. 1-2 заказа у них способны перекрыть всю разницу в цене разработки, и только упертый дурак будет экономить на сайте, чтобы потом за год потерять в разы, а порой и в десятки раз больше на недополученной прибыли.
От IE6 можно было бы начинать отказываться — на непродающих сайтах типа хабра. Эй, хабр, ты отказываешься от IE6?
1) Приятный вывод — клиенты готовы платить двойную/тройную цену за верстку под IE6+, и я смог заработать больше.
2) Неприятный вывод — заказчик не готов отказаться от IE6, т.к. по его счетчику ливинтернет до 50-70 посетителей в день это IE6. А даже один удачный посетитель, ставший клиентом, с лихвой окупит всю эту тройную цену.
Единственные кто отказались от повышения цены — мелкие и бесперспективные проекты, где в общем-то и так не слишком денежно было. Говорю вам из реальной практики, а не теоретических изысков.
Я скажу очевидную вещь, но специфика разработки любого коммерческого софта — в получении денег. При этом идеальная ситуация — когда делать ничего не надо, а деньги идут. Что мы на данный момент и видим.
Чтобы сдвинуть ситуацию с мертвой точки — в идеале нужен толчок экономический (чтобы все резко перестали делать сайты под ИЕ), но этого пока не предвидится. Либо толчок формальный, в виде принятых индустриальных стандартов, которые ими не поддерживаются, но этого тоже не предвидится. Так по какой же причине тогда IE должен идти в ногу с прогрессом? Ему гораздо выгодней лежать в своем болоте и тихо зарабатывать свое бабло. Это просто бизнес, и все… А писать три тысячи топиков на хабре тут бесполезно.
Либо надо начинать делать сайты без поддержки IE, либо принимать стандарт. Первое — малореально, а второе — почему, собственно, бы и нет?!
Сейчас мы видим по сути второй виток этой гонки — игроки другие, но принципы те же. Причем сценарий до боли похож на первый — снова идет лавина новых фич, которые продвигаются как конкурентные преимущества своего браузера, снова пошло писькомерство «кто круче». И снова вся маркетинговая пыль остается после громких рекламных речей на голове и плечах простых верстальщиков.
Всем очевидно, что только стандартизация может спасти ситуацию, но где же тот самый живительный стандарт HTML5/CSS3, которому все должны следовать? А нет его! Между «почти стандартом» и «стандартом» целая пропасть, и лишь ребенок не видит ее. «Почти стандарт» — это такая же фикция, как беременность наполовину. Вот и получается, что на данный момент HTML5 — не более чем рекламный трюк в погоне за пользователем.
Нормальные фирмы сначала выпускают спецификацию, потом ждут ~1-2 года реализацию (зависит от объема спецификаций), и только потом используют. У нас же телега вперед кобылы идет, и все делают вид, что так и надо.
Это столь же абсурдно как, скажем, начать сажать в тюрьму по новому, еще не принятому закону, мотивируя это тем, что закон уже прошел 2 чтения и серьезных изменений быть не должно.
P.S: еще раз подчеркиваю — я понимаю всю необходимость стандарта HTML5, который назрел еще черт знает когда. Я не понимаю лишь того, какого хрена тянут с его принятием.
То, что они нужны и важны — не вызывает сомнения. Но тогда какого же рожна W3C тянет с принятием? Если бы они были приняты — то аргументы были бы куда более весомые чем «вот есть хороший черновик стандартна, он правда полезный и правда хороший, почему же вы его не поддерживаете?»
Но когда, скажем, человек украл через софта на 100 тысяч рублей — ну дайте вы ему штаф на 200 тысяч чтобы не повадно было. Но наравне с убийцами-то зачем?!
От нелегального контента пока еще никто не умер, но преступление это уголовное. Где логика?
Поясню: попав на хабр, я хочу видеть максимум информации по интересующей меня тематике. Порой, она попадает в совершенно чудные блоги, которые поиском среди тысяч других блогов я бы самостоятельно никогда не нашел. Например, новости о HTML5/CSS3 можно с равным успехом искать как в блогах CSS, так и в блогах HTML, верстки, фриланса, «будущее здесь», веб, блогах оперы/ФФ, гугля, да еще где только не найдешь (порой, диву даешься, сколько же разных мест может найтись для новости на хабре). Притом информация интересная и актуальная.
Так вот — хочу возможность быть автоматически подписанным на все блоги хабра, и потом уже руками от ненужных отписаться, а не тыкать остервенело в зеленый плюсик для подписки.
Бывает, не спорю, причем бывает нередко. Но тут стоит отметить 2 момента:
1) Количество таких ситуаций обратно пропорционально вашему опыту. Т.е. когда вы разрабатываете десятый подобный заказ, вы уже насквозь видите основные трудности и сложности, и способны быть на шаг впереди и предугадывать «больные места», своевременно поднимая вопрос (в идеале — на стадии согласования), и обходя его.
2) Те случаи, когда избежать не удалось — это ваши риски. Бизнеса без риска не бывает! И, хоть и невозможно понять заранее какой из проектов «скосячит», с опытом вы наверняка будете знать, что неудачных проектов у вас бывает, скажем, 20%. После чего эти 20% закладываются как надбавка во все проекты, и когда наступает критический момент, и вы не сможете выправить ситуацию «по-хорошему» — вы всегда свободны отказаться, заплатить неустойку и пойти работать дальше, а не вкладывать неоправданные усилия в «плохой» проект.
ИМХО именно непонимание природы рисков и неумение их планировать косит добрую половину фрилансеров, превращая их в фатальных нытиков. А в жизни всегда чем больше потенциальный выигрыш, тем выше потенциальный риск :-)
P.S: товарищ Guderian, эта ваша статья просто шикарна. Вы не хотите продолжить ее статьей про управление рисками во фрилансе? С удовольствием бы почитал, т.к. сам еще не достиг достаточного просветления в этом вопросе, но чувствую, что здесь очень важная собака зарыта.
К тому же первый пункт — уметь отказываться от плохих клиентов. Если вам попался такой индивид, то ваша ошибка хотя бы в том, что вы от него не отказались. И эту ошибку никогда не поздно исправить ;-)
Вы смеетесь? В тарифе идет речь про 3 мегабита, а не про 156 кбит/с.
Аналогично и во всех остальных тарифах. Если вы не сотрудник мегафона, который пришел нам пудрить мозг, то будьте добры уже указывать реальные условия, а эту маркетинговую замануху, которую вы тут написали.
В тарифах все самое интересное именно в этих ограничениях, а не в том, что «в первые два дня, пока луна находится в нужной фазе и если день ясный, а курс доллара повышается — вы можете воспользоваться фантастической скоростью».
Ну мы же про него начали:) Не я начал, я лишь поддерживаю разговор;)
Функции типа [:], in, List Comprehensions — это из разряда того, что единожды учится при изучении нового языка. Такие фичи есть в любом языке — что те же доллары перед переменной, что === и тому подобные конструкции.
Конечно, идеально чтобы их было бы по-меньше, но одно дело изучить какой-то небольшой объем вначале и дальше работать свободно, другое дело — когда процесс обучения нужен постоянно. Из ряда языков, на которых мне приходится работать — C#, Java, Python, PHP, C++ (Qt) — в PHP эта проблема выражена ярче всего (в C тоже много такого, но там Qt спасает). Т.е. в процессе работы на PHP надо постоянно следить за порядком параметров, искать функции с далеко не очевидными названиями и следить даже за их написанием, т.к. часть из них написана без "_" в имени, а часть с ним.
> Я замечу, ни в pyqt4 ни в opencv эта проблема не решена и решается она как б-г на душу положит.
Да, тут вы правы. Но тут скорей проблема в том, что и Qt и Python написаны по четким Code Conventions и написаны хорошо и качественно. Но эти конвенции, увы, не сходятся. И потому местами получается ядреный микс, от которого может потянуть на тошноту. Для этого приходится перетягивать GUI в отдельный модуль или пакет.
С другой стороны неизвестно что было бы лучше — оставить чистый код, но заставить людей изучать Qt дважды (с оригинальным написание и без), либо попустится чистотой. Для такой большой библиотеки, возможно, их решение оптимально т.к. позволяет использовать те тысячи готовых в сети примеров на C++ практически без портирования. А вот более мелкие библиотеки надо было бы писать в «питонячьем» синтаксисе.