nilart.com

El siguiente artículo, del blog Andoni Arroyo  de geeks.ms, representa muy bien, con un ejemplo cotidiano real, lo que suele ocurrirle al programador a la hora de construir una aplicación, especialmente si se saltan todos los procesos “que no sirven para nada”, pero bueno, esto es otra historia…

Os dejo el fragmento de texto:

La historia que os voy a contar está basada en hechos reales. Aprovechando que tengo unos días libres antes de salir de viaje me he dispuesto a acabar con la fila india de zapatos que tengo por casa. Así que ni corto ni perezoso me fui al Ikea y me cogí un zapatero de esos tan apañado que te montas en casa.

Me puse manos a la obra y decidí seguir las instrucciones que tan amablemente incluyen los suecos a modo de ”paso a paso”. Tras una revisión previa combinada con mis nulos conocimientos en bricolaje y ebanistería, me decidí a seguir los pasos indicados al pie de la letra. El resultado, os lo podréis imaginar, un zapatero impresionante con una de las tablas del frontal colocada al revés, es decir, un precioso acabado en madera virgen…

Me ha dado por pensar los motivos de este pequeño desastre y la analogía de los mismos en los proyectos de desarrollo de Software. Podemos decir que yo he sido el programador currillo que he recibido una serie de pequeñas tareas bien definidas. Estas tareas fueron creadas por un gran analista sueco como resultado de un diseño basado en el análisis de la funcionalidad a cubrir.

Por supuesto, no tengo ninguna duda de que el señor analista sueco creó las tareas de manera correcta en su contexto y en su momento. Lamentablemente en el proceso de “codificación” de mi zapatero se han dado algunas circunstancias inesperadas.

• Errores humanos
  Tras comprobar de nuevo las instrucciones observo que no se especifica explícitamente el lado que debe dar hacia el frontal y cual no. Obviamente mi decisión no fue la correcta.
• Falta de comunicación
  La verdad es que el analista sueco no me pillaba lo suficientemente a mano para completar las dudas que me surgían sobre el manual mientras avanzaba el desarrollo del proyecto.
• Falta de perspectiva e interiorización del alcance global del proyecto

He depositado mi confianza en el manual, sin llegar a interiorizar los componentes del proyecto. Si lo hubiese comprendido como un conjunto, me hubiera dado cuenta de que ese madero en el frontal dado la vuelta no encaja bien, pero para cuando  comprendí que eso era el frontal ya era demasiado tarde….

• Falta de revisiones
  Una pequeña revisión al finalizar cada paso o conjunto de pasos podría haber evitado la desviación. Esto me habría limitado la cantidad de pasos a deshacer para recolocar el maldito madero y por lo tanto, el esfuerzo (dinero en proyectos reales) malgastado en problemas que yo mismo me he buscado.

En el mundo del Software tanto las especificaciones como los entregables son más abstractos. Si no comprendemos bien las necesidades del cliente, (las que nos transmite y las que ni él mismo ha identificado aún!) podemos llegar a las oficinas del cliente con un software que le produzca mas enfado que satisfacción. Dichas necesidades en la mayoría de ocasiones nos son totalmente ajenas y desconocidas puesto que no conocemos profundamente el sector del cliente (Al menos en los primeros proyectos tipo!).

Sin trabajar este proceso de interiorización apoyado en la empatía, podemos entregar el zapatero al cliente sin enterarnos de que tenemos el madero al revés aunque lo estemos mirando con todo detalle…

Así que dicho queda, me voy a por la caja de herramientas de nuevo…

Ahora bien, no creo que Ikea invierta demasiado en las instrucciones, ya que yo también tengo un caso similar, aunque viendolo por otro lado, la mayoria de las empresas tampoco invierten en los procesos de diseño y documentación necesarios…

Fuente: Blog Andoni Arroyo – geeks.ms<

De la mano de CyberHades nos llega este Top 10 de frases mas usadas por programadores que la verdad es bastante fiel a la realidad, ahi os lo dejo:

1.- WTF! (Que coñ…!)

2.- It works on my machine (En mi equipo funciona).

3.- D´oh! (ouch!!).

4.- It will be ready tomorrow (Estará listo mañana)

