Довольно интересное видео (на английском, к сожалению), в котором девушка, на примере соцсетей, рассказывает о плюсах и минусах кэширования в web-приложениях.

Наиболее содержательными являются первые две трети ролика, которые можно суммировать следующим образом:

1) данных в соцсетях нынче много, обновляются они часто, а пользователю их нужно предоставлять быстро
2) поэтому без кэширования не обойтись
3) далее показывается, как кэширование (концептуально) работает в Twitter, Facebook и Reddit
4) но есть проблемка…
5) кэширование в каждом соцсетевом проекте отписывается вручную
6) в результате, имеем много кода, который делает практически одно и то же в каждом проекте. А много кода — это много багов и людского труда
7) и что же с этим делать?

Все уже столкнулись, что запрос в поисковую систему сохраняется в ваши пользовательские предпочтения и потом «используется против вас» — реклама по этому запросу будет долго преследовать вас по всему Интернету.

Но сегодня меня озадачила реклама, которую показал Яндекс на сайте Яндекс.Погоды — с одной стороны тема мне знакома (это бизнес клиента, с сайтом которого мы работаем), но с другой стороны я осознал, что никогда не искал эту тему в Яндексе. В голову закралось подозрение, которое я проверил.

В режиме «инкогнито» браузера я открыл сайт клиента, а затем сайт Яндекс.Погоды. Сначала реклама не старгетировалась, но через 30 секунд я получил то, что искал — пять объявлений от конкурентов нашего клиента. Информация о моем визите «утекла» через Яндекс.Метрику и тематика сайта была записана в мои пользовательские предпочтения. Проверил на других тематиках — результат аналогичный.

Получается следующая ситуация. Вы можете потратить кучу сил и денег чтобы привлечь человека на сайт, причем это могут быть вообще офлайн-мероприятия — знакомства на выставке, наружная реклама или визит человека в фирменный салон. Или это может быть онлайн-реклама, не имеющая к Яндексу никакого отношения — например Гугл.Эдвордс.

И вот посетитель пришел к вам на сайт (без участия Яндекса), получил информацию и ушел думать. И тут «добрый» Яндекс решает «помочь» вашему бизнесу и начинает активно и всюду показывать этому человеку рекламу ваших конкурентов. И это на основании того, что вы воспользовались сервисом статистики от Яндекса.

Легально ли это? Да, вы соглашаетесь с пунктом номер 11 из условий использования Яндекс.Метрики. Этично ли это? Для каждого будет свой ответ.

Издательство Питер решило представить недавно выведшую книгу от автора бестселлера «Карьера программиста», которая поможет вам наилучшим образом подготовиться к собеседованию при приеме на работу менеджером проекта в крупную IT-организацию или перспективный стартап. Основную часть книги составляют ответы на технические вопросы и задания, которые обычно получают соискатели на собеседовании в таких компаниях, как Google, Microsoft, Apple, Amazon и других. Рассмотрены типичные ошибки, которые допускают кандидаты, а также эффективные методики поlготовки к собеседованию.

Какое влияние оказывают веб-страницы продуктов интернет-магазина на уровень конверсии? Ну, это как сказать. Но факт в том, что страница продукта – это ваш последний шанс побудить пользователя совершить покупку.

Именно здесь пользователь ожидает найти всю необходимую информацию для совершения покупки. И это большая проблема для UX-дизайнера («юзабилити-дизайнера»), так как ему необходимо донести до пользователя так много информации на таком ограниченном пространстве. Возможно, именно поэтому большинство страниц с описанием продукта, в конечном итоге, выглядят беспорядочно и неаккуратно. Поэтому очень важно представить всю информацию самым удобным, понятным и убедительным путём.

Вот где пригодятся методы юзабилити.

Прошла неделя с первого поста в нашем блоге, из которого хабропублика узнала, что «есть такая партия» — платформа коллективных инвестиций VCStart. Для проекта этот пост стал и первым выходом в свет, поскольку никакой рекламной деятельности мы пока не вели, решив сначала поинтересоваться мнением о нашем «стартапе для стартапов» читателей Хабра. О взыскательности и дотошности хабровчан ходят легенды — мы знали, на что шли, предвидели вопросы и критику, и побаивались, в случае полного неприятия, шквала тухлых яиц и помидоров. Но с другой стороны, была надежда (и даже некоторая внутренняя уверенность), что мы пришли по адресу и именно здесь оценят, поймут и поддержат.



