На сколько я понимаю, ЦТ направлено на увеличение продаж, на основании данных (перевода проблемных зон в цифру) принятие управленческих решений.
Например, условно, узнать какими игрушками меньше/больше всего играют, узнать где меньше/больше всего проводят время дети. Ну и соответствующие решения.
Все верно, но для того, чтобы это делать и нужно собирать данные. Как раз на это и направлена данная система, она собирает не только финансовые показатели, но и так же мы понимаем какой возраст детишек, какие услуги лучше и больше работают, какие месяца и почему прибыльней, какие мероприятния были успешны. Все это собирается и потом анализируется и на основании этого прнимаются те или инные решения.
В данной статье я на простом примере показал именно сбор данных и отображение самых необходимых показателей, с минимальными тратами.
Типичный пример материала, который наглядно показывает почему SEO специалистов не любят — из-за тотальной технической беграмотности.
Почему вы решили, что эта статья от SEO специалиста или кого-то связанного с SEO?
Вбейте себе в голову
SPA != Angular React или Vue.
Где в статье написано, или вывод в том, что Angular или другой фреймверк это SPA?! Зато там написано:
Single Page Application (SPA) – это веб-приложение, компоненты которого загружаются единожды на одной странице, а контент подгружается по необходимости.
Angualr, React и другие современные фреймверки просто помогают релизовывать такие страницы, конечно можно сделть это все на Vanila js используя XMLHttpRequest или jQuery. А проблема SEO, в другом, в том что используя клиентский роутинг фреймверков, страницы рендерятся на клиенте используя и строят DOM с данными уже после того как страница была отдана сервером, и при прямом переходе на ссылку клиентского роутинга, сервер всегд отдавал index файл, и уже после клиентское приложение сторило необходимую стрницу, и не все роботы умеют обрабатывать такие страницы.
Это не стек технологий. Это вообще никакого отношения к технологиям не имеет. Это ярлык. Который получают тогда, когда на сайте используется ServiceWotker + написан Manifest.
Тут можно холиварить до усрачки. Это все зависит какой смысл вложен в слово «технология». Ведь каждый ответит по своему. Мне близко это определение.
Технология — это совокупность знаний, посвященных созданию инструментов, обработке действий и извлечению материалов.
Ведь не всегда браузеры умели запускать server workers, не всегда умели работать с пушами, это все развивалось и продолжает развиваться. Можно PWA назвать и методологией, и подходом к разработке, да не важно как ты его назовешь, главное это релально классная штука, которая может улучшить веб-сайт. Которая, совмещает в себе многие классные вещи веба и мобильных приложений.
Займитесь собственным ликбезом, а не повторяйте безграмотные вещи от других SEO специалистов.
И поверьте, у меня достаточно опыта и знаний в веб-разработке, чтобы писать и говорить на такие темы. Я не занимаюсь копирайтингом или бездумно переписываю чужие статьи, я все это применял, и моя команда применяет это все и по сей день!
В магазинах для продвижения самое чувствительное — это, пожалуй, карточка товара. Правильно оформленная… с заголовком h1, описанием, и с человеко-читаемым уникальным индексируемым роутом на каждый товар. Просто, на самом деле интересно — nextjs такое реально умеет?
Умеет, причем прекрсно. Next использует SPA SSR и на базе шаблонизатора React рендерит страницу на сервере и подготавливает приложение, отдает готовую страницу клиенту, и уже клиент запускает полноценное приложение и дальше работет как стандартное SPA
Rozetka.com.ua, hotline.ua — в топах украинского поиска, абсолютно не стесняются перезагружать страничку на каждый товар, и ничего страшного. Фильтры, табы — там да, удобнее ajax spa прикрутить.
Пусть себе перезагружают, никто не говорит что SPA это панцея, но при помощи нее можно добится более удобного интерфейса и взаимодействия с пользователем, расширить горизонты
Считаю, что именно для этого их и стоит использовать, ни никак не для «контентных» сайтов или лендингов. Иначе получается, сами создаём себе проблемы (индексация, seo, роутинг, размер и разбиение бандла и т.д.), а потом героически их же и решаем.
Конечно для лендингов это не имеет смысла, в статье я уделил внимание, когда имеет место быть SPA, а когда нет. Для блога, скорее тоже нет, чем да. А вот для магазина, вполне себе можно, просто пока нет широкораспространенных фреймверков или CMS для такой работы, и это сделать не дешево.
Спорное утверждение. Какая разница, где наблюдать спиннер — во вкладке браузера, или в самом UI?
Конечно разница есть, вместо того, чтобы рендерить страницу полностью, клиент получает только часть данных, и перерисовывает только их. Так же сервер не занимается лишними операциями по формированию html стрницы, что при большой посещаемости может существенно разгрузить сервер.
От уважаемых людей слышал, что на рынке пока нет человеческого решения для SSR, без ада и содомии для команды. Возможно, это уже не так.
Уже есть, и мы используем их каждый день в своей работе. Например, nextjs.org
Да, мы им не занимаемся уже более 2х лет. Работает стабильно, сам по себе, даже есть активные пользователи. Что касается Facebook, так у них изменилась политика и нужно скорее всего менять приложение, так же нужно обновить мобильные приложения для поддержки последних версий iOS и Android, сменить дизайн. Но на все это нужно время, ресурсы и желание. Сейчас есть другие интересные для нас проекты, и может быть однажды мы возродим этот продукт.
Проект мы делали в 2011 году, с тех пор много чего переосмысл и еще больше получил опыта. Сейчас такие вещи кажутся тривиальными и очевидными, но тогда мне никто не дал такого совета. А самостоятельно врядли бы понял не попробовав.
Поэтому я решил поделиться опытом, чтобы тот, кто сейчас думает о создании своего продукта, не наступил на такие же грабли.
Так я собственно об этом и говорил в статье, что нужного понимания у нас небыло. Думали что если мы умеем делать успешные проекты для других, то мы сделаем и себе. Работая в заказной разработке, люди видят лишь вершину айсберга, и не видят того огоромного слоя льда под водой, который далеют овнеры, чтобы их продукт «стрельнул». И из-за этого возникает классическая ошибка выжившего.
Вот и в нашем случае, мы думали, что нужно просто сделать зашибись, и все будет хорошо (нормально делай, нормально будет). То есть если мы сделам во такие классные штуки, которые по нашему мнению должны быть бомбой, то люди просто будут хотеть пользоваться нашим продуктом. Но это не так!
Тут даже не совсем в этом дело, хотя и в пиаре и маркетинге тоже, но разработка и продвижение собственных продуктов это совершенно другой бизнес, и он сильно отличается от разработки приложений на заказ.
Тут нужно не просто уметь делать, а нужно четко понимать зачем ты это делаешь и нужно ли оно сейчас. Необходимо уметь строить и быстро тестировать гипотезы. Никто и никогда не сможет придумать сразу идеальный продукт без тестирования на реальных пользователях.
Другими словами – пиар не спасет, если ты сделаешь хороший, но никому не нужный продукт, ну или нужный только тебе и сыну маминой подруги.
1) Джуниор – это человек, который уже не плохо владеет теорией и умеет быстро находить информацию, готов выполнять не очень сложные задания.
Стажер – человек, который еще не имеет уверенных знаний в области, но имеет желание и тягу к развитию. Может делать простые задания, но очень долго и скорее всего не с первого раза.
2) Нет, стажеры не решают реальные задачи компании. Ну и задания, которые я придумал не являются абстрактными. Я постарался создать задачи, очень близкие к реальности или такие, которые приходилось решать в реальных проектах, но без привязки к ним.
По поводу заданий для стажеров, которые можно будет использовать в компании, у нас была практика, но ни к чему хорошему она не привела.
Да, безусловно такая возможность есть, любой человек волен выбирать, то что ему больше нравится. Именно поэтому мы проводим стажировку в нашем офисе и стараемся прививать корпоративную культуру ребятам уже на стадии стажировки. Они являются такими же членами команды как и основной состав, участвуют на пятничных докладах, где мы делимся опытом, играют с ребятами в настолки и другие корпоративные игры. А при успешном прохождении обучения, мы выплачиваем единовременную стипендию и предлагаем работу.
Но ведь ещё бывает, когда у людей нет своего сайта, и группа в социальной сети является по-факту личным сайтом. Но и им тоже нужно красиво оформлять группу.
Все правильно, он тянет og:image, но как быть если вы добавляете сторонний ресурс? Например прикрепляете ссылку на вакансии hh или у вас есть сторонний блог.
А людей с опытом вы тоже с нуля обучаете? Если нет, то тогда мне не совсем понятно зачем вообще был приведён этот пример :)
Нет, конечно. Я же объяснил, что человек приходя с опытом, у него есть уже выработанные привычки, которые не подходят под процессы новой организации, и человеку самому довольно сложно изменить свое привычное поведение.
Ну и проблемы бывают не только в процессах и технических вещах, есть еще софт скилы, которые в каждой организации разные и их тоже иногда нужно менять и подстаиваться.
Я просто хочу сказать, что человеку иногда проще принять то, что для него ново, чем переучиваться.
Не особо понимаю почему вы впали в ступор, я как человек отвечающий за техническое развитие компании, вижу определенные проблемы и принимаю решение наладить процесс обучения. Так как я прекрасно понимаю, какими знаниями должен обладать разработчик, я составил план, внедрил процесс, провожу обкатку, изменяю. После этого, мы введем отдельного человека на эту должность, что и было сказано в статье.
“В целом ресурсы, потраченные на обучение, окупаются. Если говорить о моём времени как времени руководителя, то пока я не сильно много его трачу. Когда мы поставим систему на поток и поймём, что у нас получилось — введём отдельного специалиста по корпоративному обучению.”
Когда я говорил «способен пробить», это был пример как раз не о джуниоре, а о человеке с опытом, может даже нанятой «звезде», который привык работать по-другому.
А что касается ответа «потому что тут так прнято», я обсолютно согласен что это не хороший ответ, поэтому мы не используем эту формулировку и всегда можем объяснить почему мы делаем так, а не иначе. У нас есть регламенты, которые описывают процессы.
Это не хорошо и не плохо, это просто мешает нормальному восприятию действительности и интеграции. Человеку всегда сложно и не очень приятно делать что-то, что отличается от его привычных действий.
Поэтому процесс интеграции затягивается, и даже может привести к плачевным результатам, когда человек будет в явном или не явном виде бороться с системой.
Например. Человек привык работать один или с небольшой командой, поэтому работает не в отдельной ветке и заливает в репозиторий большое количество изменений, и только после завершения работы над задачей. Хотя на новом месте принято работать по gitflow и заливать изменения несколько раз в день в определенную ветку, чтобы коллеги могли провести ревью кода. Когда его просят, он, конечно, соглашается, но делает это с неохотой, так как его заставляют делать “ненужную” работу. И он начинает обсуждать это на кухне, или в курилке, возможно если он сильная личность, он сможет пробить свои интересы, и тем самым ломает процессы.
Гугл формой будет не возможно править, если ввёл не правильные данные или просто надо что-то изменить.
Все верно, но для того, чтобы это делать и нужно собирать данные. Как раз на это и направлена данная система, она собирает не только финансовые показатели, но и так же мы понимаем какой возраст детишек, какие услуги лучше и больше работают, какие месяца и почему прибыльней, какие мероприятния были успешны. Все это собирается и потом анализируется и на основании этого прнимаются те или инные решения.
В данной статье я на простом примере показал именно сбор данных и отображение самых необходимых показателей, с минимальными тратами.
Почему вы решили, что эта статья от SEO специалиста или кого-то связанного с SEO?
Где в статье написано, или вывод в том, что Angular или другой фреймверк это SPA?! Зато там написано:
Angualr, React и другие современные фреймверки просто помогают релизовывать такие страницы, конечно можно сделть это все на Vanila js используя XMLHttpRequest или jQuery. А проблема SEO, в другом, в том что используя клиентский роутинг фреймверков, страницы рендерятся на клиенте используя и строят DOM с данными уже после того как страница была отдана сервером, и при прямом переходе на ссылку клиентского роутинга, сервер всегд отдавал index файл, и уже после клиентское приложение сторило необходимую стрницу, и не все роботы умеют обрабатывать такие страницы.
Тут можно холиварить до усрачки. Это все зависит какой смысл вложен в слово «технология». Ведь каждый ответит по своему. Мне близко это определение.
Ведь не всегда браузеры умели запускать server workers, не всегда умели работать с пушами, это все развивалось и продолжает развиваться. Можно PWA назвать и методологией, и подходом к разработке, да не важно как ты его назовешь, главное это релально классная штука, которая может улучшить веб-сайт. Которая, совмещает в себе многие классные вещи веба и мобильных приложений.
И поверьте, у меня достаточно опыта и знаний в веб-разработке, чтобы писать и говорить на такие темы. Я не занимаюсь копирайтингом или бездумно переписываю чужие статьи, я все это применял, и моя команда применяет это все и по сей день!
Умеет, причем прекрсно. Next использует SPA SSR и на базе шаблонизатора React рендерит страницу на сервере и подготавливает приложение, отдает готовую страницу клиенту, и уже клиент запускает полноценное приложение и дальше работет как стандартное SPA
Пусть себе перезагружают, никто не говорит что SPA это панцея, но при помощи нее можно добится более удобного интерфейса и взаимодействия с пользователем, расширить горизонты
Конечно для лендингов это не имеет смысла, в статье я уделил внимание, когда имеет место быть SPA, а когда нет. Для блога, скорее тоже нет, чем да. А вот для магазина, вполне себе можно, просто пока нет широкораспространенных фреймверков или CMS для такой работы, и это сделать не дешево.
Конечно разница есть, вместо того, чтобы рендерить страницу полностью, клиент получает только часть данных, и перерисовывает только их. Так же сервер не занимается лишними операциями по формированию html стрницы, что при большой посещаемости может существенно разгрузить сервер.
Уже есть, и мы используем их каждый день в своей работе. Например, nextjs.org
Да, мы им не занимаемся уже более 2х лет. Работает стабильно, сам по себе, даже есть активные пользователи. Что касается Facebook, так у них изменилась политика и нужно скорее всего менять приложение, так же нужно обновить мобильные приложения для поддержки последних версий iOS и Android, сменить дизайн. Но на все это нужно время, ресурсы и желание. Сейчас есть другие интересные для нас проекты, и может быть однажды мы возродим этот продукт.
Поэтому я решил поделиться опытом, чтобы тот, кто сейчас думает о создании своего продукта, не наступил на такие же грабли.
Вот и в нашем случае, мы думали, что нужно просто сделать зашибись, и все будет хорошо (нормально делай, нормально будет). То есть если мы сделам во такие классные штуки, которые по нашему мнению должны быть бомбой, то люди просто будут хотеть пользоваться нашим продуктом. Но это не так!
Тут нужно не просто уметь делать, а нужно четко понимать зачем ты это делаешь и нужно ли оно сейчас. Необходимо уметь строить и быстро тестировать гипотезы. Никто и никогда не сможет придумать сразу идеальный продукт без тестирования на реальных пользователях.
Другими словами – пиар не спасет, если ты сделаешь хороший, но никому не нужный продукт, ну или нужный только тебе и сыну маминой подруги.
Стажер – человек, который еще не имеет уверенных знаний в области, но имеет желание и тягу к развитию. Может делать простые задания, но очень долго и скорее всего не с первого раза.
2) Нет, стажеры не решают реальные задачи компании. Ну и задания, которые я придумал не являются абстрактными. Я постарался создать задачи, очень близкие к реальности или такие, которые приходилось решать в реальных проектах, но без привязки к ним.
По поводу заданий для стажеров, которые можно будет использовать в компании, у нас была практика, но ни к чему хорошему она не привела.
Нет, конечно. Я же объяснил, что человек приходя с опытом, у него есть уже выработанные привычки, которые не подходят под процессы новой организации, и человеку самому довольно сложно изменить свое привычное поведение.
Ну и проблемы бывают не только в процессах и технических вещах, есть еще софт скилы, которые в каждой организации разные и их тоже иногда нужно менять и подстаиваться.
Я просто хочу сказать, что человеку иногда проще принять то, что для него ново, чем переучиваться.
“В целом ресурсы, потраченные на обучение, окупаются. Если говорить о моём времени как времени руководителя, то пока я не сильно много его трачу. Когда мы поставим систему на поток и поймём, что у нас получилось — введём отдельного специалиста по корпоративному обучению.”
А что касается ответа «потому что тут так прнято», я обсолютно согласен что это не хороший ответ, поэтому мы не используем эту формулировку и всегда можем объяснить почему мы делаем так, а не иначе. У нас есть регламенты, которые описывают процессы.
Поэтому процесс интеграции затягивается, и даже может привести к плачевным результатам, когда человек будет в явном или не явном виде бороться с системой.
Например. Человек привык работать один или с небольшой командой, поэтому работает не в отдельной ветке и заливает в репозиторий большое количество изменений, и только после завершения работы над задачей. Хотя на новом месте принято работать по gitflow и заливать изменения несколько раз в день в определенную ветку, чтобы коллеги могли провести ревью кода. Когда его просят, он, конечно, соглашается, но делает это с неохотой, так как его заставляют делать “ненужную” работу. И он начинает обсуждать это на кухне, или в курилке, возможно если он сильная личность, он сможет пробить свои интересы, и тем самым ломает процессы.