MiksIr

Сомневайтесь, нам от этого не убудет =) Мы со своей стороны тоже будем кое о чем сомневаться =) Это "ДАО" очень простое, и я его описал в начале предыдущего поста. Если кратко, то "сломай в себе ретрограда и зануду". Впрочем, закостенелых консерваторов мы и не берем, ибо они не способны развиваться вообще. И правда, меня уже утомил "ваш гений". Потом сами обижаться будете, что "перешли на личности". Ну в общем, я вам не верю, что вы сразу пишете безгрешный код, не допускаете опечаток, помните наизусть все свойста класса, с которым работаете и тому подобное. Какой анализ кода, какой рефакторинг? На конкретный пример из вас прет поток общих фраз, которые без контекста бессмыслены. Какой-то партийны деятель, а не разработчик. Что вы будет рефакторить, когда после верстки вам нужно заниматься тонкой доводкой результата, что все делают в фаирбаге/дев.тулзе. Ну бейте, да.. пусть ваши верстальщики совершают тучу ненужных переключений между программами и поиском по строчкам где что изменить. Не знаю, может вы таких набираете, кто приветствует автоматическую монотонную работу. KISS - это такая отмаза для тех, кто не тянет сложные проекты. Переводится приблизительно как "не усложняй". На самом деле он совсем не о том, этот принцип, но хорошая отмаза для тех, кто ленится.

Вообще-то моя позиция не как разработчика. И, к слову, мне попадались разработчики вроде вас. У нас с ними все очень просто - две-три недели он обязан использовать IDE, по истечении волен вернуться в свои привычные среды разработки. Никто не возвращался. К слову, это касается только фронт-энд, т.е. верстальщиков и JS. PHP программисты с "Ноутпад++" как основная среда мне не попадались... возможно отсеивались на стадии чтения резюме и оценки опыта, не знаю, не задумывался =) О, наговнокодить можно, никто не спорит. "Сильно" - это понятие относительное. Пусть даже 10%, что, откажетесь от 10% своей зарплаты за "просто так"? Хотя в реальности там больше 10% и зависимость праямо пропорциональна сложности проекта. Это если говорить о чистовой разработке. А если взять вариант возвращения к коду 3-6 месячной давности, тут IDE очень вырывается вперед - что весьма значительно влияет на стоимость поддержки ПО. У меня основное время - сон, прогулки на улице, транспорт, еда... только я в общем не это имел ввиду. Несомненно, отладка 3-х функций не доставляет труда =) О чем спорить то тогда? Значит ваши задачи пока не требуют IDE. Ну и чудненько. Я просто советую вам не заявлять всем "зачем для веб-разработки IDE, там все элементарно". У других то может быть иначе. Даже в вашем случае IDE дала бы много приятного сахара, но если вы любите сидеть на жестких стульях и кушать сухари с водой, то это ваш выбор. Для меня уже дикость даже в простом скрипте строк на 300 не получать подсветку активных переменных, не используемых и не определенных переменных и тому подобный сахар, а в HTML и CSS не получать автозаполнение по файлам в файловой системе, потерянные и измененные файлы и т.п. А верстальщик с удовольствием освоил плагин, который передает изменения css в фаирбаге напрямую в IDE и после завершения остается только посмотреть список предложенных изменений и кликом мышки перенести в css файл необходимое. Какой он там еще сахар для верстальщика нашел - не скажу, не обсуждали, а я сам не верстаю. Ложкой дегтя тут, конечно, будет ресурсоемкость. Т.е., имхо, разработчик, как в любом вообще бизнесе, должен направлять часть дохода на развитие основных средств бизнеса, коим для разработчика является компьютер только. Но, как говорится, у каждого своя песня, так что если комп не тянет IDE, то ничего уже не попишешь. Вторая ложка дегтя - это то, что в большинстве универсальных IDE на самом деле больше всего акцент делается на серверные языки. Много вещей, которые именно для JS сделаны... ну, хотелось бы лучше. Хотя тут еще сама специфика JS сказывается. По крайне мере на примере *Storm. Но в общем лучше ноутпада++ полюбому =) За сим и прощаюсь. Вроде как раскрыли обе точки зрения.

Я бы поверил, что вы всерьез понимаете о чем говорите. Но "не верю". Именно исходя из написанного ранне. IDE - это как раз инструмент понижения стоимости разработки и особенно поддержки. Ну и да, вы много думаете. Процесс разработки редко попадает под ваши 80/20. Обычно проектирование архитектуры занимает 20-30% разработки, редко больше, часто - меньше, ибо архитектура прекрасно заимствуется, так что типовые проекты требуют минимум проектирования, ибо все уже это было раньше. Основное время- это написание кода. Если написание кода у вас 80/20, то мой вам совет - попробуйте уменьшить количество бесполезной информации, которую вы держите в голове, отдайте на откуп компьютеру, а сами освободившуюся голову научите мыслить параллельно с написанием кода. Тогда вы 100% времени будете и писать и думать. Ну а про отладку говорить не будем, я понял уже все Ну и вообще, вы знаете, что бахвальство не красит человека, а "Я" - последняя буква алфавита? =)) В общем, с IDE все очень просто. Если вы не используете IDE, значит а) ваша текущая разработка не дошла еще до уровня (объема), когда IDE серьезно помогает, или б) вы просто не смогли освоить IDE как инструмент. Я не буду спорить, что скриптик с фиксами верстки на сотню строчек может проще написать и в блокноте... ну, т.е. не проще, но если соизмерять со временем первичного освоения IDE - то да, блокнот проще. Но начиная с какого-то момента... как в старом анекдоте - "да некогда мне инструкцию на бензопилу читать, буду лес топором валить дальше" =)

