• RBAC Авторизация в YII и LDAP
    0
    Да, это решает проблему.
  • RBAC Авторизация в YII и LDAP
    +1
    Гибкая система, но вот магический bizrul в виде php строки кода, который явно в eval уходит, немного покоробил. Вместо него напрашивается анонимная функция, но я думаю ребята во 2 версии это поправят.
  • Работа в PHP с Tokenizer
    0
    У меня обфускатор получился не более 80-100 строк кода. он, конечно, не идеален, но решает маркетинговые задачи не хуже готовых коробочных. учитывая, что при желании любой обфусцированный код можно деобфусцировать, а для сторонних решений есть уже готовые деобфускаторы, то простой обфускатор, использующий токинайзер более чем не плох:)
  • Работа в PHP с Tokenizer
    +1
    Еще одна возможность, которую обеспечивает токинайзер — написание простого обфускатора кода.
    Так же, есть мысль использовать его для анализа качества сторонних решений для коробочного продукта. Например, можно выявить, что разработчик из модели пытается обратиться к контроллеру или из контроллера напрямую взаимодействовать с бд (неймспейсы очень помогают в этом).
  • Новый PhpStorm 6.0 облегчает работу с Composer и другими инструментами
    0
    Спасибо за фикс youtrack.jetbrains.com/issue/WI-17397!
    Ждем 6.0.1
  • Новый PhpStorm 6.0 облегчает работу с Composer и другими инструментами
    0
    После обновления с 5 до 6 весь код в цепочном стиле подсвечивается не валидным, рефактринг такого кода тоже перестал работать. Всей командой не можем перейти с 5 на 6 из-за этой критичной баги. youtrack.jetbrains.com/issue/WI-15903
    Надеюсь вы ее поправите как можно быстрее.
    PS. других претензий к шторму нет — лучшая IDE на мой вкус
  • Comment from a drafted post.
  • Всосиску.ру — здесь встречаются друзья, места и скидки
    0
    Ну что, попьем пивка и обсудим ваш ресурс лично? ))
  • Всосиску.ру — здесь встречаются друзья, места и скидки
    +2
    Согласен, такими темпами личное присутствие при общении с родными начнут считать ретроградством. А зачем, если есть скайп и придумают какие-нибудь гаджеты — эмуляторы к нему?
    Что это за друзья, если они не могут встретиться и лично поговорить о жизни, это же намного приятнее.
    Передача изображения человека и его голоса никогда не заменят личного присутствия. Ну не буду я рассказывать о своих проблемах другу по скайпу, если есть возможность встретиться лично.
    Есть даже выражение «это не телефонный разговор» — или оно уже тоже устарело? )
  • Темная сторона кода
    +2
    … и его антогонист:
    Дарт-Продуман по несколько месяцев пишет прототип какой-либо простой фичи, усложняя и раздувая сложность реализации до вселенских масштабов. Пишет 100500 абстракций «на всякий случай». Прототип обычно готов, но фича уже не актуальна.
  • Не обманывайте своих заказчиков
    +1
    Написать идеальный код сразу (да и со временем) не возможно, но возможно написать тестируемый код. Если код возможно протестировать и эти тесты для него написаны, то код уже близкий к идеалу, так как его можно рефакторить и не бояться что отвалится пол системы.
    В том то и дело, что обычно хреновый код в долгий ящик кладут (работает — не трогай!), а код который покрыт тестами он «живой», он дышит…
  • Об идеальном коде и суровой реальности
    0
    А викторина к 8 марта — это ж вечный проект. 8 марта каждый год внезапно случается). Или каждый год новую писать? )
  • Об идеальном коде и суровой реальности
    0
    Ну да, главное чтобы все понимали что это только прототип. И не надо его завтра выкладывать в продакшн, хоть он и работает на первый взгляд =)

    А вообще, суровая реальность в том, что хороший проект делается со второго раза, ну или уж точно не с первого. Первый вариант — обкатка идеи, сбор требований и анализ ошибок. Потом все переписывается правильно.
  • Об идеальном коде и суровой реальности
    0
    > Допустим мы хотим проверить, насколько удобно воспользоваться API некого, возможного партнёра

    В этом случае проблем не вижу, в песочнице на дев-сервере попробовать можно и без TDD.
    Хотя, я не понимаю как вы убедитесь что оно работает как вы ожидаете. Ручками будете API методы вызывать и сверять с ожидаемым результатом? А если завтра обновленное API партнера вместо ожидаемого графика вам пришлет котиков?
    Как вы об этом узнаете? От клиентов? Как раз-таки в этом случае стороннего API без нормальной архитектуры и TDD вы далеко не уедете.

    > К некой дате нужно выпустить некий промо(викторина/розыгрыш), который день покрутится, а после будет забыт и удалён.

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

    PS. Во всем нужен здравый смысл и мера
  • Об идеальном коде и суровой реальности
    0
    Тема раскрыта не до конца. Рассматривается только суровая реальность написания кода для стороннего заказчика.
    Если заказчик — сама компания в которой ты работаешь (например, какой-нибудь SAAS) и поддерживать код и архитектуру, которую ты пишешь сейчас тебе предстоит годами, то я думаю вопрос о возможности говнокода, отказа от TDD и хороших практик тут вообще стоять не должен.
  • Автоматизированный рефакторинг в большом проекте
    0
    Да, чудес не бывает(
    Тут важна совокупность инструментов и процессов. Рефакторинг должен быть постоянным процессом и его нельзя откладывать «на потом».
    А чтобы его не откладывать на потом, нужно его не бояться. А не бояться возможно только при максимальном покрытии кода тестами.
    А это чаще всего чудеса, особенно на проектах, доставшихся в наследство.
  • Автоматизированный рефакторинг в большом проекте
    +5
    Ну практически все что вы описали может делать хорошая IDE'шка, причем намного удобнее «разруливать» конфликты, наблюдая непосредественный контекст вызова.
    Вообще, таким образом можно применить лишь очень ограниченный набор простых рефакторингов (Rename Class / Method и т.п.). Что-то более сложное, например «выделение класса», «замена кода типа» все равно придется вручную разруливать ибо страшно это доверять скрипту, даже с тестами…
  • Помните о реальном мире
    +3
    Если необходимо раздать все 500 призовых билетов в какой-то актуальный срок, когда не известно сколько вообще людей будут участвовать в лотерее, то можно действовать так:
    — берем промежуток времени, за который планируется раздать 500 билетов (для простого примера 100 часов),
    — делим его на маленькие промежутки (для простого примера 1 час),
    — в час у нас должны выйграть 5 билетов, раздаем их первым 5 счастливчикам (проверяя наличие кода в базе и помечая код как использованный),
    — если счастливчиков было меньше 5 (например 2), то в следующий час раздаем 7 билетов и так далее.

    Рандомность создает сам участник, попадая или не попадая в нужный промежуток времени )

    Кинотеатр заполнен, задача выполнена.
  • Добавление своего функционала в UMI.CMS при помощи обработчиков событий
    0
    По-моему даже у них есть недопонимание) Так как стандартная обработка 1С для Битрикса не подходит, у них самописная.
  • Добавление своего функционала в UMI.CMS при помощи обработчиков событий
    0
    Эх, если бы CommerceML был бы форматом, проблем бы не было!
    Сейчас же форматом его назвать не возможно, так нет схемы и описания. Точнее она есть, но давно не соответствует тому что отдает 1C(
    То что отдает 1С — это просто XML некого формата (спасибо хоть что well-formed), которая меняется / дополняется от версии к версии, что разрывает мозг разработчикам коробочных решений, заставляя их городить костыли.
  • Тестирование — это не поиск ошибок!
    0
    В идеале так и должно быть — изменения в одном модуле не должны сказываться на функциональности другого.
    На практике, конечно, такое не всегда возможно, но зависимости модулей можно учитывать.
    Например, изменения в компонентах, связанных с правами доступа (самое «ядерное» ядро) должны быть протестированы все модули, которые от него зависят — то есть практически вся система.
    А если вся команда «пилила» лишь функционал интернет магазина, то нет смысла (да и времени) тестировать модуль «Обратная связь».

    А вообще, в основной чеклист может быть занесено по одному — два не сложных теста каждого модуля, чтобы тестировщик хотя бы зашел в них и проверил живые ли они.
  • Тестирование — это не поиск ошибок!
    +3
    >… времени на их развитие уделяют меньше, что очень печально
    Очень печально что далеко не все тестировщики уделяют время на собственное развитие.
    Чтобы быть хорошим тестировщиком (ИМХО), надо иметь особый склад ума и характера и любить свою работу, постоянно изучая специалзированную литературу самостоятельно.
    Из своих знакомых я знаю только одного человека, которому действительно нравится тестирование и который посещает кучу конференций и растет профессионально. А так же знаю пару человек, кто в прямую говорят что занимается этим временно, и на самом деле это не особо интересно.
  • Тестирование — это не поиск ошибок!
    +3
    Счас кол-во минусов/плюса коммента даст более точную статистику =)
  • Тестирование — это не поиск ошибок!
    +1
    А чек-листы лучше составлять по каждому модулю, если система модульная. Это удобно. Можно прямо по репозиторию смотреть, изменили ли разработчики код модуля к текущему релизу. Если да, то, очевидно, нужно прогнать тесты этого чек-листа.
    Ну и должен быть глобальный чек-лист, который проверяется для КАЖДОГО релиза. Там должен быть самый главный и важный функционал, который ни в коем случае не должен сломаться.
  • Тестирование — это не поиск ошибок!
    +5
    Все что описано в статье, мне, как разработчику, очевидно. Надеюсь, для некоторых тестировщиков тоже.
  • Отчёт о попытке получить заявленную эффективность от prepared statements
    0
    Ну, на мой взгляд, все-таки увеличение производительности есть, просто оно не значительное и не там, где бы вам хотелось. Вы рассматриваете подготовленные запросы практически как хранимые процедуры.
    Если рассматривать что все-таки в рамках одного скрипта возможны одинаковые запросы. Например, если мы обновляем что-то на сайте и запускаем типовые INSERT/UPDATE.

    PS. спасибо за статью
  • Услуга «Привет» от Билайн или алгоритм незаметного списания денег с вашего счета
    0
    Если каждый человек будет заказывать платную детализацию по счету каждый месяц, может Билайн обогатиться и перестанет всякими ухищрениями красть списывать деньги абонентов?
  • Inline-тесты для PHP
    0
    Ну значит надо по любому зарефакторить такой публичный метод, он слишком много на себя берет. ну, например, применить к нему выделение стратегии и тестировать каждую стратегию изолированно и не зависимо от класса. Пусть одна зависит от синуса, другая от косинуса, третья от звезд на небе, на каждую будет нормальный тест.

    На практике еще никогда не возникало желания и необходимости тестировать приватные методы. На мой взгляд, в этом случае явный признак — проблема в архитектуре.
  • Inline-тесты для PHP
    0
    > А протектед-методы надо тестировать?
    Надо, через тесты на публичные методы конкретных реализаций класса

    >Абсолютно всё то же самое актуально и для публичных методов и даже для целых классов.
    Опубликованные методы и классы не так просто выпилить, особенно если ты не владеешь всем кодом проекта и публикуешь API. Тут поможет только deprecated и делегирование

    Ну да, спорить не буду, рефакторинг он разный… )
  • Inline-тесты для PHP
    0
    >С точки зрения моего класса, все его приватные методы являются открытыми для класса-обладателя.
    Конечно, ибо эти методы относятся только к нему и актуальны только для него. У наследника доступа нет, но есть своя реализация и приватные методы, ему нет дела до приватных методов своего родителя, потому что они его не касаются.

    >А если я напишу приватную функцию вычисления синуса?
    Раз она приватная, значит она нужна (касается) только для этого класса и он ее использует для своей реализации. Лучше протестировать то, для чего она используется. Завтра синус менеджеры заменят на косинус и в чем смысл теста?)

    При рефакторинге кода, написанные тесты на приватные методы составят незабываемое «удовольствие». Простейшее перемещение или изменение сигнатуры приватного метода доставит еще и кучу проблем с его тестами. В итоге, они просто будут скорее всего удалены, либо рефакторинг отложен со словами «ну вот, покрыл тестами, работает, да ну и фиг с ним, с дублированием кода».
    Приватные методы они на то и приватные, что в любой момент могут быть удалены, переписаны, дополнены, перемещены, раздроблены на более мелкие части. Если проект развивается здоровым путем, то это для него нормальная практика.
  • История создания интерактивной книги для iPad
    +4
    ну и почему отличная команда не может получиться из фрилансеров?
    Человеку, который собрал отличную команду из фриласеров — двойное уважение на мой взгляд.

    PS. зависть, плохое чувство.

  • Краткий обзор качества коммерческой CMS на Perl
    0
    Ага, не безопасно же)
    Интересно, а у себя то они его отключили, а то я смотрю такие настройки апача www.xforge.ru/images/ они не считают опасными )
  • Краткий обзор качества коммерческой CMS на Perl
    +3
    Посмешило многое на сайте горе-цмс, а особенно вот это:

    «Памятка системному администратору по вопросам профилактики от вирусов и паразитического софта:

    — Обязательное отключение поддержки PHP на Ваших серверах и зонах хост-провайдеров.
    Помните, что только при поддержке PHP можно извне завести Вам зловредный код без Вашей воли при неизвестных злоумышленику параметрах доступа по FTP»
  • Краткий обзор качества коммерческой CMS на Perl
    0
    может их ядро еще и блины печь умеет? )
  • Краткий обзор качества коммерческой CMS на Perl
    +2
    Джумла явно не самый лучший пример в данном случае.
  • Деобфускация PHP кода
    +4
    Самый смешной был случай, когда я понял что это утопия, это когда кто-то выложил разэнкоженный файл проверки лицензии продукта, который старательно энкодился зенд-гардом платным.
    Так в этом файле даже переносы строк были аккуратнее расставлены, чем в оригинальном ))))
  • Деобфускация PHP кода
    +6
    Это еще раз доказывает, что смысла в такой навороченной обфускации нет.
    Если кому-то понадобится очень, все равно напишет деобфускатор. А какой ущерб производительности от такой обфускации — вообще жесть, одни евалы чего стоят.
    У меня была задача сделать код проекта не читаемым. Долго искал обфускаторы php-кода, все слишком навороченные и многие просто не работают в режиме, когда есть часть кода обфусциорваная, а часть нет. В итоге, написал сам из 100 строчек, используя php-токинайзер и md5.
  • Критика UMI.CMS
    0
    Прекрасно вас понимаю, сам жду важных багфиксов.
    Всем хочется, чтобы важные именно для него баги были поправлены в кратчайшие сроки, но вы же, как разработчик системы должны прекрасно понимать, что приоритеты такие приоритеты…
  • Критика UMI.CMS
    +2
    Можно же запустить инсталлятор из консоли (CLI-режим), положив предварительно конфиг с параметрами установки и запускать это все одно командой. Да, придется подождать, пока все развернется и скачается несколько минут, но это же хорошо, можно идти пить кофе, думать о дальнейших действиях по проекту или почитать хабр, наконец )
  • Критика UMI.CMS
    +4
    >Извините, я не понял зачем ломать валидатор ради edit in place
    А никто его не ломает, он сам ломается) при чем тут edit in place? Конечно же можно вырезать эти атрибуты в режиме обычного посетителя, но это сразу минус производительности. Я бы рекомендовал юми сделать настройку, чтобы они вырезались простейшей регуляркой для тех кому это важно.

    >jQuery использует свои атрибуты вопреки стандарту. Но делает это в динамике.
    Нет, не вопреки, а именно ПО стандарту. И да, валидатор забивает на динамику и это опять же не правильно с его стороны. Т.е. если страница, которая проходит валидацию после отработки динамики не валидна, то грош цена такой «валидной» верстке.