[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [mindfood] Sobre frameworks
- To: <mindfood@xxxxxxxxxxxxxxx>
- Subject: RE: [mindfood] Sobre frameworks
- From: "miniOnion" <javi@xxxxxxxxxxxxx>
- Date: Thu, 27 Oct 2005 21:42:54 +0200
- Delivered-to: mailing list mindfood@orange-soft.com
- Delivered-to: moderator for mindfood@orange-soft.com
- In-reply-to: <200510251131.15345.chous@acm-sl.org>
- Mailing-list: contact mindfood-help@orange-soft.com; run by ezmlm
- Thread-index: AcXaz4Eps0/vRpURQMq0CGy4uwpgtwAXH4NA
Aunque parezca un reply no lo es; quiero contar mi experiencia en el papel
de diseño de interacción - diseño web, así que estimado José, es posible que
sigas todavía sin saberlo...
Mi experiencia con frameworks (struts en este caso) no es muy diferente al
trabajo en proyectos que no los utilizan.
En un caso se me vendió la moto de separar lógica de la interfaz, y ya sea
por la desidia del programador o la falta de comunicación indispensable, los
diseñadores nos las veíamos y deseábamos para poder encajar un triste
formulario (por mucho estándar que utilizásemos). No voy a negar que
mediante un trabajo escrupuloso la economía en el código resultaría
rentable, y la reutilización del mismo beneficiosa, pero no hasta el punto
de decir "todo está hecho, que entren los [p****s] diseñadores".
En otro caso, y con una colaboración estrecha entre diseñador-programador,
sin volvernos locos, en un proyecto pequeño, se conseguía dar salida a casi
cualquier función mediante una interfaz adecuada y mínimamente "sobada". La
parte de diseño siempre era escuchada y el programador siempre dispuesto a
colaborar. Resultado: que se consiguió separar realmente la lógica de la
forma y casi cualquier cambio estético se dejaba finalmente al CSS.
No estoy dando una visión sesgada hacia el lado "diseñatorio". Muchos de los
requisitos del cliente mezclan la función con la presentación y te puedo
asegurar que un programador sólo no lo saca adelante (y menos un triste
diseñador/analista interfaz/diseñador de interacción). Estoy hablando por
supuesto de lo que no está contemplado por prototipos, maquetas, guias de
estilo, análisis funcional, etc... es decir, todo lo sobrevenido y
sobresobeteado por el dpto. de turno (comunicación, marketing, sistemas,
etc.)
Humildemente, my two cents...
_______________________________________
javier martínez solera
interaction designer \ minionion.com
-----Mensaje original-----
De: Jose San Leandro [mailto:chous@xxxxxxxxxx]
Enviado el: martes, 25 de octubre de 2005 11:31
Para: mindfood@xxxxxxxxxxxxxxx
Asunto: [mindfood] Sobre frameworks
Hola,
Puede que esté equivocado, pero, después de hablar con distintas personas
dedicadas al desarrollo Java profesionalmente, me llama la atención la
enorme
acogida de los denominados *frameworks*, de la naturaleza que sean. A pesar
de la variedad, el pastel se lo han repartido entre unos pocos.
Supongo que todos los conocéis, aunque sea de oídas o de artículos online:
Struts/WebWork/Spring/Laszlo, Hibernate/IBatis/Spring/..
HIvemind/PicoContainer/Spring, etc. De hecho, ya son puntos fijos en los
currícula. Incluso hay muchos otros internos a cada empresa, que cumplen los
mismos objetivos.
Yo, personalmente, creo que la existencia de tantos se debe poco a aspectos
técnicos y mucho a preferencias y estilos, a lo que hay que unir que las
licencias open-source no luchan en absoluto con la resistencia empresarial a
aportar mejoras sobre los proyectos que usan.
En la fase de elección de tecnologías, se evalúan fundamentalmente los
conocimientos, experiencia y preferencias de los desarrolladores respecto a
cada alternativa.
Lo curioso es que es frecuente que, si se decide utilizar un framework
distinto al preferido, un porcentaje de los desarrolladores demostrarán
rechazo y falta de motivación, que se verá acentuada por un factor: el
cociente entre el número de lineas de código que deba escribir usando un
framework frente a otro.
En otras palabras, un aspecto técnico, como es la decisión de qué framework
es
el idóneo para un proyecto dado, se evalúa usando un criterio casi
exclusivamente económico, y termina dependiendo de factores psicológicos: me
gusta/no me gusta, me hace trabajar más/menos.
A título personal, mi resistencia a usar determinadas tecnologías es
elevadísima, pero, a nivel estrictamente técnico, la razón primordial es
siempre la misma: ¿puedo modificarlo, estudiarlo, etc.? En otras palabras,
¿puedo fiarme? En el caso peor, ¿tengo la seguridad de que solucionarlo sólo
depende de mi y del tiempo que invierta en ello?
Supongo que parte del auge se basa en que los factores económicos a nivel de
empresa y la pereza del desarrollador confluyen en este caso, de forma que
parece que "una línea de código es mejor que 10", sin necesitar ningún tipo
de argumentación. ¡Abramos la caja del "sentido común" y aceptémoslo sin
más!
Seguramente muchos no estéis de acuerdo conmigo, pero como nunca hay
"replies", me quedaré sin saberlo...
Un saludo,
Jose.
---------------------------------------------------------------------
Permalink: http://www.orange-soft.com/mindfood/archive/msg00<#n#>.html
Post to delicious: http://www.orange-soft.com/postdelicious?msg=<#n#>
To unsubscribe, e-mail: mindfood-unsubscribe@xxxxxxxxxxxxxxx