Ну, это уже слишком сильно выглядит как попытка пропиариться, причем, весьма неуклюжая.
Я честно не совсем понял ) Статья про то, что можно относиться к коду как к продукту, а в качестве пользователей воспринимать других коллег-разработчиков. И относиться к ним так же, как относятся к пользователям продукта.
То есть, если мне нравится, например, KeePass
Не совсем понял, при чем тут KeePass. Речь ведь о том, что принципы продуктовой разработки перенести в команду. То есть речь о том, чтобы команда делилась друг с другом обратной связью по коду. Команда, коллеги.
Возможно и правда это не совсем очевидно из статьи.
то Вам определенно стоит рассмотреть другие точки зрения, некомфортные
Я именно это и пытаюсь сделать сейчас ) Просто я честно, без иронии, без сарказма не совсем понимаю конкретно в чем посыл. Пока что я вижу, что смысл статьи в принципе понят неправильно. И это моя ошибка. Либо переборщил с метафорами, либо в целом формулировки неверные. В любом случае польза
Тем, что критика и желание пользователей может быть диаметрально противоположной у разных групп пользователей одного и того же приложения. Угодить всем не получится.
Вот это уже такой, холиварный очень вопрос и он не совсем в рамках этой статьи. Но все же: никто и не говорит о том, что нужно угождать всем. Угождать нужно той аудитории, которая составляет ядро и которая приносит деньги. Вот и все ) Но я все еще не понимаю, чем конкретно статья похожа на выпускника курсов программирования. Без ехидства - если вы на это укажете, будет классно, я пойму что упустил при формулировке
Тогда должны понимать, что целому сообществу, которое знает об этом много писать еще и еще..
"Об этом" это о чем конкретно?
Так внутри команды тем более проще на гите
Если нет анонимности, то никто не будет присылать никаких серьезных вещей, которые могут оскорбить автора. Но я понял, да, можно сделать приватную репу в которую все пушат но нет видимости. Но на мой взгляд это классический случай оверинжиниринга ) Личка прекрасно спралвяется с этим в команде из 20 человек
Идея рождается у, условно, программиста, он начинает ваять. Есть его взгляды, а есть - пользователей.
Ну, все книжки по запуске продуктов как раз-таки и пишут о том, что это неправильный подход ) Я, все же, склонен с ними соглашаться.
Некоторые до сих пор, кстати.
Ну, это ведь как раз-таки подтверждает, что пользователи создают продукт. Хабр сейчас точно совсем не тот, каким был. И концептуально, и по трафику.
Просто, вся эта статья похожа на статью выпускника школ программирования
Чем? Если честно, я действительно думал, что отношение к коду как к продукту, а к коллегам как к пользователям и, проводя всякие параллели с классическим продуктовым циклом, переносить из него полезные подходы, это как минимум любопытная мысль. По крайней мере, я за 15 лет разработки с таким еще не сталкивался ) Но, видимо, я ошибался. Понятное дело, что сами принципы давно известны, но опять-таки, посмотреть на это под таким углом, я думаю, было бы любопытно
Работают, конечно ) С помощью плагина привязывается проигрывание анимации к скроллу. По сути то же самое, что и scroll-timeline, только более кастомизируемое и работающее во всех браузерах уже сейчас
Сложно что-то говорить про мелкомягких, всё-таки компании такого размера не совсем стандартный случай. Я больше про то, что обычно создание продукта ведь начинается с пользователя. Кастдев, все дела.
А система git, ну или отдельный ресурс, под это дело не проще ли?
Не совсем понял про это. Речь идет про ретро внутри команды. Идея же в том, чтобы перенести часть подходов из продуктовой разработки внутрь команды.
В общем, простите меня, Алексей, может быть я желчный слегка..
Вот так смотришь на все это и вспоминается какая-то расхожая шутка про инструкцию до создания современного сайта (1. Скачайте библиотеки. 2. Настройте сервер… 146. Начинайте писать Html).
Нет, серьезно, для чего весь этот парк технологий? Для того, чтобы настроить простенькую адаптивность и обращаться к API?
Видимо, шутка про еще одну инструкции «Как заставить div двигаться? 1. Скачайте jQuery» перестает быть шуткой.
Не знаю, вообще я с достаточно большим подозрением отношусь к сеточным шаблонам. Может я что-то не совсем понимаю, но ведь в таком случае сетка диктует вам расположение контента, а значит, и логику приложения? Этот кейс ведь ярко проиллюстрирован в статье.
Мне кажется, сетка должна быть индивидуальной и строиться уже после определения концепции и набросков интерфейса, если даже не сказать — в самом конце, для структурирования и причесывания готового интерфейса (хотя здесь, я, пожалуй, слегка перегнул, но, надеюсь, мысль ясна).
Ведь все-таки дело сетки — создавать структуру, предсказуемую и понятную для пользователя. Но это же совсем не обязательно говорит о том, что можно использовать только какие-то заранее заданные строгие паттерны. У меня, например, могут быть совершенно безумные сочетания размеров и отступов, но они будут логичными и структурированными и иметь свою, разработанную сетку. Ну не помещается у весь текст с плитками на одну сетку — измените ее так, чтобы вставали, но в дальнейшем уж будьте добры строго придерживаться ее.
В черновиках статья — «Почему именно сейчас стоит начать заниматься frontend-разработкой».
В последнее время все чаще статьи на Хабре подробно описывают некоторые из пунктов этой статьи. Теперь вот думаю что делать :)
По существу: я считаю, что html+css+javascript в ближайшие два-три года очень плотно придут на мобильные платформы. WebGL, canvas, Javascript Mobile API, Firefox OS. Это очень радует )
Да не потому же, что iPhone — это престижно. Не может престижным быть то, что стоит $200.
iPhone — потому что «у всех», потому что сам по себе удобный, выглядит хорошо и т.д.
Но никак не потому что «это престижно». У нас просто совершенно разное отношение к технике (я имею в виду, их и нас). Для них доступность техники никак не связана с ее «непрестижностью».
Кажется я понял, да, мне не нужно было размещать статью в "Совершенный код"
Я честно не совсем понял ) Статья про то, что можно относиться к коду как к продукту, а в качестве пользователей воспринимать других коллег-разработчиков. И относиться к ним так же, как относятся к пользователям продукта.
Не совсем понял, при чем тут KeePass. Речь ведь о том, что принципы продуктовой разработки перенести в команду. То есть речь о том, чтобы команда делилась друг с другом обратной связью по коду. Команда, коллеги.
Возможно и правда это не совсем очевидно из статьи.
Я именно это и пытаюсь сделать сейчас ) Просто я честно, без иронии, без сарказма не совсем понимаю конкретно в чем посыл. Пока что я вижу, что смысл статьи в принципе понят неправильно. И это моя ошибка. Либо переборщил с метафорами, либо в целом формулировки неверные. В любом случае польза
Вот это уже такой, холиварный очень вопрос и он не совсем в рамках этой статьи. Но все же: никто и не говорит о том, что нужно угождать всем. Угождать нужно той аудитории, которая составляет ядро и которая приносит деньги. Вот и все ) Но я все еще не понимаю, чем конкретно статья похожа на выпускника курсов программирования. Без ехидства - если вы на это укажете, будет классно, я пойму что упустил при формулировке
Ничего, у него нет зависимостей. Установка вот здесь - https://github.com/the-illarionov/the-supersonic-plugin-for-scroll-based-animation?tab=readme-ov-file#installation
Вот здесь примеры https://the-illarionov.com/the-supersonic-plugin-for-scroll-based-animation/examples но кажется надо под vpn заходить
Не знаю, может статью надо было назвать "Свежий взгляд на старые правила", что ли )
"Об этом" это о чем конкретно?
Если нет анонимности, то никто не будет присылать никаких серьезных вещей, которые могут оскорбить автора. Но я понял, да, можно сделать приватную репу в которую все пушат но нет видимости. Но на мой взгляд это классический случай оверинжиниринга ) Личка прекрасно спралвяется с этим в команде из 20 человек
Ну, все книжки по запуске продуктов как раз-таки и пишут о том, что это неправильный подход ) Я, все же, склонен с ними соглашаться.
Ну, это ведь как раз-таки подтверждает, что пользователи создают продукт. Хабр сейчас точно совсем не тот, каким был. И концептуально, и по трафику.
Чем? Если честно, я действительно думал, что отношение к коду как к продукту, а к коллегам как к пользователям и, проводя всякие параллели с классическим продуктовым циклом, переносить из него полезные подходы, это как минимум любопытная мысль. По крайней мере, я за 15 лет разработки с таким еще не сталкивался ) Но, видимо, я ошибался. Понятное дело, что сами принципы давно известны, но опять-таки, посмотреть на это под таким углом, я думаю, было бы любопытно
Работают, конечно ) С помощью плагина привязывается проигрывание анимации к скроллу. По сути то же самое, что и scroll-timeline, только более кастомизируемое и работающее во всех браузерах уже сейчас
Сам плагин лежит в lib, да. В docs - примеры.
Нет.
Сложно что-то говорить про мелкомягких, всё-таки компании такого размера не совсем стандартный случай. Я больше про то, что обычно создание продукта ведь начинается с пользователя. Кастдев, все дела.
Не совсем понял про это. Речь идет про ретро внутри команды. Идея же в том, чтобы перенести часть подходов из продуктовой разработки внутрь команды.
Ничего страшного, бывает )
❤️
❤️
Ну, мы учим Javascript, NodeJS, Unity C#. Вполне себе техническое ) А примеры с тегами HTML использованы, чтобы было понятно большему числу.
Плавное движение фона легко реализуется через CSS3 animations и background-position.
@keyframes pl {
100% {
background-position: -1000px 0;
}
}
animation: pl 5s infinite;
А направление вращения через transform: rotateY :)
Эти вещи уже даже мобильные браузеры свободно поддерживают, по-моему.
А WEBGl тут использовать, мне кажется, чересчур, он все-таки для более комплексных задач предназначен.
Нет, серьезно, для чего весь этот парк технологий? Для того, чтобы настроить простенькую адаптивность и обращаться к API?
Видимо, шутка про еще одну инструкции «Как заставить div двигаться? 1. Скачайте jQuery» перестает быть шуткой.
Мне кажется, сетка должна быть индивидуальной и строиться уже после определения концепции и набросков интерфейса, если даже не сказать — в самом конце, для структурирования и причесывания готового интерфейса (хотя здесь, я, пожалуй, слегка перегнул, но, надеюсь, мысль ясна).
Ведь все-таки дело сетки — создавать структуру, предсказуемую и понятную для пользователя. Но это же совсем не обязательно говорит о том, что можно использовать только какие-то заранее заданные строгие паттерны. У меня, например, могут быть совершенно безумные сочетания размеров и отступов, но они будут логичными и структурированными и иметь свою, разработанную сетку. Ну не помещается у весь текст с плитками на одну сетку — измените ее так, чтобы вставали, но в дальнейшем уж будьте добры строго придерживаться ее.
Как-то так, что ли.
В последнее время все чаще статьи на Хабре подробно описывают некоторые из пунктов этой статьи. Теперь вот думаю что делать :)
По существу: я считаю, что html+css+javascript в ближайшие два-три года очень плотно придут на мобильные платформы. WebGL, canvas, Javascript Mobile API, Firefox OS. Это очень радует )
iPhone — потому что «у всех», потому что сам по себе удобный, выглядит хорошо и т.д.
Но никак не потому что «это престижно». У нас просто совершенно разное отношение к технике (я имею в виду, их и нас). Для них доступность техники никак не связана с ее «непрестижностью».