me

О перезапусках

Как «Яндекс» провалился с «Кинопоиском»

>Следовательно, на момент запуска нового «Кинопоиска» пиар-департамент «Яндекса» уже должен был иметь план действий на случай, если все пойдет не так.

Типичный пример закнутого в своей области мышления. Что надо сделать пиар-департаменту - неправильный вопрос. Фактически, это признание того, что перезапуск проекта может быть (а, скорее всего, будет) провальным и подготовка путей к отступлению. Возможно, это и подходит для какой-либо компании, но только не для технологичекого лидера индустрии.

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

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

>Во-вторых, не очень понятно, почему «Яндекс» не обнаружил все эти проблемы на этапе бета-теста?

Здесь нет ничего сложного. Недостаточно взять какую-то абстрактную аудиторию и провести тест. Если человек не пользовался сервисом, у него нет стереотипа восприятия, и ему всё равно, новая версия или старая. Можно смело утверждать, что есть и те, кому на этапе тестов меньше нравился старый Кинопоиск, просто потому, что его увидели после нового)) Аудитория для тестов должна быть репрезентативной. Жаль, что в Яндексе забыли про собственную же майку "Я - не ваша целевая аудитория".


> Все это можно было исправить. Нужно было просто начать публиковать полную, достоверную и исчерпывающую информацию по всем вопросам, интересующим пользователей. Почему новый сервис создан именно вот таким? Кто его делал? Допустили ли разработчики ошибку, или все так и было задумано? Если это ошибка, то как виновные будут за нее отвечать? Какие шаги компания предпринимает для нормализации ситуации? Услышал ли руководство компании своих пользователей, уважает ли оно их мнение, и намерено ли учитывать его в дальнейшем?

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

Теперь выводы:
1) Если вы перезапускаете проект, особенно - с длинной историей, будьте готовы к недовольству пользователей в любом случае.
2) Минимизация недовольства - отдельный, технологически сложный, проект. Только подготовкой службы PR здесь не отделаться, необходима разработка механизмов миграции аудитории по частям, причем - в обе стороны, и налаживание анализа пользовательской активности.
3) "Я - не ваша целевая аудитория". A/B тестирование работает только тогда, когда аудитории A и B имеют одни и те же статистические параметры. Если вы в "A" поместили хипстеров-либертарианцев, а в "B" - любителей традиционных ценностей, то у вас не A/B, а две разных аудитории.

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

https://www.facebook.com/sloneus/posts/543121732505994
me

Линукс на десктопе

2015 год - год Линупса на десктопе.
Что имеем сейчас:
- Unity адски тормозит на любом разумном железе, делает диафильм из любого анимированного виджета. Найти через стандартный диалог поиска ничего нельзя. Регулярно, раз в 20-30 секунд падают программы из Unity, если у вас 1-2 Гбайт оперативной памяти.

- В KDE нормально нельзя сделать самые простые вещи: вытащить на рабочий стол шорткат для программы, передвинуть его( Карл, его нельзя передвинуть, потянув мышкой!), с первого раза добавить локализацию (а после рестарта - можно!), изменить шрифт в Konsole, все темы, даже контрастные, невообразимо блеклые, и хорошо смотрятся только на IPS. При установке русской локали ставится en_RU.UTF-8 вместо ru_RU.UTF-8, из-за чего куча qt-шных программ падает без четкой диагностики (в коредампе - sigsegv в каком-то messagebox). Поиска по помощи нет, от слова "совсем" (Control-F ищет только по текущей странице, ёбстыд!). Самые простые вещи закопаны внутрь меню третьего-четвертого уровня. Общая бессистемность настроек (в одном месте выбрал локализацию, совершенно в другом - раскладку клавиатуры). И все это тоже тормозит, хотя и меньше чем Gnome.

Я помню времена KDE2 и KDE3. Тормозило всё всегда, но, по крайней мере, раньше не было таких адских требований к оперативке, да и интерфейс был примитивнее и в своей примитивности - менее убогий.

Собственно, к вопросу о том, почему каждый год - год Линукса на десктопе, а как был 1% процент рынка, так он и остался. Причина проста: ваши десктопные продукты - говно, которым невозможно пользоваться. Если вы ими пользуетесь, то либо вас заставили из-под палки, либо вы - мазохист.

Пользоваться десктопным линуксом можно только как запускатором браузера и/или терминала в Windows. Вот и весь результат двадцатилетнего прогресса.

Обсуждение в ФБ: https://www.facebook.com/sloneus/posts/518416144976553
me

Психологи в HR

Давайте поговорим о девочках, которые отучились в МГУ на психфаке, поступили в аспирантуру и даже защитили диссертацию (впрочем, последнее не обязательно).

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

Но иногда бывает и так, что приходится работать кадровичкой, по-заморски - HR-ом. И тут вдруг выясняется что почему-то всё плохо, никак не подбирается коллектив, тебе хамят, и жизнь идет мимо. Было такое? А знаешь, почему так? Я объясню.

