Судя по similarweb, у вас 320К посещений в месяц. Если не секрет, откуда у вас берутся сотни тысяч одновременных подключений со всей страны?
Мне на самом деле интересно, просто я такое видел только на проектах с посещаемостью на несколько порядков больше вашей в пики.
А что там с частотой запроса «чайник wifi купить»?
Доступные термопоты появились не так давно, люди ещё не до конца распробовали всё удобство девайса. Ну и всякие обывательские страхи: сгорит, потребляет слишком много электричества и пр. тормозят распространение.
Коля, у Panasonic (знаешь такую компанию?) есть отличные термопоты, в которых есть всегда горячая вода и стоят они 3-5 тысяч.
Конечно 3,5 гика купили бы такой чайник, но большинство вряд ли захочет усложнять себе жизнь во имя инноваций.
Скорее всего людям нужно универсальное устройство, у фитнес-трекеров всё-таки достаточно узкое применение и соответствующий внешний вид.
Да и понятие «дорогой девайс» очень относительное, некоторым разница в 200-300$ не является критичной.
У нас авторизация и поддержка сессий в API реализовано через HTTP заголовки, а DRF формирует свой Request, и у нас постоянно слетала авторизация при внутренних вызовах API. Поэтому пришлось писать свой мидлваре для авторизации.
Ещё мы не использовали его основное преимущество — прямой доступа к моделям, архитектура у нас немного не подходила.
Тут есть большая разница с BRB — мы агрегируем только лицензионный контент. Так то, если поискать, есть много сервисов с пиратками.
Я выше написал, что мы начали разрабатывать новый проект с близким функционалом и в ожидании проработки этапа UX, так что нам точно сваливание нам точно не грозит, поскольку есть бОльшая цель.
Плюс часть наработок можно использовать в основном проекте, что, как я думаю. нельзя сделать в музыке :-)
Тур-оператор бронирует места в чартерах и отелях заранее — за сезон или больше, и потом авиакомпаниям и отелям пофик будут или нет на эти места люди, чартер может хоть с одним человеком лететь — деньги возвращать всё равно не надо.
Поэтому в определённый момент, когда направление начинает «протухать» на какую-то дату, тур-оператор выставляет для агентств (и только) так называемые «спец.предложения» — это места в чартерах и отелях с очень большой скидкой, а иногда и даже меньше себестоимости, у тур-оператора задача продать хоть как-то этот протухший товар, чтобы не оказаться в ещё большем минусе, причём чем ближе к дедлайну, тем больше скидка.
А дальше турагентства уже на своё усмотрение продают это вам как «горящий», «пылающий» или просто втюхивают по нормальной цене тур.
Как-то меня свела судьба поработать у тур-оператора, так что кухню я эту немного знаю :-)
А чем плохи обычные грамотно составленные резюме?
Если человеку чего-то стоит, то достаточно и одной страницы текста, если специалист некудышный, дак тут хоть голографическую презентацию делай — лучше он от этого не станет.
Я — пользователь, и не считаю стандартные select'ы и checkbox'ы устаревшими. Наоборот, если мне для выбора значения из 5-ти пунктов будет с блевотной анимацией вываливаться разноцветная хрень с поиском и фильтрацией, то скорее всего я огорчусь.
Под впечатлением от Knockout для одного своего проекта я написал свой упрощённый велосипед, заточенный только под jQuery: jumpkot.com/js/observable.js, цель была в том, чтобы автоматом собрать нужные DOM-элементы в обёртке jQuery ну и попутно назначить какие-то экшны.
var App = {
init: function () {
$('body').observable(this);
},
hide: function () {$(this).hide()}
}
$(function() {App.init()});
После чего в App.ob.main.place мы получим наш div, а для h1 на клик повесится события App.hide.
Для крупного проекта, конечно, всё будет выглядеть гораздо интереснее.
В случае редизайна вы явно поимеете геморой, ну и обучение оператора сайта не добавит оптимизма заказчику. И «как задел на будущее» это вариант совсем не подходит, хотя наверно для текущих нужд сойдёт.
Вообще идея формировать представление на стороне пользователя давно будоражит мой ум, сейчас участвую в разработке соц.сети нового поколения (® :-)) в которой на стороне сервера будет только API и статика, а всё остальное будет формироваться на стороне клиента. Получится как минимум интересно.
Мне на самом деле интересно, просто я такое видел только на проектах с посещаемостью на несколько порядков больше вашей в пики.
Доступные термопоты появились не так давно, люди ещё не до конца распробовали всё удобство девайса. Ну и всякие обывательские страхи: сгорит, потребляет слишком много электричества и пр. тормозят распространение.
Конечно 3,5 гика купили бы такой чайник, но большинство вряд ли захочет усложнять себе жизнь во имя инноваций.
Да и понятие «дорогой девайс» очень относительное, некоторым разница в 200-300$ не является критичной.
Ещё мы не использовали его основное преимущество — прямой доступа к моделям, архитектура у нас немного не подходила.
Я выше написал, что мы начали разрабатывать новый проект с близким функционалом и в ожидании проработки этапа UX, так что нам точно сваливание нам точно не грозит, поскольку есть бОльшая цель.
Плюс часть наработок можно использовать в основном проекте, что, как я думаю. нельзя сделать в музыке :-)
Удачи вам!
Тур-оператор бронирует места в чартерах и отелях заранее — за сезон или больше, и потом авиакомпаниям и отелям пофик будут или нет на эти места люди, чартер может хоть с одним человеком лететь — деньги возвращать всё равно не надо.
Поэтому в определённый момент, когда направление начинает «протухать» на какую-то дату, тур-оператор выставляет для агентств (и только) так называемые «спец.предложения» — это места в чартерах и отелях с очень большой скидкой, а иногда и даже меньше себестоимости, у тур-оператора задача продать хоть как-то этот протухший товар, чтобы не оказаться в ещё большем минусе, причём чем ближе к дедлайну, тем больше скидка.
А дальше турагентства уже на своё усмотрение продают это вам как «горящий», «пылающий» или просто втюхивают по нормальной цене тур.
Как-то меня свела судьба поработать у тур-оператора, так что кухню я эту немного знаю :-)
головой не думай
@
быстрее пиши
Если человеку чего-то стоит, то достаточно и одной страницы текста, если специалист некудышный, дак тут хоть голографическую презентацию делай — лучше он от этого не станет.
Правда только в том, что не любой оптимизатор и вебовый программист является профессионалом в своей области.
Вашу картинку пришлось разглядывать с лупой, вот результат:
Например, для HTML-кода:
<body><div app-bind='"bind": "main.place"'>
<h1 app-bind='"click": "hide"'>Привет</h1>
</div>
</body>
Можно сделать так:
var App = {
init: function () {
$('body').observable(this);
},
hide: function () {$(this).hide()}
}
$(function() {App.init()});
После чего в App.ob.main.place мы получим наш div, а для h1 на клик повесится события App.hide.
Для крупного проекта, конечно, всё будет выглядеть гораздо интереснее.
Вообще идея формировать представление на стороне пользователя давно будоражит мой ум, сейчас участвую в разработке соц.сети нового поколения (® :-)) в которой на стороне сервера будет только API и статика, а всё остальное будет формироваться на стороне клиента. Получится как минимум интересно.