Saemon Zixel

Сделал на днях SVG версию простой страницы с заголовком и таблицей.
Мдаа, вышло хуже чем в HTML версии. Если в HTML версии текст "подстраивается" под доступное пространство, а таблица изменяется в соответствии с содержимым, то в SVG каждому элементу глубоко плевать на всё остальное, он выводится максимально простым способом (если не топорным). Сразу видно что SVG не конкурент HTML при создании страниц сайта.

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

На новой работе осваиваю HostCMS. Интерфейс админки неплохой, заметно что дизайнер посторался и нарисовал все вполне хорошо, но про юзабилити не подумали и программеры сделали посвоему. С точки зрения процесса создания сайта, полный пиздец (имхо). Входной барьер высокий (появляется желание отказатся и попробовать другое), в документации основная идеология не описанна (документация просто есть, и на поверхностный взгляд неплохая), исходники закрыты (приходится догадыватся как оно там внутри "думает"), в некоторых местах остается только использовать sql-запросы вместо api системы (но тогда зачем эта цмс вообще нужна?). Ну в принципи я только осваиваю её, возможно когда освою - увижу настоящие плюсы и минусы.

Также на работе поставил AltLinux Desktop 4.1. И скажу - неплохо. Появилась возможность шарить папки как в винде, панель настройки samba-сервера, alterator аналог yast2 в suse (но правда уступает в функциональности). Ещё бы сделали сетевое окружение через smbnetfs то было достаточно для удобной работы в Win-сети. Но есть и недочеты/недоделки. Например: не срабатывает вкладка брандмаэра (iptables) через каторую можно легко "интернет шарить", невозможно более тонко настроить клаву в XWin (тоже в алтераторе) и т.д. Да и вообще Десктоп и hardened нельзя совмещать.

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

Но, слава богу, где-то на 15 раз оно принимает вполне приличный и готовый вид.

PS. Ну ниче, завтра снова "в бой".

Разница между просто возвратом кода ошибки (или просто false) из функции и созданием Исключения в том что:
- при первом варианте (классическим) код ошибки если и будет обнаружен, то вполне возможно в дали от функции которая вернула этот код.
- при втором варианте ошибка будет обнаружена сразу (программистом или пользователем), и максимально близко от той функции в которой возникла ошибочная ситуация.

Вывод: Исключения - лутший друг программиста.

Объекты и РСУБД несовместимы.
Потому-что данные(число, строка, дата) мертвые, а объекты живые.
Потому-что для работы с данными надо знать структуру данных, а объекты скрывают свою структуру. Считается что объекты не имеют структуры, и если нужны какие-нибудь данные надо попросить их у объекта, а для этого последней должен быть живой.

За последней месяц я ясно почувствовал что
программировать на Smalltalk и в Smalltalk среде лучше чем на Ruby и в блокноте++ (хоть и по TDD).

PS. Просто мне в падлу рассказывать про свои 2 попытки решить одну и туже задачу на руби, и легкое и быстрое решение её же на Smaltalk-e.

PSS. Наверное у Smalltalk-a очень хорошая среда разработки (яб даже сказал наилучшая), а у руби ничего толком нет. Возможно я еще плохо знаю руби, а взялся решать сложную задачу. Возможно на руби я решил основные проблемы и обнаружил не правильные пути что позволило мне быстро запрограммить на Smalltalk-e нужное.

На руби программировать легче - не надо ставить точки или точку с запятой в конце каждой строки.
Также есть метод collect с которым я познакомился еще в смолтолке (есть еще reject, но случая использовать еще небыло)
Есть each по аналогии с foreach в PHP или с do в смолтолке.

Неудобно то что на руби пишешь скрипты, плоские файлы, рулоны. Получается также как с PHP. Видишь в основном код в методах, а объявления методов,
список методов в классе не видишь.
В смолтолк-средах по другому. Видишь только дерево классов, и список методов (ну и группы/протоколы), а код не видишь. Код можно посмотреть но только одного метода.
Поскольку я на работе програмлю в основном на PHP, получается что программирую дома на руби примерно так-же как на PHP, как-то "сносит" все время.
И вообще на руби можно кодировать по всякому, и это наоборот вводит в ступор. И становится тяжело определится как именно надо кодировать в данный момент для реализации данного алгоритма.

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

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

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

Мож стоит сделать как есть?
Иногда надо сделать ошибку чтоб сориентироваться куда двигаться дальше.

Начал пробовать программировать на ruby.

Причина по каторой я решил научится програмить на ruby - две: создание "оконных" приложений и близость к языку Smalltalk по части объектов.

Поставил себе задачю, сделать некий "просмотр логов". Интерфейс на QT, связь по протоколу XML-RPC, по возможности надо использовать PostgreSQL и SQLite. Программа делается естественно в образовательных целях, и только для личного использования.

