• Без математики или почему я плачу за чужой труд
    0
    Это вы приписываете разработчику мысль о том, что каждый потребитель должен окупить его расходы. В реальном мире такого нигде не наблюдается, кроме случаев, когда заказчик заказывает разработчику уникальную программу; в этом случае он платит упомянутые вами Y денег.

    Во всех других случаях стоимость продукта Y/N денег, где N — некая оценка минимального числа пользователей, которые купят копию. По сути вы утверждаете: «почему вы считаете, что вам должны платить Y? Получите Y/N и расслабьтесь!»
  • Без математики или почему я плачу за чужой труд
    +1
    Как-то вы странно Маркса прочитали. Дело в том, что очень мало кто может купить программу, оплатив труд программиста. Программа пишется иногда несколько лет, программист за это время заработал десятки тысяч долларов, но программа стоит, к примеру, всего сто долларов. Почему? Потому что продаётся множество её копий, за счёт этого каждую копию можно купить дешевле.

    Именно поэтому, например, ваш мобильник, продукт сложнейших технологий, стоит сотни, а не миллионы долларов. Потому что в разработку технологии вложились один раз, а изготовление копий обходится намного дешевле, чем разработка.
  • Эффективно уничтожаем информацию на жестком диске
    0
    Там и холодильник в одном из роликов жуют, брр…
  • Эффективно уничтожаем информацию на жестком диске
    +1
    Болгаркой опасно неоднородные субстанции пилить, дрель технологичнее.

    Имхо такой девайс имеет смысл только для тех, у кого действительно постоянный поток винтов под уничтожение.
  • Приходилось ли вам писать парсеры?
    –1
    Писал на PHP парсер сложных плейсхолдеров и условных блоков для SQL-запросов.
  • Эти бесчисленные парадигмы, концепции, инструменты и фреймворки
    0
    Как копипаст может быть вторичен, если он бесконтрольно размножает ошибки? Или вы Чак Норрис и никогда не ошибаетесь? :)

    Код есть код, его дублирование всегда порождало и будет порождать проблемы. Точно так же, как и тотальное наследование всего и вся, впрочем.
  • Эти бесчисленные парадигмы, концепции, инструменты и фреймворки
    0
    Пиписьками будем меряться или дело обсуждать? Даже онлайн-магазин — достаточно крупный проект, чтобы ощутить удушение копипаста в шаблонах.
  • Эти бесчисленные парадигмы, концепции, инструменты и фреймворки
    0
    И, кстати, лишнее доказательство того, что наличие шаблонизатора не отменяет необходимости думать. Ночной кошмар можно с равным успехом претворить в жизнь и на похапе, и на Смарти.
  • Эти бесчисленные парадигмы, концепции, инструменты и фреймворки
    0
    OMFG, ну это уже действительно порнография :)
  • Эти бесчисленные парадигмы, концепции, инструменты и фреймворки
    +1
    Ещё как нужны, причём именно наследуемые. Игра с внешним видом — это же основы маркетинга! В интернет-магазинах бывают различные акции и «сезоны скидок», бывают различные рекламные кампании — всё это требует оперативного переключения внешнего вида сайта (и, что ещё важнее — оперативной разработки оного!) Не следует понимать «скин» исключительно как возможность «поменять в личных настройках цвет форума с синенького на зелененький».

    Пожалуй, таки да, предвзято относитесь :) Но проблема действительно сложная. Хоть шаблон и программа, но способа добиться внятного полиморфизма от этой программы в общем-то нет…
  • Эти бесчисленные парадигмы, концепции, инструменты и фреймворки
    0
    Такой подход губителен в крупных проектах. Написание скинов превращается в кровавую оргию с копипастом. Да и в небольших проектах аккуратное точечное применение фрагментации позволяет упростить жизнь.
  • Эти бесчисленные парадигмы, концепции, инструменты и фреймворки
    0
    Вы про {php}? Там же его запретить можно, что и надо делать первым делом. А исполняемый код пусть в плагинах живет.

    Другое дело, что интеграция с фреймворками идёт гладко ровно до тех пор, пока работа шаблона ограничивается выводом переменных. Как только идём дальше (например, хотим использовать хелпер url в ZF для генерации URL) — начинается адский оверхед, каждому хелперу нужен прокси-плагин.
  • Эти бесчисленные парадигмы, концепции, инструменты и фреймворки
    0
    Шаблнизаторы — не панацея. Я много лет работал со Smarty и другими шаблонизаторами, потом вернулся к нативной шаблонизации. Не хотелось бы начинать холивар ради холивара, есть преимущества у обоих подходов, в том числе и множество преимуществ у нативной шаблонизации. Единственный безусловный минус — verbosity, это действительно раздражает.
  • Эти бесчисленные парадигмы, концепции, инструменты и фреймворки
    0
    Забавно, у меня имел место обратный процесс :) Я много лет был апологетом Smarty, а сейчас предпочитаю обходиться без него, а в качестве плюшек — ZF-овские view helpers. Да, синтаксис не слишком удобный, но зато на порядок меньше оверхеда при большей гибкости. Шаблонизатор отлично изолирует логику представления, но я в какой-то момент поймал себя на том, что зачастую эта изоляция дороговато обходится. Например, внедрять все хелперы в Smarty в качестве плагинов — дикий головняк, практической пользы от которого очень мало, если не отдавать проект на растерзание заведомым говнокодерам.
  • Эти бесчисленные парадигмы, концепции, инструменты и фреймворки
    0
    Респект.

    Насчёт 1.4 — тут такая фишка: шаблон — это тоже программа. Даже голый HTML является программой отображения страницы в браузере. В шаблонах голый HTML разбавлен дополнительными инструкциями, формирующими — сюрприз! — логику представления. Естественно, эта логика решает задачи типа «вывести в таблице список значений», а не делает SQL-запросы к базе. PHP для этого вполне подходит, другое дело, что такой подход требует определённой дисциплины.
  • Тонкости (странности?) работы с интефейсами
    0
    Для интеграции несовместимых интерфейсов существует паттерн "Адаптер". А объект-логгер должен быть контейнером для объектов-адаптеров с обобщенным интерфейсом. Даже в отсутствие конфликта интерфейсов нормальный проектировщик поступит именно так в целях масштабируемости. «Минимизация количества классов» — не та цель, за которую стоит воевать. Классов должно быть столько, сколько необходимо для реализации грамотной архитектуры.

    Я считаю, что если возникает проблема «конфликтующих интерфейсов», то это явный результат грязных хаков и плохой архитектуры.
  • Эти бесчисленные парадигмы, концепции, инструменты и фреймворки
    +4
    Задачи, где «старое доброе процедурное программирование» действительно (а не по причине плохого знания ООП разработчиком) эффективнее ООП, редки и нетривиальны, если речь, конечно, не о helloworld'ах и не о простых скриптах на коленке, в которых время решения непосредственно кореллирует с количеством набранных символов.

    Единственная здравая мысль — про шаблонизацию родными средствами PHP, остальное представляет собой смесь словоблудия и «вредных советов».
  • Как я объяснил жене, что такое REST
    0
    Входящая в состав русского корня.
  • Как я объяснил жене, что такое REST
    +2
    Во-первых, не только («адъютант», «трехъярусный»). Во-вторых, допускается использование при транскрипции иностранных имён и названий (недавнего японского премьера звали Коидзуми Дзюнъитиро, например).
  • Тонкости (странности?) работы с интефейсами
    0
    Это же стандартные интерфейсы :) А я про сторонние.
  • Как я объяснил жене, что такое REST
    0
    +1 А даже если бы читалось, как у автора, писать по-русски нужно было бы «Ръян», а не «Рйан».
  • Тонкости (странности?) работы с интефейсами
    0
    У меня не получается представить ситуацию, в которой мне пришлось бы реализовывать в одном классе два сторонних интерфейса. Можете привести более-менее реалистичный пример?
  • Какими платежными системами вы пользуетесь?
    0
    Так-так, всё ясненько :)
  • Какими платежными системами вы пользуетесь?
    0
    +Payoneer, Paxum, ePayService.
  • Какими платежными системами вы пользуетесь?
    0
    Нет, я тоже пользуюсь.
  • Тонкости (странности?) работы с интефейсами
    0
    Мне кажется, проблема надуманная. Если два интерфейса обладают одним и тем же методом, который служит для одного и того же, то этот метод скорее всего должен быть унаследован от некоего абстрактного интерфейса по логике вещей. В противном случае такого просто быть не должно, если серьезно подходить к именованию методов, т.е. чтобы название метода однозначно говорило, что он делает.

    Надо отметить, что в 5.4 у traits будет возможность разрешать конфликты и переименовывать методы; но надо понимать, что trait — это не интерфейс, задачи у этих механизмов разные.
  • Одержимость красивым кодом, синдромом рефакторинга
    0
    Красивый — это тот, который не обладает дурным запахом по Беку/Фаулеру, если мы говорим о рефакторинге. За официальным списком «вонючек» — в литературу, плиз, и лучше бы туда заглядывать до того, как встревать в обсуждение теории, с которой вы незнакомы.
  • Одержимость красивым кодом, синдромом рефакторинга
    0
    Топик-то вроде про рефакторинг, а не про coding standards :))) Какие рефакторинги по Фаулеру унифицируют отступы, ну-ка расскажите мне.

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

    Хорошо хоть в матанализе выше порог входа, чем в программировании, а то там, наверное, такой же бардак царил бы.
  • Одержимость красивым кодом, синдромом рефакторинга
    0
    А бывает код без отступов и без названий переменных? Мы сейчас ведь не об институтских курсачах?

    Красота кода как цель рефакторинга определяется его понятностью. Это достигается как правильным форматированием, так и правильной архитектурой. И вы заявляете, что при работе над кодом абсолютно неважно, понятен он или нет? Снимаю шляпу.

  • Одержимость красивым кодом, синдромом рефакторинга
    0
    А вы, пардон, под красотой кода что понимаете?
  • Одержимость красивым кодом, синдромом рефакторинга
    0
    Вы читали или нет, честно скажите? Просто чтобы понимать. Сентенции вроде «вместо прозрачного объяснения был введён мутный термин» наводят на мысль, что нет, и, возможно, мы просто о разных вещах говорим в этом случае.

    У задачи написания кода есть только одна плоскость, и методология рефакторинга предназначена для неё и только для неё. Взаимодействие с заказчиком — плоскость совершенно другая, и совершенно непонятно, зачем за уши перетягивать методологию из одной плоскости в другую. Заказчик в общем случае не должен знать про существование рефакторинга, так же как не должен знать синтаксиса языка, на котором пишется для него продукт, или знать о существовании ID и средств отладки, и даже о самом процессе отладки. Но почасовая работа — это не общий случай, такая модель подразумевает, что заказчик является экспертом. Если у вас возникают проблемы с тем, чтобы обосновать заказчику необходимость рефакторинга, вероятно, вы просто избрали неверную модель взаимодействия с ним.
  • Одержимость красивым кодом, синдромом рефакторинга
    0
    Полный взрыв мозга.

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

    Я замучился уже поминать Фаулера в этом топике, но у меня складывается ощущение, что никто из собравшихся тут — ни комментаторы, ни даже автор топика — его не читали. Доходит до «давайте разберемся, что такое рефакторинг, давайте дадим определение». У него ведь все написано — и определение, и методика проведения, и ответ на вопрос «что говорить начальнику», и многое другое.
  • Одержимость красивым кодом, синдромом рефакторинга
    0
    Почему? Рука не поднимается править?..
  • Одержимость красивым кодом, синдромом рефакторинга
    0
    Обычно имеют в виду рефакторинг в терминологии Фаулера, цитирую: «Р. есть изменение во внутренней структуре ПО, имеющее целью облегчить понимание его работы и упростить модификацию, не затрагивая наблюдаемого поведения». Если после «локального рефакторинга» приходится переписывать юнит-тесты, то это уже не рефакторинг. При рефакторинге юнит-тесты либо остаются неизменными, либо рефакторятся параллельно с кодом (если мы, например, изменяем название метода или переносим его в другой класс).
  • Одержимость красивым кодом, синдромом рефакторинга
    0
    Я, конечно, прошу пардону, но ключевые публикации по обсуждаемым темам вышли еще в начале двухтысячных, а на дворе 2011-й.

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

    Да, таки иногда нужно потратить 10 часов, чтобы сделать код более понятным, перед тем, как добавить новую фичу. А иногда и не 10 часов, иногда несколько недель, зависит от фичи. А иногда вовсе не нужно или нужно, но полчаса — возможно, автор топика именно это имел в виду. Но в целом топик отдает бессмысленным резонёрством. Люди либо умеют работать, либо не умеют, и рефакторинг тут в целом ни при чём.
  • Одержимость красивым кодом, синдромом рефакторинга
    0
    Раньше — это когда? До 1992 года, когда Бек с Фаулером взялись за перо?
  • Составление запросов со сложными условиями
    0
    Приведенный в статье пример скорее тянет на хак, нежели на образец кодирования. Мне кажется, более правильным было бы написание своего объекта, позволяющего конструировать сборку OR-условий, и подставлять его в where(). Там кода-то с гулькин нос будет, можно даже вот это всё порно из статьи инкапсулировать и сделать код читаемым.
  • Какой PHP фреймворк вы используете? И почему?
    0
    Использую самописную CMS на основе ZF, или «чистый» ZF, или его фрагменты — в зависимости от задач.
  • Применение алгоритмов нечеткого поиска в PHP
    0
    Точка перед знаком равенства не имеет смысла, так как дописываем к пустой строке.
  • Составление запросов со сложными условиями
    0
    Согласен с высказавшимися выше, что пример похабный. Читабельность кода сильно страдает.
    Справедливости ради надо отметить, что в ZF чрезвычайно дебильно реализован конструктор запросов. В том числе и расширять его неудобно.