В итоге получили полный комплект всего, чего ждали. Проект вызвал реакцию, закономерные вопросы и вангование скептиков, что хоть и огорчило, но вместе с тем и вызвало уверенность, что «нас заметили». Яично-помидорного залпа, слава Богу, не последовало, но некоторые одиночные броски были довольно меткими.

Так получилось, что никакое бизнес-образование не поможет запустить блестящий проект. Сначала нужно набить шишек, понюхать пороху и понять, как устроена реальная жизнь. Теоретическая модель станет помогать только тогда, когда вы окунётесь в бизнес с головой.

Проблема в том, что никто этому не учит. Хорошая новость — можно создать экосистему, где освоение такой науки будет проходить максимально болезненно для самолюбия, но при этом эффективно с точки зрения сэкономленных средств, машин и квартир.

Вот прямо сейчас кончаются времена, когда многие делали форменную туфту для получения лёгких денег по аналогу бума доткомов. И заявляли, что «начнём мы, когда найдем инвестора». Модель была простая: бралась идея с потолка, по ней ничего не делалось, но находился инвестор. По возможности — лох, не особо смыслящий в IT. Полученные деньги вкладывались в прототип и массу пиара, затем разыскивался инвестор второго раунда. Дальше стандартно: «когда водка выпита, выясняется, что джип разбит…». И проект заканчивался.

Сейчас многие собирают ручки от грабель своим собственным лбом. Наша команда наблюдала за этим несколько последних лет и все время старалась помогать знаниями. Бесплатно.

Когда мы подавались на участие в программе акселерации, нас мучил вопрос, как стартапы сосуществуют друг с другом в коворкингах и инкубаторах? Мы привыкли работать в маленьком офисе или вовсе из дома, общаясь по Skype. Конечно, часть команды и до этого работала в опенспейсах, но все же, когда в офисе сидит одна компания, или даже один отдел (только продажники, например), все намного понятнее и проще. А как это происходит, если компаний огромное множество? Не падает ли продуктивность каждого из проектов?

По прошествии почти двух месяцев акселерации мы, Анна Чащина и Аида Легранд, сооснователи Witget, решили рассказать о том, как здесь живется проектам. Офис акселератора настолько запал нам в душу, что вылезти с работы часто бывает довольно сложно, хоть мы пока и не ночуем здесь, как некоторые проекты.

Много-много фотографий акселераторских будней – под катом.

Вездесущий… это определённо то слово, которым можно описать язык PHP по отношению к вебу. Он действительно вездесущ. В настоящее время, среди всех серверных языков программирования, PHP используется наиболее широко. На нём написаны более 80% сайтов, при этом следующий по популярности ASP.NET со своими 17% остаётся далеко позади.



Почему? Что позволило PHP стать настолько популярным и широко используемым? На этот вопрос нет однозначного ответа, но простота использования языка, безусловно, существенный фактор, поспособствовавший его успеху. Новички в PHP могут быстро выйти на достаточный уровень и разместить динамический контент на своих веб-сайтах с минимум познаний в программировании.

Именно в этом и заключается основная проблема поиска высококвалифицированных PHP-разработчиков. Относительно низкий порог вхождения и 20 лет развития языка привели к тому, что PHP-программисты стали такими же вездесущими, как и сам PHP. Многие из них могут на законных основания утверждать, что «знают» язык. Однако разработчики, которые действительно являются экспертами по PHP, способны создавать куда более функциональное, надёжное, масштабируемое и простое в сопровождении программное обеспечение.

Как же отличить тех, кто обладает реальной компетентностью в PHP (не говоря уже о тех, кто входит в 1% наиболее опытных кандидатов) от тех, у кого только поверхностные знания?

Мы продолжаем делать обзор функционала современного интернет-магазина и саму технологию проектирования качественного продукта с высокой конверсией. В этой части мы расскажем про карточку товаров и все, что с ней связанно. В прошлый раз мы написали довольно популярные статьи: «Серьезное проектирование серьезного магазина. Часть 1. Исследования» и «Серьезное проектирование серьезного магазина. Часть 2. Модули интернет-магазина», эта статья логическое продолжение.

Карточка товара

Рис. 1. Карточка товара

Задача

