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

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

Для прорисовки векторной графики в IE используется VML а в остальных браузерах SVG. В идеале, хочется сделать что то вроде библиотеки Raphael Дмитрия Барановского, но Raphael это вещь в себе, хотя и совершенно волшебная, мне же хочется сделать библиотеку для работы с векторной графикой на базе ztools. С его объектно-ориентированными возможностями можно будет создавать вещи нереализуемые при помощи классического HTML/CSS

Как я уже писал, в HTML совершенно нет возможности размещать текст по-вертикали. Правда, сильно ограниченные возможности присутствуют в Internet Explorer, правда, у этого способа я обнаружил один баг — при предварительном просмотре печати текст оказывается зеркально отраженным, видимо, второй фильтр не применяется.

Хотелось бы найти универсальный способ отображать вертикальный текст по-вертикали во всех браузерах и по возможности без глюков. Как говорится если нельзя, но очень хочется, то можно.

Создал небольшой скрипт для отображения текста по-вертикали. Код получился сравнительно небольшим. Скрипт использует VML под IE и SVG под остальными браузерами.

Внешний вид полностью настраивается при помощи CSS и Javascript. Здесь можно скачать архив, а здесь увидеть как это работает в живую.

Выложенный пример тестировался на IE6-IE7, Firefox2, Google Crome, Opera и Safary.

При работе с UTF-8 привычные функции работы со строками перестают корректно работать. В этом не трудно убедиться если сохранять исходник страницы в UTF-8:

print strlen("тест");  //8

Вместо привычных strlen, strpos, substr следует использовать соответствующие многобайтные аналоги: mb_strlen, mb_strpos, mb_substr. Но это делает код плохо портируемым под другие кодировки, увеличивает вероятность ошибок, и вообще это не удобно. К счастью расширение mbstring позволяет переопределить эти функции автоматически.

добавляем в .htaccess

php_value mbstring.internal_encoding "UTF-8"
php_value mbstring.func_overload 7
 

проводим эксперимент:

print strlen("тест");  //4

...что и требовалось доказать. Конечно, теперь всегда нужно иметь в виду, что при вызове strlen на самом деле вызывается mb_strlen это всегда нужно учитывать, особенно, если ваш файл будет сохранен не в UTF-8, но зато код станет хорошо портируемым и не зависящим от кодировки исходников.

P.S. Как показала практика, такое решение полезно только если проект маленький, если же вы собираетесь использовать сторонниие библиотеки, то лучше все же создать дополнительный уровень абстакции для работы со строками - простая подмена функций приводит к непредсказуемым результатам!

Ответье мне на вопрос. Не понимаю. Andorid - это нормальная Линукс среда, с виртуальной памятью, с нормальным разделением прав, со всеми возможными средствами ввода вывода, ядром... Нахрена спрашивается запускать приложения в собственной виртуальной Java машине? Там где каждый дополнительный такт процессора означает увеличение потребляемой мощности они запускают приложения собранные не из машинных кодов а используя Java байткод, который еще неизвестно как выполняется Java машиной... Что - линукс недостаточно защищен? Неужели ребята просто заинтересованы чтобы рынок приложений для Android был только для Android, а всевозможные уже написанные приложения для Linux были бы несовместимыми с Android-мобильниками - попахивает обыкновенным саботажем.

UPD. Нашел ответ: Android построен на ядре Linux, а прикладные приложения выполняются в виртуальных машинах (sandbox) и для их разработки используется Java. Или, вернее, язык с синтаксисом Java и библиотеки аналогичные Java SE. А в качестве среды исполнения вместо JVM используется виртуальная машина Dalvik.

...все дело в лицензионной политике. В случае с Java ME, Sun продемонстрировала просто чудеса иезуитства изобретательности, выпустив ее сразу под двумя лицензиями: GPLv2 и коммерческой. А это вынуждает производителей, использующих Java ME либо открывать весь свой код, либо... платить Sun :)

