.article | Автоматический Бакап MySQL

Терял ли ваш хостер когда-нибудь ваши данные? Нет?! Ну тогда мы идём к вам! Всё, на самом деле, многим проще: я просто расскажу как обезопасить себя от потери данных вашей милой хостинговой компанией. Для этого нам понадобиться:

• Шелл Логин — одна штука
• Доступ к Cron Tab — одна штука
• Немножко Мозгов — немножко

Далее всё делается по чёткому плану. Для начала надо вытащить все данные из СУБД и запихнуть их в файл. Далее этот файл надо заархивировать. Потом свежий архивчик надобно аккуратненько отправить на мыло «параноика». Итак, будучи людьми официально образованными, разобьём задачу на две части:

Jun. 28, 2005 // 16:41 | Комментарии (3)

.archs | CMS Tables

Пока мне лень делать что-либо полезное, решился-таки накатать пару строк по построению фреймворков CMS. Начну, пожалую, с зарисовки простой, но, тем не менее, довольно гибкой структуры СУБД для поддержки структуры и контента сайта. Для начала хотелось бы определиться с возможным набором задач:

Jun. 09, 2005 // 16:06 | Комментарии (10)

.thought | Privacy

Гугл всё больше и больше принимает статус персонализированной информационной машины. С одной стороны — это волшебно: с помощью Гугл Хистори можно рыться в собственных запросах за последний эээ… последнюю жизнь; Гугл Десктоп — канфета, необходимая каждому уважающему себя человеку; Гугл Мейл — вообще почтовая сказка, да и хранилище для файлов из него получается просто отменное. Всё хорошо, конечно, но мало кто задумывается о том, что о конкретном человеке теперь узнать что-либо становится всё проще и проще. Так, например, в случае если я вдруг решу метнуться в сторону активного терроризма, то на меня можно будет собрать нехилое досье лишь с помощью информационных активов Гугла. Этический вопрос, однако.

Nota Bene, а если же покопаться в audioscrobbler, то можно узнать мои музыкальные вкусы и разработать тонкий план воздействия на неустойчивую психику ;)

Jun. 08, 2005 // 17:50 | Комментарии (2)

.note | So...

За несколько часов стало вполне возможным накидать минималистичный дизайн. Одно «но» — срочно необходима здравая критика, ибо проект обещается быть большим и хотелось бы с ходу попать в точку. Эх, нам бы 27 часов в сутках.

Jun. 07, 2005 // 21:29 | Комментарии (11)

.note | Triggers

Я не знаю, как можно жить на СУБД без триггеров. Это же просто божественно. Возможностей не счесть! Ну а самое главное в том, что полностью соблюдается концепт отделения логики хранения данных от бизнес логики приложения. Сразу воявилась мысль — а может сделать InTerra Pro на PostgreSQL? ;)

Jun. 01, 2005 // 18:52 | Комментарии (9)

.though | RuNet DNS

Найти хороший домен в рунете довольно сложно. Однако, прежде, чем я буду бросаться столь дерзкими заявами, хотелось бы прояснить что есть в народе хороший домен. Думается мне вот что:

• Имя домена должно легко запоминаться, а значит должно быть созвучным.
• Домен должно быть возможно продиктовать по телефону не прибегая к познаковой диктовке, отсюда следует, что в нём лучше избегать неоднозначных латинских букв, таких как:
  • C, K 
  • W, V 
  • X, H 
• Нежелательно смешивать в имени домена цифры и буквы.

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

Это всё теория, конечно, ибо на практике я уже несколько суток голову ломаю ;)

Май. 09, 2005 // 22:05 | Комментарии (22)

.article | Nested Sets в PostgreSQL

Вопрос посадки деревьев в реляционной СУБД ранее решался мной на MySQL. Работала эта шняга вполне успешно, за исключением нескольких неприятных моментов, а точнее:

• В корне нарушенный концепт 3х-уровневой архитектуры приложений. Ибо логика хранения данных пересекалась с бизнес логикой приложения.
• Симуляция трансакций при работе с данными