Дамагогия. Если вас IDE делает ленивым, и вы считаете профессионализмом - помнить все на зубок, то не следует проецировать это на остальной мир. Высшее образование у вас есть? 90% того, чего учат в институтах - это не забивать голову ненужными данными, а просто хорошо знать - где и, самое главное, что искать. Потому-что голова в принципе держит лишь оперативную информацию. Во-вторых, наивно предполагать, что средства IDE ограничиваются лишь "напоминанием названий". Автокомплит является не напоминалкой, он является средством ускорения ввода. IDE != автокомплит, это в первую очередь анализ написанного и указание на возможные слабые места + рефакторинг. Опечатались в названии переменной? Хотите переименовать по 100500 строчкам кода вашу переменную? Функция возвращает нестабильное значение? Нужен дебаг? Да банальный пример выше с изменением картинки. Но если вы никогда ничего не забываете, никогда не опечатываетесь, держите все килобайты JS сразу в уме и ваша скорость набора 9000 тысяч знаков в минуту - вам IDE не нужен. Только позвольте тогда посредственностям тут побеседовать, хорошо? Ваше божественное присутствие смущает =) Я рад за них. Значит они раньше работали эффективно, а сейчас их пытаются заставить копать 100 метровую траншею лопатой, ибо бригадир "вертел все эти ваши тракторы". Не боитесь оказаться как раз тем, от кого "ускользнуло"? Хотя что я спрашиваю, конечно не боитесь, но это ничего не изменит =)

Забыли еще добавить - занудство, упертость и еще одно... =) Ну именно те качества, которые мешают использовать средства упрощения жизни и заставляют ломать глаза и голову разбирая десятки килобайт жаваскрипта и дебажить их старым дедовским alert =) ЗЫ. А сколько раз я наблюдал, когда просто верстальщики забывали после замены картинки поменять ее размеры в коде... но, наверно, это были глупые тупые и не эрудированные верстальщики =)))

Если вы не можете нормальное приложение написать без всяких финтифлюшек, свистелок и перделок, то стоит задуматься над этим. Не всем блох подковывать дано... топором.

Хочется синтаксического сахара? Чем не угодила надстройка LESS? Чем удобнее нативная поддержка? Как я уже сказал - отладкой на клиентской стороне. Банально в фаирбаге изменять значения. В случае сборки из шаблонов это уже будет очень тяжело. Хотя, как я сказал, ничего страшного не случится, да, и те, кому это нужно - это используют через шаблоны. Волков бояться - в лес не ходить.

Не знаю, у меня никто не ныл. Но знаете, очень много ПХП программистов ноют по поводу ООП - не готовы, а может просто тупы. Но наличие людей, которые "не осилили" предметную область до конца будет всегда и это не повод ориентироваться на них. Переменные в css - раздутая тема. По двум причинам. Во-первых, это очень полезно, особо для всяких БЭМ, где минимум каскадов, а значит максимум повторений. Во-вторых, потому что те, кому оно надо, давно это используют у себя в виде шаблонов с генерацией результата. Хотя "чистые" css переменные были бы чуточку удобнее... хотя бы для отладки. А говорит - не нужны переменные ибо верстальщики запутаются и напортачат - глупость. Да, запутаются и напортачат, да, даже без переменных, ибо это зависит от верстальщика, а не от css.

И что? Т.е. если ЯП - не путаются, а если не ЯП - сразу путаться начинают?

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

<!--# set var="borderColor" value="#000000" --> <!--# set var="backgroundColor" value="#FFFFFF" --> ... .block { border-color: <!--# echo var="borderColor" -->; background: <!--# echo var="backgroundColor" -->; } :rofl:

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

У меня такое ощущение, что последние год-два в нашу космическую промышленность пришли именно такие люди =)

Очень плохой верстальщик не думает головой. Средний - "верстальщик обыкновенны" - думает много... слишком много. Очень хороший верстальщик думает головой настолько хорошо, что четко знает границу, когда пора перестать выё.. думать, и начать спрашивать. Идеальный верстальщик уже знает 99% ответов на свои вопросы =) Но это достижимо только внутри коллектива, конечно =)

На phpclasses.org изредка попадаются готовые библиотеки под всякие экзотические штуки, так что имеет смысл зарегистрироваться =)

http://www.phpclasses.org/package/1509-PHP-Convert-from-and-to-IDNA-Punycode-domain-names.html

