Всякие интересные штучки для WEB-разработчика

Основой безопасности любого приложения является простое правило: «пришедшим от пользователя данным доверять нельзя». Для этой цели пишется довольно большое количество кода, хотя типичные задачи можно решить стандартными средствами PHP ничего не изобретая.

Например, таким образом можно проверить адрес e-mail при помощи filter_var:

if (filter_var($user_email, FILTER_VALIDATE_EMAIL)) {
// правильный
}

также можно убрать лишнее, например, из URL:

$sanitized_url = filter_var($url, FILTER_SANITIZE_URL);

Хотя filter_var() есть в стандартном PHP начиная с версии 5.2.0, документация на него, особенно русская, хромает.

Нормальная документация и примеры:
— Руководство w3schools.
— Input Validation: Using filter_var() Over Regular Expressions.
— Data Filtering Using PHP’s Filter Functions

Какую таблицу из двух выбрать для своей базы данных в случае использования UTF?

utf8_general_ci
Убирает все акценты и приводит к верхнему регистру: ÀÁÅåāă = A, ü = U.
Не очень точно отрабатывает при сортировках. Иногда полезно при поиске. Быстрее utf8_unicode_ci.

Подходит для Русского. При использовании Белорусского и Украинского сортировка будет не верной.

utf8_unicode_ci
Довольно точно при сортировке и поиске. Например, ß (немецкий эсцет) будет при сортировке располагаться рядом с ss, как ему и положено. Медленнее utf8_general_ci.

Замечательно подходит для Русского, Белорусского и Украинского.

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

Полные таблички utf8_unicode_ci и utf8_general_ci (там, кстати, и все остальные есть).

Setting up master-master replication in MySQL is very similar to how we set up master/slave replication. There is obviously pros and cons about using master/master replication. But this is not a post which discuses advantages and disadvantages for using master/master replication. One of the differences between master/master set up and master/slave is that in master/master set up, you have true redundancy. If one server dies, second server can take all the inserts/selects. In master/slave setup, if master dies, you will have to go through steps to make slave become the master. Master/master set up we are going to set up is essentially master/slave and slave/master. Meaning, if you had two servers, db0 and db1, your setup will be db0(master)/db1(slave) and also db0(slave)/db1(master). Here are some assumptions:

Master1 server ip: 10.0.0.1
Master2 server ip: 10.0.0.2
Slave username: slaveuser
Slave pw: slavepw
Your data directory is: /usr/local/mysql/var/

Read the rest of this entry »

Часто необходимо запускать что-то (например полный бекап бд) раз в месяц, но в выходной, допустим в ночь с субботы на воскресенье.

Это можно сделать в crontab следующим образом

0 23 * * 6 [`date "+%d"` -lt 8] && /path/to/script

Это запустит скрипт в первую субботу месяца в 23:00.

MySQL Performance Tuning Primer Script
http://www.day32.com/MySQL/
http://www.day32.com/MySQL/tuning-primer.sh

This script takes information from “SHOW STATUS LIKE…” and “SHOW VARIABLES LIKE…”
to produce sane recomendations for tuning server variables.
It is compatable with all versions of MySQL 3.23 and higher (including 5.1).

Read the rest of this entry »

This document serves as a starting point for MySQL performance tuning. This document is a combination of research and experience. When I started this document, I utilized a great Google video [1] as a reference for the document structure and many bullet items. I would suggest watching this video. I then filled in a few blanks, and combined a few other articles into this overview.

You may also want to check out this good article from MySQL on performance tuning.. Now onto the show..

Benchmarking

As with all improvement activities, it is better to start with a known problem area that is able to be defined, or an activity where improvement will provide maximum benefit (the 80/20 rule works everywhere). Nobody can really grasp an intangible goal like “we want to achieve excellence” [4].

The following are decent guidelines to start with [1]:
» Target. You must have a target.
» Establish a baseline.
» Change only one thing at a time (if possible).
» Record Everything, you will need it at some point.
» Optionally disable query_cache, by setting query_cache_size = 0 for benchmarking.

Read the rest of this entry »

Созданием разделов и файловых систем на них дело подготовки дискового пространства к использованию не заканчивается. Все созданные файловые системы нужно еще сделать доступными для FreeBSD. Для чего они должны быть смонтированы — то есть включены в единую иерархию каталогов и файлов, для обозначения которой также используется название файловой системы. Однако если раньше речь шла о физической организации данных, то теперь пора ознакомиться с ее логикой.
Логика файловой системы

Логически файловая система FreeBSD (как и любой Unix-системы) организована по древовидному принципу: в основании ее лежит корень (корневой каталог, обозначаемый символом / и именуемый также root-каталогом; последнее не должно путать с каталогом /root, который выполняет роль домашнего для суперпользователя). От корневого каталога, который можно уподобить скорее стволу дерева, отходят ветви — вложенные в него подкаталоги, и побеги — обычные файлы. Последних, правда, немного: в версиях FreeBSD 5-й ветки это пара профильных файлов — /.cshrc и /.profile, на самом деле дублирующие профильные файлы суперпользователя (в каталоге /root), некий энтропийный (/entropy) файл и файл с описанием авторских прав на систему /COPYRIGHT. Read the rest of this entry »