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

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

• Будучи долгое время лидером на рынке, Нокиа сильно расслабилась и загадила свою внутреннюю инфраструктуру бюрократией, чрезмерным аутсорсингом и огромным количеством бесполезной «менеджерской прослойки».
• Будучи долгое время лидером, Нокиа просрала потратила много денег на ненужные операционные расходы, поглощения никому не нужных фирм и на невменяемую модель аутсорсинга.
• Полностью оторвавшись от реальности с уходом Йормы Оллилла, Нокиа, под управлением гениального юриста 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 тщательно проанализировали достоинства и недостатки более старших конкурентов перед тем как шагнуть вперед.

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

Меня очень интересует вопрос, почему в России очень плохо развита индустрия создания платного ПО.

Задавая этот вопрос своим друзьям, знакомым или просто ища ответ в Сети я приходил к неутешительным выводам.
Многие говорили что это связанно с тем, что в России очень плохо обстоит дело с защитой авторских прав, кто-то ссылался на то что зачем тратить деньги на разработку чего бы то ни было, если через несколько недель этот продукт взломают и в сети появятся бесплатные (взломанные) аналоги. А кто-то совсем пессимистичный говорил о том, что в нашей стране просто нельзя заниматься высокими технологиями.

За окном второе десятилетие 21 века, наши спутники бороздят просторы мирового океана, но разговор я заведу не о любимом Asterisk, а о старых добрых офисных мини-АТС в сравнении с IP-PBX аналогами. И прежде всего я расскажу, когда и почему (ИМХО) не стоит иметь с ними дело.

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

2 года назад я выступал на конференции CodeFest с темой «Пентест на стероидах. Автоматизируем процесс» и делал пересказ выступления в качестве статьи. В этом году я с большим удовольствием снова принял участие в конференции и выступил с темой «BlackBox тестирование безопасности клиент-серверного API» и, видимо уже в качестве традиции, также делаю пересказ выступления.

Уязвимости в API встречаются. Правда.

О чем разговор?

Разговор про API, но API бывает разным — API операционной системы, сайта, десктопной программы, да хоть чего. Вкратце — API это обращение к методам чего-либо (например в случае ОС — запись в файл) через определенный метод. И запуск какого-нибудь файла с т.ч. зрения разработки произойдет схожим образом (тоже через API метод ОС), хотя результат выполнения команды совершенно разный. В веб-технологиях многие тоже реализуют API к своим проектам, и если на пальцах: можно отправить сообщение в соц. сети зайдя на сайт, а можно — сформировав специальный HTTP запрос. И при реализации подобного альтернативного использования функционала допускаются (как и везде) ошибки в безопасности. Статья как раз о специфичных ошибках при реализации подобного функционала в веб-проектах.

Инструменты, которые мы будем использовать

Docker

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

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

Простой пример — это БД Redis. Если нам необходимо несколько серверов Redis на одном компьютере, при обычном подходе нам придется изменять конфигурационные файлы в /etc/redis и менять файлы в /etc/init.d. Можно написать bash скрипт, но это не делает процесс легче.

В статье будет рассказано о возможном применении xdebug системными администраторами web-серверов. Может показаться, что администратор не должен заниматься диагностикой и отладкой кода, поскольку это – работа программиста. Это так. Но, как, в случае возникновения проблемы, убедить программиста в том, что его код неоптимален (если это действительно так) и нуждается в переработке, если программист все время заявлет: «У нас все хорошо – чините сервер»? Представим, что это программист, с которым нежелательно спорить. Например, наш очень дорогой и возмущенный клиент.

Ввиду того, что во время Хабравстречи я рассказывал об 11 различных сценариях, естественно, мне хотелось бы на каждом из этих моментов остановиться подробнее. Другими словами, начиная с этой статьи я рассмотрю большинство моментов, о которых шла речь во время предыдущего доклада. Итак…
Относительно недавно мне в Windows Live Messenger задали несколько вопросов, связанных с делегированием административных полномочий в Active Directory. Однако, прежде чем переходить к самим вопросам по этой теме, я буквально в двух словах расскажу, что же собой представляет делегирование и для чего оно нужно.

Эта статья представляет собой хороший теоретический материал о TDD для тех, кто об этом ещё ничего не знает.

jQuery плагин Mailcheck (github) — клиентсайд проверка емейла на опечатки по заранее определённму списку (к примеру, наиболее популярных почтовых сервисов).

Демка | сорсы демки (jsfiddle)

По заявлению (en) авторов (Kicksend), сей плагин увеличил кол-во подтверждений емейла при регистрации на 50%.

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

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

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

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

Когда я говорю «дворецкий», я подразумеваю слугу, официанта или любой другой обслуживающий персонал. Т.е. персону, работа которой состоит в помощи, обслуживании, выполнении за Вас грязной работы и умении пропасть с глаз долой за мгновение до того, как Вам бы этого захотелось.

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