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

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

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

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

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

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

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

Опровержения компании сами по себе смешные — у них «нет бэкдоров». Откуда они взяли эти бэкдоры? Веризон был обязан сам заливать данные без всяких бэкдоров. Опровержений про слив я от Гугла собственно и не видел, только про бэкдоры.
everzet
+5
Какой-то рекламный буклет. Ни одного личного ощущения
Ни слова об экране, который по многим обзорам является слабой точкой в телефоне, с его углами обзора.

Добро пожаловать в
Блог компании Sony Mobile Communications
Duh!
everzet
+1
Пожалуйста, не надо мне рассказывать что такое «TDD» и какие книги мне надо прочитать чтобы это понять. Ну вот, не надо…
everzet
0
Вы намешали вопрос проверки «правильности» кода и вопрос неизменности его поведения. Да, вы не можете доказать что кусок кода остался «100% верными», потому как даже с тестами вы не были на 100% уверены в его полной правильности. Фишка в том, что это никогда и не было важно. Вас интересовало другое — поведение.

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

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

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

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

Для того чтобы полноценно спланировать и разработать успешное приложение вы не можете себя фиксировать только на бизнес или только на юнит уровне. Вам важно уметь говорить, понимать и описывать оба уровня на всем протяжении разработки.
everzet
–3
Рефакторинг в принципе невозможен без тестов. Если у вас код не покрыт тестами и вы его все-равно на живую правите, это называется как угодно, но не рефакторинг.
everzet
+4
everzet
+14
И по умолчанию (при установке) он как раз таки ЗАПРЕЩЕН. Так?
everzet
+30
По-моему он как раз и пытается сказать, что они всю интерфейсную часть Хромиума выломали и вставили свою, которая ни разу не мультиплатформенная.
everzet
+7
Говорю вам как программист повидавший виды в разных компаниях мира. Альтруизм — дело неблагодарное, неприбыльное, изматывающее и, наконец, несуществующее. Сегодня он «без вашего ведома на свой страх и риск» «отрефакторил все за ночь», а завтра пойдет искать другую контору, потому что на этой его не ценят и в нем не нуждаются.
everzet
0
Ну вы только что подтвердили мои слова. Вы мыслите о коде в плоскости «тактов», я мыслю в плоскости «что я хочу получить». Весь смысл конструкций в функциональном стиле как раз в том, что вам не нужно видеть реализации, чтобы понять что делает $method('getTitle'). Вот серьезно, не притворяйтесь что можете прочитать эту конструкцию как-то по-другому нежели «метод getTitle».
everzet
0
Ваши циклы легко читаемы только потому, что ваш мозг привык код интерпритировать, а не читать. Функциональный стиль, напротив, дает вам возможность «читать» смысл кода до его интерпритации мозгом или машиной. Попробуйте разобрать на состовляющие ваш мыслительный процесс в обоих случая. Я мыслю так:

$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()
everzet
+4
Мне совсем не нравится эта бессмысленная фунция 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'));
everzet
+2
$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();
}
everzet
0
Исходя из написанного в статье, для меня ваше «не более» уже черезчур.
everzet
+1
Знаете, иногда бывает трудно объяснить клиенту. Почему надо сделать проект дорого и медленно, вместо быстро не дорого.

Вся проблема как раз в том, что у вас:
результат почти одинаков.

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

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

И идут такие клиенты уже к истинным говнокодерам, студентам-любителям или к демпингующим индийцам.

То есть вы спасаете своих клиентов от говнокодеров, соглашаясь писать говнокод самостоятельно? В чем разница?
everzet
+3
Вы же должны понимать, что заказчики 2го типа существуют только потому, что есть «разработчики» вроде вас, которые соглашаются «запустить проект в эксплуатацию завтра» со «строго ограниченными финансами». Тепличные условия — это нормальный рынок, который вы сознательно обходите стороной по своему собственному решению.
everzet
+3
Все зависит от того, как вы эту «производительность» измеряете. Если в объеме кода, написанного в день, тогда вы действительно сильно быстрее любого программиста с серьезным опытом, включая меня. Если же мы начнем измерять объемы 100% рабочего, протестированного и расширяемого кода, который не стыдно передать другому разработчику, сравнение будет сильно не в вашу пользу. Всегда.
everzet
+3
Простите, а сколько времени и невров вы потом тратите на поддержку этого «решения за пару часов»? Самолет тоже можно собрать из бумаги за пару дней. Как на нем летать — вопрос другого порядка, правда?
everzet
+1
Ну я как бы и не утверждал обратного.

Это просто ответ на комментарии «PHP недостаточно быстро развивается» и «другие языки развиваются быстрее».

Есть разница между развитием и переделыванием. Python как раз переделали — получили 2 активно используемые, но практически несовместимые версии и сообщество, которое вот уже 4 года не могут заставить перейти на новую ветку.
everzet
0
Ага, развиваются: python3wos.appspot.com/ :)
everzet
–1
Axax. Ok :D
everzet
–4
Это не развитие, это бездумное копирование с задержкой в год. Я вижу тот же сири, только в другой обертке и никакого развития идеи. Ждем грядущей презентации нового айфона, затем целого года разговоров про «это нам не надо», потом снова бездумная копия и сравнительные замеры скорости.

Серьезно, это не развитие. Мне нравится продукция эпл, но я ненавижу то, что происходит с рынком вокруг нее. Вся индустрия будто разучилась думать. Честное слово, хочу увидеть продукт от Google, чтобы у меня отпала челюсть как от первого айфона. Первым бы побежал его покупать, но на выходе лишь те же самые айфоны и айпады в другой обертке.
everzet
–3
И да, никого больше не смущает, что мы не видим «гонки вооружений»? Что нет развития основанного на конкуренции? Это когда кто-то реализует какую-то идею, а другая компания берет эту идею за основу и делает что-то намного интереснее.

