Ruben's Blog » Программирование

Яйца в одной корзине

Ruben — Tue, 01 Sep 2009 20:10:43 +0000

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

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

WePlan – нулевой шаг

Ruben — Fri, 21 Aug 2009 02:23:20 +0000

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

[View with PicLens]

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

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

Тяжела и неказиста…

Ruben — Thu, 13 Aug 2009 08:50:21 +0000

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

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

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

Хостинг у ИКЕИ

Ruben — Thu, 13 Aug 2009 07:28:09 +0000

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

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

ЗАДАЧИ ДИАГРАММЫ ГАНТА

Ruben — Sat, 14 Feb 2009 01:34:45 +0000

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

Связи процессов

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

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

Каскадные таблицы стилей

Ruben — Fri, 13 Feb 2009 20:46:08 +0000

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

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

Оригинальный GUI элемент

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

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

Общая схема подделки

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

Подделка

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

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

Месяц

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

Задачи на месяц

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

[/lang_ru][lang_en][/lang_en]

Python? Javascript?

Ruben — Fri, 13 Feb 2009 05:20:19 +0000

[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]