Oduvan’s Web Blog

Данной темой я хотел рассказать, как можно на Debian поставить VirtualBox и на него WindowsXP. Грустно то, что вчера вечером я над этим и над мучался до часу ночи ну и еще над дружбой trac + Mercurial, а утром уже как то само и легко пошло, а последнее оказалось до боли просто. При чем я был в легком ужасе о того, на сколько он оказался удобнее чем тот же VMWare. Но часть эйфории начала потихоньку спадать. И я уселся написать про свои ощущения.

Одной из самых приятных фичей было то, что не обязательно настраивать сеть, поднимать самбу сервер в линухе, чтоб подключить сетевой диск в венде и начать пользоваться общими ресурсами с двумя осями, все это организовывается встроенными средствами VirtualBox. И очень приятным дополнением к этому было то, что окна обоих систем можно мешать друг с другом на одном десктопе и на нем же у вас будут две главных панели от обоих осей. Хотя как оказалось в последствии эта фикча ещё довольна сырая.

Ставится это чудо — очень просто, через aptitude

перед первым запуском надо будет ввести modprobe vboxdrv под рутом.

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

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

Дальше устанавливаете ваш дистрибутив винды.

Shared Folder – одина из настроек вашей виртуалки. Там можете задать каталог, который на вашей ФС, которой будет доступен из виртуалки.

После этого запускаете вашу ОС в верхнем меню выбираете Devices> Install Guest Additions…

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

Далее уже в винде подключаем сетевой диск. Правой кнопкой на сетевое окружение, «Подключить сетевой диск» . В «обзоре» выбираем «Вся сеть», «Virtual Shared Folders» и выбираем свою папку. Надеюсь никому не надо объяснять, что винда у меня русская, и поэтому названия все идут по русски.

Все просто.

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

Так что теперь успешно пользуюсь. В меню Machine можете посмотреть сами все прелести вашей новой малютки. А я просто разворачиваю во весь экран и пользуюсь необходимыми мне тулсами.

И еще один маленький плюс – это система опенсорсная, можете смело присоединятся к разработке. И довольно вменяемая пользовательская документация.

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

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

Итак немного предыстории и введение в проблематику.

Я веду один из банковских проектов — написания и сопровождения CashPay терминалов. И изначально решение предназначалось именно для них, хотя и для других моих проектов — это тоже будет хорошим дополнением.

От слов к делу. Как выглядит лог, например, лайти. Вот одна запись:
10.55.6.59 10.55.6.57 – [19/Jan/2009:15:56:39 +0200] “POST /index.cgi HTTP/1.1″ 200 31 “-” “libwww-perl/5.812″

Что какое поле тут означает – я распинатся не будут. Просто скажу, что для этих логов, и для многих других как правило все сводится к определённому формату.

1.Всегда есть время. И даже если его нет, то как правило — это ПОКА нет. Т.к. вообще теряется сам смысл ведения логов.
2.Есть какая то служебная инфа, присутствующая во всех записях. Это может быть айди процесса, который сейчас пишет лог, или айди пользователя, который сейчас совершает действия.
3.Собственно данные которые вы хотите сохранить для потомков, которые будут разгребать ваши баги. Иногда их подписывают фразами (error, debug, info) Это необходимо для некой группировки логов.

Кажется ничего не забыл. Как правило — этого достаточно. Для чего?

Случилась ошибка, сервер вам о ней отрапортовал, вы выкачали логи, нашли запись о этой ошибке и пошли смотреть хронологию событий. В случае если у вас один процесс, который пишет данные, то этого достаточно, и именно так оно происходит. Если идет взаимодействие двух служб процессов, разные логи, открываем оба, в оба смотрим. Больше сервисов, больше логов, больше мониторов. Тенденция ясна. Но с другой стороны логи должны вестись просто. Открыл файл, плюнул в файл данные, закрыл файл.

Мое решение — логи в CSV формате. Идея реально не нова. Я ее подсмотрел в постгрисе, если его не привязывать к syslog, то свои логи он пишет именно так. Плюс, один мой друг, высказывал идею ведения логов в базе. По окончанию получился некий сембиоз идей.

Итого, ведя логи в CSV — можно вести их легко и быстро + для анализа можно ипортировать их в любую удобную для вас БД.
В PostgreSQL это делается одной командой.

COPY tables_for_log FROM ‘/full/path/to/logfile.csv’ WITH csv;