Все дело в том, что вот ты в свои неполные 30 кандидат психологических наук, выпускник Универа, вроде как ученый, а вынуждена обхаживать заносчивых технарей, каждый из которых имеет мнение, говорит на англорусском суржике, тебя, из-за того что ты не въезжаешь, ни во что не ставит, при этом сам еще и кандидатом наук не является.

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

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

О том, какие умения нужны - в следующем посте. Возможно))
me

ЖЖ такой ЖЖ

http://www.rbc.ru/rbcfreenews/559f98d49a79473e2d0a2a46

Дорогая София Иванова​!
Давайте я вам расскажу почему никто не пойдет в уютную ЖЖ-шечку. Правда, я не совсем понимаю, почему вы сами не видите причин, и почему настолько прописные истины надо объяснять в 2015 году.

Смотрите, в чем дело.
1. Уютная ЖЖ-шечка постоянно вываливает 500-е ошибки. Настолько, что если на странице "Varnish Error 503 Service Unavailable" поставить рекламный баннер доход от него превысит доход от всех платных пользователей.

2. В 2015 году вы предлагаете платить деньги за юзерпики(!). Кто не знает, это - аватарки, мааааленькие такие картиночки. И платным пользователям разрешаете использовать до 30 (тридцати!!! юзерпиков!!!). При размере юзерпика в 40 килобайт максимум и цене в $10 за 40 дополнительных вы хотите снять с пользователя $10 за 1.5 мегабайта дискового пространства в год. Это примерно в 1 300 000 раз дороже чем если самому купить хард-диск соответствующего размера.

3. Купить место для фоточек невозможно не купив платный аккаунт, а изначально дается всего 1 Гб. Примерно 100 фоток можно залить в среднем качестве.

4. ЖЖ, когда не падает, работает. Но делает это откровенно медленно, настолько, что вспоминаются времена до-ADSL.

София, давайте по чесноку, вы действительно считаете что сервис образца 2005 года может быть более привлекателен чем Facebook только на основании того что там никого не банят? Это, кстати, ложь "http://navalny.livejournal.com/ -> ОШИБКА 451
На территории вашей страны просмотр этой страницы запрещен органами власти".

София, пару советов. Прежде чем предлагать перейти из ФБ в ЖЖ, хотя бы сделайте сервис стабильным. Черт с ними, с юзерпиками, все обходятся одним-двумя. Можно обойтись без картинок, для этого есть фоточки Яндекса. Но постоянные 503... - это для 2015 года перебор. И нет, не надо рассказывать что ЖЖ слишком сложен, что его невозможно переделать, что вас DDoS-ят каждый день. Facebook справился - значит, и вы справитесь, если хотите чтобы пользователи пошли из ФБ к вам.
me

Email list

Если вы прочли rfc и вздумали написать парзер списка адресов, у меня для вас очень плохие новости. Эти же плохие новости относятся к Dovecot и Communigate.

Мир намного сложнее стандартов, особенно учитывая наличие программистов на PHP и мега-CMS Drupal, Joomla и 1C Bitrix.

Да, надо следовать стандартам, но если вы пишете парзер, то следовать надо не стандарту, а реальности, иначе у вас вместо логина и домена очень часто будет nil или MISSING_MAILBOX/MISSING_DOMAIN.

Вы не сможете объяснить заказчику, что адрес Ivan <ivan@example.com> - валидный, а адрес .Ivan <ivan@example.com> - нет только на том основании что еще один PHP-джуниор не смог осилить rfc. Особенно, если ведущие почтовые сервисы спокойно обрабатывают битые адреса.

https://tools.ietf.org/html/rfc2822
https://tools.ietf.org/html/rfc5322
https://tools.ietf.org/html/rfc6532
https://tools.ietf.org/html/rfc6854

P.S. И, да. У Мэйлрушечки в парзере списка адресов баги. Хорошо, что в большинстве случаев они не проявляются, но тестировщики их должны были бы найти.

https://www.facebook.com/sloneus/posts/478702688947899
me

Про ZeroMQ

Спасено из тонущего поста ФБ.
https://www.facebook.com/oleg.i.tsarev/posts/10206505560627604

Участники: slonik_v_domene, lionet и zamotivator

Претензии к 0MQ:
- повторяя семантику BSD sockets не работает как BSD sockets;
- дескриптор 0mq нельзя передавать между потоками;
- оно глючит при/после коредампа или любого некорректного завершения одного из peer;
- криво построена работа в асинхронном режиме (все эти poll);
- течёт;
- по дизайну (!) не даёт делать прокси;
- по имплементации не рассчитано на слишком большое количество клиентов;
- по дизайну (!) не рассчитано на облака и доступ интернетных клиентов, только на fixed IP и всякий энтерпрайз подобный;
В общем, использовать это в продакшене = наживать лишний геморрой и седые волосы.

