Ruben's Blog

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

И тогда думай: “как нужно было бекапить почтовые сообщения, где теперь всять адресную книгу…”.

Более-менее начинает приходить понимание как должен выглядеть WePlan. Общая структура его должно представлять собой сочленение двух видов плагинов: сценариев и документов.

Сценарий определяет последовательность действий и устанавливает для каждого действия соответствующий шаблон документа. Шаблон документа, в свою очередь является как “вместилищем” содержания действия (например текст, таблица, изображение и пр.), так и содержит в себе цитируемые блоки. Цитируемый блок – строка, абзац, численное значение или изображение. Цитируемый блок может используется документом сценария для составления общего содержания. Причём шаблон документа определяет в каком виде передаётся цитата в сценарий. Например цитата табличного документа может передаваться в виде изображения части таблицы, а может передаваться как некое результирующее числовое значение. Перечень цитат с их превьюшками или значениями должны быть видны из сценария.

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

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

1. Найти на диске все оригинальные рисунки и фотографии. Собрать из них галлереи и перебросить на сайт. Все галлереи наполнить описаниями.
2. Пройти по всем постам и переназначить галлереи заново.
3. Поудалять к чертям суперметки языка, всё равно они работают через пень-колоду.
4. Поправить тэги.
5. Сделать разделы.

Вот так всегда! “Два переезда равносильны пожару” – русская народная пословица.

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

После переназначения кодировки кириллических полей на UTF8 всё заработало. Правда в некоторых темах вордпресса, заголовки на русском языке не появляются, но при таком богатом выборе халявных тем, который предоставляет вордпрессовское сообщество это не так важно.
А теперь вопрос! Как мог оказаться у хостера шведский вордпрес? Не иначе как этот хостер – ИКЕЯ! Сразу становится понятным почему цена за безграничное пространство вдвое ниже чем у предыдущего, американского конкурента.

Продолжая исследования в области применения Javascript + CSS для построения сетевого приложения управления проектами, я сделал открытие! Для того, чтобы соединить в диаграмме Ганта два процесса, достаточно отрисовать два DIV-образных прямоугольника!

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

Для полноты соответствия изображениям, которые готовят такие программные продукты как MSProject и OmniProject не хватает только… маленьких стрелочек, но я не уверен в их необходимости. Я не представляю случая, чтобы стрелочка была направлена “назад”, а следовательно, в любом случае, можно понять, какой процесс из какого вытекает.

[lang_ru]Открытие сабклассинга в каскадных таблицах стилей просто перевернуло моё мировозрение! Оказывается, раньше я видел всё шиворот-навыворот, плоско и убого. Сказывалось неумение пользоваться великим и могучим собранием мудрости – интернетом.

На таких радостях я решил срочно скопировать элемент упралвения типа “календарь” из одноимённого приложения “iCal” для размещения на сайте. Для пародирования оригинала я использовал только CSS и Javascript.

Можно заметить, что у яблочников имеется небольшая оплошность в календаре. Для февраля 2009-го у них отрисована лишняя пустая неделя. Я решил избавиться от всяческих лишних полосок и учёл, что в месяцах случается от четырёх до шести (май 2009-го) недель.

Сам календарь по идее должен был войти в общую GUI панель, которая должна показать “товар лицом” в приложении. Общая структура размещения элементов управления должна быть таковой:

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

В элементе управления нет ни единого фонового рисунка. Всё делает “-webkit-…”. Безусловно немного другой шрифт и жирность, но использование Verdana продиктовано исключительно реалиями использования элемента в гипертексте.

Та же участь постигла элемент управления MonthView ((Я не знаю, как на самом деле этот элемент (или по терминологии Cocoa – [Custom, User, My] View) управления называется, но по факту своего назначения, такой псевдоним ему подходит как нельзя лучше. Внешне он очень напоминает таблицу, но на самом деле это в чистом виде DIV-ы в DIV-ах с координатным размещением. Зачем? Для того, чтобы аккуратно разместить в нём всякие разные элементы, отвечающие за процессы. Сложность последних в том, что некоторые из них начинаются одной датой, а заканчиваются другой. Иные просто протекают через месяц без начала и конца)), который в гипертекстовой разметке выглядит очень чистым и аккуратным:

А вот, задуманная структура этого элемента управления:

Конечно, ещё многого не хватает, как в календаре (выделение отображённых дней) так и в месячном просмотре (отображение проходящих задач), но это связано с тем, что на данном этапе программирования, кодируются только фоновые элементы. Появление же данных и межэлементное взаимодействие будет позже, когда дело дойдёт модулей структуры данных. Я уже сделал общую структуру, но постоянно рождаются новые идеи, которые напрочь сносят предыдущие.