На самом деле уже это дает очень много плюсов. Хотя бы то, что теперь процесс анализа логов может сводится к простому пользовательскому интерфейсу, в котором вы на первом шаге выбираете даты и возможно сервисы, по которым вам необходимо искать данные. На следующем этапе находятся необходимые логи, распаковываются при необходимости, импортируются в БД и выводится инфа и совершенном импорте. Далее у вас просто текстовое поле, в котором вы оперируете SQL командами для выдачи результатов по логам. Это текстовое поле вам необходимо будет только для начала, чтоб понимать какого рода выборки вам необходим будет делать для решения проблем. После все можно будет свести уже к более удобным интерфейсам. Но это уже будет для каждого проекта своё и глубже я заходить не буду.

Ещё одним неоспоримым плюсом является то, что если две системы друг с другом взаимодействуют и пишут логи в одинаковых ( или сходных друг с другом ) форматах, то вы можете импортировать эти логи в одну таблицу вашей БД. И уже в одном сплошном листинге наблюдать процесс взаимодействие двух сервизов друг с другом. Мне кажется это очень удобным, т.к. в одном из моих проектов таких взаимодействующих систем 4. И процедура поиска ошибки просто выматывает. Да и можно проводить автоматическое тестирование работы систему уже по её результатам ( но про это я рассказывать не буду, потому что подходов много, а решений ещё больше)

Далее, если развивать идею ведения логов, то очевидно, что в любой системе, либо сервисе — есть событие и есть реакция системы на это событие. Запрос урла к вашему серверу — есть событием, а то, что ваш сервер начал делать выборки из базы, изменять её, формировать ответ и выдавать пользователю результат — это уже реакция системы на произошедшее событие. Таким образом я предлагаю разделать на два лога (два CSV файла), и связывать их как один ко многим. Как поле связи можно использовать время, когда было получено событие в миллисекундах. Итого в первую таблицу мы кладем события. Для веб сайтов это может быть время, урл, куки, пост данные, айди пользователя. Вторая таблица уже куда более привязана к конкретному проекту, туда мы сбрасываем все трейсы переменных, возможно ошибки, короче все, что вы до этого писали в логи. Но обязательно должно быть время события ( для связи), время лога. Дальше можно разделить код на компоненты и в логах записывать название компонентов в которых они ведутся, можно просто записывать имя модуля и имя функции. На самом деле вариантов масса. Но я бы всегда разбивал логи по степени важности (debug, info, error)

Все, идеи по логам кончились. Примеров реализации пока не выкладываю, ну просто потому, что там реально будет строк 20 кода. А вообще как вам идея?

Спонсор поста Вывоз мусора в Москве ( у них я взял картинку )

ну Мазила стоит у меня сразу. Откуда взялась – не знаю, но взялась, и слава богу.

Опера. Ну, у нее вообще все хорошо, скачад прям .deb

И на последок – статейка, как сафари поставить

“Please, don’t use any of these IEs to navigate!! Get Firefox. ”

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

Можно юзать ие 6,5.5 и 5. Жалко, что 7ого нет. Тоже было бы полезно.

Выложу разве что принскрин.

PS: О, нашел и для 7ого, бетка.

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

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

“Будьте лучшим программистом в некоторых проектах; будьте худшим в некоторых других. Будучи лучшим, вы сможете проверить свои способности вести проект и внушать другим свои взгляды. Будучи худшим, вы сможете учиться у мастеров и сумеете понять, что им самим не нравится делать (потому что они будут заставлять вас делать это за них). “.

В тех проектах, которые я сейчас веду – я ведущий. Поэтому буду стараться вклинится в какой нить опенсорс. По крайней мере по проекту Django у меня и правда есть много идей, и в этом проекте есть люди, у которых по настоящему есть чему поучится, и есть вещи, реализация которых мне не всегда понятна, при чем как правило не понятен местами подход и даже иногда реализации этих подходов. Возможно об этом я ещё напишу.

И ещё хотел предложить вам почитать интересные статьи, Эльдара Мусаева “Как стать хорошим программистом” ( разбита на части 1 2 3 4 ). Очень легко написано, с юмором. А сравнение хакера и программиста при помощи анекдота про пасущихся быков – это просто ПЕРЛ.

И на последок – чуть более прогматичная статья, из opennet.ru 25 самых опасных ошибок при создании программ.

Вот прямая ссылка на презентацию лекций.

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

К слову говоря, на том же сайте, новость о встреча профессионалов в области двух “конкурирующих” СУБД.

Итак, подборка советов из newcontimemt.ru:

