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

Традиционно, для тех кто не любит много буков, краткие (более-менее) тезисы:

• Будучи долгое время лидером на рынке, Нокиа сильно расслабилась и загадила свою внутреннюю инфраструктуру бюрократией, чрезмерным аутсорсингом и огромным количеством бесполезной «менеджерской прослойки».
• Будучи долгое время лидером, Нокиа просрала потратила много денег на ненужные операционные расходы, поглощения никому не нужных фирм и на невменяемую модель аутсорсинга.
• Полностью оторвавшись от реальности с уходом Йормы Оллилла, Нокиа, под управлением гениального юриста CEO Олли-Пекки Каласвуо, потратила кучу денег и усилий на создание бесполезной и неконкурентоспособной сервисной инфраструктуры Ovi. В результате этого, помимо денег, Нокиа потеряла уйму полезного времени, которое можно и нужно было потратить на развитие основного бизнеса — телефонов, софта и т.д.
• Бюрократия и непотопляемая менеджерская прослойка в Нокиа, последовательно мигрировала из одного передового проекта в другой, в составе одних и тех же групп лиц, самореплицируясь в виде кучи формальных дебилопроцессов комитетов и управленческих групп, немного перетасовываемых с учетом специфики. В итоге именно эта бюрократия убила и Symbian, и Ovi, и MeeGo и остальные попытки догнать уходящий поезд своими силами.
• Борьба с бюрократией и прослойкой в Нокиа зашла в полный тупик.
• У великого CEO Элопа просто не было другого выхода кроме как прибить всю старую, неповоротливую и прогнившую организацию, путем создания альянса с Майкрософтом и переходом на Windows Phone. Тем самым все старые процессы, компетенции, технологии и самое главное — люди резко стали, что называется, «не в тему». И следовательно тем самым можно было под благовидным предлогом прибить этот табун менеджеров, бесконечно рисующих фэнтезийные роадмапы с единорогами и перекладывающих бумаги с левого края стола на правый.
• Новая Нокиа, после 2011 года и старая Нокиа до 2011 года – это две РАЗНЫЕ организации. Их объединяет только общее название и операционка S40 для телефонов Asha.
• Горящая платформа, это не Symbian и не MeeGo. Горящая платформа, это то состояние в которое Нокиа загнали годы расслабленного лидерства и тупоголовые амбиции предыдущего CEO – Олли-Пекки Каласвуо с кликой подкаркивающих вице-президентов.
• С бюрократией и бизнес процессами, имеющимися на 2010 год, Нокиа не спас бы ни Андроид, ни половина населения Бангалора, пишущих на Qt под MeeGo. Даже если бы Apple бесплатно передал Нокиа iOS и все сервисы, то они бы выродились руками всяких Requirement Managerов в типичные Нокийские дизайн-химеры и в итоге загнулись через какое-то время.
• То, что сделал великий CEO Элоп – было единственно возможным разумным решением, дающим хоть какие-то шансы на выживание. Вопрос «каким образом он это сделал?», остается открытым, равно как и вопрос «поможет ли это Нокиа?» в итоге. Не следует забывать, что нынешняя Нокиа — это совершенно новая организация, поэтому глупо предполагать, что она разом вернет себе лидерство. Как и всем новым организациям ей придется за это лидерство долго бороться.
• Без ошибок и побед Нокиа никогда не было бы ни Андроида, ни Айфона. И Google и Apple тщательно проанализировали достоинства и недостатки более старших конкурентов перед тем как шагнуть вперед.

Все это в деталях — под катом. Предупреждаю что клевых картинок там нет. Сплошное графоманство и ёрничанье.

Компания Google вчера опубликовала разъяснение по поводу ослика, которого заметили на фотографиях Street View в Ботсване (ссылка). Компания провела расследование и подняла архивы снимков из этой африканской страны. В официальном блоге Google Maps сотрудники развеяли все опасения пользователей и опубликовали доказательства, что ослик остался жив.

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

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

Компания использует разные способы получения прибыли в зависимости от страны. Если для рынка США стратегию можно описать коротко «экстремально дешевые принтеры, дорогие картриджи», для рынков СНГ и азии она немного другая — «дорогие принтеры, дорогие картриджи».
На мой взгляд, причины такой разной политики — в менталитете людей в разных странах.

Робот PhantomX от Trossen Robotics обладает впечатляющей гибкостью и подвижностью и способен бегать со скоростью около одного метра в секунду. Он работает под управлением Arduino-совместимого контроллера, и может управляться дистанционно с пульта или компьютера. Робот уверенно передвигается по пересечённой местности.



Стоимость комплекта для сборки робота составляет 1200 долларов.

9 октября должен был состояться прыжок с высоты 36 километров, который отложили на несколько дней из-за сильного ветра.

И если верить обратному отсчету на официальном сайте проекта, то прыжок должен состояться вот-вот: 14 октября, 19:15 МСК на момент написания топика. О переносах буду писать ниже.

Прямая трансляция уже началась и продлится примерно 4 часа. Так что запасаемся попкорном и смотрим либо на сайте Redbull Stratos, либо напрямую с канала на youtube.

Добрый день, хабраюзеры.

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

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

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

Жизнь мальчиков с математическими способностями в атомных городах была предопределена — школа с пятерками по алгебре и геометрии, мех-мат столичного университета, возвращение в систему, квартира через год, кандидатская степень в 40 лет, ВАЗ 2103 к пятидесяти годам, звание доктора, гараж, шесть соток, четыре квадратных метра.

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



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

С давних времён я был большим поклонником System.Collections.Concurrent и BlockingCollection в особенности. Сколько раз это чудо инженерной мысли выручало в самых разнообразнейших ситуациях — не счесть.

