Тут еще такое дело.
Допустим, есть две однотипные ММОРПГ, в одной появилась реклама, а в другой — нет.
Вопрос на засыпку: из какой игры игроки уйдут, и куда?
Часто люди играют, чтобы уйти от реального грязного мира, и жить в другом мире — волшебном, фентезийном, фантастическом и т.д. А если еще и там будет обычная бытовая реклама, то кому оно понравится-то… Кому-то, конечно, без разницы, но могу предположить что потеря численности аудитории, по крайней мере на данный момент, явно обойдется дороже, чем прибыль от показа рекламы.
У этой идеи уже борода выросла, старая она. Но, как видите, до сих пор массово рекламу в играх не крутят.
Первая причина в том, что рекламу крутят не просто так где угодно, а там, где есть платежеспособная аудитория.
А какая аудитория у игр ММОРПГ?
В основном, это дети, чаще школьники, реже студенты, причем не ведущие активную жизнь в реале. Обычно они не платежеспособны, и рекламодателям не интересны. В общем, на данный момент крутить рекламу в ММОРПГ примерно так же экономически не оправдано, как и крутить рекламу детям в детских садах.
Вторая причина, все-таки у ММОРПГ игр сравнительно аудитория по сравнению с тем же TV. Соответственно, пока игроков меньше, чем сидящих у зомбоящика, рекламодатели будут предпочитать именно телерекламу.
В будущем, когда игры примут более массовый характер, и текущее поколение игроков, не бросивших играть, вырастет (то есть у них заведутся деньги), то и рекламу в играх крутить будет выгодно, и эта реклама неизбежно появится. Но сейчас еще не время.
Возможно, тут обычный бытовой экономический расчет.
Если супруга всерьез собралась уходить к другому, это значит, что скоро последует развод, и соответственно предстоит раздел имущества. Уголовное дело против мужа очень в этом поможет. Типичная ситуация.
Но в любом случае, принцип подобных покупок таков: желательно сначала уточнить детали у саппорта компании-производителя софта (в данном случае JetBrains) перед тем, как покупать их продукты где-либо кроме их сайта.
P.S. В 2008 году я покупал себе персональную лицензию InteliJ IDEA 8 (это основной продукт JetBrains, включающий в себя в том числе и возможности WebStorm) на SoftKey.ru за Webmoney, успешно. Тогда у меня это вышло на сколько-то процентов дороже, чем продавалось на сайте JetBrains, возможно это получилось из-за конвертации WMZ в WMR, но этим можно пренебречь.
Та ладно, можно и самому назвать любую цифру на уровне средней стоимости, а потом поторговаться. Это не проблема, особенно если часто пользуетесь такси, и особенно если ездите по одному и тому же маршруту. Таксист почувствует матерого клиента, и не будет наглеть.
Помню, когда в Харькове жил, там таксисты использовали другой метод, похлеще.
Подходишь к такси, спрашиваешь цену, а таксист «садись, поехали, приедем — рассчитаемся».
Потом приезжаете, а он выставляет цену больше раза в два.
И уже особо не поторгуешься, услуга-то уже оказана, и особенно не поторгуешься, если например едешь не один, а с дамой.
Так что выход один, скрупулезно договариваться о цифрах до поездки.
Так-с, ну раз он психолог, то должен понимать психологию клиента. Что будет, когда клиент через некоторое время узнает, что из-за своего незнания технологий разработки он заплатил в два раза больше, чем стоит работа, а фрилансер об этом ему не сказал, и переплаченных денег не вернул? Каковы шансы, что этот клиент даст исполнителю следующий заказ?
Заказчики, которые хотят получить ТЗ нахаляву, нам не нужны.
Описанный в статье способ имеет смысл, если разработчик не уверен в себе, и не знает, что у него получится или не получится. Или если он хочет привлечь этим заказчика, выделившись из других фрилансеров в тендере.
===
Если же разработчик знает стоимость разработки, и при этом не говорит заказчику цену, играя в игры таксистов «Сколько стоит доехать до вокзала? Та ладно, садись, приедем — рассчитаемся», то это выглядит некоторым лукавством.
Это ставит заказчика в очень неудобное положение.
И разработчика тоже ставит в неудобное положение, если потом через некоторое время заказчик узнает, что заплатит за работу намного больше, чем она стоит, а разработчик его об этом не предупредил и лишние деньги не вернул.
Это — некрасиво, хотя да, работает (как и обман, воровство, и т.д. — тоже «работает», но достойный ли это путь?). Но не мне судить, конечно.
Специалист может только знать, сколько будет стоить разработка (и то приблизительно).
Прошу прощения, разве я писал что-то другое?
Все правильно, именно это я и имел в виду, специалист знает, сколько будет стоить ЕГО работа, то есть, разработка.
Работа по реализации сама по себе стоит одинаково, независимо от того, заработает ли заказчик на проекте миллионы, или влезет в долги из-за убытков. Это и есть профессионализм, когда разработчик занимается только своим делом, и получает за то деньги.
То, что потом с разработанным проектом сделает заказчик, профессионала волновать не должно, к тому времени он уже занят другим проектом.
«Предпроектные изыскания» — это называется аналитической работой, которая тоже должна быть учтена и оплачена.
Пример этому на фрилансе — если у заказчика нет ТЗ, то фрилансер может предложить написать ТЗ для заказчика за определенную сумму.
Также, периодически сталкиваюсь с такими проектами, когда изначально определить стоимость невозможно, и ТЗ тоже нет.
В этом случае идет почасовая оплата.
Это не профессиональный подход.
Специалист, который не знает, сколько стоит его работа, не может являться профессионалом.
Такие трюки — удел или новичков, или любителей (кстати, иногда любители могут быть более опытными спецами, чем профессиноналы, так что слово любитель это не оскорбление). А также тех, у кого нет другого выхода чтобы получить заказ из-за высокой конкуренции, у кого нет стабильного источника доходов.
Работать такой способ, конечно, может, но не массово, и только с проверенными клиентами, с которыми планируете работать в дальнейшем, и которые эту оплату скорее всего рассмотрят как инвестицию в исполнителя.
Пример — упомянутые выше рестораны с принципом «оплатите столько, насколько понравилась еда», штучные подобные рестораны работать будут прекрасно и быть в плюсе. Но должны соблюдаться условия:
— такие рестораны должны быть расположены только в респектабельных районах, где обычно нет бедноты, в идеале — богатые туристы.
— таких ресторанов не может быть много, иначе моментально появятся сайты типа «списки бесплатных ресторанов», и куча бомжей, автостопщиков, прочих халявщиков, а также школьников, студентов, (для Европы в этот список можно еще добавить выходцев из стран третьего мира, особенно из Африки) и т.д. постоянно будут там тусоваться.
С фрилансом то же самое. Делать работу на условиях «заплатите сколько, на сколько сами оцениваете работу» имеет смысл только тем заказчикам, которые в любом случае оплатят по работу по достоинству. Но на поток ставить такой подход можно только если нет другого выхода, ибо это уже из серии маркетинговых трюков, и, как я и писал выше, не является профессиональным подходом.
Еще одно альтернативное решение, подобное тому, что было ранее (но с одним условием с BETWEEN, вместо двух условий с AND, как я и писал выше).
Возможно, оно более наглядное, хотя оно скорее всего и не лучше по производительности, нужно проверять.
SELECT
COUNT(IF(201001 BETWEEN a AND b, 1, NULL)) AS jan,
COUNT(IF(201002 BETWEEN a AND b, 1, NULL)) AS feb,
COUNT(IF(201003 BETWEEN a AND b, 1, NULL)) AS mar,
COUNT(IF(201004 BETWEEN a AND b, 1, NULL)) AS apr,
COUNT(IF(201005 BETWEEN a AND b, 1, NULL)) AS may,
COUNT(IF(201006 BETWEEN a AND b, 1, NULL)) AS jun,
COUNT(IF(201007 BETWEEN a AND b, 1, NULL)) AS jul,
COUNT(IF(201008 BETWEEN a AND b, 1, NULL)) AS aug,
COUNT(IF(201009 BETWEEN a AND b, 1, NULL)) AS sep,
COUNT(IF(201010 BETWEEN a AND b, 1, NULL)) AS oct,
COUNT(IF(201011 BETWEEN a AND b, 1, NULL)) AS nov,
COUNT(IF(201012 BETWEEN a AND b, 1, NULL)) AS dec
FROM (
SELECT EXTRACT(YEAR_MONTH FROM start_date) AS a, EXTRACT(YEAR_MONTH FROM end_date) AS b
FROM test
WHERE start_date < '2011-01-01' AND end_date >= '2010-01-01'
)
Да, все правильно. А еще можно к Вашему решению добавить дополнительное условие в конце:
WHERE start_date < '2011-01-01' AND end_date >= '2010-01-01'
Это для того, чтобы не делать выборку событий, которые прошли в прошлом году, или начинаются лишь в следующем году. А то иначе для этих лишних данных придется впустую вызывать кучу проверок, учитывать их при вычислении сумм и т.д.
Кстати, ниже я привел еще несколько альтернативных решений (заинтересовала меня эта задачка).
В общем, различных вариантов решения данной задачи довольно много.
Вот, кстати, альтернативное решение.
Если что, заранее прошу прощения, я его не проверял, так что потенциально возможны опечатки/ошибки, но смысл, думаю, должен быть понятен.
SELECT
SUM(x >> 11 & 1) AS jan
SUM(x >> 10 & 1) AS feb,
SUM(x >> 9 & 1) AS mar,
SUM(x >> 8 & 1) AS apr,
SUM(x >> 7 & 1) AS may,
SUM(x >> 6 & 1) AS jun,
SUM(x >> 5 & 1) AS jul,
SUM(x >> 4 & 1) AS aug,
SUM(x >> 3 & 1) AS sep,
SUM(x >> 2 & 1) AS oct,
SUM(x >> 1 & 1) AS nov,
SUM(x & 1) AS dec
FROM (
SELECT
IF(start_date >= '2010-01-01', 0xfff >> MONTH(start_date) - 1, 0xfff) &
IF(end_date < '2011-01-01', 0xfff << 12 - MONTH(start_date), 0xfff) AS x
FROM test
WHERE start_date < '2010-01-01' AND end_date >= '2010-01-01'
);
Конечно, вряд ли это будет работать быстрее, чем предыдущее решение с кучей условий, нужно проверять.
И с BETWEEN можно, но придется по-другому переписать запрос. При этом он будет менее нагляден (придется хардкодить порядковые номера первых/последних дней месяцев начиная с прошлого года), это недостаток конечно, но количество условий в запросе будет меньше. Впрочем да, на использовании BETWEEN я не настаиваю в данном случае, наглядность важнее копеечной выгоды от уменьшения количества условий на небольших наборах данных.
А вон COUNT вместо SUM должен прекрасно работать даже на этом примере (с условиями с AND), но только если убрать «else 0». Попробуйте.
Я не утверждаю, что во всех случаях функции тормозят. Но в том или ином конкретном случае могут тормозить. Это можно выяснить поставив эксперимент, и сделав замеры на Ваших данных.
По поводу программиста-предсказалеля. Если для Вас важен вопрос производительности, то при проектировании хранилища данных и составлении запросов первый же вопрос, который должен быть задан, это какими объемами данных придется оперировать.
Его еще можно немного улучшить, если заменить пары условий с AND на условия с BETWEEN.
И «else 0» тут не обязательно, можно опустить.
И если «else 0» опустить, то в этом случае вместо SUM, скорее всего, можно будет использовать COUNT.
Да, то, что одна выборка, в общем случае, быстрее, чем 12 или 24 — с этим нельзя спорить, это — истина.
Но в тех случаях, когда данных очень мало (всего десятки записей, как то часто бывает в подобных системах с ивентами), обработка результата выборки с помощью функции может оказаться дороже, чем несколько простых выборок. То есть, имеет смысл попробовать разные решения, и выбрать то, которое будет работать эффективнее на типичном наборе данных текущего проекта.
Также для эксперимента можно попробовать несколько (хоть все 12 или 24) простых запросов, объединенных в один через UNION ALL. Но сказать однозначно что выгоднее (на очень малых наборах данных) можно лишь проведя серию экспериментов с разными решениями, таково мое мнение.
Впрочем, ниже привели пример запроса с CASE, вот это намного выгоднее, чем использование функции, особенно если AND заменят на BETWEEN, хоть и придется хардкодить данные. Вероятно, это лучший вариант с точки зрения производительности.
Если Вас заботит производительность данной функциональности, рекомендую сделать следующее:
1. Используйте 12 простых запросов, но при этом применяя mysqli multiquery
2. Используйте 12 простых запросов, но при этом применяя mysqli prepared statements
3. Выберите из этих решений то, которое работает на Ваших наборах данных быстрее.
4. Потом сравните это решение (с 12 простыми запросами) с Вашим сложным решением (с одним запросом и функциями).
5. Если будет не сложно, потом пожалуйста напишите сюда цифры замеров производительности, что получилось на Ваших наборах данных, интересно будет посмотреть.
Допустим, есть две однотипные ММОРПГ, в одной появилась реклама, а в другой — нет.
Вопрос на засыпку: из какой игры игроки уйдут, и куда?
Часто люди играют, чтобы уйти от реального грязного мира, и жить в другом мире — волшебном, фентезийном, фантастическом и т.д. А если еще и там будет обычная бытовая реклама, то кому оно понравится-то… Кому-то, конечно, без разницы, но могу предположить что потеря численности аудитории, по крайней мере на данный момент, явно обойдется дороже, чем прибыль от показа рекламы.
Первая причина в том, что рекламу крутят не просто так где угодно, а там, где есть платежеспособная аудитория.
А какая аудитория у игр ММОРПГ?
В основном, это дети, чаще школьники, реже студенты, причем не ведущие активную жизнь в реале. Обычно они не платежеспособны, и рекламодателям не интересны. В общем, на данный момент крутить рекламу в ММОРПГ примерно так же экономически не оправдано, как и крутить рекламу детям в детских садах.
Вторая причина, все-таки у ММОРПГ игр сравнительно аудитория по сравнению с тем же TV. Соответственно, пока игроков меньше, чем сидящих у зомбоящика, рекламодатели будут предпочитать именно телерекламу.
В будущем, когда игры примут более массовый характер, и текущее поколение игроков, не бросивших играть, вырастет (то есть у них заведутся деньги), то и рекламу в играх крутить будет выгодно, и эта реклама неизбежно появится. Но сейчас еще не время.
Если супруга всерьез собралась уходить к другому, это значит, что скоро последует развод, и соответственно предстоит раздел имущества. Уголовное дело против мужа очень в этом поможет. Типичная ситуация.
Поиск по WebStorm: www.softkey.ru/search/index.php?query=webstorm
Но в любом случае, принцип подобных покупок таков: желательно сначала уточнить детали у саппорта компании-производителя софта (в данном случае JetBrains) перед тем, как покупать их продукты где-либо кроме их сайта.
P.S. В 2008 году я покупал себе персональную лицензию InteliJ IDEA 8 (это основной продукт JetBrains, включающий в себя в том числе и возможности WebStorm) на SoftKey.ru за Webmoney, успешно. Тогда у меня это вышло на сколько-то процентов дороже, чем продавалось на сайте JetBrains, возможно это получилось из-за конвертации WMZ в WMR, но этим можно пренебречь.
Помню, когда в Харькове жил, там таксисты использовали другой метод, похлеще.
Подходишь к такси, спрашиваешь цену, а таксист «садись, поехали, приедем — рассчитаемся».
Потом приезжаете, а он выставляет цену больше раза в два.
И уже особо не поторгуешься, услуга-то уже оказана, и особенно не поторгуешься, если например едешь не один, а с дамой.
Так что выход один, скрупулезно договариваться о цифрах до поездки.
Описанный в статье способ имеет смысл, если разработчик не уверен в себе, и не знает, что у него получится или не получится. Или если он хочет привлечь этим заказчика, выделившись из других фрилансеров в тендере.
===
Если же разработчик знает стоимость разработки, и при этом не говорит заказчику цену, играя в игры таксистов «Сколько стоит доехать до вокзала? Та ладно, садись, приедем — рассчитаемся», то это выглядит некоторым лукавством.
Это ставит заказчика в очень неудобное положение.
И разработчика тоже ставит в неудобное положение, если потом через некоторое время заказчик узнает, что заплатит за работу намного больше, чем она стоит, а разработчик его об этом не предупредил и лишние деньги не вернул.
Это — некрасиво, хотя да, работает (как и обман, воровство, и т.д. — тоже «работает», но достойный ли это путь?). Но не мне судить, конечно.
Прошу прощения, разве я писал что-то другое?
Все правильно, именно это я и имел в виду, специалист знает, сколько будет стоить ЕГО работа, то есть, разработка.
Работа по реализации сама по себе стоит одинаково, независимо от того, заработает ли заказчик на проекте миллионы, или влезет в долги из-за убытков. Это и есть профессионализм, когда разработчик занимается только своим делом, и получает за то деньги.
То, что потом с разработанным проектом сделает заказчик, профессионала волновать не должно, к тому времени он уже занят другим проектом.
Пример этому на фрилансе — если у заказчика нет ТЗ, то фрилансер может предложить написать ТЗ для заказчика за определенную сумму.
Также, периодически сталкиваюсь с такими проектами, когда изначально определить стоимость невозможно, и ТЗ тоже нет.
В этом случае идет почасовая оплата.
Специалист, который не знает, сколько стоит его работа, не может являться профессионалом.
Такие трюки — удел или новичков, или любителей (кстати, иногда любители могут быть более опытными спецами, чем профессиноналы, так что слово любитель это не оскорбление). А также тех, у кого нет другого выхода чтобы получить заказ из-за высокой конкуренции, у кого нет стабильного источника доходов.
Работать такой способ, конечно, может, но не массово, и только с проверенными клиентами, с которыми планируете работать в дальнейшем, и которые эту оплату скорее всего рассмотрят как инвестицию в исполнителя.
Пример — упомянутые выше рестораны с принципом «оплатите столько, насколько понравилась еда», штучные подобные рестораны работать будут прекрасно и быть в плюсе. Но должны соблюдаться условия:
— такие рестораны должны быть расположены только в респектабельных районах, где обычно нет бедноты, в идеале — богатые туристы.
— таких ресторанов не может быть много, иначе моментально появятся сайты типа «списки бесплатных ресторанов», и куча бомжей, автостопщиков, прочих халявщиков, а также школьников, студентов, (для Европы в этот список можно еще добавить выходцев из стран третьего мира, особенно из Африки) и т.д. постоянно будут там тусоваться.
С фрилансом то же самое. Делать работу на условиях «заплатите сколько, на сколько сами оцениваете работу» имеет смысл только тем заказчикам, которые в любом случае оплатят по работу по достоинству. Но на поток ставить такой подход можно только если нет другого выхода, ибо это уже из серии маркетинговых трюков, и, как я и писал выше, не является профессиональным подходом.
Возможно, оно более наглядное, хотя оно скорее всего и не лучше по производительности, нужно проверять.
Это для того, чтобы не делать выборку событий, которые прошли в прошлом году, или начинаются лишь в следующем году. А то иначе для этих лишних данных придется впустую вызывать кучу проверок, учитывать их при вычислении сумм и т.д.
Кстати, ниже я привел еще несколько альтернативных решений (заинтересовала меня эта задачка).
Вот, кстати, альтернативное решение.
Если что, заранее прошу прощения, я его не проверял, так что потенциально возможны опечатки/ошибки, но смысл, думаю, должен быть понятен.
Конечно, вряд ли это будет работать быстрее, чем предыдущее решение с кучей условий, нужно проверять.
А вон COUNT вместо SUM должен прекрасно работать даже на этом примере (с условиями с AND), но только если убрать «else 0». Попробуйте.
По поводу программиста-предсказалеля. Если для Вас важен вопрос производительности, то при проектировании хранилища данных и составлении запросов первый же вопрос, который должен быть задан, это какими объемами данных придется оперировать.
Его еще можно немного улучшить, если заменить пары условий с AND на условия с BETWEEN.
И «else 0» тут не обязательно, можно опустить.
И если «else 0» опустить, то в этом случае вместо SUM, скорее всего, можно будет использовать COUNT.
Но в тех случаях, когда данных очень мало (всего десятки записей, как то часто бывает в подобных системах с ивентами), обработка результата выборки с помощью функции может оказаться дороже, чем несколько простых выборок. То есть, имеет смысл попробовать разные решения, и выбрать то, которое будет работать эффективнее на типичном наборе данных текущего проекта.
Также для эксперимента можно попробовать несколько (хоть все 12 или 24) простых запросов, объединенных в один через UNION ALL. Но сказать однозначно что выгоднее (на очень малых наборах данных) можно лишь проведя серию экспериментов с разными решениями, таково мое мнение.
Впрочем, ниже привели пример запроса с CASE, вот это намного выгоднее, чем использование функции, особенно если AND заменят на BETWEEN, хоть и придется хардкодить данные. Вероятно, это лучший вариант с точки зрения производительности.
1. Используйте 12 простых запросов, но при этом применяя mysqli multiquery
2. Используйте 12 простых запросов, но при этом применяя mysqli prepared statements
3. Выберите из этих решений то, которое работает на Ваших наборах данных быстрее.
4. Потом сравните это решение (с 12 простыми запросами) с Вашим сложным решением (с одним запросом и функциями).
5. Если будет не сложно, потом пожалуйста напишите сюда цифры замеров производительности, что получилось на Ваших наборах данных, интересно будет посмотреть.