Blogalia

"En el arte marcial como en la vida diaria. En la vida diaria como en un arte marcial."

Aikido

Sígueme en Twitter

<Octubre 2017
Lu Ma Mi Ju Vi Sa Do
            1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
29 30 31        


Todas las Historias

VELOCIDAD DE ESCAPE

Inicio > Historias > RESUMEN Y EXPECTATIVAS VISUAL STUDIO

2005-05-06

RESUMEN Y EXPECTATIVAS VISUAL STUDIO

Si algunos de vosotros os dedicais como yo, a la creación de aplicaciones que residen en intranets corporativas, probablemente habéis llegado a la conclusión de que la mejor relación coste/beneficio implica usar el modelo cliente-servidor n-capas y ofrecer una interfaz web para vuestros clientes. El tiempo de desarrollo se acelera y los problemas de implementación e instalación son menores.
Pero claro, no todo son parabienes. En este modelo de desarrollo uno ha de enfrentarse a determinadas características inherentes al entorno, como son la ausencia de estado, lentitud de respuesta, riqueza e interactividad del interfaz, que intentamos solventar cada uno con sus propias ideas y conocimientos.
En mi caso el uso de una usabilidad estricta al estilo Jakob Nielsen (nada de imagenes ni chorraditas salvo las estrictamente necesarias) y un acercamiento al diseño del software basado en lo que el cliente desea ver en su pantalla más que en lo que el programa tiene que hacer entre "bambalinas". Vamos, que me siento con el usuario y definimos una a una las pantallas del programa y lo que quiere que suceda en cada caso.
Hasta ahora me ha ido bien con esta aproximación, pero claro, nos enfrentamos con las limitaciones características del ASP en mi caso y supongo que similares problemas con PHP o JSP. Queda claro desde el primer momento que no es lo mismo crear clientes pesados que aplicaciones ligeras que funcionan con navegador. El potencial de los clientes pesados está en estos momentos a mucha distancia de lo que una aplicación Web puede hacer aunque usemos tecnologías de servidor, y si habéis desarrollado una aplicación contable con generación de recibos y diversas operaciones matemáticas en cliente sabréis a qué me refiero. Más allá de los problemas que se presentan cuando el usuario deja un proceso a medias y se va a tomar café, o cuando quiere imprimir una relación de recibos en un formato determinado, o simplemente subir, bajar o generar archivos para uso posterior, que resolvemos con mejor o peor fortuna, nos encontramos con que tras la llegada de ASP NET a bombo y platillo NO EXISTE UN IDE REALMENTE ADECUADO PARA DESARROLLAR CON ASP NET.
Ni siquiera el Visual Studio, que considero el mejor entorno de desarrollo de aplicaciones existente, cumple su cometido si lo que queremos es desarrollar una simple página web que nos dé acceso a una aplicación con otra capa de datos y su correspondiente lógica de negocio.
Durante los últimos años la creación de Web dinámicas dirigidas por datos se ha convertido en un proceso casi estándar que permite la creación de entornos de desarrollo que aceleren cuantitativamente el proceso. Con el ASP tradicional y el uso de VBSCript no había problema ninguno porque un simple bloc de notas algo mejorado era suficiente. Yo he probado varios y que quedo con EditPlus o mejor aún Homesite.
Con la llegada del ASP NET tenemos una herramienta potente y versátil para matar moscas a cañonazos. Muy bueno lo de crear clases, lo de compilar, las herramientas de depuración...todo muy bonito. Pero claro, prueben ustedes simplemente a cambiar de la vista de código a la vista HTML y después vuelvan atrás. El galimatías generado es capaz de romperle los nervios al más templado. El formateado y las etiquetas han mutado a una jerigonza que para más inri no guarda ninguna adecuación con ningún estándar. Y eso para no hablar de que desaparecen las conexiones entre un evento y su manejador cuando menos te lo esperas.