Отдельное замечание про паттерн REQ-REP:
Дело в том, что в 0mq REQ-REP принципиально нельзя работать иначе как вызывая read и write в четкой последовательности.

Отсюда проблема с ребутом: если процесс упал, есть 50% вероятности что данные не были записаны или прочитаны. После чего оно залипает и приходится гасить второй peer. Это все проходили в продакшене, проходили с большой кровью, что когда один компонент отваливался, надо было рестартить все остальные из-за того, что 0mq находилось не в том состоянии.

REQ-REP 0mq - ужасно неудобная вещь, пользовыаться ею как альтернативой BSD sockets нельзя.

В паттерне PUB-SUB этой проблемы уже нет. Но проблема в том, что когда ты все паттерны разберешь и поймешь, что тебе нужен только один, и он — самый сложный, самый нерекомендуемый докой на ømq, самый недодокументированный, и с самыми неочевидными преимуществами над обычными сокетами паттерн ROUTER-ROUTER.

Вообще, с 0mq работа выглядит примерно так: ты что-то делаешь, как правило - простые вещи. И они у тебя получаются быстро и просто.
Потом ты осознаешь что в проекте надо сделать каую-то простую и очевидную вещь, ну там между потоками передать дескриптор очереди.

И вот тут получается Drupal learning curve.
me

Вопросы на собеседованиях

Я вот понять одного не могу: чего добиваются интервьюеры на собеседованиях, когда задают вопрос из серии "реализуйте B/B+ дерево"?
В финском языке есть такое слово "myötähäpeä" - чувство стыда за другого человека. Вот когда я слышу на собеседовании подобное, мне, цЫничному гопнику, становится стыдно до состояния "пойти и удавиться шнурками кед".

Мне.

Становится стыдно.

Да, я сам вахуе.

Дорогие сениоры, техдиректоры и прочие системные архитекторы! Задавая подобные вопросы на собеседовании вы демонстрируете дремучесть студента 1-го курса института при зашкаливающей самооценке, рядом с которой Дейкстра, Керниган и Ричи - дети, едва изучившие BASIC. Сколько при этом котиков убивает господь, я судить не берусь, но думаю, что не меньше 9000 за раз.

Просто запомните, если не готовы сами повторить эксперимент: работоспособное B/B+ дерево начинается от 4000 строк кода. До этого момента это не дерево, а школьное поделие, ценность которого околонулевая с любой точки зрения. Дерево, которое поддерживает транзакции, требует по крайней мере 8000 строк кода (данные - про реализацию на С; но написанное актуально и для Java/C++). Добавление в дерево репликации, lock-free доступа обходится примерно в 3-5 тысяч строк для каждого изменения. Представьте себе, да: это - действительно сложный алгоритм. В любом случае это не тема ни для рисования алгоритма на собеседовании, ни даже для домашнего задания на несколько дней.

Если вы не верите написанному, велкам смотреть исходники SQLite, InnoDB и BerkeleyDB.

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

ФБ-копия поста - тут: https://www.facebook.com/sloneus/posts/476966385788196
me

О солдатиках и СССР.

Так вот. В тоталитарном СССР в 1983 году у меня были солдатики: красного цвета - наши, и зеленого - фашисты. Именно фашисты - со зверскими рожами и шмайссерами.
Потому, что даже пятилетнему ребенку очевидно, что наши с нашими не воюют, а воюют с фашистами. Очевидно это было и тем, кто этих солдатиков делал на заводе.
А тупые поцреоты и ханжи 2015 года, и все те говноеды что устраивают вой, пусть займутся автофелляцией и укусят себя за хуй.
me

В очередной раз о Хабре, мозгах и безопасности.

http://geektimes.ru/post/247794/

Нет повести печальнее на свете, чем повесть об идиотах с Хабры.
Здесь можно много чего обсуждать, но особо хотелось бы отметить следующее:

1. Отсутствие мониторинга происходящего. Хостинг в облаке не дает вам права забить на мониторинг своих проектов. И - нет, мониторинг не должен и не может работать с того же облака, которое мониторит. Более того: доступ к машине мониторинга с серверов облака - серьёзнейшая дыра в безопасности.

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

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

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

5. Общая глупость автора, как то: незнание английского языка _хотя_ бы на уровне написания жалобы в саппорт, нежелание найти в конторе (в которой он, на минутку, совладелец) человека, говорящего по-английскию

Теперь выводы.
1. Для работодателя и коммерческого партнера Хабра стала лакмусовой бумажкой. Нет более простого способа вычислить дебила, чем зайти на Хабру и поискать публикации потенциального работника или коллеги.

2. Облака на самом деле не упрощают работу. Они лишь позволяют автоматизировать некоторые действия. Но при этом облака остаются инструментом, который требует ответственного отношения, понимания как все работает, и главное - наличия средств объективного контроля за происходящим.

Обсуждение - здесь: https://www.facebook.com/sloneus/posts/456730424478459