* Используйте постоянные подключения к базе данных, чтобы избежать накладных расходов на текущие подключения. Если Вы не можете использовать постоянные подключения, и Вы делаете много новых подключений, стоит изменить значение переменной thread_cache_size
* Обязательно проверьте, что все Ваши запросы в самом деле используют индексы, которые Вы создали в таблицах. В MySQL Вы можете сделать это командой EXPLAIN.
* Избегайте сложных запросов SELECT на таблицах, которые часто модифицируются. Это должно помочь избежать проблем с блокировкой таблицы.
* Новые таблицы MyISAM могут вставлять строки в таблицу без удаленных строк в то же самое время, когда другой запрос ведет чтение. Если это важно для Вас, Вы должны рассмотреть методы, где Вы не должны удалить строки или выполните OPTIMIZE TABLE после того, как Вы удалили много строк сразу.
* Используйте вызов ALTER TABLE … ORDER BY expr1,expr2… если Вы обычно получаете строки в порядке expr1,expr2,… . Используя эту опцию после внесения больших изменений для таблицы, Вы можете получить значительно более высокую эффективность.
* В некоторых случаях может иметь смысл представлять столбец, который является хэшем, основанным на информации из других столбцов. Если этот столбец короткий и приемлемо уникальный, это может быть намного быстрее, чем большой индекс на многих столбцах. В MySQL это очень легко в использовании: SELECT * FROM table_name WHERE hash=MD5(concat(col1,col2)) AND col_1=’constant’ AND col_2=’constant’
* Для таблиц, которые часто изменяются, Вы должен пробовать избежать любых столбцов типов VARCHAR или BLOB. Вы получите динамическую длину строки, как только Вы используете хоть один стобец VARCHAR или BLOB.
* Если Вы очень часто должны вычислять значения, основанные на информации из большого количества строк (подобно количеству), вероятно, намного лучше представить новую таблицу и модифицировать счетчик в реальном времени. Модификация типа UPDATE table set count=count+1 where index_column=constant очень быстрая! Это действительно важно, когда Вы используете базы данных подобные MySQL, которые имеют только блокировку уровня таблицы. Это также даст лучшую эффективность с большинством баз данных, поскольку администратор блокировки строки в этом случае будет иметь куда меньше работы.
* Если Вы должны собрать статистику из больших таблиц файла регистрации, используйте итоговые таблицы вместо того, чтобы просмотреть целую таблицу. Поддержание резюме должно быть намного быстрее, чем попытка сделать живую статистику. Намного быстрее получить новые итоговые таблицы из файлов регистрации, когда происходит изменение, чем менять работающее приложение!
* Если возможно, нужно классифицировать отчеты как “живые” или “статистические”, где данные, необходимые для статистических отчетов, сгенерированы только, исходя из итоговых таблиц, которые в свою очередь были сгенерированы из фактических данных.
* Воспользуйтесь преимуществом того факта, что столбцы имеют значения по умолчанию. Вставляйте значения явно только, когда значение, которое будет вставлено, отличается от значения по умолчанию. Это уменьшает синтаксический анализ, который MySQL должен сделать, и улучшает быстродействие вставки.
* В некоторых случаях удобно упаковывать и сохранить данные в blob. В этом случае Вы должны добавить некоторый дополнительный код к Вашей прикладной программе, чтобы упаковать/распаковать данные, но это может сохранить много времени доступа в некоторой стадии. Это удобно, когда Вы имеете данные, которые явно не соответствуют статической структуре таблицы.
* Обычно Вы должны пробовать хранить все данные неизбыточными (что названо третьей нормальной формой в теории базы данных), но Вы не должны бояться дублирования или создания таблиц-резюме, если Вы нуждаетесь в них, чтобы получить большее быстродействие.
* Сохраненные процедуры или UDF (определяемой пользователем функции) может быть хорошим способом получить большую эффективность. В этом случае Вы должны, однако, всегда иметь способ делать это некоторым другим (более медленным) путем, если Вы используете СУБД, которая не поддерживает это.
* Вы можете всегда получать неплохие результаты, кэшируя запросы/ответы в Вашей прикладной программе и пробуя делать много вставок/модификаций в то же самое время. Если Ваша база данных поддерживает блокировки таблиц (подобно MySQL и Oracle), это должно помочь гарантировать, что индексный кэш сбрасывается только однажды после выполнения всех модификаций.
* Используйте INSERT /*! DELAYED */, если Вы не должны знать, когда Ваши данные будут записаны. Это ускоряет дела потому, что много записей могут быть выполнены за один дисковый обмен.
* Используйте INSERT /*! LOW_PRIORITY */, когда Вы хотите, чтобы Ваши вызовы select были более важными.
* Используйте SELECT /*! HIGH_PRIORITY */, чтобы получить select, обходящий очередь. То есть select будет выполнен, даже если имеется кто-то ждущий, чтобы сделать запись в таблицу.
* Используйте многострочную инструкцию INSERT, чтобы сохранить много строк одной командой SQL (многие серверы SQL поддерживают это).
* Используйте LOAD DATA INFILE, чтобы загрузить большие количества данных. Это быстрее, чем нормальные вставки, а будет еще быстрее, когда myisamchk интегрирован в mysqld.
* Используйте столбцы с поддержкой AUTO_INCREMENT, чтобы сделать уникальные значения.
* Используйте OPTIMIZE TABLE время от времени, чтобы избежать фрагментации при использовании динамического формата таблицы.
* При использовании нормальной установки Web-сервера, изображения должны быть сохранены как файлы. То есть сохраните только ссылку на файл в базе данных. Основная причина для этого в том, что нормальный Web-сервер намного лучше при кэшировании файлов, чем содержание базы данных. Так что намного проще получить быструю систему, если Вы используете файлы.
* Используйте таблицы в памяти для некритических данных, к которым обращаются часто (подобно информации относительно последнего показанного баннера для пользователей, которые не имеют cookie).
* Столбцы с идентичной информацией в различных таблицах должны быть объявлены идентично и иметь одинаковые имена. До Version 3.23 Вы получали медленные объединения в противном случае. Старайтесь делать имена проще (например, name вместо customer_name в таблице заказчиков). Чтобы сделать Ваши имена переносными на другие SQL-серверы, Вы должны озаботиться тем, чтобы они не превышали в длину 18 символов.
* Объявление таблицы с DELAY_KEY_WRITE=1 будет делать модифицирование индексов быстрее, поскольку они не регистрируются на диске, пока файл не закрыт. Обратная сторона в том, что Вы должны выполнить myisamchk на этих таблицах прежде, чем Вы запускаете mysqld, чтобы гарантировать, что они правильные, если что-то уничтожило mysqld в середине запроса. Поскольку информация ключа может всегда генерироваться из данных, Вы не должны терять что-нибудь, используя DELAY_KEY_WRITE.