Hay que reconocer que Visual Studio no fué diseñado teniendo en mente a los desarrolladores ASP. Muy bueno para crear las librerias de clases que necesitemos para nuestros proyectos (objetos de negocio, capa de acceso a datos, etc) y muy bueno también para los que trabajamos intensivamente con bases de datos (procedimientos almacenados, creación y vista de tablas), pero cuando hay que maquetar la interfaz el diseñador es el mayor fracaso que he visto en mi vida. Por su cuenta y riesgo asume que es más listo que nosotros y mete etiquetas donde le da la real gana además de que se pasa el estándar XHTML por el arco del triunfo.
No sólo eso. Cada vez que creamos un proyecto se crea un nuevo directorio virtual en IIS, una nueva carpeta, y un chorro de nuevos archivos que no sabemos realmente para qué demonios sirven. Como hagas muchas pruebas o seas un poco desordenado al final tienes el directorio C:\Inetpub\wwwroot que para busar algo allí hay que ir con casco de espeleólogo y látigo de Indiana Jones. Y no vamos a hablar de mover cualquiera de esos innumerables proyectos a otra máquina. Tarea nada fácil. Si habéis intentado facilitaros la vida planificando bien el diseño con una plantilla para el sitio, CSS, imagenes, y demás, al final habréis dejado el tema por imposible y recaído en los viejos vicios. El mío se llama DreamWeaver MX. Para rematar la faena, por narices tenemos que usar el Code-Behind en vez del Inline-Code, los controles de usuario son una caja tonta gris, no hay FTP para colocar los archivos en el server, etc...

Algunos dirán: ¡ pues usa WebMatrix !. Vale, WebMatrix tiene FTP, maneja mejor los controles de usuario en su vista de diseño, es ligero (1,3 MB) y fácil de usar. No necesita IIS sino que usa Cassini, un servidor Web interno que elimina dependencias del Sistema Operativo. Pero no tiene para mí lo más importante: intellisense y depuración asistida.

Por eso es que estoy (estamos) esperando con ansiedad la llegada del nuevo Visual Studio NET 2005 porque todo indica que a diferencia de su versión anterior, ha sido diseñado con los programadores Web en mente. El diseñador no toca las etiquetas, no necesita IIS para funcionar porque lleva un servidor web al estilo de Cassini y además podemos crear un proyecto web en cualquier parte del disco duro, no solo en WWWROOT, MasterPages para unificar el diseño, y controles de usuario correctamente renderizados en el diseñador. En la misma linea van las herramientas Expréss. Concretamente Visual Web Developer 2005 incluye para mí lo esencial, el intellisense y las herramientas de depuración. Con el añadido espectacular de que podemos utilizar Inline-code rodeando nuestro código con las etiquetas script dentro de la página ASPX y seguir accediendo a Intellisense y depuración para dicho bloque de código.

¿alguien da más?

Programación | jomaweb | 14 Comentarios | Enlace


Referencias (TrackBacks)

URL de trackback de esta historia http://jomaweb.blogalia.com//trackbacks/29487

Comentarios

1
De: Guille Fecha: 2005-05-06 11:48

Soy nuevo en esto. Empecé a utilizar ASP.NET hace tan sólo dos meses (más unos 4 previos de estudio). Como ves, novato perdido. Pero, otra vez, has dado en el clavo.

No he probado WebMatrix, y por ello no se si es mejor o peor, pero Visual Studio tiene exactamente lo que tu dices: depuración asistida. Pero no todo es un campo de flores, y es verdad que a Visual Studio le faltan algunos retoques, y esto sí que lo he podido comprobar en mi poco tiempo de trabajo.

Efectivamente, en mi carpeta WWWROOT encuentro mil carpetas de proyectos a medias, pruebas, etc. Algunos ni siquiera los puedo borrar, y algunos archivos no se ni lo que son. Ahora ya soy mas ordenado, eso sí.

Pero, como dices, lo peor reside en "hacer" un proyecto, digamos, "externo" a nuestro equipo. Tarea nada sencilla, o no tan sencilla como debiera en un principio. Y el diseño de interfaz, malo malo (por dios, que nadie mire el código en HTML, porque es un laberinto infinito).

Espero, en conclusión, que el nuevo Visual Studio arregle todos esto. Si lo consigue... será la mejor herramienta que exista en este ámbito, sin duda.



2
De: Epaminondas Pantulis Fecha: 2005-05-06 11:50

Vamos, que me siento con el usuario y definimos una a una las pantallas del programa y lo que quiere que suceda en cada caso.

Esa es la clave. De hecho, el manual de usuario debería ser el documento de especificación.



3
De: Anónima Fecha: 2005-05-06 12:25

Caray, JomaWeb, que integración vertical del trabajo: en mi trabajo anterior, los que nos sentábamos con el cliente/usuario erámos los de ingeniería, escribímaos el Análisis Funcional y luego se lo pasábamos a los de software para hacer el análisis orgánico y la programación.

¡Y por lo que cuentas tu te lo guisas y tu te lo comes todo solito!

Y estoy con Epaminondas, anque me parece un poco radical: el documento de especificación es para los de software, que saben de software pero no de la aplicación, y el manual para el usuario, que sabe de la aplicación pero no de software. Vamos que los enfoques son distintos, pero los dos documentos describen lo mismos - o deberían :)