5.- Have you tried turning it off and on again? (¿Has intentado apagarlo y encenderlo de nuevo?

6.- Why? (¿Por qué?)

7.- It is not a bug, it´s a feature (No es un error, es una característica).

8.- That code is crap (Ese código es una mierda).

9.- My code is compiling (Mi código está compilando).

10.- No, I don´t know how to fix your microwave (No, no sé como arreglar tu microondas).

Yo tambien añadiría:

11.- Has probado a tracear?

12.-Yo creo que…

13.- Seguro que es el antivirus…

14.- Estoy en ello…

15.- $·@#~€”·$%!!!

16.-Me tendría que haber dedicado a…

17.-Error humano

18.-Puta mierda de [pon aqui un lenguaje]

19.-Quiero irme a casa.

20.-Siempre ha funcionado perfectamente

Fuente: CyberHades

Blogeando por eso que llaman “El interné” he encontrado un artículo interesante sobre la gestión de proyectos en el que comparan este con el proceso de ir a comprar un coche, los resultados son bastante cómicos.

Cita:

Buenos días, me gustaría comprar un 750i, blanco, que le gusta a mi mujer de eso color, aunque a mi me parece un poco taxi. Taxi, un 750i, ni aunque le ponga lucecita verde hombre, ha dicho el comercial. Ya que estamos, no lo vamos a mirar, he seguido yo… póngamelo con llantas de 20’’, como no y todos los extras, lo quiero todo, todo y todo… si si el paquete M también, como no, yo soy un joven, dinámico y profesional, no puedo ir por el mundo sin el paquete M, faltarías más.

¿No sería interesante añadir también la garantía extendida? Por su tranquilidad, ya sabe. Ha dicho el comercial. Y claro, pues yo he pensado… como no se me habrá ocurrido, póngalo, póngalo. Quizás no lo use pero que le vamos a hacer, nunca se sabe lo que puede pasar.

Y la bola de caravana, ¿no la necesitará usted?… Hombre, yo no tengo caravana, pero ya que lo comentas, y como nunca se sabe, a lo peor me da por cambiar el pueblo por un camping… venga vale, total, molestar tampoco molesta.

Y claro, seguro que un profesional, joven, dinámico, con paquete M y toda la zarandaja es una avezado ciclista, de los de mountain bike molona, de esos de los de gafas Oakley, maillot, culotte, zapatillas y pedales automáticos ¿no? Seguro que necesita el exclusivo portabicicletas de BMW para pasear, digo transportar sus bicis. Pues no, he dicho yo, eso si que no, que yo hace mucho que deje la bici y soy de pelota mano y tal y cual. Hombre, recuerde que nunca se sabe, ha dicho el comercial, y se lo dejo a precio de risa, a añadido. Así que he pensado, por si acaso, con portabicis, ¿voy a saber yo más que el comercial?.

Ya solo nos quedan dos detalles menores. Empecemos por el plazo de entrega. El comercial a empezado a farfullar no se que de disponibilidad, que si las opciones retrasan no se que y no se cual. Yo he pensado, coño, aquí el cliente soy yo ¿no? y le he dicho… a ver si yo lo entiendo todo, pero me lo tienes para dentro de dos semanas, son fiestas del pueblo y tengo que fardar. El comercial no ha dicho ni mu, es más me ha dicho, que quizás lo tenga un poco antes.

El segundo tema menor, el precio. Aquí yo he tomado la iniciativa que para algo soy el cliente ¿no?. Para esto tengo treinta mil euritos, entiendo que tengo que poner otros dos cientos, por la llantas, pero esto es lo que hay. Me han dicho que en la india hay unos concesionarios que lo hacen más barato y mejor, eso sí, por evitarme el papeleo que sino te iba a comprar al ti el BMW Rita… la cantadora.

Entonces me he despertado. Claro. ¿Por qué estas cosas solo nos pasan en el mundo del software? La historia no se sostiene, claro está, pero cambiad BMW por aplicación de software, y dar sudores fríos el pensar realismo que se añade. ¿Alguno de vosotros le suena?

Es bueno, ¿verdad?

Fuente: Geeks.ms

Una técnica frecuente cuando realizamos grandes proyectos web es crear un log o registro de todos los errores que suceden en el servidor de nuestra aplicación web, de manera que, aunque no estemos depurando podamos conocer cuando y donde falla nuestra aplicación. Es especialmente útil cuando es utilizada por un gran numero de usuarios, pues estos siempre acaban encontrando fallos.

Sin embargo, en muchos casos, nos habremos dado cuenta de que la descripción del error que nos aparece, a pesar de ser muy detallada, no nos da una información esencial, la clase donde ocurre el error y la linea.

Estos datos se obtienen facilmente en el equipo local cuando depuramos, pero se pierden cuando la aplicación se ejecuta en el servidor con el debug desactivado. Para añadir esta información a la descripción del error deberemos hacer dos cosas:

1.- En las propiedades del proyecto, dentro del Visual Studio, debemos ir a la pestaña Compilar y a Opciones de compilación avanzadas. Dentro cambiaremos “Generar información de depuración” a pdb-only.

2.- Ahora solo tenemos que volver a generar nuestra aplicación  y recordar subir el fichero .pdb del proyecto que se genera junto a la dll en la carpeta “bin”.

Con este método obtendremos en la información del Stack, el nombre del fichero donde ocurre el error y la linea exacta en la que se lanzó la excepción.

Otro día explicaré el método entero parar generar un log de errores, pero esto, mediante un poco de Google, es bastante sencillo.
Saludos

Buscando información en mi amigo Google he encontrado un artículo muy interesante a la hora de programar en ASP.NET. Es muy interesante, yo conocia y uso algunas, pero otras me han sorprendido y van a pasar a mi lista de mandamientos…

El texto esta en inglés y no me motiva demasiado traducirlo:
There are certain things you should take into account when you are developing your applications. Over the last 12 years or so of working with asp and asp.net, I have learned to avoid and do certain things that increase your application performance by a massive amount! Below are my top tips to improving ASP.net application Performance.

1. Disable Session State
Disable Session State if you’re not going to use it. By default it’s on. You can actually turn this off for specific pages, instead of for every page: You can also disable it across the application in the web.config by setting the mode value to Off.

2. Output Buffering
Take advantage of this great feature. Basically batch all of your work on the server, and then run a Response.Flush method to output the data. This avoids chatty back and forth with the server. Then use:

2. Avoid Server-Side Validation
Try to avoid server-side validation, use client-side instead. Server-Side will just consume valuable resources on your servers, and cause more chat back and forth.
3. Repeater Control Good, DataList, DataGrid, and DataView controls Bad
Asp.net is a great platform, unfortunately a lot of the controls that were developed are heavy in html, and create not the greatest scaleable html from a performance standpoint. ASP.net repeater control is awesome! Use it! You might write more code, but you will thank me in the long run!
Take advantage of HttpResponse.IsClientConnected before performing a large operation:

if (Response.IsClientConnected)
{
// If still connected, redirect
// to another page.
Response.Redirect(“Page2CS.aspx”, false);
}What is wrong with Response.Redirect? Read on…

4. Use HTTPServerUtility.Transfer instead of Response.Redirect
Redirect’s are also very chatty. They should only be used when you are transferring people to another physical web server. For any transfers within your server, use .transfer! You will save a lot of needless HTTP requests.
5. Always check Page.IsValid when using Validator Controls
So you’ve dropped on some validator controls, and you think your good to go because ASP.net does everything for you! Right? Wrong! All that happens if bad data is received is the IsValid flag is set to false. So make sure you check Page.IsValid before processing your forms!

6. Deploy with Release Build
Make sure you use Release Build mode and not Debug Build when you deploy your site to production. If you think this doesn’t matter, think again. By running in debug mode, you are creating PDB’s and cranking up the timeout. Deploy Release mode and you will see the speed improvements.
7. Turn off Tracing
Tracing is awesome, however have you remembered to turn it off? If not, make sure you edit your web.config and turn it off! It will add a lot of overhead to your application that is not needed in a production environment.

8. Page.IsPostBack is your friend
Make sure you don’t execute code needlessly. I don’t know how many web developers forget about checking IsPostBack! It seems like such a basic thing to me! Needless processing!
9. Avoid Exceptions
Avoid throwing exceptions, and handling useless exceptions. Exceptions are probably one of the heaviest resource hogs and causes of slowdowns you will ever see in web applications, as well as windows applications. Write your code so they don’t happen! Don’t code by exception!
10. Caching is Possibly the number one tip!
Use Quick Page Caching and the ASP.net Cache API! Lots to learn, its not as simple as you might think. There is a lot of strategy involved here. When do you cache? what do you cache?
Create Per-Request Cache
Use HTTPContect.Items to add single page load to create a per-request cache.
11. StringBuilder
StringBuilder.Append is faster than String + String. However in order to use StringBuilder, you must new StringBuilder()Therefore it is not something you want to use if you don’t have large strings. If you are concatenating less than 3 times, then stick with String + String. You can also try String.ConcatTurn Off ViewState
If you are not using form postback, turn off viewsate, by default, controls will turn on viewsate and slow your site.

public ShowOrdersTablePage()
{
this.Init += new EventHandler(Page_Init);
}

private void Page_Init(object sender, System.EventArgs e)
{
this.EnableViewState = false;
}

12. Use Paging
Take advantage of paging’s simplicity in .net. Only show small subsets of data at a time, allowing the page to load faster. Just be careful when you mix in caching. How many times do you hit the page 2, or page 3 button? Hardly ever right! So don’t cache all the data in the grid! Think of it this way: How big would the first search result page be for “music” on Google if they cached all the pages from 1 to goggle
13. Use the AppOffline.htm when updating binaries
I hate the generic asp.net error messages! If I never had to see them again I would be so happy. Make sure your users never see them! Use the AppOffline.htm file!
14. Use ControlState and not ViewState for Controls
If you followed the last tip, you are probably freaking out at the though of your controls not working. Simply use Control State. Microsoft has an excellent example of using ControlState here, as I will not be able to get into all the detail in this short article.
15. Use the Finally Method
If you have opened any connections to the database, or files, etc, make sure that you close them at the end! The Finally block is really the best place to do so, as it is the only block of code that will surely execute.
16. Option Strict and Option Explicit
This is an oldy, and not so much a strictly ASP.net tip, but a .net tip in general. Make sure you turn BOTH on. you should never trust .net or any compiler to perform conversions for you. That’s just shady programming, and low quality code anyway. If you have never turned both on, go turn them on right now and try and compile. Fix all your errors.