Pull to refresh
27
0
Артем @Lond

Web developer

Send message
Урлы с utm_* в аналитиксе обычно используются для отслеживания эффективности различных маркетинговых или коммерческих активностей. Так, если будет серверный редирект, Вы не сможете четко понимать, откуда пришли люди — рассылка партнера, ваша рассылка или прямой заход, партнерское рич-медиа размещение или переход с премиум-баннера, и т.д.
Один заход будет считаться как 2 — реферальный и внутренний
Я знаю, с оценки по времени всегда проблемы. Это такие штуки которые кладут на вас ответственность.

Кстати, по тексту часто встречается дистанцирование от команды. Например, в данном случае, проблемы с оценкой времени — это всегда вина руководителя, как и большинство остальных проблем отдела, поскольку их решение находится в кругу ответственности руководителя, следовательно, наличие проблем в отделе — недоработка именно руководителя. В таком положении дистанцирование от команды сродни переводу стрелок на них.

Когда на вас начнут давить вопросами в стиле «А можно как-нибудь быстрее?» я ожидаю услышать «Нет».
Во-первых, не следует допускать разработчиков к общению с другими отделами в формате планирования без личного участия. Подобные вопросы должны быть адресованы руководителю. Во-вторых, практически всегда «можно быстрее», доходчиво объяснив менеджерам — или работа занимает столько времени, сколько было озвученно, или упрощается исходная задача — при наличии ряда свойств проекта (проект уже в возрасте, основа дохода — реклама, и т.п.), этот выход часто является единственным способом заработать деньги. Доводилось сталкиваться с несколькими руководителями, которые не предлагали варианты, услышав подобные требования по ускорению. Закономерно — их всех уволили или сняли с должности по одной и той же причине — рецедив срыва сроков по крупным заказам.
Для угоды всем, мы часто используем некое подобие MVP — если планируем запустить N фитч, но не успеваем, то выкатываем, скажем, N-2, но вполне стабильных, остеивая малоприоритетные. Бизнес не очень страдает (результат все-таки есть) и пользователи рады, потому-что не были в курсе планов.
Возможно, я чего-то не понял, но… На мой взгляд, подобный манифест должен быть прозрачным для команды (я имею, что команду нужно подталкивать и наставлять к тому, чтобы каждый её участник самостоятельно пришел к выводам, написанным выше, вместо декларирования этих выводов перед лицом команды в формате ожиданий), иначе это походит на слова человека, функция которого сводиться лишь к объявлению планки качества и применению дисциплинарных мер за её превышение, что уже дает подрыв авторитета и есть шагом к Fear-driven Development.
Мы на нашем проекте как-раз столкнулись с такой же проблемой, но условия были несколько другими — вместо полноценных моделей использовался слой DAO — 1 метод класса = 1 sql запрос, что-то типа getNewsForMainBlock($limit). Поэтому решили отталкиваться от чистого SQL-запроса, выделив роль тегов именам таблиц, которые используются в запросе. При операциях обновления ключи сбрасываются, при выборках, соответственно, устанавливаются.

Мы изначально стремились полностью уйти от потери записей в кэше, отдав под него всю память (исключая выталкивание по LRU) и устанавливая TTL записи в 0. Таким образом, единственно возможная ситуация, при которой ключ пропадал, являлся бы сброс из приложения.

Далее, мы использовали свою расширенную версию адаптера кэширования, во многом похожую на Вашу, но столкнулись с рядом проблем, из-за которых пришлой отказаться от такой схемы хранения тегов. Изначально мы имели в кэше запись вида:
AllCacheTags => [
    tag1 => [
        key_id1,
        key_id2,
        key_id3,
        ...
    ],
    tag2 => [ ... ]
]


Но после внедрения такой схемы, у нас очень сильно поднялся average load на сервере — как выяснилось, у расширения memcache есть параметр compress_threshold, который устанавливает лимит на размер ключа, по достижении которого это значение перед вставкой в memcache будет сжиматься в принудительном порядке, независимо от установленного при вызове add() флага. Так, поскольку чтение и запись этого ключа проходили довольно часто, постоянные операции сжатия/распаковки и давали такой эффект повышения нагрузки.

Также, из-за состояния гонки при записи этого мастер-ключа, мы стали получать значения, которые оставались «намертво» висеть в кэше, не удалявшиеся при сбросе. Как первую ситуацию, так и вторую решили разбиением этого «массива массивов» на составляющие части — 1 тег = 1 запись (хотя первую можно было решить поднятием лимита в параметре).

Пока работает без нареканий :)

Из планов по оптимизации можно выделить внедрение защиты от dogpile эффекта методом имплементации механизма локов и отдачей не-актуальной записи на момент лока.
Все Linux, что есть на работе (Arch, CentOS, Fedora, Ubuntu) co Skype 2.2.0.25 и 2.1.0.81 не работают, как с удалением shared.xml и всего ~/.Skype/, так и без удаления.
На ubuntu стоял 2.2 — валился, сделал даунгрейд до 2.1 — работает нормально.
Делал похожий механизм для ZF, сейчас переношу его на проект, написанный на Kohana 3.1, но с небольшими дополнениями — есть такая задумка определять теги автоматически, разобрав sql-запрос и выбрав из него все используемые таблицы, используя их как теги при модификации (для сброса) и выборке (для сохранения). Решение довольно деревянное, но для сайтов с не слишком хитрой структурой кэша подойдет прекрасно.
Свои скрипты, конечно, лучше красить таким методом, который указан в статье (cwrapper — это всё-таки стороннее приложение). А для уже существующего набора команд из окружения такие обвертки самому писать несколько накладно, гораздо проще использовать уже готовый.
Существует замечательный проект cwrapper, который навешивает обработчики на самые частоиспользуемые (с точки зрения автора проекта), разукрашивая их вывод.
Нет, они сделали свою замену интернетам по принципу p2p на wifi, которая работает на обычном железе.
Существует вполне работоспособная (если не ошибаюсь, сейчас проблемы с ихней заменой DNS). Более того, это уже вторая, полностью переработанная версия (первая была на C) на Python. Вот хороший бложек на тему разворачивания сети у себя.
Как я понял, эта сеть зависит от специализированного железа, что, в принципе, не хорошо. На сколько я помню, уже давно существует альтернативная разработка от итальянцев, реализующая подобный принцип но на стандартном железе, Netsukuku. Правда, её недостаток — нацеленность на wifi, впрочем, у них в планах была реализация полноценной работы на проводах — не знаю, реализовали ли её, или нет.
А я и не говорил, что это метаязык. Если я правильно понял комментарий, на который ответил, то речь там шла именно о ре-использовании кода в различных окружениях, а не о природе подхода.
Facebook для этой цели придумал Apache Thrift.
Тоже не знал, одно время начали вылавливать в user-uploads файлах всякие интересности в виде картинок с php-кодом внутри, долго думали, как они исполняются, в итоге завернули все запросы на index.php.
В принципе, да, законодательство волшебно в отношении различных сносок и пояснений.
Поле полезное, кроме шуток. Но если сделать такое поле, это разве не будет уголовно наказуемым в духе «содействие проституции» и т.п.?

Information

Rating
Does not participate
Location
Светловодск, Кировоградская обл., Украина
Registered
Activity