Первые впечатления:
- регулярные выражения и вообще стиль (постфиксные записи if,less, объявления def, class, хеши и массивы, yeild) напоминает perl.
- отсутствие точки запятой в конце и необязательное использование скобок напоминает Basic.
- ООП (если неуказывать кому посылается сообщение то посылается self, методы inspect, instant_methods, методы класа -> def Test.setClassVar, #symbol -> :symbol) напоминает Smalltalk.
- неочень понял разницу между Proc и {}, но это наверное должно напоминать lisp (но lisp я почти не знаю).
- старт был быстрый, наверное сказалась особенность языка т.е. "ожидаемость".
- с QT тяжеловато, нужно регулярно смотреть в официальный справочник по QT для с++, ну и самому думать.
- иногда ruby кидает эксепшен что типа метод не найден, хотя он есть и ты его уже использовал. Фишка в том что для каждого набора параметров есть свой метод, и с теми параметрами с которыми ты хочеш вызвать метод соответствующего метода нет. К этому надо привыкать.
- с отладкой пока-что тяжко (есть аналог gdb - "ruby -rdebug <файл>", но с ним надо разбиратся).

Восновном програмлю на работе, в openSuseLinux+KDevelop (пробую RDT).
Дома восновном балуюсь и просто пробую ruby, и там среда похуже - win98+notepad++, QT к сажелению нету (и это плохо), поэтому пробуем FOX (FXRuby).

а еще музыка помогает пережить тяжелые моменты в жизни

PS ...особеннно OST-ы от аниме-сериалов.

....я понял что для каждой проблемы нужно решение достаточного калибра.

Например есть у нас фотки в папке одинакового формата и размера. Нужно их обштамповать логотипами.
Делаем одну процедуру которая в цикле их открывает, ставит лого и сохраняет.
Если форматы разные да и размеры тоже, то надо делать несколько процедур/функций каждая из которых сделает свою часть работы.
Если там еще надо подумать в каком месте лого штампонуть, то стоит и класс нарисовать который будет представлять файл-фото и решать как его обрабатывать...
Чем крупнее калибр тем проще и легче решается поставленная задача, не теряется зря время и "мозговые ресурсы".

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

На php тяжело программировать.
Рисовать все объектами слишком рутинно (да и боязнено с точки зрения производительности). Вот в Смолтолке это легко. Там мало телодвижений надо делать чтоб создать класс, метод, тело метода. Больше надо думать головой что и где создать и как это все переделать.
Программировать чисто процедурно (php изначально был чисто процедурный язык) вполне можно но с более сложной логикой и большими объемами это становится гемором.
Вот и приходится учится программировать полу-объектно полу-процедурно. Именно для таких языков и были придуманы патерны ГоФ.

1). Какая все-таки гадость этот переснятый Appleseed, максимум сюжет присутствует.
2). от Javascript пахнет self языком (вот не знаю радоваться или нет, пока-что наслаждаюсь).
3). XUL (наконец-то я начал с ним работать.):
а) придурошная верстка! (это мне кроме html надо будет учится верстать и xul?)
б) скорость не супер... (ну это понятно)
в) "оживлять" все это javascript-ами не так легко как я рассчитывал (есть только самые необходимые функции у контролов)
4). regexp-ы рулят, всем кто хочет обрабатывать строки знать обязательно (ну это все знают), но выглядят ужасно (это тоже все знают)!

У меня медленный компьютер (Athlon 750Mhz шина 200Mhz памяти 512 (раньше было на четверть меньше)). Это проявляется когда я редактирую таблицу в какой-нибудь админке кого-нибудь сайта в поле с "расширенном" редакторе (типа FCKedit, TinyMCE...); когда копирую и вставляю таблицу из OOCalc в NVU и переключаюсь в "Source" чтоб почистить html код; когда я переключаюсь в Оперу с 15 вкладками из IE6 запущенного под wine чтоб посмотреть как смотрится измененная в админке мною информация на сайте...
Хотя когда перезагружаюсь в win98 с ie55, office97, frontpage и делаю это-же то у меня все летает.
Хмм... Вот я думаю, стоит ли покупать какой-нить Core2 Duo для вышеприведенных действий или нет...

Теперь я понял и почувствовал почему создатели PHP против OOP в их детищи. Теперь я их мнение полностью разделяю!

Оказывается в ANSI стандарте по языку Smalltalk 243 страницы (с 52 по 295) это описания методов, при этом только базовых. Если на одну страницу входит где-то 2-3 описания методов, то получается ~600 методов...
А есть еще куча не базовых методов, которые тоже очень даже нужны...

В общем, меня эти цифры сильно огорчают. Опять я просчитался...

За то небольшое время которое я программирую на ST - кристально чистом объектно ориентированном языке, я понял что на нем тяжело писать. Сложность заключается не в написание алгоритмов, а "придумывание" классов, методов, имен методов и instance variables. Т.к. не знаешь как по настоящему правильно и куда уведет "дорожка"...

И всетаки Squeak тормозная штука, особенно в связки squeak3.9-8 + sq3.9-7067dev08.01.1.image + Athlon750.

ЗЫ И еще каму-то в голову взбрело использовать его как веб-платформу...

В этом году AKROSS CON выдался хуже чем в прошлие разы.
Лутший клип конкурса (SVS - Spoil) мне не показался лутшим, хотя техника и синхранизация с музыкой впечетляет.

В первый раз когда я писал на php "объектно ориентированно" я долго ломал голову какой стиль использовать при создании классов. ST стиль наврядли здесь подходил, а классически-популярный стиль когда вместо функций код укладывается в методы и класс это просто группа таких методов (который мне некогда не нравился) или для PHP создателями был придуман свой стиль.
Второй раз (совсем недавно) воспользовался пакетом SimpleTest (достаточно убогая оказалась вещь) для написания тестов, и что то похожее на стиль ST начал появляться при написании классов. Но долго сохранять этот стиль не удалось, всё таки объекты/классы PHP слишком далеки от ST. Сложно писать объектно ориентированно на языках которые изначально для этого не предназначались.

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