Естественно, все это не укладывалось в рамки политики, которую избрал Google для продвижения Android. В отличие от Sun, у которой хорошие юристы, Google решил положиться на своих инженеров и... создал свою реализацию виртуальной машины. Причем, Dalvik - это не просто новая реализация JVM (которую все едино пришлось бы лицензировать в Sun), Dalvik вообще не использует Java байт-код (вернее байт-код, полученный в результате компиляции в design-time преобразуется в dex формат, который и используется в run-time). В общем, инженеры Google обставили лоеров Sun.

В то время как Apple делает iPhone невероятно сладким, лакомым кусочком для разработчиков игр, но в тоже время делает его и невероятно закрытым. Google не только делает Andriod открытым для разработчиков мобильных устройств но и дает возможность миллионам существующих Java программистов стать разработчиками под Andriod.

А ведь умно...

Функция substr служит для взятия подстроки, синткасис у нее следующий:

string substr ( string string, int start [, int length] )

Допустим, вам нужно отрезать последний символ, знатоки Javascript или Си напишут примерно следующее:

$s = 'some string1';
$s = substr($s,0,strlen($s)-1); //some string

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

$s = 'some string123';
$s = substr($s,strlen($s)-4); //123

понять что делает этот код довольно трудно, несмотря на то что его назначение тривиальнейшее.

К счастью в PHP в substr можно использовать ОТРИЦАТЕЛЬНЫЕ ЗНАЧЕНИЯ для стартового символа и длинны:

//пример первый
$s = 'some string1';
$s = substr($s,0,-1); //some string

//пример второй
$s = 'some string123';
$s = substr($s,-3); //123

Кака видно, в этом случае код читается на порядок проще. Ничего подобного нет ни в Си ни в JavaScript, а жаль.

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

- побольше глобальных перемнных. Глобальные переменные жрут память - ну и фиг с ней, пусть клиент купит еще планочку - не  разорится

- в жопу комментарии. Кому надо сам разберется что к чему!

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

- чем больше листинг тем круче. Если в файле листинга меньше десяти тысяч строк кода - это и не листинг вовсе.

Потребовалось сделать favicon.ico, да как назло никакого софта для сохранения в ico не оказалось под рукой, даже премного-мной-уважаемый Photoshop не умеет сохранять в ico, пришлось импровизировать.

В PHPThumb обнаружил отличную функцию для сохранения GD ресурса в ICO. На основе этой функции сделал собственный мааааааленький скриптик для преобразования графических файлов в ico. В общем, инструмент получился действительно полезный - выкладываю его для общего пользования. Здесь исходник.

Поддерживает GIF, PNG и BMP.

Upd: для этих же целей есть офигительный сервис favicon.ru

Upd2: Бесплатный конкурент Фотошопа - Gimp прекрассно умеет сохранять в ico.

Upd3: Как оказалось гимп всё-же сохряняет ico с ошибкой - получается фигня, по крайней мере в Windows версии.

Похоже, что эта пагубная традиция идет со времён когда переменные, передаваемые через GET и POST превращались в глобальные переменные. Eсли поле формы описано как <input type="text" name="Last Name"> то в PHP оно преобразуется в $_POST['Last_Name'].

Довольно неприятное поведение, но это факт.

Начинаю понимать почему многие разработчики забивают на тип DATETIME в MySQL и используют вместо него целочисленные поля:

  $date = gmmktime(0,0,0,1,1,2010); //2010-01-01 00:00:00;
  DB::execute("insert into messages SET date_created=from_unixtime(?)",$date);  
  $id = DB::getLastID();
  
  $r = DB::execute("select date_created from messages where message_id=?",$id);
  print $r->fields[0]; //2010-01-01 03:00:00

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

Оказывается для MySQL нужно выставлять зону отдельно.

DB::execute("SET time_zone='".Config::$mysql_timezone."'");

причем, строковые значения вида 'America/New_York' для зоны дают странные результаты - почемуто у меня получилось расхождение в 34 секунды c PHP, возможно связано с тем, что MySQL высчитывает даты с использованием leap seconds c в PHP просто прибавляет или вычитает часовую разницу, поэтому решил, что лучше использоватать числовые зоны, типа SET time_zone='-5:00'.

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

Компонент представляет собой RGB палитру, наподобие той, что используется в Photoshop - на мой взгляд, так выбирать цвет удобнее всего, хотя, есть задумка сделать еще несколько оригинальных колорпикеров.