К примеру, у вас есть уже настроенный и распространённый по всей компании сервис мониторинга Zabbix а ещё вы пользуетесь поисковым движком Sphinx. Он ищет быстро, но встроенных средств для живого мониторинга его производительности в разрезе индекса не имеет. К примеру, поисковых серверов у вас много и вы хотите соотносить потребление ресурсов системы каждым конкретным индексом дабы понимать — как распределять их по серверам — а так же видеть — какая из коллекций начинает отвечать дольше, чем хотелось бы — и понимать, коррелируется ли это с возрастанием пользовательской нагрузки или ещё чем-то.

Это история одного из самых запомнившихся случаев в моей инженерной практике. По понятным причинам я поменял имена, места и некоторые узнаваемые детали, чтобы нельзя было точно определить заказчика и других участников истории.


Вот так выглядит ленточное хранилище (наше было поменьше) и библиотечный робот (наш такой же). Китаец в комплект не входит.

Часть 1. Коробка

Помню, стояли последние дни ноября. Уже думая об окончании рабочего дня, я планировал свой вечер, когда вдруг мне сообщили, что в славном сибирском городе N у нашего заказчика сломалась ленточная библиотека. Запчасть сразу же отправили транспортной компанией, но вот уже 3 дня, как она все еще была в пути. Транспортная компания невнятно объяснялась и хмыкала в телефон, а заказчик стал не в шутку нервничать. Прогнозы были неопределенные, поэтому было принято решение везти еще одну запчасть своими силами на самолете. Сотрудник склада вручил мне габаритную коробку весом килограмм десять, обклеенную штрих-кодами и стикерами, и радостно хлопнул меня по плечу со словами: «Только не вздумай в багаж сдавать — помнут».

Коробка меня, безусловно, беспокоила, но не меньшее беспокойство мне внушал пакет с сухим молоком, который в последний момент мне вручил менеджер проекта. «У них там какие-то траблы с молочкой сейчас… из-за непогоды что ли… ребята местные просили 2 кг им привезти. Тебе ж не сложно?» — сказал он. По выражению его лица и характерному жесту ладони, как бы прикрывавшей мне рот, было ясно, как он сейчас хотел, чтобы я оказался сговорчивым или даже немым.

В первой части цикла «Прибыльный интернет магазин», мы рассказывали об основных метриках и способах повышения прибыли. В данной статье подробно рассмотрим основной способ увеличения среднего количество товаров в корзине – кросс селлинг.

Кросс селлинг (cross selling) – дословно: перекрестные продажи. Об эффективности данного метода на Западе известно давно. Так, в 2006 году Amazon сообщил, что 35% всех продаж составили именно перекрестные.

Суть данного метода заключается в том, что пользователю, покупающему тот или иной товар, предлагается купить ряд дополнительных товаров, соответствующих его интересам.

Как правильно использовать данный инструмент: что предлагать, кому предлагать, при каких обстоятельствах и в какой форме? Ответы на данные вопросы требуют понимания механизма работы перекрестных продаж, и знания способов его реализации. Итак, что же нужно знать, чтобы разработать индивидуальную стратегию эффективного кросс селлинга?

В начале февраля этого года мы всерьез задумались над рекламным бюджетом и каналами для продвижения Омнидеска. Бета-версия маячила на горизонте, и у нас сильно чесались руки запустить страницу для подписки на получение инвайта.

План был простой как две копейки. Потратить несколько тысяч долларов на рекламу, собрать полторы-две тысячи подписчиков, разослать им через какое-то время приглашения и получить обратную связь. Конечно, мы заранее продумали и следующий этап продвижения, но решили пока на нем не зацикливаться, так как и текущих дел было предостаточно.

Конец февраля ознаменовался началом операции. Действовали строго по сценарию, но скоро стало понятно, что с рекламой вышла накладочка. Правда, не такая, как вы подумали. Расположитесь поудобнее, вас ожидает занимательное чтиво.

Спросите у водителя рейсового междугороднего автобуса: «сколько часов добираться в пункт назначения?». В большинстве случаев — услышите тишину, а если не повезет — получите испепеляющий взгляд и привкус бензина будет преследовать вас пару дней как минимум: потому что неизвестно никому, что случится за поворотом :-) То же самое происходит ежедневно в программных проектах — и в ответ на «когда» нужно либо промолчать, либо что-то красиво и уверенно соврать.



