Apliacions de gestió en html

Escrit per Aaloy a 15 de April , 2007 a les 5:38 p.m.

L'altra dia amb un consultor estàvem discutint damunt la conveniència o no de realitzar una aplicació de gestió bé en Oracle Forms o bé en tecnologia web, J2EE en aquest cas. És a dir, triar entre una tecnologia antiga o una tecnologia en constant moviment com és la tecnologia associada a la web. Fa uns anys jo mateix no m'ho hagués ni plantejat. Encara que era perfectament possible fer aplicacions web de gestió, quan la usabilitat i la velocitat d'entrada de dades i la validació d'aquestes era un punt crític, les aplicacions d'escriptori [1] eren molt més potentes que la tecnologia web del moment podia oferir. Ara per ara, però, si coparam el que es pot fer en entorns com Forms i en entorns web, la diferència jo no està tan clara. I si a més optam per tenir Oracle Financials com a base, aquesta diferència s'escursa encara més, ja que aquest precisament no destaca per la seva gran usabilitat. En aquests moments la tecnologia web ens proporciona la capacitat de crear complexes interfícies d'usuari, llibreries com YUI, Dojo, Google web toolkit, Zk, Tibco, Qoodox, etc. són productes prous madurs com per a deixar-nos construir complexes interfícies gràfiques que poc tenen que envejar a les aplicacions clàssiques d'escriptori, i que per executar-se sols necessiten un navegador. Que l'aplicació sigui d'escriptori clàssic o sols basada en navegador té molta importància quan parlam d'empreses que tenen la informàtica centralitzada i per tant s'han d'evitar al màxim els problemes derivats de la instal·lació i les actualitzacions [2]. Si un va un poc viu pot estandaritzar per a l'empresa un navegador que no ens doni sorpreses [3] i fer que les nostres aplicacions s'hi executin. L'argument que es dona a favor de desenvolupament de les aplicacions amb Forms, Delphi, VB, etc. en aquests moments és que és molt més ràpid desenvolupar en aquestes aplicacions que fer-ho en tecnologia web. En concret aquesta és l'excusa que em donà a mi el consultor amb qui discutia el tema. No he fet cap comparativa seriosa de velocitat de desenvolupament, sols he llegit alguns articles damunt el tema i tampoc hi havia massa diferència. El que sí m'he trobat és un problema que afecta a la velocitat de desenvolupament: quan fas una aplicació en un llenguatge com Forms o Delphi, la gent accepta que és una aplicació d'escriptori i mentre la disposició de botos i camps d'entrada els vagi bé, ja no hi ha més discussió. En canvi, quan l'aplicació és web, tothom és dissenyador! La comparativa entre ambdues tecnologies s'ha de fer amb els mateixos criteris, és a dir, o bé posant disseny a les aplicacions de Forms i totes les mandangueries que es demanen a les aplicacions web o bé deixant que una vegada s'ha establerta una línea mestre de disseny aquest es mantengui. Suposem però que tot i això el desenvolupament en Forms fos més ràpid, encara així hem de tenir en compte que és una tecnologia que ens limita:
  • A una aplicació web podem mesclar fàcilment els conceptes d'escriptori i el millor que ens dona la navegabilitat de la web. Fer enllaços, drill-down, mostrar informació contextual és inherent a les aplicacions web i en canvi duen força treball en les aplicacions d'escriptori.
  • La tecnologia de Forms és tancada i antiga, avançarà quan Oracle vulgui. La tecnologia web és fonamentalment oberta i ets tu quan tries que vols canviar. I el millor de tot, a la capa de presentació no hi ha més que html i javascript, per la qual cosa pots anar adaptant-te a la tecnologia segons te vagi millor sense afectar a l'usuari.
  • El control de versions. Per mi és fonamental poder tenir gent que pugui fer feina si cal en el mateix troç de codi, en el mateix paquet i dur un control estricte del que s'ha canviat i de qui ho ha canviat. Això és molt mal de fer quan hom programa en Forms i PL.
  • El factor humà. No dubt de la qualitat d'algú que avui en dia tengui com a màxima aspiració fer feina en Forms, però potser no és el tipus de gent que està oberta a canvis, que és capaç de trobar solucions imaginatives. En un entorn canviant les empreses han d'anar construint els seus equips de desenvolupament a partir de gent de pugui adaptar-se als canvis. Demà el negoci requerirà coses noves i haurem de ser capaços d'adaptar-nos. El factor humà és el que determina que l'èxit d'un projecte. La motivació i la qualificació dels programadors són un factor de primer ordre, el llenguatge de programació triat és un factor de segon ordre, i tots ens coneixem, és molt més motivant estar fent feina en tecnologies que tal com va el mercat informàtic poden queder sols per manteniments correctius i evolutius.
  • El manteniment. Afegir nova funcionalitat a una aplicació web sol ser cosa de programar-ho o trobar les llibreries necessàries, o potser pensar "la manera web" de fer les coses. Fins i tot si desenvolupam en llenguatges d'script (php, ruby, django) una actualització que no afecti a base de dades pot ser tan simple com fer un update de subversion.
