Из этой проблемы формируются две гадости: во-первых правила долго писать, во-вторых по ним искать сложно. Попробуем пойти нестандартным путем и решить проблему, сделав роли более селективными.
read more »
Для начала определимся с тем, что мы делаем. Обычно наш продукт состоит из:
Начнем с конца, пропустив бессоные ночи.
О том, что где-то рядом живут sed, grep, awk и pipelines, я узнал еще года 4 назад, но использовать (с толком) их не приходилось. Пока не захотелось странного…
Dog-pile эффект — ситуация когда кэш протухает, а большое количество запросов генерирует высокую нагрузку на источник данных, из которых строиться кэш. read more »
Навеяно парой статей на Хабре, и тем, что вчера сделал cache тег для Macro.
read more »
Version 0.4
Передо мной в данный момент стоит задача сравнить популярные бытрые хранилища данных, основанные на использовании оперативной памяти. Найденные сравнения(например, вот это) не совсем подходят, так как необходима информация не только о скорости get/set операций, но и о add/delete (их предполагается использовать для создания мьютексов).
read more »
То о чем так долго говорили большевики…
Кратенько:
А теперь подробно…
read more »
Вроде бы все всё знают, но почему не все всё используют? Меньше кода, хорошего и разного? Или читаемость все таки теряется?
Больше:
$id = $request->getId();
if(!$id) {
return false;
}
Меньше:
if(!$id = $request->getId()) {
return false;
}
Немного снижает читаемость кода. Если переменная используется за пределами ветвления (после него), то применять такой подход не стоит.
Больше:
if($id) {
return $id;
} else {
return false;
}
Меньше:
return ($id) ? $id : false;
Читаемость нисколько не снижается. ИМХО их и объединять можно:
$a = ($a) ? a : ($b) ? $b : 'default';
Больше:
function resolveArray($params) {
if(array_key_exists('foo', $params)) {
return $params['bar'];
}
}
Меньше:
function resolveArray2($params) {
extract($params);
if(isset($foo)) {
return $bar;
}
}
или
function resolveArray3($params) {
list($foo, $bar) = $params;
if(isset($foo)) {
return $bar;
}
}
Использование extract – несколько порочная практика, ибо непонятно откуда переменные берутся. Использование list’а в этом плане лучше, но он завязан на порядок следования элементов…гад.
Поэтому в больших методах лучше все таки вытаскивать “ручками”:
function resolveSomeArrayInformation3($params) {
$foo = array_key_exists('foo', $params) ? $params['foo'] : false;
$bar = array_key_exists('bar', $params) ? $params['bar'] : false;
if(isset($foo)) {
return $bar;
}
}
, ибо можно нормальные значения по умолчанию задавать и наглядность не теряется. А если писать влом, то используйте возможности вашей IDE (она же позволяет использовать шаблоны, правда?).
Больше:
$count = count($array);
for($i = 0; $i < $count; $i++) {}
Меньше:
for($i = 0, $count = count($array); $i < $count; $i++) {}
Вполне нормально для меня, для остальных, говорят, не очень.
Больше:
for($i = 0; $i < 10; $i++) {
$str .= $i;
}
Меньше:
for($i = 0; $i < 10; $str .= $i++);
Тоже самое, что и в предыдущем.
Больше:
$current_letter = substr($str, $i, 1);
Меньше:
$current_letter = $str{$i};
Читаемость лучше, однозначно стоит применять.
Функциональное тестирование – процесс, в ходе которого, готовая программа проверяется на соответствие требованиям того на чьи деньги мы пьем кофе. Главная задача функционального тестирования – говорить, либо “странно, но ты ничего не сломал”, либо “я так и знал, теперь чини”.
Функциональное тестирование называют также тестированием “черного ящика”, то есть тесты, в идеале, не должны ничего знать про тестируемую систему. Это позволит менять разработчиков архитектуру, язык приложения, базу данных.
Функциональное тестирование для web-сайтов подразумевает эмуляцию работы конечного пользователя: открытие страниц, переход по ссылкам, заполнение и отправка форм, проверка значений полей форм, наличие определённого текста на страницах, получение почты, отправку файлов, а также попытки взлома, и кривизну рук.
Например, есть форма регистрации. Для каждого из заполняемых полей мы должны проверить все граничные условия, даже самые извращённые. В итоге получается по 2-3 проверки на поле.
После этого мы должны проверить, что нам пришло “правильное” письмо, не пришло неправильных.
Из за использования метода addRecipient(), вместо setRecipient(), у класса PHPMailer, мы однажды разослали 15 000 писем нашим пользователям. По 50-70 штук на каждую невинную жертву. Если бы тест проверял наличие лишних писем, то все бы было хорошо, а так – по башке получили. Хорошо хоть в спам-лист не попали.
Часто функциональное тестирование выполняется специально натренированным человеком со стойкой психикой и любовью к механической работе. Его вооружают листочком с описанием теста и ограждают от окружающего мира, так как не понятно, как он отнесётся к программисту, из-за ошибки которого, ему пришлось опять полностью обходить весь сайт. Ошибаться этот тестер не должен, так как если ошибка пройдет в релиз, ее увидят все, и время ее исправления будет зависеть от ее близости к основным пользовательским “маршрутам”. Такой подход с легкой руки сослуживца получил название wiki-тестирование.
Есть два больших лагеря продуктов для функционального тестирования:
Первые немного ущербны даже идеологически, так как браузер это неотъемлемая часть веб-приложений. То есть то, что тесты проходят, совершенно не гарантирует, что приложение будет работать у конечных пользователей. Но их высокая скорость позволяет использовать их для простых задач, типа определения “битых” ссылок.
Среди вторых хочется отметить Selenium, который уже стал стандартом де факто, для автоматизации функционального тестирования веб-приложений, ибо:
Продолжение следует…
То ли мне спам-боты надоели, толи просто решил сделать что-то большое и чистое. В итоге размышлений родились мысли. Первая, о том, что хочется есть, а вторая, что думать надо усердней. Стал думать усердней, и набросал несколько вариантов защиты:
Тут все относительно просто. Достаточно выделиться из серой массы, и количество ботов снижается почти до нуля. Пример: на странице регистрации можно присваивать id-шникам input’ов случайные значения, подписи к ним выводить с помощью JavaScript, и между некоторыми вставлять поддельные input’ы. Дополнительно можно проверять время заполнения формы, и нажатие клавиш.
Вот несколько способов пришедших на ум.
Найти на картинке, покрытой мелкими треугольниками, овалами, и прочими линиями квадрат, и указать его цвет.
Указать пол человека, изображенного на фотографии.
Если придумаете, то, пожалуйста, скажите мне . Только гугловский поиск по медиа-контенту не предлагайте, так как он не очень релевантный.
Собирание пазла.
Вывод простой – серебрянной пули, как всегда, не получилось, но идея с пазлом мне нравится.