Разработка софта (полет на Марс, строительство небоскреба новой спиралевидной формы в Дубае) — это, положив руку на сердце, настолько сложный и полный рисков процесс, что, не имея формально четкого технического задания (в стиле строгого доказательства формулы корней квадратного уравнения через вывод из бинома Ньютона) — можно лишь задекларировать религиозные постулаты (фичи) и сроки (пророчества) и заставить себя и других поверить в них (во веки веков аминь). Поэтому вы обречены каждый раз шагать в туман с молитвенником и компасом — каждый раз надеясь на удачу и… надежных людей в команде.

Приветствую!

Хочу поделиться собственным опытом разработки электронного устройства. Сначала расскажу небольшую предысторию, чтобы было понятно, зачем это, собственно, нужно было мне.

С чего все начиналось

Изначально мы занимались разработкой программного обеспечения для чип-тюнинга. Одна из основных задач которого — считать прошивку из ЭБУ (электронный блок управления двигателем) и записать ее обратно. Понятное дело, что для этих целей нужно каким-то образом связать компьютер и ЭБУ при помощи адаптера. Когда раньше подавляющее количество ЭБУ использовало простейший способ приема-передачи данных, достаточно было использовать простейший адаптер на транзисторах или специализированной микросхеме. Однако на сегодняшний день большинство автомобилей для «общения» своих компонентов со внешней средой используют CAN шину. Адаптер для CAN шины на транзисторах уже не соберешь, и тут однозначно нужен процессор, который будет управлять всем по определенной программе.
Так возникла первая проблема — как побороть CAN шину. Для того, чтобы не изобретать велосипед выбор сделан на использовании готового адаптера, который работает по стандарту J2534. Для тех, кто не в курсе, стандарт J2534 это стандарт, описывающий аппаратную и программную части устройства, с помощью которого можно произвести подключение к ЭБУ посредством компьютера. Разработали его американцы. Основной причиной его разработки стало законодательное закрепление возможности обновление прошивки ЭБУ не специализированным дилерским сервисом, а любым желающим. Собственно, если каждый желающий может обновить прошивку на своем телефоне, то почему он не может это сделать со своим автомобилем.

Самый доступный импортный аналог стоит в районе 200 долл. США. Как впоследствии оказалось, два одинаковых устройства, удовлетворяющие стандарту J2534, могут работать по-разному с одним и тем же программным обеспечением. Поэтому изначально пришлось привязаться к конкретному производителю и его устройству.

Мы любим изучать города и особенности жизни в них. Обнаруживать проблемы городских жителей и предлагать решения в продуктах 2ГИС. Например, чтобы люди быстрее находили компании, мы подготовили данные о входах в миллион компаний страны.

Решая одну проблему, мы обнаружили другую. Да, теперь 2ГИС приводит пользователей прямо к двери, но что если организация или банкомат находятся внутри большого здания?



По сути, мы бросили человека с его проблемой, так и не показав, где именно находится объект его поиска. Нужно было срочно искать решение.

Так появилась идея, которую мы назвали «Этажи».

Помимо истории новой возможности в 2ГИС хочется поделиться нашим подходом к её созданию, рассказать об участниках и особенностях процесса создания. Поэтому познакомьтесь с ролями, которые будут появляться на каждой ступеньке формулирования продукта.

Редкий Интернет-магазин ни разу не сталкивался с проблемой отсутствия товаров на складе. Влияние этой проблемы простирается далеко за пределы потерь продаж отдельного продукта. Из-за этого может снижаться удовлетворенность покупателей от принятого решения о покупке, а в будущем это может привести к тому, что покупатель выберет другой магазин или бренд. Итак, как же все-таки можно решить проблему отсутствия товаров на складе, с которой сталкиваются сегодня онлайн-магазины? Мы решили разобраться в этом вопросе на примере опыта Аудиомании.

Вчера Atlassian выпустила обновление своего сервиса Bitbucket. Полностью обновился интерфейс, и добавилось немного интересных багов фич. Под катом приведу краткий обзор нововведений на основе записи в блоге разработчиков, ну или можно сразу потыкать у себя в браузере.

В одном из комментариев к посту автора, многоуважаемого пользователями Habr, я ответил, что основной причиной неудач проекта является не использование методологий «через %опу» или «как получится», а наличие только операционного управления в рамках проекта. Проектный подход у таких менеджеров заканчивается уже после составления сметы проекта.
В этом посте проведу более детальное сравнение операционного подхода с проектным.

Уровни управления проектом