Эта статья – о рисках смены руководства в больших компаниях и характерных явлениях при попытках игнорировать закон эффективного управления собственностью:

Эффективно управлять можно только той собственностью, которую мог бы создать сам.
Кто не может создать, – будет только разрушать!
И.А. Дедюхова, Кодекс Хамурапи

Картинка для привлечения внимания читателей из поколений Y и Z:

Краткое содержание

Новый директор себе в подчиненные и советники пригласит своих «проверенных людей». Увеличение штата топ-менеджеров в условиях фиксированного ФОТ повлечет за собой сокращение рядовых сотрудников на значительный процент.
Новый директор в первую очередь будет сокращать те подразделения, работу которых он не понимает. Под прессом психологического давления руководители этих подразделений возмут на себя обязательства самостоятельно разработать планы по сокращению и принять на себя все риски их реализации.
Сокращения пройдут под флагом повышения эффективности, но для «непонятных директору» подразделений не смогут сформулировать критерии этой эффективности, кроме «минимизации затрат». Цель по минимизации затрат без дополнительных обоснованных ограничений – это цель по уничтожению, и не имеет отношения к настоящей оптимизации.
Отсекая непонятные ему части компании (выводя в аутсорс и т.п.), директор попытается превратить компанию в ту, работу которой он полностью способен понять, которой он в полной мере способен управлять.
Проблему нехватки знаний в технической области новый директор и его команда компенсируют «помощью» от западных консалтинговых компаний. Это приведет к ситуации внешнего управления, причем без всякой ответственности за диктуемые извне решения.
Внешняя и внутренняя отчетность о работе компании до самого конца не будет показывать никаких признаков проблем, т.к. тому, кто принес плохие вести не выдают премию, а рубят голову.

---

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

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

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

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

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

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

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

Продолжение.

Начало здесь: Нейробиология и искусственный интеллект: часть первая — ликбез,
и здесь: Нейробиология и искусственный интеллект: часть полуторная – новости от Blue Brain Project.

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

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

И как же интеллект связан с деятельностью нейронов?

Коллеги, сегодня, первого августа, в Германии вступил в силу проект "Blue Card", позволяющий инженерам и в частности, IT специалистам получить возможность работать в Германии и Евросоюзе, при этом получить четырёхлетнюю визу с правом работы по упрощённой процедуре. Проект этот обсуждался довольно давно, но вот теперь получил официальное подтверждение. Он в общих чертах напоминает программу Green Card десятилетней давности, но есть несколько важных отличий.

В последние время на хабре по теме ИИ начали появляться сильно легковесные статьи, это точнее даже не про ИИ, а про философию ИИ. Причем такую философию, которая не ставит НИ КАКИХ принципиальных вопросов перед исследователями. Ну, скажем так это просто трёп за жизнь. И что удивительно такие статьи набирают некоторое количество плюсов.

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

Понятно, что такие статьи писали те кто даже близко не имеет соответствующего образования. Но не это главная причина появления подобных статей. Ведь они действительно публикуя такие статьи думают, что это может хоть как то направить исследователя, который имеет соответствующие образование. Я их разочарую — нет не направит, т.к. в статьях нет ни одной идеи куда. А происходит это (появление подобного трепа) от того, что им кажется, что исследователи сами не знают куда им развиваться. И это порой выглядит именно так. Даже в профессиональной среде ИИ-специалистов часто нет понимания какие задачи надо решать, нет так сказать «списка нерешенных ИИ-проблем», в отличии от математики. Книги часто содержат лишь методы решения задач, и практически ничего не говорят о задачах которые надо еще решить. Подрастающему поколению сложно поставить себе задачу, и они начинают фантазировать исходят только из слова «интеллект». Но все наверное забыли/(не знают?), что название «Искусственный интеллект» — это провокация, рекламный трюк — серьезные ученые не занимаются «сильным ИИ», и не потому, что его нельзя сделать, а потому как это не имеет технической постановки.

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

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

Я жутко хочу на это место

Свою первую работу в Кремниевой долине я получил благодаря прозорливости (с моей стороны) и отчаянию (со стороны первого работодателя). Мое резюме было коротко: четыре года в ВВС, конструирование аварийной защиты для ядерного реактора, стартап в Энн-Арбор (Мичиган) и, в общем-то, всё.

Во время работы во втором стартапе (Zilog) жизнь и карьера совершили интересный поворот. Меня нашел рекрутер (теперь он работает в маркетинге товаров) и захотел познакомить меня с руководством новой интересной организации, которая производила что-то под названием «рабочая станция». «Эта компания занимается развитием технологий, а твоя биография чудесна. Почему бы тебе не выслать мне резюме, я передам его.» Несколько дней спустя рекрутер перезвонил мне. «Стив, ты не заполнил графу образования. Где ты учился?»

«Я не закончил колледж,» — ответил я.

На другом конце трубки повисла тишина. «Стив, вице-президент отдела продаж и маркетинга раньше был руководителем технического отдела, он профессор информатики в Гарварде. До этого он работал в отделе передовых разработок исследовательского центра Xerox в Пало-Альто. Большинство в отделе продаж — бывшие инженеры. Я не могу представлять кандидата без диплома окончания колледжа. Сделай что-нибудь.»

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

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

