Почему вы считаете, что высшее руководство и менеджеры — это инопланетяне? Это такие же жители бывшего СССР как и вы, которым как и вам может быть наплевать на компанию, наплевать на то как они зарабатывают деньги, чего они достигают в этом мире и какими (чьими?) усилиями.

Но вы так же должны понимать, что аргумент «всем наплевать и мне наплевать» уже не тянет. Вы же потом все-равно будете грустить, что никто (правительство, компания, друзья) о вас не думает. Пока сами не попадете в это самое правительство. Почему бы не начать изменения с СЕБЯ? Театр абсурда.

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

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

Русский разработчик в большинстве своем рассматривает себя как инструмент для использования других инструментов (кода, ИСР, ОС). Ему наплевать на то, что он своими инструментами в этой компании или этом мире достигает — ему важны только сами инструменты. Это как врач, которому наплевать на больницу, людей и болезни, ведь его «реальная» работа — использовать градусник. Или как пожарник, которому наплевать на пожары и людей в них, ведь его волнует только пожарный топор и методы его применения для открытия дверей в рушащихся зданиях. Или педагог, которому наплевать на детей, образование и родителей — ему нравится составлять учебные планы.

Проблема русских программистов именно в этом, а беда России в том, что эта проблема на программистах не заканчивается…

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

Но если Гугл официально сказал, что <… см. выше...>, то это скорее всего правда

Боже, какой же детский наивняк у человека. Выше ссылку привели. По закону Гугл в этом конкретном случае обязан врать всем — в целях «национальной безопасности». Вы как бы не забыли что NSA — это аббревиатура не для частной шарашки, а для «National Security Agency»? Включите логику — что легче и дешевле если вы — само государство? Потратить миллионы на системы взлома и обхода систем защиты или втихую приказать Гуглу и компаниям отдавать данные из рук в руки? Вот как бы да…

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

Какой-то рекламный буклет. Ни одного личного ощущения

Ни слова об экране, который по многим обзорам является слабой точкой в телефоне, с его углами обзора.

Добро пожаловать в

Блог компании Sony Mobile Communications

Duh!

Пожалуйста, не надо мне рассказывать что такое «TDD» и какие книги мне надо прочитать чтобы это понять. Ну вот, не надо…

Вы намешали вопрос проверки «правильности» кода и вопрос неизменности его поведения. Да, вы не можете доказать что кусок кода остался «100% верными», потому как даже с тестами вы не были на 100% уверены в его полной правильности. Фишка в том, что это никогда и не было важно. Вас интересовало другое — поведение.

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

Вот в вопросе «правильности поведения» и включается тестирование и рефакторинг — вы покрываете ту самую «спецификацию» тестами (ручными или автоматизированными) и только затем производите изменения в структуре, удостоверившись что они не ломают описанное в спецификации поведение. Это дает 100% уверенность, что ваш код все еще работает как вы и система того ожидаете! Работает ли он таким же образом в неизученных ситуациях? Возможно нет, но это абсолютно не важно :) А вот когда станет важно — вы расширите спецификацию.

Ну тут тогда идея в следующем — рефакторинг делаете не вы, а IDE. И вопрос как раз в том, тестируют ли эти автоматизированные рефакторинги разработчики IDE (скорее всего да) и насколько вы им в этом доверяете.

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

Спецификации они разноуровневые. Есть бизнес-спецификации (http://cukes.info, behat.org) для того чтобы описать поведение вашего приложения целиком с точки зрения бизнеса. И есть юнит-спецификации (http://rspec.info, phpspec.net) для того чтобы описать поведение внутрянки вашего приложения с точки зрения разработчика.

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

С 11кой сравнивайте:

И по умолчанию (при установке) он как раз таки ЗАПРЕЩЕН. Так?

По-моему он как раз и пытается сказать, что они всю интерфейсную часть Хромиума выломали и вставили свою, которая ни разу не мультиплатформенная.

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

Ну вы только что подтвердили мои слова. Вы мыслите о коде в плоскости «тактов», я мыслю в плоскости «что я хочу получить». Весь смысл конструкций в функциональном стиле как раз в том, что вам не нужно видеть реализации, чтобы понять что делает $method('getTitle'). Вот серьезно, не притворяйтесь что можете прочитать эту конструкцию как-то по-другому нежели «метод getTitle».

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

$itemsTitles = array_map($method('getTitle'), $items);
// $itemsTitles = ARRAY OF $items, MAPPED BY method getTitle




$itemsTitles = array();
foreach ($items as $item) {
    $itemsTitles[] = $item->getTitle();
}
// $itemsTitles = ARRAY
// for each $item in ARRAY OF $items
// append to $itemsTitles $item->getTitle()

Мне совсем не нравится эта бессмысленная фунция x(). Если уж ты начал делать DSL, основанный на функциях, то чего бы не идти до конца:

use collada\to_collection;
use collada\method;

$items = array_to_coll($items);

$itemsTitles = $items->mapBy(method('getTitle'));
$itemsTexts  = $items->mapBy(method('getText'));
$itemsDates  = $items->mapBy(method('getDate'));

$method = function($name) {
    return function($item) use($name) { return $item->$name(); };
};

$itemsTitles = array_map($method('getTitle'), $items);
$itemsTexts  = array_map($method('getText'), $items);
$itemsDates  = array_map($method('getDate'), $items);

vs.

$itemsTitles = array();
foreach ($items as $item) {
    $itemsTitles[] = $item->getTitle();
}
$itemsTexts = array();
foreach ($items as $item) {
    $itemsTexts[] = $item->getText();
}
$itemsDates = array();
foreach ($items as $item) {
    $itemsDates[] = $item->getDate();
}

Ксерокс не судится — поезд ушел уже давно, когда слово «ксерокопия» попало в словарь. Намного интереснее дела обстоят с Адоби, давненько читал, что они практически каждый год посылали «предупредительные» письма в большой английский словарь, чтобы те не смели включать слово «photoshoping» в их словари. Ибо если слово будет включено в словарь (будет принято общепризнанным обозначением), любой производитель автоматически заимеет возможность называть свой растровый редактор «best photoshoping experience ever». Почитайте, там много интересного.