N'hi ha que diuen que les aplicacions d'escriptori són mortes, que en el futur tot serà web. Jo no ho tenc tan clar, m'agrada la potència de la fulla de càlcul de l'OpenOffice i m'agrada que s'executi al meu PC, però sí és cert que cada cop hi ha menys aplicacions que no es puguin fer pensant en que s'executin en un navegador, i en el cas d'empreses grans, o empreses que tenen el suport informàtic externalitzat, que les aplicacions de gestió estiguin basades en tecnologia web els pot estalviar molts maldecaps i sobretot moltes despeses d'administració i actualització.
[1] Permeteu-me que classifiqui a Forms com a aplicació d'escriptori clàssica encara que s'executi mitjançant un navegador per diferenciar-la de les aplicacions que sols necessiten el navegador, sense jinitiator ni més històries. [2] En aquest cas el jinitiator pot ser un mal son. [3] El Firefox home!

2 comentaris, 0 trackbacks (URL) , Tags: Informàtica


Tractament de cadenes en Python

Escrit per Aaloy a 15 de April , 2007 a les 11:33 a.m.

El tractament de cadenes de Python és potser una d'aquelles coses que fan el llenguatge més potent. He fet feina amb altres llenguatges: C, C++, Forté, Pascal, Basic, ... i de lluny el tractament de cadenes de Python és el més clar, potent i a la vegada intuïtiu que m'he trobat, sols s'hi atraca un poc un llenguatge un tant esotèric anomenat icon al qual m'hi vaig aficionar ja fa molt de temps. Anem a veure un parell d'exemples: 
>>> a = "hola"
>>> b = ' món'
>>> print a+b
hola món
Com podem veure no import si feim servir cometes dobles o simples, i la concatenació de cadenes és simplement una suma. Tot i això hem de saber que les cadenes són també objectes i un dir ens dirà el que hi podem fer 
>>> dir(a)
['__add__', '__class__', '__contains__', '__delattr__', '__doc__', '__eq__',
'__ge__', '__getattribute__', '__getitem__', '__getnewargs__', '__getslice__',
'__gt__', '__hash__', '__init__', '__le__', '__len__', '__lt__', '__mod__', '__mul__',
'__ne__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__rmod__',
'__rmul__', '__setattr__', '__str__','capitalize', 'center', 'count', 'decode',
'encode', 'endswith', 'expandtabs', 'find', 'index', 'isalnum', 'isalpha', 'isdigit',
'islower', 'isspace', 'istitle', 'isupper', 'join', 'ljust', 'lower', 'lstrip', 'partition',
'replace', 'rfind', 'rindex', 'rjust', 'rpartition','rsplit', 'rstrip', 'split', 'splitlines',
'startswith', 'strip', 'swapcase', 'title', 'translate', 'upper', 'zfill']
Per exeple un help(a.zfill) ens dirà què fa aquesta funció 
Help on built-in function zfill:zfill(...)    S.zfill(width) -> string
Pad a numeric string S with zeros on the left, to fill a field
of the specified width.  The string S is never truncated.
(END)
És a dir, afegeix zeros a l'esquerra fins a l'emplada que volguem: >>> a.zfill(10) '000000hola' Juguem un poc més amb les cadenes, què us imaginau que passarà si multiplicam una cadena per un sencer? 
>> a*2
'holahola'
Bastant previsible, no? Python té aquestes coses, que pots preveure què passarà sense tenir-ne massa idea del llenguatge. Suposem ara que volem agafar trossos d'una cadena, python tracta les cadenes com a matrius de caràcters i per tant és possible fer coses com aquestes: 
>>> test = "hola món què 'passa' per aquí"
>>> print test[0]
'h'
>>> print test[0:4]
hola
>>> print test[:4]
hola
>>> print test[9:]
què 'passa' per aquí
>>> print test[9:22]
què 'passa'
>>> print test[9:-9]
què 'passa'
Fixem-nos en el darrer exemple, hem fet servir valors negatius per a referir-nos al final de la cadena. També podem fer coeses com un recorregut pels caràcters de la cadena amb 
>>> for char in test:
...     if char == "'":
...             print "cometa"
...
cometa
cometa
>>> [x for x in test if x > 'h']
['o', 'l', 'm', 'xc3', 'xb3', 'n', 'q', 'u', 'xc3', 'xa8',
'p', 's', 's', 'p', 'r', 'q', 'u', 'xc3', 'xad']
Però de llarg la meva preferida és la possibilitat de crear plantilles, a l'estil del printf de C o de les que darrerament ha incorporat Java 5, que ja era hora! 
>>> missatge="hola %s, avui vindré a les %i"
>>> print missatge % ('Maria', 10)
hola Maria, avui vindré a les 10
O fins i tot fer servir diccionaris per això: 
>>> missatge="hola %(nom)s, avui vindré a les %(hora)i"
>>> params = {'nom':'Catalina', 'hora':8}
>>> print missatge % params
hola Catalina, avui vindré a les 8
Me deix tota la part de funcions, expressions regulars i altres, això és sols per obrir boca, i potser ajudar a entendre a alguna gent del perquè el Python m'agrada tant. Us deix algunes referències:

0 comentaris, 0 trackbacks (URL)