(no subject)

[kastaneda]

Был у меня флеймообразующий пост про то, что back-office (то есть, веб-интерфейс администратора) на сайтах должно вытесняться в сторону клиентов, общающихся непосредственно с БД этого сайта. Помните? Так вот. Вышедший неделю назад KOffice 1.4 beta1 несёт на борту Kexi и Krita. Ну, про Krit'у говорить сейчас не буду. Я про Kexi.

Товарищи скептики! Вы просто посмотрите, насколько это «end-user» софтина. Да ей даже менеджеры сами по себе могут пользоваться. Вместо access'а. Принимая все возражения, что идиотов у нас 99%, что заказчики ничего не знают и знать не хотят — всё-таки посмотрите.

Есть у кого-то выводы? Мой вывод: чтобы совесть потом не замучила, надо продавать не «продукт» (сайт, услуги, интегрированные решения итд), — вместо этого надо продавать идеологию. Нужно сначала из брутального клиента-ламера сделать тонкого целителя правильных технологий, а уж дальше…

Comments

[vassanta.livejournal.com]

Так, кто-то мне обещал TeX и линух, с которого проще начать? :-))

[kastaneda]

О, какие люди! =)

По делу. Linux - штука универсальная. Хоть KDE с его форточками, хоть TWM, хоть чистая консоль. Так вот, софт для "чистой консоли" уже есть, и давно. А для тех, кто мануалы не читает - для тех пишут такие вот Kexi.

[vassanta.livejournal.com]

аха, это мы :-))
Так, Линух ставила, КДЕ немного мучала, Гнома - тоже видела :-)
Мануалы я читать могу, но вот прорываться сквозь дебри инглиша - лень :-)

[tymofiy.livejournal.com]

Шоти внушають :). Це буде щось на кшалт Visual Foxpro?

[kastaneda]

На кшталт MS Access, який може працювати з MySQL та PostgreSQL.

[spr.livejournal.com]

прочитал флеймообразующий пост, но пофлеймить захотелось тут

Каким образом ты предлагаешь тот же локально проинсталлированный access (или kexi) подключать к той же мускльной базе, расположенной на удалённом сервере? То есть, понятно, что подключить её можно. Но при этом также понятно, насколько медленно это будет работать. И ещё вопрос, насколько это будет безопасно - гонять sql-ный трафик по всей сети.

[kastaneda]

OK :)

Во-первых, заставить access использовать mysql - э-э... я даже не знаю, насколько правдоподобна такая задача. В основном, я подразумевал что-то вроде Kexi.

Во-вторых, локальный Kexi и далеко стоящий MySQL. OK. Давай рассмотрим разные варианты:

1. Офис, выделенка, хороший канал.
2. Офис, выделенка, медленный (но стабильный) канал.
3. SOHO, диал-ап.

В первом варианте и обсуждать нечего. Во втором, пожалуй, одним из оптимальных решений будет установка двух серверов MySQL с репликацией: в офисе стоит master, на хостинге стоит slave. При этом в офисе ведётся нифига себе accounting с потенциальными возможностями выродиться в локальный ERP+CRM: все данные, которые хорошо укладываются в реляционную БД, должно туда попадать, чтобы это можно было эффективнее использовать.

Ну, а на диал-апе всё плохо. Скорее всего, как во втором варианте, но без "нормальной" репликации - синхронизация каким-нибудь простым скриптом. Да, это недалеко уходит от закачки обновлений по ftp.

А гонять sql'ный трафик по сети... Хм... Неужели ещё кто-то не пользуется ssl-туннелированием? :)

[spr.livejournal.com]

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

Имхо, это должен быть какой-то очень почётный проект от 10k$.

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

[kastaneda]

Туннель строить легко и просто. Репликацию (штатную MySQLную) - тоже. Обновления софта (в теории) не нужны, поскольку клиент только работает с данными.

Впрочем, реализовать что-то подобное сейчас вряд ли получится.