Использовался материал:

1) newcontinent.ru

2) dev.mysql.com

С нового года, по кусочкам, я писал этот пост. Наверно хочется, чтоб он больше отличался от моих бональных и суховатых постов. А когда я наткнулся на “новогоднее програмистическое интервью”, то захотелось побыстрее закончить уже далеко не новогодний пост, и новой силой покорять новые вершины.

С ЗАПОЗДАЛЫМ Новым Годом вас друзья. Желаю вам на ошибках предыдущего года учится, а его успехи и наработки приумножать в будущем! Коллегам больше успешных проектов и стабильных релизов. Хотя к чему эти пожелания, когда все и так знаю, что им надо от следующего года, так что сил вам и успехов.

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

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

Для начала – уберу лишние категории, а именно под под под темы вынести в теги, т.к. считаю это более целесообразно.

По поводу тематики. От многих блогеров, во многих блогах я читал, что блог, который ты ведеш – должен быть специализирован. Т.е., к примеру тематикой должен быть твоя любимая технология, фреймворк. Хм, а если она не одна…. Тогда давайте блог просто о программировании на твоём любимом языке…. И тут не задача, очень часто приходится чередовать некоторые языки, хотя бы серверная и клинской части… Ок… черт с ним, давай блог просто о веб программировании… (и тут такой невинный взгляд)… Как что ещё?? задачи не только программирования приходится решать… Расширяемость, Управления, БД, Геймкреатинг, Юзабилити… И даже иногда дизайн, хотя рисовать сам не умею, но ведь иногда вижу и понимаю – это красиво… Дебиан – благодаря хорошим друзьям вокруг, обучение им проходит довольно легко и вот уже около полу года стоит как десктоп на моем ноуте. Начал пробовать БД PostgeSQL, хотя и MySQL мне забыть не дают, пока получается, но особо грандиозным нечем похвастаться. Скоро буду вынужден добраться до Флеша, хотя АС3 уже юзал с флексом. Как основной язык использую Python, хотя и на Perl-е по приходится поддерживать проекты . Да и вообще лажу я по инету, наталкиваюсь на умные ссылки от умных дядей и их сюда буду плевать, со своими пятью копейками.

Да… Опережая ухмылки, скажу и без того понятную вещь, я не являюсь профессионалом во всех этих областях. Просто первична задача и я уже под задачу ищу решение, конкретные решения, в областях которые я знаю. Но не в коем случае не наоборот, хоть это и кажется очевидным, но очень часто приходится сталкиваться с тем, что люди наталкиваются на прикольную фикчу в своей области, где истинно считают себя профи, и пытаются ее вставить где надо и не надо. Им в кайф – а мне гемор )

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

Вот так… Ещё раз с прошедшими вас праздниками… Не переключайте….