Comments 55
Ну что ж… поздравляю. Достойно и полезно. О Quasar тоже слышал хорошее, к тому же там же есть и кордова, то есть apk-ши из коробки. Хотелось бы подискутировать о бекенде, если используется только api, почему бы не взять js или что нибудь другое? Не рассматривали или не хотели чуть менее протоптанной комьюнити дорожкой пользоваться? О плюсах и минусах лары в этой связи было бы интересно послушать.
чуть менее протоптанной комьюнити дорожкой
Если Вы о технологиях, то я использовал php на бэке, потому что знаю php. JS как бэк не пробовал. Если о формате в общем, то да, креативности побоялся и просто ее не хватило.
О плюсах и минусах лары
Плюс — куча готовых пакетов. Минус — скорость работы. Лара больше о функциональность, чем о скорости.
> Изображение страницы входа
Немного ли полей ввода (форм) на этой странице?
Может отпугивать людей идея ввода большого количества данных.
Можно оставить только форму входа и для незарегистрированных — ссылку «зарегистрироваться».
А в последнее время видна тенденция — ещё и в форме входа сокращать количество полей ввода, оставляя сперва только поле логина, а поле пароля добавлять после.
В такой тенденции я и показ кнопки входа (ок, войти и т.п.) отложил бы на потом. Но отсутствие такой кнопки на первом взоре может навести пользователя на мысль о том, что он не сможет войти (т.к. не на что нажать после ввода логина) и тоже отпугнёт его.
Немного ли полей ввода (форм) на этой странице?
Может отпугивать людей идея ввода большого количества данных.
Можно оставить только форму входа и для незарегистрированных — ссылку «зарегистрироваться».
А в последнее время видна тенденция — ещё и в форме входа сокращать количество полей ввода, оставляя сперва только поле логина, а поле пароля добавлять после.
В такой тенденции я и показ кнопки входа (ок, войти и т.п.) отложил бы на потом. Но отсутствие такой кнопки на первом взоре может навести пользователя на мысль о том, что он не сможет войти (т.к. не на что нажать после ввода логина) и тоже отпугнёт его.
Мне медиум нравится: написал емейл — пришла ссылка с авторизацией. Перешел — залогинился.
Страх перехвата ссылки может быть починен небольшим ключиком, валидирующим запрос на авторизацию с того браузера, с которого он и сформировался.
Страх перехвата ссылки может быть починен небольшим ключиком, валидирующим запрос на авторизацию с того браузера, с которого он и сформировался.
Страх перехвата ссылки может быть починен небольшим ключиком, валидирующим запрос на авторизацию с того браузера, с которого он и сформировалсяИмхо, избыточно, разве нет?
Если кто-то может перехватить ссылку посланную в почту, то что ему мешает заказать эту ссылку самому и тут же ее перехватить? А если не может, тогда о чем беспокоиться?
Почта может быть только на мобильном, и пересылать ссылку авторизации на десктоп не всегда удобно, для защиты от перехвата можно просто не отправлять ссылку на почту, а дать войти сразу с логином + паролем. Может пользователь будет сам решать нужно ему восстановление аккаунта через почту или нет?
Это сделано для поддержки нескольких способов авторизации, в том числе двухфакторки. Например, если у пользователя в настройках выбран внешний аутентификатор вместо пароля, то и пароль ему нет смысла показывать.
Немного ли полей ввода (форм) на этой странице?
Повествование статьи идет от первого варианта ко второму. «Изображение страницы входа» относится к первому визуальному варианту и отличается от того, что есть сейчас по факту. Я предвидел, что такой формат может не сразу просматриваться, но оставил как есть.
Имхо, "голая вера" — это неустойчивая мотивация. "Вера", подкреплённая исследованием + MVP — возможно лучший фундамент.
Зашел, посмотрел. На первый взгляд с фильтрами "рост, вес, цвет глаз, тип внешности и т.д." больше похоже на каталог модельного агенства, чем на соцсеть) Юзеров, как я понял, не более 20-30, причем, из рандомно открытых 5-7 ни у кого не увидел подписчиков или подписок.
Вообще, наверное, проект и не имел шансов с таким подходом. Очень много описаны технологии, но почти ни слова о проверке гипотез, изучении потенциального пользователя, общение с теми, для кого сайт предназначен, способы продвижения, маркетинг. Проводя параллель, один знакомый моей знакомой (да, звучит уже, как байка) сделал всемирно используемый софт для диджеев. Но во время написания он реально спал днем, а все ночи проводил в клубах, тусуясь с диджеями, и пробуя новые гипотезы в своем софте. Какие-то фичи писал прям с ноутбука в подсобках клубов)
Согласен с вами, проект больше похож на чудовище Франкенштейна собранное из кусков популярных соц сетей, и никакой фишки для сферы искусства у него нет. Автору стоит обратить внимание на сервисы которые действительно популярны у художников и других деятелей искусства — artstation, sketchfab. Из соцсетей — amino(последнее время), tumblr
Очень много описаны технологии
Писать о маркетинге не посчитал уместным, потому что маркетинг у каждого продукта индивидуален. Но в целом я согласен, маркетингу уделил недостаточно внимания.
Отдельно хочется сказать, что я избегаю использования абстракций на начальных этапах проектирования, если без них сейчас можно обойтись. Их преждевременное использование ведет к усложнению модуля приложения, который может быть никогда не использован. Решайте проблемы по мере поступления.
Золотые слова! Сам участвовал в проекте на Laravel, так лидер проекта похоже решил установить рекорд по количеству используемых паттернов и абстракций. Причем подчас совершенно не обоснованно. Что невероятно затормозило разработку всего проекта.
Отдельное спасибо за полезные сервисы.
Женский пол у мужика — это такой прикол или значение по умолчанию?
> Лучше выпустить не идеальный продукт и быть первым, чем потом догонять конкурентов.
Вот поэтому нас и окружают постоянно сырые вещи :(
> трудоустроенности людей искусства намного глубже и, возможно, специализированной социальной сетью не помочь.
+1000
> Это рыночная проблема
+10000000
Это не кормит. На корпоративах играть унизительно. Да и прибивальщики яиц бросают тень.
> Лучше выпустить не идеальный продукт и быть первым, чем потом догонять конкурентов.
Вот поэтому нас и окружают постоянно сырые вещи :(
> трудоустроенности людей искусства намного глубже и, возможно, специализированной социальной сетью не помочь.
+1000
> Это рыночная проблема
+10000000
Это не кормит. На корпоративах играть унизительно. Да и прибивальщики яиц бросают тень.
Женский пол у мужика — это такой прикол или значение по умолчанию?
Можете подробнее, пожалуйста?
>> Лучше выпустить не идеальный продукт и быть первым, чем потом догонять конкурентов.
> Вот поэтому нас и окружают постоянно сырые вещи :(
Иногда лучше что-то немного сырое, чем никакое. Особенно если альтернатив особо нет.
Если это «сырое» принято достойно, то и развиваться проще. А если не достойное, то само стухнет.
У многих стартапов есть эта болезнь когда хочется сделать много плюшек, а в результате даже не могут запуститься. Потом заканчиваются тугрики и маленькому хорошему проекту приходит большой кирдык ещё до запуска.
> Вот поэтому нас и окружают постоянно сырые вещи :(
Иногда лучше что-то немного сырое, чем никакое. Особенно если альтернатив особо нет.
Если это «сырое» принято достойно, то и развиваться проще. А если не достойное, то само стухнет.
У многих стартапов есть эта болезнь когда хочется сделать много плюшек, а в результате даже не могут запуститься. Потом заканчиваются тугрики и маленькому хорошему проекту приходит большой кирдык ещё до запуска.
Был когда то интересный проект, автомобильный гараж («социальная сеть автомобилей») под названием CarProfile. Закрыли мы его, в связи с тем, что сил не хватило!
Можно ссылку на соцсеть?
А более подробна ваша идея, ваши цели и ориентиры где-то описаны?
Вау, дейсвтительно отличная статья. Очень мотивируется заниматься собственными проектами, хоть я пока ещё Джун )
В конце концов, техническая часть проекта будет хорошо смотреться в резюме программиста)
Свободный, без слежки, без метрик.
Кстати, если хотите выжать из этого проекта ещё интересных навыков в резюме, попробуйте реализовать метрики.
Скажем, расчет конверсии "зашел -> зарегался", "зарегался -> написал другому".
Потому что свою соцсеть делали, наверное, многие.
А вот прикручивать к ней продуктовую аналитику пробовали далеко не все.
приходится описывать абсолютно все и это как минимум +30% к срокам разработки
Здесь есть некоторая ошибка)
Это не +30% к срокам разработки. Это (может быть и то с оценкой не согласен) максимум +30% к времени набора кода. Но минус десятки, а то и сотни процентов именно к времени разработки, за счет избегания тупых багов вроде банальных опечаток.
Интерфейсы используются не для отображения данных, а для связи некого устройства с чем — либо, например, пользователем.
Свою сеть сделать несложно, делал это многократно, в т.ч и с аналитикой.
Проблема всегда на уровне постановки задач — идее, выработке идеального решения и поиске путей реализации, После перехода к кодированию всегда при работе в одиночку имеют место проблемы практической реализации, требующие большого опыта и знаний во многих областях, начиная с баз данных и кончая дизайном.
Много лет веду дневники практических решений по дизайну, реализации функциональности — UI, LINQ, SQL и т.д. На бумажках ничего не записываю — веду систематизированный дневник с анализом тех или иных проблем и способов их решения.
В части реализации дизайна мне понравились решения Limitless — demo.interface.club/limitless/demo/bs3/Template/layout_3/LTR/default/full/index.html
Относительно инструментов. В 70-х работал на ассемблере, бейсике и программно — ориентированном квейсике (Quasic), потом был Паскаль, его развитие — Delphi — на нем получался очень красивый по тем временам (90-е, начало 2000) дизайн, матлаб… Долго не хотел переходить на C#, но в конце концов перешел. Бейсик, паскаль, Фортран, Дельфи — где они? не говоря уж о мелких пакетах. После появления Core долго дискутировал с ребятами из Майкрософт об отсутствии готовых UI для нас разработчиков и в конце концов как будто оказался прав — прошло, по моему уже 5 лет и пока ничего серьезного.
Свою сеть сделать несложно, делал это многократно, в т.ч и с аналитикой.
Проблема всегда на уровне постановки задач — идее, выработке идеального решения и поиске путей реализации, После перехода к кодированию всегда при работе в одиночку имеют место проблемы практической реализации, требующие большого опыта и знаний во многих областях, начиная с баз данных и кончая дизайном.
Много лет веду дневники практических решений по дизайну, реализации функциональности — UI, LINQ, SQL и т.д. На бумажках ничего не записываю — веду систематизированный дневник с анализом тех или иных проблем и способов их решения.
В части реализации дизайна мне понравились решения Limitless — demo.interface.club/limitless/demo/bs3/Template/layout_3/LTR/default/full/index.html
Относительно инструментов. В 70-х работал на ассемблере, бейсике и программно — ориентированном квейсике (Quasic), потом был Паскаль, его развитие — Delphi — на нем получался очень красивый по тем временам (90-е, начало 2000) дизайн, матлаб… Долго не хотел переходить на C#, но в конце концов перешел. Бейсик, паскаль, Фортран, Дельфи — где они? не говоря уж о мелких пакетах. После появления Core долго дискутировал с ребятами из Майкрософт об отсутствии готовых UI для нас разработчиков и в конце концов как будто оказался прав — прошло, по моему уже 5 лет и пока ничего серьезного.
Всегда удивляюсь как веб-разработчикам удаётся быть в курсе всех этих десятков технологий, фреймворков, библиотек. Это же какое-то безумие! У меня на какую-нибудь одну уходит пол-года — год времени. А тут не только знание, но и активное их комбинирование, да перебор со сравнением разных вариантов. В вебе наверное только гении с огромной скоростью мышления и гигантскими объемами памяти.
ну, скажем так, есть все же разница между «быть в курсе» и «знать основательно».
Комбинировать и перебирать — это только в самом начале проекта, дальше уже делают под то, что есть. Максимум — с постоянным переходом на последнюю версию фреймворка\библиотеки.
Так что: делайте по два-три проекта за год — и вы тоже будете «в курсе» новинок.
Комбинировать и перебирать — это только в самом начале проекта, дальше уже делают под то, что есть. Максимум — с постоянным переходом на последнюю версию фреймворка\библиотеки.
Так что: делайте по два-три проекта за год — и вы тоже будете «в курсе» новинок.
Просто у них тысячи мертвых «домашних проектов» чуть ли не на каждую технологию.
Ну знаете, постоянное обучение в любой профессии присутствует. Думаете врачам, юристам, учёным, плотникам, инженерам, поварам и прочим нужно знать меньше? Зоопарк инструментов, методов и технологий есть в любой работе, чуть сложнее грузчика. Да и у них, я уверен, есть нюансы.
Автор, вы сказали, что использовали Nuxt для SSR в первой вариации проекта.
Для второго варианта, как я понял вы отказались от этого? Как реализовывали SSR во втором варианте?
Просто использовали blade + laravel, + на некоторые интерактивные элементы интерфейса vue?
Для второго варианта, как я понял вы отказались от этого? Как реализовывали SSR во втором варианте?
Просто использовали blade + laravel, + на некоторые интерактивные элементы интерфейса vue?
SSR не делал.
Полноценный SPA. Рендерить шаблоны через php неудобно, долго, теряется вся интерактивность и независимость от бека.
Просто использовали blade + laravel, + на некоторые интерактивные элементы интерфейса vue?
Полноценный SPA. Рендерить шаблоны через php неудобно, долго, теряется вся интерактивность и независимость от бека.
Спасибо за ответ)
Был опыт интеграции vue.js в проект на laravel. Там SEO было оч. важно, а интерактивность требовалась в ограниченных местах, в таком варианте у нас был рендеринг основного контента на blade, а на некоторые странички отдельно подключали Vue скрипт, + inline-template
Конечно было не так классно, и интерактивно, как полное SPA на Vue + laravel как API. Но свою задачу решало.
Переписать проект на SSR тогда казалось оч. сложной задачей. (учитывая что Node-сервера, как такового в проекте и нет).
Был опыт интеграции vue.js в проект на laravel. Там SEO было оч. важно, а интерактивность требовалась в ограниченных местах, в таком варианте у нас был рендеринг основного контента на blade, а на некоторые странички отдельно подключали Vue скрипт, + inline-template
Конечно было не так классно, и интерактивно, как полное SPA на Vue + laravel как API. Но свою задачу решало.
Переписать проект на SSR тогда казалось оч. сложной задачей. (учитывая что Node-сервера, как такового в проекте и нет).
UFO just landed and posted this here
На это мало кто обращает внимание, но от этого оно не становится менее значимым: FPS на странице. На главной вашего сайта в месте где летают треугольники fps не поднимается выше 50-55, а иногда падает вплоть до 20. Заметно даже визуально. Возможно, проблема в реализации через css.
node.js ssr тянуть сложно
На основании чего сделано такое громкое заявление? Если вы не разобрались как сконфигурировать Nuxt.js это еще не значит, что node.js не тянет SSR.
UFO just landed and posted this here
определенно, нужно менять дизайн: убрать стандартные иконки, заменить шрифт, цветовую гамму подобрать, чтобы не было так уныло, разбавить красками
на dribbble можно вдохновиться по полной
на dribbble можно вдохновиться по полной
UFO just landed and posted this here
Emprove
вы используете Docker на проде?
какие сервисы из AWS вы используете? и сколько по итоговой стоимости получилось с сервисами AWS? По-моему хватило бы минимального по мощности VPS от того же Digital Ocean за $5/month.
«Роутинг кастомизировал и вынес файлы роутов из единого api.php, т.е. один файл, один роут.»
Зачем?
вы используете Docker на проде?
какие сервисы из AWS вы используете? и сколько по итоговой стоимости получилось с сервисами AWS? По-моему хватило бы минимального по мощности VPS от того же Digital Ocean за $5/month.
«Роутинг кастомизировал и вынес файлы роутов из единого api.php, т.е. один файл, один роут.»
Зачем?
mis click. del
Sign up to leave a comment.
Как я делал социальную сеть в 2019