Конечно, почему бы и нет. Только для начала бы неплохо взять хром с бета-канала и проверить там.

Ок а почему без int 8 ??? Полагаю, что echo делает какое-то округление само. Для того, что бы убедиться, попробуйте print (8-(0.7+0.1)*10); или 'printf("%.20f", (0.7+0.1)*10);

Особенности работы с плавающей запятой на современных вычислительных машинах. Можете гуглить - найдете много. В двух словах, из-за этих особенностей у вас получается не 8.0, а 7.9999... (int) просто отбрасывает дробную часть и использует целое. Т.е. если вы начинаете работать с дробными числами, сначала обязательно изучить теорию.

А что такое верстка? Это создание описательного css/html кода в точном соответствии с техническим заданием в виде psd макета. Т.е. верстка - разработка, написание css правил - неотъемлемая часть процесса верстки, т.е. неотъемлемая часть разработки. Создание css - процесс разрабоки.

> И к чему это? Ну не творчество и что? Дизайн - творчество. Вертска - не творчество. Но для вас верстка - это дизайн. "> Но только CSS я отношу к дизайну, а не к разработке" Ну что же, давайте сделаем голосование: Верстка, это - а) дизайн б) разработка и посмотрим, кто прав.

А зря. Просто прежде чем рассуждать что относится к тому или иному термину, следует понять, что вообще эти термины значат. > Вот с ней я полностью согласен. Но только CSS я отношу к дизайну, а не к разработке Дизайн - это в первую очерель творчество. Даже технический дизайн. А какое творчество в переводе одного формата в другой? Вот программу с одного языка на другой переписать - это ну никак не творчество. Дизайн макет перевести из psd в html/css - это творчество? Никогда. Даже всякие анимации которые делает верстальщик, должнны ему быть переданы в виде описания или раскадровок дизайнером. Верстка не подразумевает никакого творчества. Формально. Ясно, что могут быть пересечения в одном человеке, но как правило очень хороший дизайнер и очень хороший верстальщик в одном лице быть не могут - менталитеты разные.

У вас неправильное представление. Осталось выяснить - с чего это. Есть верстка. Есть JS программирование. По отельности. Все вместе + смежные области - это фронт-енд разработчик. Чем больше смежных областей, включая проектирование взаимодействия - тем ближе к фронт-енд архитекторы. Чикуенок - фронт-енд разработчик или архитектор (ну, скажем, был), но от этого он не перестает уметь верстать. Так же и в сервере - есть PHP программист. Есть UNIX администратор. Есть ДБА. Все вместе + смежные области - бек-енд разработчик, хотя такой термин не очень популярен. Чем больше знает смежных областей и глубже знания в указанных - тем ближе к архитектору. > Вот проектирование взаимодействия клиента с юзером и сервером - и есть фронт. Кого с кем? Проектирование взаимодействия вообще ничего про сервер не знает. Да и про браузерные технологии - только набор ограничений для интерфейсов. Проектирование взаимодействия - это то, что модно называется юзабилити. По больщому счету это даже не дизайн. А информационный дизайн - это уже скорее перевод проекта взаимодействия в доступные элементы интерфейса в виде прототипа или дизайн-макета. Проблему я вижу в том, что вы используете просто слово "фронт-енд". Вы прочитайте все же мой пост. Это слово оторванное от сущности - смылса никакого не имеет. Что для вас - сущность? Для меня - это разработка. Т.е. есть фронт-енд разработка, бек-енд разработка. Дизайн сюда не лезет.

Это на флеше API не напишешь? И вообще причем тут API? У нас есть разработка сайтов. Условно набросам процесс 1. Постановка задачи, выяснение функционала, интервью и все такое 2. Проектирование взаимодействия + информационный дизайн 3. Реализация спроектированного Все, реализация пошла. Разработка. Которая может делиться только на две части - фронт и бек. Еще раз, деление на фронт и бек применимо к некой сущности, с которой происходит какое-то взаимодействие. Сущность состоит из множества сильно связанных элементов, но можно найти некую точку, которая делит эти элементы на две группы, во-первых, очень слабо связанные между собой в этой точке, во-вторых, взаимодействие приходится только на первую группу, которая является посредником для взаимодействия со второй группой. И что есть только "бек" и "фронт", третьего нет. Деление "бек" и "фронт" - это скорее филосовская категория, чем техническая терминология. Если мы возьмем исключительно десктопное браузерное приложение, тут тоже можно найти фронт и енд. Наверно, HTML/CSS будет фронтом, JS+Storage станет беком, а интерфейсом между ними - события и обращения к DOM. Но когда мы ведем речь о веб-разработке сайта с серверной частью - здесть точка деления другая. И HTML/CSS оказывается в куче с JS. Ибо нет третьего. И HTML/CSS ну никак не лезет в пункт проектирования взаимодействия и дизайна.

Css это не ui. Равно как фотошоп - это не дизайн. Вы еще программистов адоба дизайнерами назовите ибо они делают фотошоп. Css - это средство реализации спроектированного UI. Равно как и js. Это может быть не css, а флеш или жава или чтото еще