Что мы видим сейчас? Apple делает Siri, через почти год Google выпускает точно такой же Siri с немного измененным интерфейсом и разбором текста на девайсе. Не новый интерфейс построенный на голосовом управлении, не развитие идей, заложенных в изначальной идее, а просто копия в другой обертке. Я не вижу развития — я вижу как одна компания вводит инновации на рынке маленькими шажками каждый год а остальные только ждут результатов их работы, чтобы бездумно скопировать на своем стеке технологий.

Сугубое ИМХО.
everzet
–3
Вы так говорите будто это патенты заставляли Google разрабатывать это:
www.infinitezest.com/images/android-first-app-window.jpg

Патенты не работают, с этим никто не спорит. Но их применение в большинстве случаев обусловлено злостью, основанной на том, что через пол-года после выхода первого iPhone аппарат с первой картинки «плавно» трансформировался в:
thehottestgadgets.com/wp-content/uploads/2008/09/tmobileg1.jpg

Никто не спорит, что патенты — зло, которое вредит развитию индустрии. Но как по мне, так этой же индустрии не меньше вредят целые линейки продуктов, занимающихся простым копированием вместо попытки родить/попробовать что-то новое.
everzet
+1
> ни один большой проект на PHP тоже невозможно полноценно разрабатывать без современной IDE
Занимаюсь разработкой 2ух (Behat, Mink) и активным контрибутом в другой десяток очень крупных проектов (Symfony2, Composer, Doctrine2) на PHP через vim. Другие аргументы?
everzet
+1
Про джава проекты смотрим коммент выше.

Про разделение данных, конечно можно использовать десятки программ, которые в совокупности возможно сделают редактирование пакетной конфигурации проще, а можно просто отредактировать *.json файл в vim/textmate/notepad/sublime/anything_else.

Про DSL на PHP — как вы будете разбирать такие описания пакетов на центральном сервере (packagist?) не рискуя безопасностью? Почитайте мэйл-листы ребят с rubygems чтобы понять всю суть проблемы.
everzet
0
Речь про PHP. JAVA — отдельная история. Неоднократно слышал от джавистов что на джава писать без IDE невозможно. В виду этого, для джавы XML действительно может быть идеальным форматом для всего :) Ибо IDE, которая для многих (всех?) джавистов обязательна, будет автоматически компенсировать огрехи формата.
everzet
+6
Это к тому, что XML никогда в качестве формата конфигурации/описания пакетов не работал. Смотрим на PEAR — каждый крупный проект писал скрипт для билда xml описания пакета. Скрипт, который генерировал описание пакета, который использовался для создания пакета. И так делали все проекты с мало-мальски крупной базой кода.

Оно просто никогда не работало. Если вам кажется обратное, значит вы просто никогда серьезно этим не пользовались.
everzet
+15
Это у вас XML головного мозга. Если ваш IDE убирает все изначальное неудобство и нечитаемость XML, это не значит что XML резко становиться лучшим форматом для конфигов. Это лишь значит, что ваш IDE убирает все изначальное неудобство и нечитаемость XML (отжирая на это сотни мегабайт оперативы?).

JSON не идеальный формат. Изначально был разговор с Жорди и о yml и о DSL на чистом PHP, но ребята решили пойти по пути npm. И оно работает!

XML? Bitch, please:
github.com/symfony/symfony1/blob/1.4/data/bin/release.php
everzet
+1
Т.е. вы специально вяжете ActiveRecord на все объекты, которые хотите выводить в шаблоне, чтобы упростить ваши шаблоны?

Давайте теперь представим, что $category собирается в памяти, никуда не персистится и имеет структуру, которую я в начале привел. Что будете делать? Привяжете туда ActiveRecord или просто добавите публичные проперти, чтобы упростить шаблон?
everzet
0
Мои примеры абсолютно одинаковые. Twig автоматически заресолвит:

{{ category.metaInformation.name }}

В:

$meta = $category->getMetaInformation();
echo $meta['name'];

Или в:

echo $category->getMetaInformation()->getName();

В зависимости от того, что из себя представляет $category. Это и называется отделением логики от представления.
everzet
0
Давай предположим, что эта метаинформация — контейнер переменного размера, в который сущности системы могут помещать что угодно и когда угодно, помимо типичной информации типа «name». В этом случае, использование объекта для представления меты излишне, хэш для этого подходит куда лучше ;-)

Да, пример достаточно редкий, но не «невозможный».
everzet
0
То есть наличие чистого публичного API домена для вас — говнокод, а опубличивание пропертей домена с целью упрощения шаблонов — вариант «без говнокода». ОК!
everzet
0
Ах и да, часто вместо <?= $category->name ?> у вас будет что-то вроде:

<? $meta = $category->getMetaInformation(); ?>
<?= $meta['name'] ?>


Сравниваем:

{{ category.metaInformation.name }}
everzet
+4
<?php if ($category_tree && count($category_tree)): ?>
    <?php foreach($category_tree as $category): ?>
        <?= $category->name ?>
    <?php endforeach; ?>
<?php else: ?>
    No items in tree
<?php endif; ?>

Хоть както полегчало за счет этого <?= $category->name ?>?
Окей окей, у вас собственный VPS, где вы можете включить шорты на начало/конец блоков кода тоже:

<? if ($category_tree && count($category_tree)): ?>
    <? foreach($category_tree as $category): ?>
        <?= $category->name ?>
    <? endforeach; ?>
<? else: ?>
    No items in tree
<? endif; ?>

Наконец ваш шаблон читабелен и лаконичен, так?