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

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

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

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

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

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

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

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

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

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

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

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

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

    Для того чтобы полноценно спланировать и разработать успешное приложение вы не можете себя фиксировать только на бизнес или только на юнит уровне. Вам важно уметь говорить, понимать и описывать оба уровня на всем протяжении разработки.
  • О стартапе-ловушке, или Роберт Мартин хочет нам навредить
    –3
    Рефакторинг в принципе невозможен без тестов. Если у вас код не покрыт тестами и вы его все-равно на живую правите, это называется как угодно, но не рефакторинг.
  • Браузер Yandex
  • Браузер Yandex
    +14
    И по умолчанию (при установке) он как раз таки ЗАПРЕЩЕН. Так?
  • Браузер Yandex
    +30
    По-моему он как раз и пытается сказать, что они всю интерфейсную часть Хромиума выломали и вставили свою, которая ни разу не мультиплатформенная.
  • Красной таблетки не существует
    +7
    Говорю вам как программист повидавший виды в разных компаниях мира. Альтруизм — дело неблагодарное, неприбыльное, изматывающее и, наконец, несуществующее. Сегодня он «без вашего ведома на свой страх и риск» «отрефакторил все за ночь», а завтра пойдет искать другую контору, потому что на этой его не ценят и в нем не нуждаются.
  • Colada — удобная работа с коллекциями
    0
    Ну вы только что подтвердили мои слова. Вы мыслите о коде в плоскости «тактов», я мыслю в плоскости «что я хочу получить». Весь смысл конструкций в функциональном стиле как раз в том, что вам не нужно видеть реализации, чтобы понять что делает $method('getTitle'). Вот серьезно, не притворяйтесь что можете прочитать эту конструкцию как-то по-другому нежели «метод getTitle».
  • Colada — удобная работа с коллекциями
    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()
    
  • Colada — удобная работа с коллекциями
    +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'));
    
  • Colada — удобная работа с коллекциями
    +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();
    }
    
  • Zend Framework, субъективные впечатления
    0
    Исходя из написанного в статье, для меня ваше «не более» уже черезчур.
  • Zend Framework, субъективные впечатления
    +1
    Знаете, иногда бывает трудно объяснить клиенту. Почему надо сделать проект дорого и медленно, вместо быстро не дорого.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Оно просто никогда не работало. Если вам кажется обратное, значит вы просто никогда серьезно этим не пользовались.
  • Composer — менеджер зависимостей для PHP
    +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
  • <? if: ?>Используете ли вы <?=шорттэги?> в темплейтах<? endif ?>
    +1
    Т.е. вы специально вяжете ActiveRecord на все объекты, которые хотите выводить в шаблоне, чтобы упростить ваши шаблоны?

    Давайте теперь представим, что $category собирается в памяти, никуда не персистится и имеет структуру, которую я в начале привел. Что будете делать? Привяжете туда ActiveRecord или просто добавите публичные проперти, чтобы упростить шаблон?
  • <? if: ?>Используете ли вы <?=шорттэги?> в темплейтах<? endif ?>
    0
    Мои примеры абсолютно одинаковые. Twig автоматически заресолвит:

    {{ category.metaInformation.name }}
    

    В:

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

    Или в:

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

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

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

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


    Сравниваем:

    {{ category.metaInformation.name }}
    
  • <? if: ?>Используете ли вы <?=шорттэги?> в темплейтах<? endif ?>
    +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; ?>
    

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