А потому моя скромная особа перенесла мутированный концепт вложенных множеств в СУБД PostgreSQL в виде User Defined Functions. Работать с данными стало более чем приятно, ибо целостность всех индексов автоматически контролируется СУБД. Более того, все операции по пересчёту индексов и кешей проводятся в трансакционном порядке. Если же к этим массовым приятностям добавить обертку в виде класса на PHP5, которая автоматом отлавливает возможные SQL Exceptions в блоках try{}catch{}, то жизнь вообще начинает казаться маслом.

Apr. 20, 2005 // 22:05 | Комментарии (8)

PostgreSQL Trees

Пришло озарение, что при работе с древовидными структурами в реляционных СУБД, таких как PostgreSQL, встроенные функции — штука полезная и незаменимая.

Например, в целях массовой оптимизации я храню весь путь до какой-либо ноды в отдельном поле «path_cache» (не столько путь по id, сколько реальный путь, ибо это древо для работы с ЧПУ). Проблема, естественно, в том, что при переносе части дерева или изменениях в родителе этот путь надо снова пересчитывать. Что делать, Мама?

Да всё просто, описываем свою функцию get_path(integer), которая смотрит наличие уже просчитанного пути в поле path_cache. Если путь ещё не просчитан (при любых переменах просто даём полю значение NULL), то мы запрашиваем его и записываем в это поле. В итоге запрос к СУБД выглядит «как обычно», а на заднем плане имеет место быть постоянная проверка данных на целостность.

И будет всем щастя.

Apr. 17, 2005 // 13:55 | Комментарии (0)

.note | Moore's Law

Среднестатистическому фрику хороший комп совершенно ни к чему. Сделал я этот вывод после того, как два месяца кряду провёл за Pentium II 400 MHz. Признаюсь честно, что моя работоспособность совершенно не пострадала, а в некоторых моментах даже выросла. Так что гонка за скоростью — признак собственного инфантилизма.

Apr. 11, 2005 // 16:45 | Комментарии (6)

.question | Trees

Господа, а кто-нибудь сажал деревья в PostgreSQL? Может поделитесь, а то что-то не тянет меня снова изобретать колесо?! =)

Apr. 09, 2005 // 18:03 | Комментарии (0)

.question | Sysaminds

У меня созрел вполне актуальный вопрос. Предположим, что есть у нас банк, и есть в нём, соответственно, датацентр. И обслуживают его, конечно, Сисадмины, и есть среди них кто-то с корневым доступом к системе. Сразу напрашивается вопрос о том, кто, собственно, контролирует действия сисадминов, им же натворить какую-то пакость — раз плюнуть!?

Хотя, даже если не банк, а просто компания, у которой в СУБД инфы на мильён. Так что, собственно, мешает сисадмину её тихонько свистнуть и продать конкурентам? Как эта проблема вообще решается, кроме как народными методами в виде хорошей зарплаты и паяльника в жопе?

Mar. 27, 2005 // 19:50 | Комментарии (15)

.note | Blog Usability

Координируя работу команды разработчиков пришёл к выводу, что главная фишка движка для блогов — это простота и скорость публикации данных. Это ещё одно «за» в пользу InTerra, ибо «С Нами Удобно»!

Mar. 20, 2005 // 17:37 | Комментарии (5)

.question | Security Policies

Господа, подкиньте идей по составлению «политики информационной безопасности компании». В первую очередь, это относится, конечно, к IT. Далее следуют мои первоначальные наброски (дополнения/изменения более чем приветствуются).

Это всё, конечно, только наброски. Тем не менее, целью является создание оптимальной политики безопасноти, доступной как малому, так и среднему и большому бизнесу. Будут ли ещё какие идеи?

Mar. 17, 2005 // 15:04 | Комментарии (12)

RTB

Альфа версия спецификаций Русского ТракБака — дополнения и критика приветствуются. Так же всех желающих приглашаю принять участие в дисскусии в ГуглГруппе.

Feb. 22, 2005 // 14:14 | Комментарии (0)

Trackback и всё всё всё

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

Шо це такое этот ТракБак?

Прежде, чем разводить полемику на ровном месте, не мешало бы расставить несколько точек над «ё» и рассказать, что же за чудо техники такое — этот незамысловатый TrackBack.

Feb. 20, 2005 // 15:14 | Комментарии (9)