4
De: Epaminondas Pantulis Fecha: 2005-05-06 12:32

"Vamos que los enfoques son distintos, pero los dos documentos describen lo mismos - o deberían"

Bueno, al menos en mi experiencia, si algo lo entiende un cliente, lo entiende un desarrollador porque éstos al cabo del tiempo terminan conociendo también el dominio del problema.



5
De: jomaweb Fecha: 2005-05-06 12:45

Pues sí Anónima, yo me lo guiso y me lo como todo. Ah, y eso se llama ¿integración vertical?. Yo lo llamo "falta de personal", o más bien, "descontrol organizacional".

Yo soy de la opinión de Epaminondas. Si está claramente explicitado, el manual del usuario es idéntico al documento de especificación. Al margen de que luego en el departamento hagamos otro tipo de manuales.



6
De: Anónima Fecha: 2005-05-06 12:52

Claro, a veces les cuesta salir de los bits y los bytes, pero con un poco de esfuerzo acaban aprendiendo también de la aplicación :D

De las muchas anécdotas al respecto recuerdo así, a bote pronto, un cliente, RENFE, que necesitaba tags creo que con 10 letras y números para que tuvieran sentido para ellos (3 letras estación, 3 letras dispositivo y 2 letras estado). Y al responsable de software peleando como gato panza arriba que no, que no necesitaban eso, que con un número secuencial iban que chutaban que el cambio de agujas 7 de la estación de León, estaba tirado memorizar que era el equipo 321 y el semáforo 8 de la misma estación el equipo 322...y que en toda la línea jamás se iba a superar el límite de 999 dispositivos.

Vamos que me refería a que no vale con darle el manual de usuario a la gente de software porque se dan por sentado muchas cosas de la aplicación que los desarrolladores no saben y se cuentan muchos detalles de manejo de pantallas de forma muy repetitiva, que a los de desarrollo les sobran.

Pero en cuanto al fondo del asunto tienes razón, como JomaWeb, se debe programar orientado a resolver las necesidades del usuario y aunque suena de perogrullo, lamentablemente no siempre es así ni se escucha al usuario antes de programar.

Ahora que me he convertido en usuaria me toca sufrirlo a veces con los programas que hacen los de informática de la Oficina. Y también oir comentarios como "pues lo pone bien claro en el manual que hay que cerrar dando al botón de cerrar y no al aspa de windows" y el botón de cerrar está todo lo más lejos del aspa de windows lo que hace que sea totalmente anti-intuitivo ... Enfin.

Me vuelvo a mis informes ...



7
De: Anónima Fecha: 2005-05-06 12:58

se ve que todavía no :)

JomaWeb,

Dije integración vertical del trabajo, es una nueva forma de management para tu lista, no está bien eso de calificar negativamente aspectos tan innovadores del management ¿que es eso de falta de personal? o ¿descontrol organizacional? Eso no son expresione políticamente correctas en el mundo empresarial, hombre. ¿En qué estarías tu pensando, que normalemente eres tan diplomático?

XDDDD



8
De: jomaweb Fecha: 2005-05-06 14:27

Me habían llamado muchas cosas, pero diplomático....
XD



9
De: Leonardo Herrera Fecha: 2005-05-06 18:47

¿Sharp Develop?



10
De: JOMAWEB Fecha: 2005-05-06 19:53

Es desde luego el mejor si lo que miramos es el coste.



11
De: achaval Fecha: 2005-05-07 02:25

Muchas discusiones pero se olvidaron que guille no puede limpiar el servidor web. guille, para poder eliminar las carpetas debes parar IIS y luego si, shift+delete, jeje, o a la papelera en caso de querer recuperarlo.
Ahora bien queria hacer un comentario de que todos los proyectos web se crean dentro wwwroot, con iis se pueden mapear directorios virtuales que apunten a directorios que nosotros queramos, y luego ahi creamos todo nuestro proyectito y mantendremos todo ordenado.

Saludos desde el otro lado del charco. :-)



12
De: r Fecha: 2005-11-15 18:55

odio visual studio!!!!!!!!!!!!!!!!!!!!!!!111111



13
De: cucuniqui Fecha: 2007-03-14 19:27

es mi perrita, asi la llamo..
la colubis :)



14
De: cucuniqui Fecha: 2007-03-14 19:51

Disculpen, me equivoqué de foro y confundí las ventanas.



Nombre
Correo-e
URL
Dirección IP: 54.162.154.91 (06b1d18c38)
Comentario