[/lang_ru][lang_en][/lang_en]

[lang_en][/lang_en][lang_ru]

Хотите знать, нахрена мне, 35-и летнему мужчине, которому по состоянию здоровья скорее подошло бы заниматься триатлоном, чем таращить зенки в монитор и массировать кончики пальцев клавишами, понадобился Питон? Не хотите? Всё равно отвечу!

Несколько лет назад, занимаясь в Самаре строительством базовых станций, я подумывал о том, что нет программного продукта, который бы решал задачи организации процессов так легко и просто, как текстовые редакторы верстают договоры, фотошоп корректирует фотографии и квиктайм проигрывает видео. Годом позже я познакомился с MSProject, который успешно использовал до того момента, пока не перешёл на Mac OS и мне не пришлось перейти на PmniPlan.

Проблема любых программных продуктов, которые сейчас могут быль использованы, в том, что они не должны работать локально. Сама идея проектов в том, чтобы быть доступными всем участникам проекта одновременно. Файлы, которые пересылают по электронной почте создают только мусор на жёстком диске. К тому же нужно постоянно переименовывать файл, добавляя к нему номер версии. Как вариант можно написать программу, которая будет вынимать файлы из почты самостоятельно и складывать в некую базу данных.

Другими словами, когда я год назад увидел Google Doc, я был приятно поражён тем, что нашлись ребята, которые догадались сделать это же. К сожалению, у них нет ничего, способного нарисовать диаграмму старины Ганта, которая очень и очень нужна для прикидок на тему “когда же это всё наконец закончится!?”.

Совсем недавно я узнал, что в прошлом году, Google анонсировала App Engine. Штука очень завлекательная. Возможность на бесплатной серверной платформе с мощностями, которые недоступны никакому другому хостингу на планете Земля, разместить сетевое приложение практически любой мощности. Но тут есть не просто подводные камни, а целый барьерный риф. В качестве языка программирования высокого уровня, они выбрали Питон. Язык вздорный по своей сути. Конечно, могло быть и хуже. Всегда может быть хуже.

Чтобы не взорвалась голова, можно сделать так: максимально использовать адекватный Javascript на клиентской стороне и минимум Pithon на серверной. Только для доступа к базам данных.

Но сделаем шаг назад. В декабре 2008-го, случился у меня разговор с Ольгой Поляковой, о β-тестировании разрабатываемого её программистом приложении для управления проектами. Паренёк оказался очень амбициозным, решившим во что бы то ни стало сверстать программу за пару месяцев. Моя практика показывает, что даже на в MSAccess + VBA такое можно сделать не менее чем за три-четыре месяца, с тем, что у майкрософтовцев отличные дебаггеры и приложение получится, хоть и клиент-серверное, но локальное. Изучив версию номер ноль, я усомнился как в том, что такое приложение будет написано, так и в том, что программист вообще понимает что делает. Действительно, глобальная ошибка любого программиста, решившего взяться за разработку программного продукта в одиночке в том, что он зачастую не занет матчасти. Матчать – опыт в самой деятельности, которую собираешься автоматизировать. Взять к примеру разработку приложения для написания сценария для кино. Что делает программист? Он берёт и верстает текстовый редактор. Чем для программиста отличается программа для вёрстки сценария для кино и для телевидения? Ничем! Но это в корне не правильно. Так же и с управлением проектами. Я допускаю, что вполне возможно делать приложение по частям. Можно дописывать кусками функционал или углублять его, усложняя те или иные функции, но с самой первой строки нужно точно знать куда стремишься. Что в конце концов будет работать на тебя. В противном случае, ты станешь рабом софта, коими стали все, установившие себе 1C-Бухгалтерию. Почему я не слышал жалоб от пользователей Final Cut? Почему никто не жалуется на Google Maps? Потому, что эти программы заточены на то, ради чего они написаны. Так же должно быть и с проектами. Не под таблицы нужно создавать объекты данных, не под библиотеки стандартных элементов пользовательского интерфейса подстраивать бизнес-процессы, а под события и восприятие реальности, адаптировать весь возможный потенциал информационных технологий.

Я не имею права пускать вас в портал проектов Ольги, но покажу несколько показательнейших скриншотов:

Главное окно [caption id="attachment_396" align="alignleft" width="150" caption="Вложенные файлы"][/caption] Таблица [caption id="attachment_398" align="alignleft" width="150" caption="Превьюшки"][/caption] Служебная таблица

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

В любом случае, я не считаю себя неправым. Скорее грубым, но неправым – нет!

[/lang_ru]