Что можно сделать без массивов, циклов и нормальных условных конструкций?
Раз уж вы понимаете необходимость миксинов, циклов, переменных и пр. в css, может повлияете на csswg как один из крупнейших сервисов мира? Результаты последнего face-to-face показали что они слишком далеко ушли от реальной веб-разработки и слабо понимают потребности девелоперов.
Даже если разработчик занимается чисто бэкендом, ему нужно знать как работает фронтенд. Девелопер который не видит общей картины и не интересуется последними технологиями — кодер и не больше.
Мой баттхерт обусловлен тем, что поневоле мне приходится пользоватся продуктами таких кодеров: интернет-банкинги, сайты авиакомпаний, платёжные системы и т.д. И именно из-за непонимания как работает фронтенд, пользование этими продуктами если не невозможно, то весьма затруднительно.
Когда вставляют jQuery + плагин что бы установить cookie — это вон из профессии!
Просто проблема в том, что многие девелоперы, которые делают веб-софт для людей, отстали (по меркам IT) на целую эпоху. Продукты таких девелоперов — автоваз среди Тойот. Статья о том, что пора научится делать фронтенд хорошо, иначе можно просто отправиться на свалку истории.
Я в вебе много лет, я современен… но я не касаюсь фронтенда. Зачем мне всё это?
Вот из-за таких как вы, мне хочется иногда убивать людей. Зачем думать о юзабилити? Зачем думать о браузерах кроме IE? Зачем думать? Можно просто жрать зарплату и делать интерфейсы, на которые будут потом материться десятки тысяч пользователей. Ведь цель — сдавать вовремя функционал и получить за него деньги. А пользователь… Да пошёл он нахер, пользователь!
1. Есть фреймворки, полифиллы и фоллбеки. Плюс техники progressive enhansement и graceful degradation.
2. Аякс уже давно хавается всеми нормальными поисковиками. Гораздо больше играет роль правильность и семантичность разметки (видел я код дотнетчиков — там человек фиг разберётся, куда уж там роботу)
3. CSS никуда не отвалится — это же статика! Быстрее серверная часть ляжет
«предпренимательство», «эфимерная» – я смотрю вы много книг прочитали.
По делу: изложено хорошо и никто не призывает сидеть на жопе. Просто нужно иметь мозги и идти тем путём, который тебе самому кажется правильным. Это как естественный отбор: умные добьются, тупые нет.
И да, покажите мне хоть одного миллионера, который бы сказал что он заработал благодаря книге «как стать миллионером».
Две недели, пять фич, сто спеков, как вам удобнее.
Срочных задач не бывает — заказчик должен понимать какие риски за собой несёт «здесь и сейчас». В крайнем случае можно отбранчеватся от production (под обещание не иметь потом претензий). На самом деле схема не жёсткая: если правила мешают работе — нафиг такие правила. Это больше рекомендация (вполне несложная и разумная, согласитесь).
Лично мы используем три ветки: master, testing, production. В мастер попадают мержи и коммиты на протяжении итерации. После окончания итерации код замораживается, ставится тег x.x.x-rc1 и отправляется в тестинг. После того как мы удостоверяемся что код в тестинге готов для продакшна (аппрув от QA и заказчика, все баги пофикшены) ставится тег x.x.x-release и (именно по тегу) мержим код в продакшн.
Возможно для кого-то другого вышеприведённая схема и не будет работать, но конкретно для нас работает на отличненько.
Возможно потому что появляются такие статьи? Лично я не вижу никаких преимуществ Hg перед Git или наоборот. Но Git намного быстрее работает в больших проектах и ещё есть козырь в виде GitHub. Если у вас возникают трудности — значит вы неправильно его готовите. Просто сядьте и подумайте — как бы вы могли организовать свой workflow, чтобы вообще не заботиться о нём, а просто работать.
Ну для начала, представленная схема бранчинга — полное говно. Обосную:
1. Ветка master — это ветка по умолчанию, изначально созданная для хранения development-кода. Переделывать её в production — это как ссать против ветра.
2. Постоянный мержинг через rebase — анальный секс для всей команды, вот навскидку паруссылок о том что думает по этому поводу сам создатель (вообще найдите весь тред по первой ссылке, там интересно).
3. В остальном схема достаточно усложнена и избыточна и слепое следование ей приводит к достаточно печальным последствиям.
В общем, ничего мы не ждём, мы просто используем свой мозг.
Раз уж вы понимаете необходимость миксинов, циклов, переменных и пр. в css, может повлияете на csswg как один из крупнейших сервисов мира? Результаты последнего face-to-face показали что они слишком далеко ушли от реальной веб-разработки и слабо понимают потребности девелоперов.
Мой баттхерт обусловлен тем, что поневоле мне приходится пользоватся продуктами таких кодеров: интернет-банкинги, сайты авиакомпаний, платёжные системы и т.д. И именно из-за непонимания как работает фронтенд, пользование этими продуктами если не невозможно, то весьма затруднительно.
Просто проблема в том, что многие девелоперы, которые делают веб-софт для людей, отстали (по меркам IT) на целую эпоху. Продукты таких девелоперов — автоваз среди Тойот. Статья о том, что пора научится делать фронтенд хорошо, иначе можно просто отправиться на свалку истории.
Вот из-за таких как вы, мне хочется иногда убивать людей. Зачем думать о юзабилити? Зачем думать о браузерах кроме IE? Зачем думать? Можно просто жрать зарплату и делать интерфейсы, на которые будут потом материться десятки тысяч пользователей. Ведь цель — сдавать вовремя функционал и получить за него деньги. А пользователь… Да пошёл он нахер, пользователь!
Не думай @ херячь код!
1. Есть фреймворки, полифиллы и фоллбеки. Плюс техники progressive enhansement и graceful degradation.
2. Аякс уже давно хавается всеми нормальными поисковиками. Гораздо больше играет роль правильность и семантичность разметки (видел я код дотнетчиков — там человек фиг разберётся, куда уж там роботу)
3. CSS никуда не отвалится — это же статика! Быстрее серверная часть ляжет
По делу: изложено хорошо и никто не призывает сидеть на жопе. Просто нужно иметь мозги и идти тем путём, который тебе самому кажется правильным. Это как естественный отбор: умные добьются, тупые нет.
И да, покажите мне хоть одного миллионера, который бы сказал что он заработал благодаря книге «как стать миллионером».
Срочных задач не бывает — заказчик должен понимать какие риски за собой несёт «здесь и сейчас». В крайнем случае можно отбранчеватся от production (под обещание не иметь потом претензий). На самом деле схема не жёсткая: если правила мешают работе — нафиг такие правила. Это больше рекомендация (вполне несложная и разумная, согласитесь).
Возможно для кого-то другого вышеприведённая схема и не будет работать, но конкретно для нас работает на отличненько.
1. Ветка
master— это ветка по умолчанию, изначально созданная для хранения development-кода. Переделывать её в production — это как ссать против ветра.2. Постоянный мержинг через rebase — анальный секс для всей команды, вот навскидку пару ссылок о том что думает по этому поводу сам создатель (вообще найдите весь тред по первой ссылке, там интересно).
3. В остальном схема достаточно усложнена и избыточна и слепое следование ей приводит к достаточно печальным последствиям.
В общем, ничего мы не ждём, мы просто используем свой мозг.