Это обновленная версия устаревшего поста.

Этот пост покажет вам простые шаги по созданию менеджера задач TODO с использованием Ext JS, Ruby on Rails и Netzke. Это займет у вас приблизительно 7 минут, и если вам заранее любопытно, стоит ли оно того, загляните прямиком в секцию «Обсуждаем результаты» (кстати, самую большую). Наша цель заключается в создании веб-приложения которое позволит нам добавлять, редактировать и удалять задачи TODO, так же как и помечать их как завершенные. В дополнение к этому вы сможете сортировать задачи, делать поиск по ним, редактировать несколько задач одновременно — и это еще не все. Если хотите, засекайте время на секундомере — и давайте приступим.

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

На позицию CTO я пришёл не через стандартный путь “Developer -> Senior -> Team lead -> CTO”, а через гуманитарный вариант – “PM -> Senior PM -> CTO”. В этом были как свои плюсы, так и минусы, и трудно сказать, чего больше, но персональных вызовов хватало всегда и техническое прошлое часто спасало, однако, сейчас не об этом.

4. Вынужденные оценки

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

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

Просматривая одно из обучающих видео "Школы разработки интерфейсов" Яндекса, наткнулся на ссылку на офигенный труд израильской веб-программистки Тали Гарсиэль (Tali Garsiel) "How browsers work" (Как работают браузеры).

Она в течение нескольких лет отслеживала всю издаваемую информацию о внутреннем устройстве браузеров, изучала исходный код WebKit и Gecko и, в конце концов, собрала все воедино. Вот что пишет сама Тали:

Когда на 90% компьютеров был установлен IE, приходилось мириться с тем, что это загадочный «черный ящик», однако теперь, когда более половины пользователей выбирает браузеры с открытым исходным кодом, пришло время разобраться, что скрывается у них внутри, в миллионах строк программного кода на C++...

Пролистав, я был поражен — отличная работа. Внутреннее устройство браузеров, алгоритмы разбора — все хорошо иллюстрировано, доступно и понятно. И без излишних подробностей, страниц на 30-40. Как раз то, что нужно. Решил — это надо обязательно перевести. Покопался еще немного — оказалось перевод уже как 1,5 года есть!

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

Под катом содержание перевода, чтобы решить стоит ли читать.

Мне постоянно приходится слышать от студентов и начинающих гейм-дизайнеров – да, честно говоря, и от бывалых программистов тоже – один и тот же вопрос, который звучит примерно так: “Какую архитектуру AI мне выбрать для своего проекта?”. Этим вопросом пестрят форумы, его можно услышать на конференции разработчиков игр GDC, и, конечно же, его не один раз вспоминают во время пре-продакшна создатели любой игры – от AAA-класса до инди. Я работаю консультантом по игровому AI, поэтому я постоянно слышу ее от своих клиентов.

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

Волею судеб, запуская очередной проект, я столкнулся с достаточно интересным фактом.

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

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

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

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

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

Если ты всегда мечтал написать свой язык программирования — добро пожаловать. Здесь ты наверняка найдёшь для себя что-нибудь интересное.

GitHub-юзер yawnt собрал чудесную подборку ссылок для любителей драконов, языков и прочих вкусных внутренностей. А знающие камрады в комментариях наверняка поделятся с тобой и другими яствами.

Пишет yawnt следующее:

С каждым днём мне всё интереснее тема компиляторов, интерпретаторов и дизайна языков программирования в целом. И я решил поделиться с народом ссылками на собранные мной материалы (большую часть мне самому ещё предстоит прочитать :<). Надеюсь, кому-нибудь они окажутся полезными.

Я не включил (и не собираюсь) в список ссылки на официальную документацию, т. к. считаю очевидным, что первым делом следует смотреть именно туда ;P.

Опять понедельник, и опять что-то интересное у нас на столе в Box Overview! На этот раз — интеллектуальное зарядное устройство для Ni-Mh аккумуляторов типоразмера AAA и AA.
Почему интеллектуальное?


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

Привет, Хабр!

Меня всегда интересовал геймдев. Несколько лет назад я сделал шаг и окунулся в этот мир. Меня поражал успех Энгри Бердс (Angry Birds), взлёт и падение Зинги (Zynga), и одна мысль мне не давала спать — «Как же они сделали такие классные игры?».

Прошло немало времени, накопился ящик опыта, в закромах образовались какие-то отрывочные записи и комментарии. Я решил все структурировать и систематизировать, стараясь ответить на один из краеугольных вопросов — «Почему же пользователь вернётся в игру?».

Маркетинг сыграл с Raspberry Pi злую шутку.
Я изложу свой взгляд на эту плату, потому что неоднократно сталкивался с тем, что люди не понимают ее предназначения, пытаются применить ее не по назначению и разочарованно переключаются на другие ARM платы.
А тем временем Raspberry Pi — это очень важный шаг, которого до нее сделать не удавалось никому.