Где-то год назад, мы с коллегами обратили внимание на время чекина пассажира (в нашем случае в автобус), как на один из коррелирующих при формировании user satisfaction factor.
В итоге даже на первый взляд незначительные изменения в интерфейсе checkin-оператора, снизили среднее время чекина с 1 минуты до 10 секунд.
Самые «продвинутые» пользователи умудряются чекинить по одному пассажиру в 3-5 секунды.
P.S.
В добавок к EasyJet-овскому Borading-pass, любителям анти-паттернов, я бы порекомендовал глянуть на WizzAir (по сравнению с их посадочным, EasyJet – еще те гуру юзабилити).
Намедни было в папке 6 (3 туда + 3 назад) таких посадочных формата А4, и в каждом направлении 3 раза просили показать их поименно.
Структура докумета такова, что не то что секунды, а их десятки, занимает найти ответ на такой простой вопрос как:
— Это билет «туда» или «назад»?
— Это на какого из 3х пассажиров билет?
— А на какой этих этих 3х билетов у вас оплачен багаж, еда и priority boarding?
Когда приходится делать подобное «полное сканирование» листа формата А4 по 9 раз в течении 30 минут, волей-не-волей появляется раздражительность и недовольство услугой.
/me очень хотел ругаться отборным русско-украинским матом
Если честно то больше похоже на какое-то нытье немецкого эмигранта первой пост-СССР-овской волны…
Уверен что вы не такой, ибо большинство людей из той волны не то что не платят мед-страховку по 600 евро, они не знают как интернетом пользоваться.
Но все же:
Что вам мешает перейти на частную мед-страховку и платить только согласно выбранным мед-услугам?
Что вам мешает работать не наемный рабочим, а иностранным контрактором, и не платить пенсионные отчисления (2 года такое точно работает, дальше есть какие-то нюансы)?
Не нравится немецкая модель, – Америка тоже очень любит программистов. Там и мед-страховка частная и пенсионные взносы необязательны, и НДС нет. Может даже за общественное телевидение платить не прийдется.
Распоряжайтесь/откладывайте свои заработанные сколько душе угодно.
Иными словами ценой какого-то не очень весомого оверхеда достигается распараленивание того, что в классических моделях хранения данных паралелится из вон рук плохо — дискового IO
Я имел ввиду если нод много то и дисков много — следовательно суммарный diskIO всей системы выше.
Т.е. тот же террабайт данных и будет фильтроваться, но параллельно (!!!!) на большом количестве нод (какие кроме всего имеют кеш в памяти) и легко масштабируемо.
Сделать примитивный MapReduce запрос, который на MongoDB будет весьма быстр даже на больших количествах постов-авторов-комментариев.
Тут стоит понимать что при работе NoSQL нужно существенно перестроить мозг с реляционной модели и SQL-like запросов, на слабо-структурную с map-reduce выборками.
Грубо говоря, в отличии от SQL где ты в функионально-декларативном стиле описываешь ЧТО тебе нужно получить, тут ты задаешь правила КАК работать с данными.
IMHO для хостинга прототипа вполне хватит и какого-нибудь виртуального хостинга за $25/месяц.
А вот стоимость и время, затраченное на «переписывать всё с нуля», в случае минимального успеха проекта, нужно будет умножить на 10 по сравнению с сегодняшним моментом.
Грубо говоря позже, вместо того, чтоб войти в кураж и развивать проект со скоростью 2 релиза в день, вы будете тратить время на то, чтоб опыт, полученный на прототипе, перенести на другую платформу и «вот теперь-то сделать все как надо».
Я совершенно не против идеи подхода release early as possible, но это не повод изначально расставлять себе на будущее совершенно необязательный грабли.
Обилие вопросов от людей «знакомых с MSSQL» в топиках о MySQL совершенно ни о чем не говорит.
Разве что о растущей популярности последнего.
И если для MSSQL-щиков и Oracle-истов что-то работает не так как они привыкли, это отнюдь не говорит о проблемах в MySQL. Это говорит о том, что в MySQL это ввиду разных причин это попросту иначе.
Этим «новшествам» в MySQL уже года так 2.5 (точно помню что пробовал партишининг еще на старой работе, с какой ушел 2.5 года назад)
Также как и триггеры с хранимыми процедурами.
Так что новшества далеко не новы, и уже успешно обкатаны.
Потому статья в контексте MySQL слегка «баянистая», зато хорошо расписаны pros & cons самого подхода.
Ересь — это как раз ваша «статья».
То, что вы тут демонстрируете это самый что ни на есть класический SSL Man-on-the-Middle-Attack (когда некое звено в цепи, имея возможность управлять роутингами, внедряется в фазу SSL-negotiation, и дальнейшем выступает в качестве прокси).
И снифер тут не причем, потому как то что работает подобным образом — это не снифер.
Попробуйте снять ашим «снифером» SSL-трафик с вашего сетевого интерфеса? Много интересного нашли?
А теперь попробуйте снять SSL-трафик с интерфейса соседа? Получилось?
Вот это и называется «снифинг».
А то, о чем пишете вы — это засевший у пользователя в системе троян и надеяться на то, что «А трояны КУКИ не перехватывают!» — по меньшей мере глупо.
P.S. Ну и перед тем, как с пеной у рта начинать писать опровержения, еще раз перечитайте коментарии ниже — там умных мыслей предостаточно.
И все-таки мне кажется что шуткой так и останется.
MSSQL (как впрочем и Oracle) — это уже не просто СУБД — это платформа и инфрастуктура.
Хотя если немного отойти от темы, хочется заметить что в последнее время администрирование и поддержка MySQL становится чемто сродни той черной шаманской магии, что и администрирование Oracle.
Правда у последнего есть масса вспомогательно инструментария для этого.
Мое мнение что начинать писать стоит с GRails.
Причем для тех, кто c Groovy не знаком, можно делать вставки/отсутпления для пояснения синтаксических особенностей.
>> ps в ближайшее время я планирую написать пару топиков о groovy/grails для начинающих,
>> если есть желающие помочь, пожалуйста обращайтесь.
Думаю стоит сконцентрироваться больше на Grails, т.к. о Groovy для начинающих уже написано не переписано
Например voituk.kiev.ua/groovy-presentation-for-exception-7/
и по ссылкам отсюда voituk.kiev.ua/groovy/
В то же время вводного русскоязычного материала по Grails в сети пока не наблюдал.
Зря вы про over-engineered. Сравните с SOAP — полюбите Jabber за простоту и логичность.
Возможно вы имели ввиду излишние обьемы трафика — ну так это решается банальным сжатием (правда и клиент и сервер должны его поддерживать)
В итоге даже на первый взляд незначительные изменения в интерфейсе checkin-оператора, снизили среднее время чекина с 1 минуты до 10 секунд.
Самые «продвинутые» пользователи умудряются чекинить по одному пассажиру в 3-5 секунды.
P.S.
В добавок к EasyJet-овскому Borading-pass, любителям анти-паттернов, я бы порекомендовал глянуть на WizzAir (по сравнению с их посадочным, EasyJet – еще те гуру юзабилити).
Намедни было в папке 6 (3 туда + 3 назад) таких посадочных формата А4, и в каждом направлении 3 раза просили показать их поименно.
Структура докумета такова, что не то что секунды, а их десятки, занимает найти ответ на такой простой вопрос как:
— Это билет «туда» или «назад»?
— Это на какого из 3х пассажиров билет?
— А на какой этих этих 3х билетов у вас оплачен багаж, еда и priority boarding?
Когда приходится делать подобное «полное сканирование» листа формата А4 по 9 раз в течении 30 минут, волей-не-волей появляется раздражительность и недовольство услугой.
/me очень хотел ругаться отборным русско-украинским матом
Уверен что вы не такой, ибо большинство людей из той волны не то что не платят мед-страховку по 600 евро, они не знают как интернетом пользоваться.
Но все же:
Что вам мешает перейти на частную мед-страховку и платить только согласно выбранным мед-услугам?
Что вам мешает работать не наемный рабочим, а иностранным контрактором, и не платить пенсионные отчисления (2 года такое точно работает, дальше есть какие-то нюансы)?
Не нравится немецкая модель, – Америка тоже очень любит программистов. Там и мед-страховка частная и пенсионные взносы необязательны, и НДС нет. Может даже за общественное телевидение платить не прийдется.
Распоряжайтесь/откладывайте свои заработанные сколько душе угодно.
Т.е. тот же террабайт данных и будет фильтроваться, но параллельно (!!!!) на большом количестве нод (какие кроме всего имеют кеш в памяти) и легко масштабируемо.
Тут стоит понимать что при работе NoSQL нужно существенно перестроить мозг с реляционной модели и SQL-like запросов, на слабо-структурную с map-reduce выборками.
Грубо говоря, в отличии от SQL где ты в функионально-декларативном стиле описываешь ЧТО тебе нужно получить, тут ты задаешь правила КАК работать с данными.
А вот стоимость и время, затраченное на «переписывать всё с нуля», в случае минимального успеха проекта, нужно будет умножить на 10 по сравнению с сегодняшним моментом.
Грубо говоря позже, вместо того, чтоб войти в кураж и развивать проект со скоростью 2 релиза в день, вы будете тратить время на то, чтоб опыт, полученный на прототипе, перенести на другую платформу и «вот теперь-то сделать все как надо».
Я совершенно не против идеи подхода release early as possible, но это не повод изначально расставлять себе на будущее совершенно необязательный грабли.
P.S. +1 к mrskam комментариям.
Учитывая что 6 месяцев для хобби-проекта вообще не срок.
И без каких либо инвайтов :)
Хотя многий из описанного выше функционала — еще в закрытом бета-тестировании.
Разве что о растущей популярности последнего.
И если для MSSQL-щиков и Oracle-истов что-то работает не так как они привыкли, это отнюдь не говорит о проблемах в MySQL. Это говорит о том, что в MySQL это ввиду разных причин это попросту иначе.
Также как и триггеры с хранимыми процедурами.
Так что новшества далеко не новы, и уже успешно обкатаны.
Потому статья в контексте MySQL слегка «баянистая», зато хорошо расписаны pros & cons самого подхода.
То, что вы тут демонстрируете это самый что ни на есть класический SSL Man-on-the-Middle-Attack (когда некое звено в цепи, имея возможность управлять роутингами, внедряется в фазу SSL-negotiation, и дальнейшем выступает в качестве прокси).
И снифер тут не причем, потому как то что работает подобным образом — это не снифер.
Попробуйте снять ашим «снифером» SSL-трафик с вашего сетевого интерфеса? Много интересного нашли?
А теперь попробуйте снять SSL-трафик с интерфейса соседа? Получилось?
Вот это и называется «снифинг».
А то, о чем пишете вы — это засевший у пользователя в системе троян и надеяться на то, что «А трояны КУКИ не перехватывают!» — по меньшей мере глупо.
P.S. Ну и перед тем, как с пеной у рта начинать писать опровержения, еще раз перечитайте коментарии ниже — там умных мыслей предостаточно.
Очевидно автор не вкурсе ни как работают сниферы ни как SSL.
А предложенная «защита» сродни картонной двери в квартиру.
MSSQL (как впрочем и Oracle) — это уже не просто СУБД — это платформа и инфрастуктура.
Хотя если немного отойти от темы, хочется заметить что в последнее время администрирование и поддержка MySQL становится чемто сродни той черной шаманской магии, что и администрирование Oracle.
Правда у последнего есть масса вспомогательно инструментария для этого.
Тогда начинайте присматриваться к новой профессии :)
А если серьезно, то на Eclipse свет клином не сошелся — есть как минимум продукты от JetBrains и вроде как ничуть не хуже того же Eclipse.
Причем для тех, кто c Groovy не знаком, можно делать вставки/отсутпления для пояснения синтаксических особенностей.
>> если есть желающие помочь, пожалуйста обращайтесь.
Думаю стоит сконцентрироваться больше на Grails, т.к. о Groovy для начинающих уже написано не переписано
Например
voituk.kiev.ua/groovy-presentation-for-exception-7/
и по ссылкам отсюда voituk.kiev.ua/groovy/
В то же время вводного русскоязычного материала по Grails в сети пока не наблюдал.
Возможно вы имели ввиду излишние обьемы трафика — ну так это решается банальным сжатием (правда и клиент и сервер должны его поддерживать)