С чуть менее давних времён в обиход прочно вошли async/await. Казалось бы, жизнь прекрасна, но есть одно «но»: асинхронный код миксовать с блокирующим кодом как-то не очень-то хочется. А BlockingCollection, как несложно догадаться (хотя бы из названия), в ряде случаев поток блокирует.

Пусть мы хотим вычислить десятимиллионное число Фибоначчи программой на Python. Функция, использующая тривиальный алгоритм, на моём компьютере будет производить вычисления более 25 минут. Но если применить к функции специальный оптимизирующий декоратор, функция вычислит ответ всего за 18 секунд (в 85 раз быстрее):


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

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

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


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

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

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

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

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

Для сведения: Во многих упоминаниях данной статьи авторы ошибочно называют меня сотрудником Opera Software. На самом деле я ушёл из Opera больше года назад и сегодня работаю в новой компании — Vivaldi Technologies AS

Обновление от 12 мая
После более тщательного исследования проблемы совместно с F5 выяснилось, что тест, используемый для обнаружения серверов F5 BigIP, показывал более высокие числа, чем это должно быть, поэтому количество подобных серверов оказалось при проверке завышенным. Это означает, что соответствующая информация о серверах BigIP и выводы неверны, поэтому я вычёркиваю главу, посвящённую серверам BigIP. Приношу извинения F5 и их клиентам за эту ошибку.

Предыстория

Как я уже рассказывал в моей предыдущей статье, несколько недель назад в библиотеке OpenSSL была обнаружена уязвимость (CVE-2014-0160), получившая громкое название "Heartbleed". Данная уязвимость позволяла злоумышленникам добывать такую важную информацию, как, например, пользовательские пароли или закрытые ключи шифрования сайтов, проникая на уязвимые «защищённые» веб-серверы (поясняющий комикс).

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

Сколько было сломано копий при обсуждении вопроса «Возможно ли сделать eval безопасным?» — невозможно сосчитать. Всегда находится кто-то, кто утверждает, что нашёл способ оградиться от всех возможных последствий выполнения этой функции.
Когда мне понадобилось найти развёрнутый ответ на этот вопрос, я наткнулся на один пост. Меня приятно удивила глубина исследования, так что я решил, что это стоит перевести.

Коротко о проблеме

В Python есть встроенная функция eval(), которая выполняет строку с кодом и возвращает результат выполнения:

assert eval("2 + 3 * len('hello')") == 17

Это очень мощная, но в то же время и очень опасная инструкция, особенно если строки, которые вы передаёте в eval, получены не из доверенного источника. Что будет, если строкой, которую мы решим скормить eval'у, окажется os.system('rm -rf /')? Интерпретатор честно запустит процесс удаления всех данных с компьютера, и хорошо ещё, если он будет выполняться от имени наименее привилегированного пользователя (в последующих примерах я буду использовать clear (cls, если вы используете Windows) вместо rm -rf /, чтобы никто из читателей случайно не выстрелил себе в ногу).

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

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

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

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

Знакомьтесь, это обычный «литровый» пакет молока:

• Проверка на внимательность: там 900 грамм. Рядом несколько по 950. Но пакет может быть воспринят как литровый.
• Проверка на знание физики. Рядом лежит похожий кефир. Объём измеряется в миллилитрах, масса — в граммах. Плотность кефира трагически выше плотности воды. То есть 900 грамм кефира 3,2% жирности — это примерно 874,5 миллилитров.

Второй пациент:



25 лет гарантии. Круто, правда? Есть одна проблема. Надо сохранять чек. Проверка, опять же, на знание физики. Чек у них печатается на обычной кассовой термоленте (я проверил на месте). У меня в офисе лежит много чеков. Мы их ксерокопируем, потому что через год-два они полностью выцветают. Самый старый чек, который видел коллега, держался 3 года в папке в архиве. UPD: смотрите самый низ топика, Икея ответила.

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

Осторожно, трафик: под катом много находок с фотографиями.

Недавно kuznetsovin опубликовал пост об использовании Питона для анализа временных рядов в экономике. В качестве модели была выбрана «рабочая лошадка» эконометрики — ARIMA, пожалуй, одна из наиболее распространенных моделей для временных данных. В то же время, главный недостаток АRIMA-подобных моделей в том, что они не приспособлены для работы с нестационарными рядами. Например, если в данных присутствует тренд или сезонность, то математическое ожидание будет иметь разное значение в разных участках серии — , что не есть хорошо. Для избежания этого, АRIMA предполагает работать не с исходными данными, а с их разностью (так называемое дифференцирование — от «taking a difference»). Все бы хорошо, но тут возникают две проблемы — (а) мы возможно теряем значимую информацию беря разницу ряда, и (б) упускается возможность разложить ряд данных на составляющие компоненты — тренд, цикл, и т.п. Поэтому, в данной статье я хотел бы привести альтернативный метод анализа — State Space Modeling (SSM), в русском переводе — Модель Пространства Состояний.

Некоторые из вас, вероятно, видали на просторах сети эту задачку: какое число продолжает следующий ряд?

Предлагался такой очевидный правильный ответ:

Для тех, кому неочевидно, как он получен, предлагалось объяснение. Пусть (ну и 1 при x = 0, хотя неважно). Тогда каждый член ряда — это значение следующего интеграла в цепочке:

Пока всё идёт хорошо, но тут внезапно:

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

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

Что же всё-таки можно нарисовать с помощью всего двух треугольников? Квадрат? Фрактал? Полёт сквозь мегатонной мощности взрыв в центре города? Есть ли предел безумию, где заканчивается реальность и начинается явь? Как правильно ухаживать за лучами, чем их кормить и обо что отражать вы узнаете во внезапном продолжении цикла статей про демомейкинг!

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

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

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

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