Антон Прусов aprusov

Да, это решает проблему.

Гибкая система, но вот магический bizrul в виде php строки кода, который явно в eval уходит, немного покоробил. Вместо него напрашивается анонимная функция, но я думаю ребята во 2 версии это поправят.

У меня обфускатор получился не более 80-100 строк кода. он, конечно, не идеален, но решает маркетинговые задачи не хуже готовых коробочных. учитывая, что при желании любой обфусцированный код можно деобфусцировать, а для сторонних решений есть уже готовые деобфускаторы, то простой обфускатор, использующий токинайзер более чем не плох:)

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

Спасибо за фикс youtrack.jetbrains.com/issue/WI-17397!
Ждем 6.0.1

После обновления с 5 до 6 весь код в цепочном стиле подсвечивается не валидным, рефактринг такого кода тоже перестал работать. Всей командой не можем перейти с 5 на 6 из-за этой критичной баги. youtrack.jetbrains.com/issue/WI-15903
Надеюсь вы ее поправите как можно быстрее.
PS. других претензий к шторму нет — лучшая IDE на мой вкус

Ну что, попьем пивка и обсудим ваш ресурс лично? ))

Согласен, такими темпами личное присутствие при общении с родными начнут считать ретроградством. А зачем, если есть скайп и придумают какие-нибудь гаджеты — эмуляторы к нему?
Что это за друзья, если они не могут встретиться и лично поговорить о жизни, это же намного приятнее.
Передача изображения человека и его голоса никогда не заменят личного присутствия. Ну не буду я рассказывать о своих проблемах другу по скайпу, если есть возможность встретиться лично.
Есть даже выражение «это не телефонный разговор» — или оно уже тоже устарело? )

… и его антогонист:
Дарт-Продуман по несколько месяцев пишет прототип какой-либо простой фичи, усложняя и раздувая сложность реализации до вселенских масштабов. Пишет 100500 абстракций «на всякий случай». Прототип обычно готов, но фича уже не актуальна.

Написать идеальный код сразу (да и со временем) не возможно, но возможно написать тестируемый код. Если код возможно протестировать и эти тесты для него написаны, то код уже близкий к идеалу, так как его можно рефакторить и не бояться что отвалится пол системы.
В том то и дело, что обычно хреновый код в долгий ящик кладут (работает — не трогай!), а код который покрыт тестами он «живой», он дышит…

А викторина к 8 марта — это ж вечный проект. 8 марта каждый год внезапно случается). Или каждый год новую писать? )

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

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

> Допустим мы хотим проверить, насколько удобно воспользоваться API некого, возможного партнёра

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

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

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

PS. Во всем нужен здравый смысл и мера

Тема раскрыта не до конца. Рассматривается только суровая реальность написания кода для стороннего заказчика.
Если заказчик — сама компания в которой ты работаешь (например, какой-нибудь SAAS) и поддерживать код и архитектуру, которую ты пишешь сейчас тебе предстоит годами, то я думаю вопрос о возможности говнокода, отказа от TDD и хороших практик тут вообще стоять не должен.

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

Ну практически все что вы описали может делать хорошая IDE'шка, причем намного удобнее «разруливать» конфликты, наблюдая непосредественный контекст вызова.
Вообще, таким образом можно применить лишь очень ограниченный набор простых рефакторингов (Rename Class / Method и т.п.). Что-то более сложное, например «выделение класса», «замена кода типа» все равно придется вручную разруливать ибо страшно это доверять скрипту, даже с тестами…

Если необходимо раздать все 500 призовых билетов в какой-то актуальный срок, когда не известно сколько вообще людей будут участвовать в лотерее, то можно действовать так:
— берем промежуток времени, за который планируется раздать 500 билетов (для простого примера 100 часов),
— делим его на маленькие промежутки (для простого примера 1 час),
— в час у нас должны выйграть 5 билетов, раздаем их первым 5 счастливчикам (проверяя наличие кода в базе и помечая код как использованный),
— если счастливчиков было меньше 5 (например 2), то в следующий час раздаем 7 билетов и так далее.

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

Кинотеатр заполнен, задача выполнена.

По-моему даже у них есть недопонимание) Так как стандартная обработка 1С для Битрикса не подходит, у них самописная.

