Да здравствует плоский мир). На самом деле не очень разделяю восторга от повального увлечения подобного рода интерфейсами в вебе. Ведь очевидно — юзабилити в большинстве случаев в пролёте.
К слову, новая версия lHabr была полностью перепроектирована и Александр (plasm) сейчас полным ходом занимается её реализацией. Мы много-много думали, читали отзывы и постарались максимально упростить навигацию и доступ к наиболее важным фичам.
После завершения работы над версией, думаю, напишем пост с описание процесса разработки и прецентацией финального результата. А пока можете ознакомиться с макетами грядущего )
Сейчас выбираем между Kinetic JS и вашей библиотекой. Fabric явно пошустрее будет, на мой взгляд.
Только несколько смущает позиционирование объектов: вот пример
Я так понимаю, отсчет координат идет о центра объекта? Если да, то с какой целью так сделано и можно ли это поведение изменить?
Идеально, если веб-дизайнер и верстальщик — одно лицо
Еще года два назад я считала также и очень не любила отдавать свои творения на вёрстку другому человеку. Мне казалось, что правильно реализовать всё благолепие могу только сама).
Но по мере прокачки навыков дизайнера интерфейсов, я стала замечать интересную вещь — при создании графического макета я подсознательно делала некоторые вещи мене сложными и интересными, чем они могли бы быть, потому что «мне еще потом это верстать под IE».
Другой немаловажный момент — в некоторых случаях фронтенд-разработка занимает очень много времени, а я хотела всё больше заниматься дизайном, изучать новые инструменты, следить за трендами, основательно позалипать над скетчами и т.д.
И тогда я все-таки решила начать доверять верстальщикам). Главное — это диалог и по-возможности, приятельские отношения с фронтендером. Тогда сотрудничество получается продуктивным, а результат только радует.
Я люблю работать над фронтом и стараюсь следить за новыми веяними, но теперь не считаю это своей основной деятельностью. И это на порядок упростило мне жизнь. Чего и всем желаю).
Насчет
(ещё лучше, когда он же — ещё и программист, но это, скорее, редкость, чем правило)
Мне кажется, для дизайнера кодинг может быть только хобби, но никак не видом деятельности, которым он занимается наравне с основными обязанностями.
По себе знаю, что переход от фотошопа к IDE и наоборот — это как смена часовых или климатических поясов, ресурсов затрачивается огромное количество, а настроится на работу занимает очень много времени. Если я сегодня пишу код (без разницы, HTML, JS или PHP), то от души подизайнить я смогу, скорее всего, только завтра.
Мораль: дизайнеру в первую очередь нужно быть дизайнером, включать голову и уметь выстроить диалог с фронтед-технологом. И всё будет.
«Fail Fast» — термин, который, если не ошибаюсь, уходит корнями как раз-таки в программирование.
Да, в управлении проектами тоже есть такое понятие, но ни в той, ни в другой области оно ни в коем случае не означает, что нужно создавать заведомо нерабочее решение.
И уж тем-более, на мой взгляд, нельзя ставить знак равенства между методологией и одним из подходов или концепций. Да и здравый смысл еще никто не отменял).
Agile — это методология (даже философия, если угодно) и чтобы быть «agile» достаточно следовать манифесту и основным принципам. Scrum и Canban — это методики с набором правил и артефактов, из которых желательно ничего не выбрасывать, особенно на этапе внедрения процесса (то самое «Shu»).
Все основные моменты по Scrum можно найти в чеклисте от ребят из ScrumTrek. Это и есть правила, которые нельзя нарушать.
С Kanban еще проще, правил всего 3:
— визуализировать процесс;
— ограничивать количество задач, находящихся в работе;
— измерять время цикла задачи и оптимизировать его.
А мне почему-то (в силу происходящего сейчас с моей командой, наверное) видится такое: в пятницу вечером к менеджеру продукта прилетает маркетинг с горящими глазами, который решил, что луна как раз в той фазе, чтобы срочно и немедленно учинить акцию (руководство уже одобрило, распоряжение имеется). Менеджер несётся к команде, где застает несчастного, зачем-то задержавшегося в офисе, программиста. Программист, находясь уже одной ногой в субботе, краем уха выслушав сбивчивые объяснения и требования «сделать по-быстрому, там же работы на полчасика», кодит НЕЧТО. НЕЧТО не тестируется и уходит на продакшен. Занавес, апплодисменты.
Спасибо за перевод.
Особо приглянулось разжевывание поведения «this». Распечатаю и раздам коллегам-кодерам, которые «ой, да вообще он странный, ваш этот JS, особенно эта магия с this».
Отдельное спасибо за ссылку на «Understanding delete»
Теория единого информационного поля в действии) Буквально с утра пришел мысль: «странно, что никто еще не занялся переводом iOS-гайдлайнов. Нужно подумать об этом». И тут вдруг такой сюрприз. Успехов вашим коллегам!
Как вы сами говорите: «Тут ошибка, пожалуй, в том, что сначала «придумали крутую идею», потом стали искать кому она нужна». Это самый главный и бесповоротный фейл, все остальное — просто вытекающие последствия.
Вот вам не жалко тратить комментарий (который у вас раз во сколько там минут?) на такой неумелый троллинг?) Или вы в процессе борьбы за новый бейджик для профиля?
Поверьте, я неплохо представляю, как настроить тоже самое в Ubuntu (как я говорила выше, убунта у меня есть в виртуалке. И что еще более страшно — на нетбуке у меня Минт, и там тоже всё успешно настроено ).
Но ежедневно я просыпаюсь и сажусь за свою Windows-машину, в которой мне всё нравится, в которой я работаю над проектами и тут же тестирую во всём многообразии браузеров. Пока мне так удобно.
Нет, на момент проверки мы уже изменили настройки апача (сменили порт) и запустили nginx, поэтому и проверяем, что статика у нас не отвалилась. Что апач работает, мы удостоверились сразу после установки Денвера.
На сайте Nginx-а не нашла никаких упоминаний о проблемах под Windows.
В 99% процентах случаев nginx локально, конечно, не нужен. Но у нас есть достаточно крупный и сложный full-ajax проект, для которого разработчики намутили какую-то магию в nginx (настройки заголовкой или что-то вроде того), без которой пара фич работает некорректно (жить можно, но мне захотелось праздника). Отсюда и nginx на локалке.
К слову, новая версия lHabr была полностью перепроектирована и Александр (plasm) сейчас полным ходом занимается её реализацией. Мы много-много думали, читали отзывы и постарались максимально упростить навигацию и доступ к наиболее важным фичам.
После завершения работы над версией, думаю, напишем пост с описание процесса разработки и прецентацией финального результата. А пока можете ознакомиться с макетами грядущего )
И да, будем признательны за критику и пожелания.
Только несколько смущает позиционирование объектов: вот пример
Я так понимаю, отсчет координат идет о центра объекта? Если да, то с какой целью так сделано и можно ли это поведение изменить?
Еще года два назад я считала также и очень не любила отдавать свои творения на вёрстку другому человеку. Мне казалось, что правильно реализовать всё благолепие могу только сама).
Но по мере прокачки навыков дизайнера интерфейсов, я стала замечать интересную вещь — при создании графического макета я подсознательно делала некоторые вещи мене сложными и интересными, чем они могли бы быть, потому что «мне еще потом это верстать под IE».
Другой немаловажный момент — в некоторых случаях фронтенд-разработка занимает очень много времени, а я хотела всё больше заниматься дизайном, изучать новые инструменты, следить за трендами, основательно позалипать над скетчами и т.д.
И тогда я все-таки решила начать доверять верстальщикам). Главное — это диалог и по-возможности, приятельские отношения с фронтендером. Тогда сотрудничество получается продуктивным, а результат только радует.
Я люблю работать над фронтом и стараюсь следить за новыми веяними, но теперь не считаю это своей основной деятельностью. И это на порядок упростило мне жизнь. Чего и всем желаю).
Насчет
Мне кажется, для дизайнера кодинг может быть только хобби, но никак не видом деятельности, которым он занимается наравне с основными обязанностями.
По себе знаю, что переход от фотошопа к IDE и наоборот — это как смена часовых или климатических поясов, ресурсов затрачивается огромное количество, а настроится на работу занимает очень много времени. Если я сегодня пишу код (без разницы, HTML, JS или PHP), то от души подизайнить я смогу, скорее всего, только завтра.
Мораль: дизайнеру в первую очередь нужно быть дизайнером, включать голову и уметь выстроить диалог с фронтед-технологом. И всё будет.
Да, в управлении проектами тоже есть такое понятие, но ни в той, ни в другой области оно ни в коем случае не означает, что нужно создавать заведомо нерабочее решение.
И уж тем-более, на мой взгляд, нельзя ставить знак равенства между методологией и одним из подходов или концепций. Да и здравый смысл еще никто не отменял).
Scrum и Canban — это методики с набором правил и артефактов, из которых желательно ничего не выбрасывать, особенно на этапе внедрения процесса (то самое «Shu»).
Все основные моменты по Scrum можно найти в чеклисте от ребят из ScrumTrek. Это и есть правила, которые нельзя нарушать.
С Kanban еще проще, правил всего 3:
— визуализировать процесс;
— ограничивать количество задач, находящихся в работе;
— измерять время цикла задачи и оптимизировать его.
Особо приглянулось разжевывание поведения «this». Распечатаю и раздам коллегам-кодерам, которые «ой, да вообще он странный, ваш этот JS, особенно эта магия с this».
Отдельное спасибо за ссылку на «Understanding delete»
Но ежедневно я просыпаюсь и сажусь за свою Windows-машину, в которой мне всё нравится, в которой я работаю над проектами и тут же тестирую во всём многообразии браузеров. Пока мне так удобно.
В 99% процентах случаев nginx локально, конечно, не нужен. Но у нас есть достаточно крупный и сложный full-ajax проект, для которого разработчики намутили какую-то магию в nginx (настройки заголовкой или что-то вроде того), без которой пара фич работает некорректно (жить можно, но мне захотелось праздника). Отсюда и nginx на локалке.