Хотелось бы больше одушевленных деталей о трудностях, с которыми пришлось бороться во время конструирования. Без них выглядит похоже на отчет о проделанной работе :(
Мне кажется что быстрее растут те, кто может показать что профит от них выше на другой должности.
В конечном итоге все это всего лишь вопрос рентабельности. Ведь если вы действительно умны как разработчик и смогли сделать несколько невозможных вещей на проекте как разработчик, вряд ли вас захотят терять как разработчика в ответ на чисто гипотетическую перспективу увеличить профит, используя вас как менеджера.
С другой стороны, если вы, как разработчик, своими силами подготовили на проекте базу, при помощи которой выполнять необходимую работу смогут относительно «недорогостоящие» разработчики (прости меня, повелитель джуниоров, я уважительно!), то вы уже показали себя как менеджер. Может это не потребовало от вас столько же ментальных мощностей, как внедрение идеально подходящего, но сложного в восприятии фреймворка, но денег этим вы уже заработали, как и репутации у тех, кто эти деньги считает.
Теплая ламповость этой истории подарила мне хорошее начало рабочего дня.
Вы рассказали это с такой теплотой и душевностью, что мне казалось, делали это лично для меня, спасибо :)
Наверное вам могло показаться, что я так именно про вас говорю.
Но это не так: ваша статься действительно интересная. Я в общем сетую на сложившуюся ситуацию.
Познавательно, можно сделать вывод о методах получения качественной информации для каждой отдельной ЦА на проекте и форсировать именно те методы, которые подходят. Не знаю, делится ли кто-то подобной статистикой for-free, но возможные затраты на самостоятельный эксплорейшн несколько пугают.
Хабра-эффект имеет место :)
Единственное чего я опасаюсь — слишком сильной его эксплуатации и снижения качества контента. Это неминуемо, в случае со слишком широким распространением площадки, когда первоначальной целью авторов становится не оповещение коммьюнити, а беспощадная кровавая бойня за аудиторию для своих проектов.
Все очень круто, UX в разы улучшен. Осталось побороть проблему утёнка :)
Конструктивно, не радует неполный редиз. Многие блоки остались в совершенно первозданном виде и выглядят немного не к месту в свете нового вида.
Хотя, мне кажется, что такие изменения обычно закидываются, как и в политике, с малого. Например, редиз стрелок кармы, а потом, пока все заняты обсуждением этого, полное обновление сайта.
//предполагается, что это будет находится в теле функции
//или методе, в которой/ом, будет устанавливатся таймер.
//очищаем объект в котором лежал счетчик, если он уже существовал до этого.
var timeout = null;
//инициализируем новый счетчик
timeout = setTimeout([function], [time]);
//как только интервал закончился, останавливаем счетчик
function [function]() {
if (timeout) clearTimeout(timeout);
}
Я еще не слишком полно знаком с тем, как кушает память setTimeout(), но этот код указывает видимо на то, что все таймеры из моих примеров оставались в памяти, хоть ссылка на них уже и не была доступна. А этот метод позволяет однозначно установить соответствие одного таймера одной итерации, без накопления лишних и без возможности «временного перекоса», когда предыдущий вызов еще не закончен, а уже наступил следующий.
Да, точно. Во-первых это самая важная часть в коде, во вторых мне пришлось сравнительно много понять, прежде чем прийти к этому. А во-вторых, на деле он не такой уж и точный в этом контексте, как ни печально.
Да, все верно. Только точность от этого нисколько не выше и не ниже, это просто механизм реализации. А в посте мы гонимся именно за коррекцией таймера, для повышения стабильности периодичности срабатывания.
Всегда есть что-то интересное.
Под трудностями я полагал «технические задачи», которые пришлось решить во время сборки.
Этот стиль написания не навеян ExtJS? Очень напомнило.
В конечном итоге все это всего лишь вопрос рентабельности. Ведь если вы действительно умны как разработчик и смогли сделать несколько невозможных вещей на проекте как разработчик, вряд ли вас захотят терять как разработчика в ответ на чисто гипотетическую перспективу увеличить профит, используя вас как менеджера.
С другой стороны, если вы, как разработчик, своими силами подготовили на проекте базу, при помощи которой выполнять необходимую работу смогут относительно «недорогостоящие» разработчики (прости меня, повелитель джуниоров, я уважительно!), то вы уже показали себя как менеджер. Может это не потребовало от вас столько же ментальных мощностей, как внедрение идеально подходящего, но сложного в восприятии фреймворка, но денег этим вы уже заработали, как и репутации у тех, кто эти деньги считает.
Резкие пики на графиках — зимние каникулы, плавные сёдла — периоды летних отпусков :)
Вы рассказали это с такой теплотой и душевностью, что мне казалось, делали это лично для меня, спасибо :)
Но это не так: ваша статься действительно интересная. Я в общем сетую на сложившуюся ситуацию.
Хабра-эффект имеет место :)
Единственное чего я опасаюсь — слишком сильной его эксплуатации и снижения качества контента. Это неминуемо, в случае со слишком широким распространением площадки, когда первоначальной целью авторов становится не оповещение коммьюнити, а беспощадная кровавая бойня за аудиторию для своих проектов.
Конструктивно, не радует неполный редиз. Многие блоки остались в совершенно первозданном виде и выглядят немного не к месту в свете нового вида.
Хотя, мне кажется, что такие изменения обычно закидываются, как и в политике, с малого. Например, редиз стрелок кармы, а потом, пока все заняты обсуждением этого, полное обновление сайта.
Я еще не слишком полно знаком с тем, как кушает память setTimeout(), но этот код указывает видимо на то, что все таймеры из моих примеров оставались в памяти, хоть ссылка на них уже и не была доступна. А этот метод позволяет однозначно установить соответствие одного таймера одной итерации, без накопления лишних и без возможности «временного перекоса», когда предыдущий вызов еще не закончен, а уже наступил следующий.
Этим комментарием я ставлю вам плюсик, ибо абсолютно с тем же мнением :)
[/minute of a courtesy]