Ну что могу сказать, похоже рынок действительно дозрел до независимых консультантов, которые брали бы на себя все бизнес-аналитику по такого рода проектам. Мне тут написали «в личку» несколько хороших специалистов с Wordpress, дам им ссылку на ваш комментарий (сами мы все-таки смотрим в другую сторону пока).
Есть ли реальный спрос на услуги фриланс-биржи, предлагающей высокий проф.уровень и качество услуг исполнителей?
Это смотря где. На UpWork мы в основном работаем с англоговорящими фрилансерами (не IT, — переводчики, иллюстраторы, редакторы, войсовер). Там, конечно, тоже бывает всякое. Но случаев, когда человек не прочитал требования, не ответил на прескрин-вопросы, или попытался откликнуться «на шару» — считанные единицы, я бы сказал, меньше 10%. Я вообще иногда поражаюсь, насколько крутых профи там иногда можно встретить за весьма умеренные деньги.
Напрашивается вывод, который очень не хочется делать. Похоже, что уровень развития экономики определяет уровень развития бизнес-этики.
К слову, за шесть дней после публикации этой статьи мне «в личку» написало оч. много народу. Большинство из них активно работают на UpWork.
Эластик не надо — он тяжелый, тормозной, неудобный.
Вполне возможно. Но, что любопытно, пока большинство «кандидатов» топят именно за Эластик. Нашелся только один, кто рекомендовал сфинкса, и еще один (?!?), кто умеет готовить FTS самостоятельно. Я сам очень удивляюсь.
Вот этого я не совсем понимаю. Этап обсуждения задачи — лучшее время для согласования цены. Посмотрел ТЗ первый раз — приблизительно оценил трудозатраты. Уточнил детали — скорректировал предварительную оценку. Причем исполнитель может предложить какие-то идеи, интересные заказчику. То есть стоимость проекта на этапе согласования может как понижаться, так и повышаться. Разве это не логично?
Ого! Даже странно, что вы решили опубликовать это как комментарий, а не как отдельный пост. Тем более, что вы даже обсуждали статью с друзьями (другом). Ведь сейчас читаемость данной статьи уже почти нулевая, а ваши выкладки могли бы быть интересны сообществу.
Короче, все по делу, и с большинством выводов я согласен.
Самое интересное вот что: мы все смотрим на мир со своей колокольни. Исполнители — с колокольни исполнителей, заказчики — с колокольни заказчиков. Я просто хотел показать, как ситуация выглядит с другой, непривычной, стороны. И хотя мне немного «прилетело» в комментариях, в целом (в том числе судя по вашему комментарию), можно сделать вывод, что мы пока не разучились смотреть на мир с разных точек зрения.
Есть Wordpress и Python, длинные ТЗ и короткие, «сайты из коробки» и «индивидуальные проекты», и во всем этом многообразии совершенно точно нет ничего плохого, если все мы станем смотреть на мир чуть шире, чем делаем это обычно.
А еще я получил просто огромное количество личных сообщений: соболезнований, советов, немного едкого троллинга, и массу предложений сделать, наконец, этот чертов сайт! Некоторые даже писали, чтобы просто поболтать.
Я обратил внимание, что многие специально зарегистрировались на Хабре, чтобы написать мне личное сообщение. Это чертовски приятно!
Так что, похоже, что все идет к тому, что у этой статьи будет продолжение. Хотя мне пока не вполне понятно, каким оно будет.
Мне все-таки кажется вы сильно недооцениваете современные базы данных. Просто для интереса, посчитайте объем всех данных с индексами для сайта на, скажем, 1000 статей.
Давайте подсчитаем: статья, которую мы сейчас комментируем, это 19 000 знаков. Допустим мы ее будем хранить в UTF-16. Это 38 килобайт. Тысяча статей — 38MB. Со всеми тегами, индексами, и так далее — пусть будет 50MB (это я примерно с двадцатикратным запасом, потому что большинство статей существенно меньше, и используют UTF-8).
Но, допустим, 50MB. Вся база влезет в память как минимум 80 раз! Причем встроенный в любую базу планировщик запросов уже после второго-третьего однотипного запроса так все оптимизирует, что время запроса, который я привел, будет фактически 0.
Вот это — реалии нагрузки среднего сайта. Я предполагаю, 90% реальных Wordpress сайтов и того меньше.
Но, конечно, если дергать три запроса по очереди, с промежуточным выводом в массивы (как это наверняка делает Wordpress) -тогда конечно, закат солнца вручную и добрый вечер.
… а когда приходит поисковый робот, оно уже не так радостно.
Ну так в любом случае, как бы вы не делали, будет ровно такое же количество запросов + оверхед от прослойки WP.
Думаю поступать надо проще. Сделать родителя, туда поместить все теги шипящие стопы назальные. Если буква в родителе, отображать все теги родителя.
Не, так нельзя. Получится совершенно другая таксономия, и не тот результат.
А, тем временем, пообщался сейчас с человеком, который, как и вы, специализируется на wordpress. Вроде мы договорились до того, что в теории задачку можно сделать для сайта на Wordpress. Но, только на низком уровне.
тем более у вас он еще вложенный, так точно делать не стоит.
признаюсь, я от вас такого не ожидал )) — во-первых там вложенный да еще и с джойном, во-ворых иначе мою задачу не решить даже в теории, в третих этот запрос на 10 000 статей выполняется 1 миллисекунду.
Хотел бы заметить, что я этого не утверждал.
Я предполагал, что большинство дочитало книгу «алгоритмы и структуры данных» до конца, и предложат классическую имплементацию. А впрочем, кто-то, возможно, предложит что-то более интересное.
Напрашивается вывод, который очень не хочется делать. Похоже, что уровень развития экономики определяет уровень развития бизнес-этики.
К слову, за шесть дней после публикации этой статьи мне «в личку» написало оч. много народу. Большинство из них активно работают на UpWork.
Короче, все по делу, и с большинством выводов я согласен.
Самое интересное вот что: мы все смотрим на мир со своей колокольни. Исполнители — с колокольни исполнителей, заказчики — с колокольни заказчиков. Я просто хотел показать, как ситуация выглядит с другой, непривычной, стороны. И хотя мне немного «прилетело» в комментариях, в целом (в том числе судя по вашему комментарию), можно сделать вывод, что мы пока не разучились смотреть на мир с разных точек зрения.
Есть Wordpress и Python, длинные ТЗ и короткие, «сайты из коробки» и «индивидуальные проекты», и во всем этом многообразии совершенно точно нет ничего плохого, если все мы станем смотреть на мир чуть шире, чем делаем это обычно.
А еще я получил просто огромное количество личных сообщений: соболезнований, советов, немного едкого троллинга, и массу предложений сделать, наконец, этот чертов сайт! Некоторые даже писали, чтобы просто поболтать.
Я обратил внимание, что многие специально зарегистрировались на Хабре, чтобы написать мне личное сообщение. Это чертовски приятно!
Так что, похоже, что все идет к тому, что у этой статьи будет продолжение. Хотя мне пока не вполне понятно, каким оно будет.
И сделать первый в мире блог на Go?
Если серьезно, что не так с «пыхой» (кроме богомерзких $$$)?
Давайте подсчитаем: статья, которую мы сейчас комментируем, это 19 000 знаков. Допустим мы ее будем хранить в UTF-16. Это 38 килобайт. Тысяча статей — 38MB. Со всеми тегами, индексами, и так далее — пусть будет 50MB (это я примерно с двадцатикратным запасом, потому что большинство статей существенно меньше, и используют UTF-8).
Но, допустим, 50MB. Вся база влезет в память как минимум 80 раз! Причем встроенный в любую базу планировщик запросов уже после второго-третьего однотипного запроса так все оптимизирует, что время запроса, который я привел, будет фактически 0.
Вот это — реалии нагрузки среднего сайта. Я предполагаю, 90% реальных Wordpress сайтов и того меньше.
Но, конечно, если дергать три запроса по очереди, с промежуточным выводом в массивы (как это наверняка делает Wordpress) -тогда конечно, закат солнца вручную и добрый вечер.
Не, так нельзя. Получится совершенно другая таксономия, и не тот результат.
А, тем временем, пообщался сейчас с человеком, который, как и вы, специализируется на wordpress. Вроде мы договорились до того, что в теории задачку можно сделать для сайта на Wordpress. Но, только на низком уровне.
признаюсь, я от вас такого не ожидал )) — во-первых там вложенный да еще и с джойном, во-ворых иначе мою задачу не решить даже в теории, в третих этот запрос на 10 000 статей выполняется 1 миллисекунду.
Хотел бы заметить, что я этого не утверждал.
Я предполагал, что большинство дочитало книгу «алгоритмы и структуры данных» до конца, и предложат классическую имплементацию. А впрочем, кто-то, возможно, предложит что-то более интересное.