Эх, если бы CommerceML был бы форматом, проблем бы не было!
Сейчас же форматом его назвать не возможно, так нет схемы и описания. Точнее она есть, но давно не соответствует тому что отдает 1C(
То что отдает 1С — это просто XML некого формата (спасибо хоть что well-formed), которая меняется / дополняется от версии к версии, что разрывает мозг разработчикам коробочных решений, заставляя их городить костыли.

В идеале так и должно быть — изменения в одном модуле не должны сказываться на функциональности другого.
На практике, конечно, такое не всегда возможно, но зависимости модулей можно учитывать.
Например, изменения в компонентах, связанных с правами доступа (самое «ядерное» ядро) должны быть протестированы все модули, которые от него зависят — то есть практически вся система.
А если вся команда «пилила» лишь функционал интернет магазина, то нет смысла (да и времени) тестировать модуль «Обратная связь».

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

>… времени на их развитие уделяют меньше, что очень печально
Очень печально что далеко не все тестировщики уделяют время на собственное развитие.
Чтобы быть хорошим тестировщиком (ИМХО), надо иметь особый склад ума и характера и любить свою работу, постоянно изучая специалзированную литературу самостоятельно.
Из своих знакомых я знаю только одного человека, которому действительно нравится тестирование и который посещает кучу конференций и растет профессионально. А так же знаю пару человек, кто в прямую говорят что занимается этим временно, и на самом деле это не особо интересно.

Счас кол-во минусов/плюса коммента даст более точную статистику =)

А чек-листы лучше составлять по каждому модулю, если система модульная. Это удобно. Можно прямо по репозиторию смотреть, изменили ли разработчики код модуля к текущему релизу. Если да, то, очевидно, нужно прогнать тесты этого чек-листа.
Ну и должен быть глобальный чек-лист, который проверяется для КАЖДОГО релиза. Там должен быть самый главный и важный функционал, который ни в коем случае не должен сломаться.

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

Ну, на мой взгляд, все-таки увеличение производительности есть, просто оно не значительное и не там, где бы вам хотелось. Вы рассматриваете подготовленные запросы практически как хранимые процедуры.
Если рассматривать что все-таки в рамках одного скрипта возможны одинаковые запросы. Например, если мы обновляем что-то на сайте и запускаем типовые INSERT/UPDATE.

PS. спасибо за статью

Если каждый человек будет заказывать платную детализацию по счету каждый месяц, может Билайн обогатиться и перестанет всякими ухищрениями красть списывать деньги абонентов?

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

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

> А протектед-методы надо тестировать?
Надо, через тесты на публичные методы конкретных реализаций класса

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

Ну да, спорить не буду, рефакторинг он разный… )

>С точки зрения моего класса, все его приватные методы являются открытыми для класса-обладателя.
Конечно, ибо эти методы относятся только к нему и актуальны только для него. У наследника доступа нет, но есть своя реализация и приватные методы, ему нет дела до приватных методов своего родителя, потому что они его не касаются.

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

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

ну и почему отличная команда не может получиться из фрилансеров?
Человеку, который собрал отличную команду из фриласеров — двойное уважение на мой взгляд.

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

Ага, не безопасно же)
Интересно, а у себя то они его отключили, а то я смотрю такие настройки апача www.xforge.ru/images/ они не считают опасными )

Посмешило многое на сайте горе-цмс, а особенно вот это:

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

— Обязательное отключение поддержки PHP на Ваших серверах и зонах хост-провайдеров.
Помните, что только при поддержке PHP можно извне завести Вам зловредный код без Вашей воли при неизвестных злоумышленику параметрах доступа по FTP»

может их ядро еще и блины печь умеет? )

Джумла явно не самый лучший пример в данном случае.

Самый смешной был случай, когда я понял что это утопия, это когда кто-то выложил разэнкоженный файл проверки лицензии продукта, который старательно энкодился зенд-гардом платным.
Так в этом файле даже переносы строк были аккуратнее расставлены, чем в оригинальном ))))

Это еще раз доказывает, что смысла в такой навороченной обфускации нет.
Если кому-то понадобится очень, все равно напишет деобфускатор. А какой ущерб производительности от такой обфускации — вообще жесть, одни евалы чего стоят.
У меня была задача сделать код проекта не читаемым. Долго искал обфускаторы php-кода, все слишком навороченные и многие просто не работают в режиме, когда есть часть кода обфусциорваная, а часть нет. В итоге, написал сам из 100 строчек, используя php-токинайзер и md5.

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

Можно же запустить инсталлятор из консоли (CLI-режим), положив предварительно конфиг с параметрами установки и запускать это все одно командой. Да, придется подождать, пока все развернется и скачается несколько минут, но это же хорошо, можно идти пить кофе, думать о дальнейших действиях по проекту или почитать хабр, наконец )

>Извините, я не понял зачем ломать валидатор ради edit in place
А никто его не ломает, он сам ломается) при чем тут edit in place? Конечно же можно вырезать эти атрибуты в режиме обычного посетителя, но это сразу минус производительности. Я бы рекомендовал юми сделать настройку, чтобы они вырезались простейшей регуляркой для тех кому это важно.

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