Equipos de pruebas de sistemas / Test team

Equipo de pruebas

Existe un pensamiento generalizado que el equipo de pruebas de sistemas y los desarrolladores del mismo son enemigos naturales. Posiblemente en un pasado esto fue así, pero ahora con la necesidad de siempre entregar software libre de errores, se hace necesario que exista una relación de fraternidad entre ambos equipos. Los desarrolladores no son capaces de entregar un software 100% libre de errores, no importa que tanta experiencia tengan, esta es la realidad. Un ingeniero desarrollador puede ser muy profesional pero no puede imaginarse todos los escenarios donde su software va a estar presente, por eso nacieron los ingenieros de pruebas. Así como un ingeniero de desarrollo experimentado no le tiene miedo a crear nuevo software para casi cualquier requerimiento, un ingeniero de pruebas con mucha experiencia es capaz de encontrar errores en el software desarrollado.

Incluso las grandes empresas desarrolladoras de software, conscientes de esto, han optado por volver “probadores” a todos sus clientes potenciales, entregando versiones “Beta” libres para descargar y “reportar” errores al fabricante.

Una empresa que se dedica a generar software de excelente calidad, debe tener un equipo de pruebas de alta calidad y fomentar el buen ambiente entre desarrolladores y probadores, ellos garantizarán que el software va a llegar al cliente con una cantidad mínima de errores… Porque mínima? porque una vez el software es aprobado para entrega al cliente existe al menos un 1% de probabilidad de que el cliente encontrará errores adicionales.

NO EXISTE un software 100% libre de errores, todos lo sabemos, todos hemos usado Windows, Linux, Mac, IPhone, BlackBerry, Android, WindowsPhone, etc.

Error Blackberry	Error Ipad
Error Iphone	Error Iphone
Error Linux	Error Mac
Error Windows Phone	El clásico, error Windows

C# + SQL Server developer best practices / Mejores prácticas desarrollador SQL Server + C#

For a developer, start to develop, save data, query data and update data sometimes is the only goal needed for an specific project. Once the project is installed the problems arrive being the first one and most problematic: ”too slow”

To prevent this, developers need to construct software that prevents slow performance when executing process on SQL Server databases:

1. Check Indexes with DBA. DBA is there because his expertise working with data, so share with them your indexes to understand the best performance while constructing code, and make a plan when changing to production.

2. Do not create ad-hoc queries. Database performance is really affected by using “burned queries” with instructions like “..where state=’Open’”, you must implement as much as you can queries inside stored procedures with parameters, this way SQL Server will create easily reusable “cache execution plans”.

3. Do not run everything on server side. The use of stored procedures to run the entire application logic on the server is not good, there are a lot of small/medium result size queries that can be handled on client side. Do not affect the database performance by applying any single queries on stored procedures.

4. Avoid to query a lot of data. Bringing too much data when you need only a few records is a bad practice. If that amount of data is needed, always use pagination in the application, this will bring more data only when user request it.

5. Use views. The normal use of views allows SQL Server to create “cache execution plans”, this means next time you call the view, this is optimized to bring data in shortest time.

6. Do not use Cursors. Developers always will find a good reason to create cursors in their stored procedures. Try to avoid this as much as you can because these are very costly in processor and memory for the server. This executes one row at a time.

7. Good Design database. To prevent the use of over joining when querying data. Up to 10 joins in a single query are normal, more than that mean that your design may be in bad design. If you have this problem, try to Normalize your database share some work with the DBA.

8. Use roles to handle security. There are a lot of job in SQL server security to avoid it by using sysadmin or “sa” accounts. If you don’t understand how the security works in the database, take your time to talk to DBA and together prepare some users/ roles to use in the application and avoid the use of “super users”.

9. Design the proper audit system. A lot of projects miss to define the audit system from the beginning and tries to do it after the project was implemented, big mistake. Ask the management/stakeholders what kind of auditory will be needed for the project and apply it from the start of the project.

10. Prepare the test environment. Testing is one of the best and needed tools to guarantee the project will be working as needed. Do not hesitate to help testers with any information they need to test the entire project. If the project fails, the construction of the code is the first implicated.

This rules can be applied to any other database, this is most like generic thinking about database development process.

*************************************************Español:

Para un desarrollador, empezar a desarrollar, guardar los datos, los datos de consulta y actualización de datos es a veces la única meta necesaria para un proyecto específico. Una vez que está instalado el proyecto los problemas llegan, siendo el primero y más problemático: “demasiado lento”

Para evitar esto, los desarrolladores necesitan construir software que no tenga rendimiento lento cuando esté en ejecución en bases de datos SQL Server:

1. Compruebe índices con el DBA. El DBA está ahí por su experiencia de trabajo con los datos, por lo que vale la pena compartir con ellos los índices y retroalimentarse mientras la construcción de código y hacer un plan al cambiar a la producción.

2. No crear consultas ad-hoc (al instante). El rendimiento de la base de datos será muy afectado por el uso de “consultas quemadas” como “..where estado=’Abierto’”, debe poner en práctica siempre que pueda consultas dentro de procedimientos almacenados con parámetros, así SQL Server creará “planes de ejecución de caché” fácilmente reutilizables.

3. No pase todo el lado del servidor. El uso de procedimientos almacenados para ejecutar toda la lógica de la aplicación en el servidor no es bueno, hay una gran cantidad de consultas pequeñas / medianas en resultado como en la instrucción, que se pueden manejar en el lado del cliente. No afectar el rendimiento de la base de datos mediante la aplicación de cientos de consultas individuales en procedimientos almacenados.

4. Evite consultar una gran cantidad de datos. Llevar demasiados datos cuando se necesita sólo unos pocos registros es una mala práctica. Si en realidad necesita esa gran cantidad de datos, use siempre la paginación, esto traerá más datos sólo cuando el usuario lo solicite.

5. Utilice views. El uso normal de views permite que SQL Server cree “planes de ejecución cache”, esto significa que la próxima vez que llame a la vista, estará optimizada para llevar los datos en menor tiempo.

6. No utilizar los cursores. Los desarrolladores encuentran siempre una buena razón para crear cursores en sus procedimientos almacenados. Trate de evitar esto tanto como sea posible ya que estos son muy costosos en el procesador y la memoria del servidor, porque ejecuta una fila a la vez.

7. Un buen diseño de la base de datos. Para evitar el uso de joins excesivos al consultar datos. Hasta 10 joins en una sola consulta son normales, más de eso quiere decir que su diseño puede estar malo. Si usted tiene este problema, trate de normalizar su base de datos, compártale trabajo al DBA.

8. Utilice los roles para manejar la seguridad. Hay un montón de trabajo en la seguridad del servidor SQL para tratar de evitarlo mediante cuentas “sa” o sysadmin. Si usted no comprende cómo funciona la seguridad en la base de datos, tome su tiempo para hablar con el DBA y juntos preparen algunos usuarios / roles para usar en la aplicación y evitar el uso de “súper usuarios”.

9. Diseñar un sistema de auditoría adecuada. Una gran cantidad de proyectos no define el sistema de auditoría desde el principio y trata de hacerlo después de que el proyecto se implementa, gran error. Haga la gestión de preguntar al equipo administrativo / stakeholders de que tipo de auditoría será necesaria para el proyecto y aplíquela desde el inicio del proyecto.

10. Prepare el entorno de pruebas. Las pruebas es una de las mejores y más necesarias herramientas para garantizar que el proyecto va a funcionar. No dude en ayudar a los testers con cualquier información que necesiten para poner a prueba todo el proyecto. Si el proyecto fracasa la construcción del código es la primera implicada.

Estas reglas se pueden aplicar a cualquier otra base de datos sobre la cual se haga un desarrollo.

Software development technologies (Introducing SAL: Software Assembly Line)- Tecnologías de desarrollo de software

When searching on internet to find the best method to create or modify software what will we find? A LOT of methods, architectures, patterns, etc. How can we deal with that? what to trust? If we know someone that is using some of these methodologies and it’s working fine, we can start with that, but what if we don’t? Just to list some of the actual methodologies (to know more about any of them, just search the name listed plus the word methodology):

1. Waterfall
2. EVO
3. Crystal
4. EUP
5. AUP
6. EssUP
7. OpenUP
8. MSF
9. FDD
10. CMMI
11. PMBOK
12. Prince2
13. DSDM
14. RUP
15. LeanSD
16. USDP
17. XP
18. Scrum
19. Prototype
20. Spiral
21. ……and a lot more

So, what is the main goal of all of these methods? Answer: to create excellent software. And all they have the same sources as well: Stakeholders, Processes and Data. Nothing else, so when in this life this becomes so complicated?

Trying to get the best results people or engineers use existing methods to create new ones.

Starting with the fact that the source to create software is Always the same we can deduct this:

1. Stakeholders, processes and data are the sources to create the software.
2. We need to understand in the most exact way the requirements for the software talking with stakeholders until we and they are complete sure everything related is correctly written.
3. Create a design for the new software and show it to the stakeholders until its accepted making the proper changes.
4. Start to develop the software.

And I call that: SOFTWARE ASSEMBLY LINE

This is needed for any of the existing methodologies, the difference is how we use the sources. What I can tell right now is that We cannot create software if the source is not telling us exactly what they need. Once we know what to do and the design is accepted, we are done. How to construct the software is just a matter of what the stakeholders want (web, desktop, mobile, Tablet, tv, or any device).

All these methodologies are good enough to create software, We just need to know the proper one and go through that. Or We can just: create software by using SOFTWARE ASSEMBLY LINE – “SAL”.

*********************************************Español

Al buscar en Internet los mejores métodos para crear o modificar el software que vamos a encontrar? Una gran cantidad de métodos, arquitecturas, patrones, etc ¿Cómo podemos lidiar con eso? en qué confiar? Si conocemos a alguien que está usando alguna de estas metodologías y está funcionando muy bien, podemos empezar con eso, pero lo que si no lo hacemos? Sólo para enumerar algunas de las metodologías actuales (para saber más sobre cualquiera de ellos, sólo buscar la palabra metodología más el nombre listado): 1.Waterfall 2.EVO 3.crystal 4.EUP 5.AUP 6.EssUP 7.OpenUP 8.MSF 9.FDD 10.CMMI 11.PMBOK 12.Prince2 13.DSDM 14.RUP 15.LeanSD 16.USDP 17.XP 18.Scrum 19.Prototype 20.Spiral 21 ……. y mucho más

Así que, ¿cuál es el objetivo principal de todos estos métodos? Respuesta: crear un excelente software. Y todos ellos tienen las mismas fuentes, como son: las partes interesadas (stakeholders), procesos y datos. Nada más, por lo que, cuando en esta vida, esto se volvió tan complicado?

Tratando de obtener los mejores resultados los ingenieros y otras personas utilizan métodos existentes para crear otras nuevas metodologías.

Empezando por el hecho de que la fuente de la creación de software es siempre la misma, podemos deducir lo siguiente: 1.Stakeholders, los procesos y los datos son las fuentes para crear el software. 2.Se debe entender de la manera más exacta los requisitos para el software que hablando con los stakeholders hasta nosotros y ellos estemos completamente seguros que todos los requisitos relacionados están escritos correctamente. 3.Crear un diseño para el nuevo software y mostrar a las partes interesadas hasta su aceptación haciendo los cambios adecuados. 4.Iniciar a desarrollar el software.

Y esto lo llamo: SOFTWARE LÍNEA DE MONTAJE (SLM o SAL en inglés)

Esto es necesario para cualquiera de las metodologías existentes, la diferencia es la forma en que utilizamos las fuentes. Lo que puedo decir ahora es que no podemos crear software si la fuente no nos dice exactamente lo que necesitan. Una vez que sabemos qué hacer y el diseño es aceptado, hemos terminado. Cómo construir el software es sólo una cuestión de lo que los stakeholders quieren (web, escritorio, portátiles, Tablet, tv, o cualquier dispositivo).

Todos estos métodos son lo suficientemente buenos para un proyecto, sólo necesitamos saber el adecuado y listo. O podemos simplemente: crear software utilizando SOFTWARE LÍNEA DE MONTAJE – “SLM”. (Software Assembly Line SAL).

Software Design Patterns / Patrones de Diseño de Software

Software Patters are just “Solutions to recurring problems in software development”, its independent from the development tool and language. Better than antipatterns, We can see these as good examples on how to create good software, because almost everything is already studied and analyzed, we must take advantage of that previous knowledge and stop inventing the wheel everytime.
Patterns is not just “code reuse” its the “whole” knowledge for a solution. Thinking in all created software must “change” or “grow” to keep alive, the patterns are the best way to do these changes without reconstruct most of the code everytime.
Each time we need to create new software, a design must be applied, if We use design patterns, we can guarantee success as the pattern is being success in many projects.
There are many kinds of patterns to use, but the main goal for each one is to have the following characteristics:

1. Client should always call the abstraction (interface) and not the exact implementation.
2. Future changes should not impact the existing system.
3. Change always what is changing.
4. Have loose coupling
*Inheritance ( Very coupled )
*Composition
*Aggregation
*Association
*Dependency
*Realization ( Least couple )

Some examples of Design Patterns to search for are:
MVC (Model View Controller) separates the representation of information from the client side (user’s interaction). Must be identificable Data, Business Rules, Login and Functions.

MVP (Model View Presenter) is derivated from MVC, but the Presenter handles all the presentation logic. This facilitate automated unit testing and improve the separation of concerns in the presentation logic.

There are other propietary patterns for Microsoft’s development tools like MVVM, MVPVM. You can search them to understand specifically about them.

Summary: Design Patterns in Software Development are only templates that allow us to work quickly and safetly(for results) when creating software.

********************************************************************Español:
Patrones de Software son sólamente “Soluciones a problemas recurrentes en desarrollo de software”, es independiente de la herramienta de desarrollo y lenguaje. Mejores que los antipatrones, podemos verlos como ejemplos de cómo crear buen software, porque casi todo ya ha sido estudiado y analizado, debemos tomar ventaja de ese conocimiento previo y parar de inventar la rueda cada vez.
Los Patrones no son sólo “Reutilización de código”, son el conocimiento “completo” de una solución. Pensando en que todo software creado debe “cambiar” o “crecer” para mantenerse vivo, los patrones son el mejor camino para realizar estos cambios sin tener que reconstruir la mayoría del código en cada momento.
Cada vez que necesitamos crear nuevo software, un patrón de diseño debe ser aplicado, si lo hacemos, podemos garantizar un éxito tanto como el patrón siempre lo ha tenido en muchos proyectos.
Existen muchas clases de patrones para usar, pero el principal objetivo de cada uno debe tener las siguientes características:

1. El Cliente debe llamar la abstracción (interface) siempre y no la implementación exacta.
2. Los cambios futuros no deben impactar el sistema existente.
3. Cambiar siempre lo que necesita cambio.
4. Mantener acoplamiento flexible
*Herencia ( Muy unido )
*Composición
*Agrupamiento
*Asociación
*Dependencia
*Realización ( Menos unido )

Algunos ejemplos de Patrones de diseño para buscar son:
MVC (Modelo Vista Controlador) separa la representación de la información de la interfaz de usuario. Deben identificarse Datos, Reglas de Negocio, Acceso usuario y funciones.

MVP (Modelo Vista Presentador) derivado de MVC, pero el presentador realiza todo el manejo de presentación y lógica. Esto facilita pruebas unitarias automatizadas y mejora la separación de inquietudes de la lógica de presentación.

Existen otros patrones propietarios para herramientas de desarrollo Microsoft como son MVVM, MVPVM solo para citar algunos que no son de dominio público en cuanto a la herramienta de desarrollo.

Resumen: Los Patrones de Diseño para Desarrollo Software son solo plantillas que nos ayudan a trabajar más rápidamente y con seguridad(de resultados) cuando realizamos software.

Antipatterns in Software Development Life Cycle (SDLC) / Antipatrones en el ciclo de vida del Desarrollo de Software

The processes involved in creating / altering software group the SDLC.

Normally we have 6 steps to create software:
1. Requirements Specification
2. Program Design
3. Program Coding
4. Program Testing
5. Documentation
6. Maintenance

Very easy, each point is self-explanatory.
Now what I want to explain is the Antipatterns around these ones.

What are Antipatterns? These are BAD practices in Software Development, We don’t need to even think about it, right? Wrong, we need to know antipatterns to do not repeat these bad practices in our projects. Every bad lesson learned in previous projects become Antipatterns practices, later these will help us to get better results in our currents projects, together with Patters of software development that are the good practices.

Normally in Software development we found 3 types of people around each project: Managers, Architects and Developers. Each one of the members of these groups can be affected by antipatterns.

Developers:

1. Lava Flow, this means a lot of code emerging like lava from a volcano, uncontroled code means low understanding about what are being developed and later this will “solidify” like lava and will be very dificult to understand. No documented code, away from the architectural concept and hard to modify.

2. Ghosts, a lot of classes or dependencies with a few responsabilities each one.This makes it difficult to find the important functions.

3. God Mode, a single program that does everything. Hard to read and understand. This comes from the old programming style, like ms-dos coding style.

4. Golden Hammer, avoid the use of any other technology to resolve problems that we know cannot be resolve with current tools. Marry a technology and not allow others to help.

5. Spaghetti Code, a lot of no documented code, hard to read, very difficult to understand and a indecipherable lines of code.

Architects:

1. Reinvent the wheel, this means trying to create the same software solution every time. Usually this is due to ignorance on the business requirements.

2. Marry a technology, sometimes the same technology is not able to handle all the requirements for the project, instead of reconstruct a lot of functionalities to allow the current technology to emulate other technology, it will be better to use another existent solution to solve that.

3. Stovepipe, “hot cooking”, this means performing unprogrammed changes, changing everything everyday.

Managers:

1. Super developers team, this is when managers think something like “if a mother gives birth 1 son in 9 months, 9 mothers can give birth to 1 son in 1 month”. Sometimes increase the development time can cause other delays instead of increase velocity.

2. Corncob, difficult people that affects the work of other team members, there are a lot of that people that don’t create good software and don’t allow others to do their job.

3. Project miss-management, this is the bad manager, he doesn’t know how to do his job. I know many of these, especially now that arose a specialization misnamed PMP (Project Management Professional) that accepts any type of graduate person without appropriate professional experience. Problem with this is that always is known very late, after the project is badly affected.

Summary: Each lesson we learned during the project development can become a pattern or good development practices and the opposite could become a bad practice or anti pattern.

*********************************************Español:
Los procesos usados en crear o modificar software agrupal el SDLC. (Ciclo de Vida del Desarrollo de Software).

Normalmente tenemos 6 pasos para crear software:
1. Especificación de requerimientos
2. Diseño de programas
3. Codificación de programas
4. Pruebas de los programas
5. Documentación
6. Mantenimiento

Muy fácil, cada punto se explica solo.
Ahora voy a explicar los Antipatrones que surgen alrededor de cada uno de estos.

Que son los antipatrones? Estas son malas prácticas en desarrollo de software. Que no necesitaríamos ni nombrar cierto? Error, Nosotros necesitamos conocer todos los antipatrones que no deseamos se repitan en nuestros actuales proyectos. Cada mala lección aprendida en proyectos anteriores se convierten en Antipatrones, luego estas nos ayudarán a obtener mejores resultados en nuestros proyectos, junto a los Patrones de Desarrollo de software que son las buenas prácticas.

Normalmente en desarrollo de software encontramos 3 tipos de personas en cada proyecto: Directores, Arquitectos y Desarrolladores. Cada uno de los miembros de estos grupos puede verse afectado por los antipatrones.

Desarrolladores:

1. Flujo de lava (Lava Flow), se refiere a una cantidad enorme de código fluyendo como lava de un volcán, código incontrolado significa bajo conocimiento sobre lo que se está desarrollando y más tarde como la lava esto se “solificará” y será más difícil de entender. Código sin documentar, lejos del concepto arquitectónico y difícil de modificar.

2. Fantasmas (Ghosts), muchas clases o dependencias con pocas responsabilidades cada una, esto hace muy dificultoso encontrar las verdaderas funciones importantes.

3. Modo Dios (God Mode), un sólo programa que hace todo. Duro de leer y entender. Esto viene del antiguo estilo de programación, como los programas ms-dos.

4. Varita mágica (Golden Hammer), evitar el uso de otras tecnologías para resolver problemas que no se puede hacer con las herramientas actuales. Casarse con una tecnología y no dejar entrar otras.

5. Código espagueti (Spaghetti Code), cantidades de código no documentado, duro de leer, muy difícil de entender y se puede decir indecifrable cantidad de líneas de código.

Arquitectos:

1. Reinventar la rueda, esto significa tratar de crear la misma solución de software cada vez que se requiere. Normalmente esto es por ignorancia a los requerimientos de negocio.

2. Casarse con una tecnología, a veces la misma tecnología no es capaz de manejar todos los requerimientos de un proyecto, en lugar de reconstruir una gran cantidad de funcionalidades para hacer el software actual emular lo que hacen otras tecnologías lo mejor sería hacer uso de estas.

3. Tubo de estufa, “cocinar en caliente”, significa realizar cambios no programados, cambiando todo cada día.

Directores:

1. Super equipos de desarrollo, cuando los administradores piensan que todo es tan simple que con solo añadir personal se resuelve, por ejemplo el que se atreve a decir “Si una madre tiene un hijo en 9 meses, 9 madres pueden tener un hijo en un mes”. Algunas veces añadiendo personal al proyecto lo que hace es entorpecerlo más.

2. Malgeniados, personal difíciles afectan el trabajo de los demás miembros del equipo, especialmente aquellos que es más lo que hablan que lo que hacen, no producen buen software y no dejan a los que si saben hacerlo.

3. Mal manejo del proyecto, este no es sino un mal director, no sabe como hacer su trabajo. Conozco a muchos de estos especialmente ahora que salió una mal llamada “Especialización” llamada PMP (Profesional Director de Proyectos) que está aceptando cualquier graduado que no tiene la experiencia requerida para convertirse en Director de proyectos. Lo malo de esto es que siempre se sabe muy tarde cuando se ha comprometido el proyecto.

Resumen: Cada lección aprendida durante el desarrollo de cada proyecto puede convertirse en un patrón de buenas o malas prácticas, dependiendo lo que sea. Malas prácticas=antipatrones, buenas prácticas=patrones.

Mejoramiento del email / Email improvement

Esta es una pequeña sugerencia para mejorar el cliente email, se necesitan 3 nuevos campos donde guardar direcciones. Cuantos de nosotros hemos necesitado enviar un email que tiene un anexo que debe irse solo para algunos destinatarios pero no para todos, entonces que hacemos? nos toca enviar al menos 2 veces el email, la primera con el anexo y la siguiente sin el anexo, es una pérdida de tiempo. Además de que posiblemente estamos saturando el servidor de correo. Ver explicación abajo: // This is a small suggestion to improve customer email, it will need 3 new fields to store addresses. How many times we’ve needed to send an email that has an attachment that should go only to some recipients but not for all? So we have to send at least 2 emails, the first with the Annex and the next without the annex, is a waste of time. Besides we are probably saturating the mail server. See explanation below:

 

New fields for email client

To na –> Enviar a sin anexo

CC na –> Con Copia a, sin anexo

BCC na –> Con Copia Oculta a, sin anexo.

 

La Belleza Excepcional del Código Fuente de Doom 3′s

Por Shawn McGrath

Esta es una historia acerca del código fuente de Doom 3‘s y su belleza. Si, belleza. Permítanme explicar.

Después de publicar mi video juego Dyad me tomé un pequeño descanso. Leí algunos libros y miré algunas películas que había postergado por mucho tiempo. Estaba trabajando en la versión Europea de Dyad, pero durante ese tiempo estaba más que todo esperando por la retroalimentación del equipo de aseguramiento de calidad de Sony, así que tenía mucho tiempo libre. Luego de vagar alrededor de más o menos un mes, empecé a considerar seriamente que iba a hacer en seguida.

Deseaba extraer las partes reusables del motor-y de Dyad para un nuevo proyecto.

Cuando inicié a trabajar originalmente en Dyad era un juego muy limpio, un motor para juegos muy funcional que creé de una acumulación de años de trabajo en otros proyectos. Al finalizar Dyad tenía un desorden espantoso.

Al final de seis semanas de desarrollo de Dyad agregué alrededor de 13K líneas de código. MainMenu.cc se aumentó a 24,501 líneas. El que una vez fue un lindo código fuente se convirtió en un desorden acribillado con #ifdefs, punteros gratuitos en funciones, horrible SIMD en línea y código asm, hasta aprendí un nuevo término: “entropía de código.” Busqué por internet otros proyectos que pudiera usar para aprender como organizar cientos de miles de líneas de código. Después de mirar bastantes extensos motores de juegos estaba muy desalentado; el código fuente de Dyad en realidad no estaba tan mal comparado a todo lo que había allí afuera!

Insatisfecho, continué mirando y encontré un muy agradable análisis del código fuente de Doom 3 por el experto en computación Fabien Sanglard.

Gasté algunos días mirando el código de Doom 3 y leyendo el excelente artículo de Fabien, entonces triné:

I spent a bit of time going through the Doom3 source code.It’s probably the cleanest and nicest looking code I’ve ever seen.

— DYAD (@DyadGame) September 20, 2012

Fué la verdad. Nunca antes me había preocupado por el código fuente. Realmente no me considero un “programador.” Soy bueno, pero para mi es sólo el medio para un fin. Mirando el código fuente de Doom 3 me hizo realmente apreciar a los buenos programadores.

***

Para poner las cosas en perspectiva: Dyad tiene 193k líneas de código todo en C++. Doom 3 tiene 601k, Quake III tiene 229k and Quake II tiene 136k. Eso ubica a Dyad en algún lugar entre Quake II y Quake III. Estos son proyectos grandes.

Cuando me pidieron escribir este artículo, lo usé como excusa para leer más código fuente de otros juegos, y para leer acerca de estándares de programación. Luego de días de búsqueda estaba confundido por mi propio trino que inició todo este paseo: En realidad ¿que significa “agradable” o “bonito” en términos de código fuente? Le pregunté a algunos amigos programadores lo que ellos pensaban que significaba. Sus respuestas fueron obvias, pero vale la pena señalarlas:

• El código debería ser coherente localmente y de funcionalidad simple: Una función debería hacer exactamente una cosa. Debe ser clara acerca de lo que hace.
• El código local debería poderse explicar según el diseño de todo el sistema.
• El código debería auto documentarse. Los comentarios deberían prevenirse siempre que sea posible. Los comentarios duplican el trabajo para lectura y escritura de código. Si se necesita comentar algo para hacerlo entendible, probablemente debe ser reescrito.

Hay un estándar de codificación idTech 4 (.doc) que creo que vale la pena leer. Yo sigo la mayoría de esos estándares que trataré de explicar porque son buenos y porque específicamente hacen que el código de Doom 3 sea muy bonito.

Parseo Unificado y Análisis Léxico

Una de las cosas más inteligentes que vi en Doom es el uso genérico de su parser analizador léxico. Todos los archivos de recursos son ascii con sintaxis unificada que incluyen: scripts, archivos de animación, archivos de configuración, etc. todo es lo mismo. Esto permite que todos los archivos se lean y procesen por un pedacito de código. El parseador si es particularmente robusto, soportando la mayoría de los subconjuntos de C++. Al pegarse a un programa de análisis léxico unificado, todos los demás componentes del motor no necesitan preocuparse de la serialización de datos ya que existe código para eso. Esto hace todos los demás aspectos del código más limpio.

Constantes y Parámetros Rígidos

El código de Doom es bastante rígido, aunque no lo suficiente en mi opinión con respecto a constantes. Las constantes sirven para diversos propósitos los cuales creo que muchos programadores ignoran. Mi regla es “todo debería ser siempre contanste a menos que no lo pueda ser”. Me gustaría que todas las variables en C++ fueran constantes por defecto. Doom casi siempre conserva una política de parámetros de “no in-out”, esto significa que todo parámetro en una función o son de entrada o de salida, pero nunca ambos. Esto hace mucho más fácil de entender que pasa con una variable que pasas a una función. Por ejemplo:

La definición de esta función me hace feliz!

Sólo por unas constantes ya sé muchas cosas:

• El idPlane que se pasa como argumento no será modificado por esta función. Puedo usar de forma segura el “plane” después que se ejecute esta función sin chequear modificaciones en idPlane.
• Sé que épsilon no será cambiado en la función, (aunque podría ser fácilmente copiada a otro valor y escalada por ejemplo, pero sería contraproducente)
• front, back, frontOnPlaneEdges and backOnPlaceEdges son variables de salida. En estas se escribirá.
• la constante final después del parámetro lista es mi favorita. Le indica idSurface::Split() no modificará a “surface” ella misma. Esta es una característica de mis favoritas de C++ que no existe en otros lenguajes. Me permite hacer algo como esto: void f(const idSurface &s) { s.Split(….); }   si Split no fue definida como constante Split(….) este código no compilará. Ahora sé que dondequiera que se llame f() no modificará “surface”, incluso si f() pasa a surface a otra función o llama algún Surface::method(). Las constantes me dicen mucho acerca de la función y además sugieren un gran diseño de sistema. Simplemente por leer la declaración de la función se que surface se puede dividir por un plane dinámicamente. En lugar de modificar surface, retorna nuevas surface, front y back, y opcionalmente frontOnPlaneEdges y backOnPlaneEdges.

Las constantes mandan y parámetros que no sean input/output es probablemente la cosa más sencilla a mi forma de ver que separan buen código de código bonito. Eso hace que todo un sistema sea más fácil de entender y más fácil de editar o mejorar.

Comentarios Mínimos

Este es una cuestión de estética, pero una cosa que hace del código de Doom una belleza es que no está sobre-comentado. He visto mucho código como este:

Encuentro esto extremadamente irritante. Puedo decir que hace este método por su nombre. Si la función no se puede inferir desde su nombre, su nombre debe ser cambiado. Si su nombre la describe demasiado, disminúyalo. Si no se puede realmente refactorizar y renombrar para describir su simple propósito sólo entonces está bien comentar. Creo que los programadores aprendieron en la escuela que los comentarios son buenos, pues no, no lo son. Los comentarios son malos a menos que sean totalmente necesarios y normalmente no lo son. Doom hace un excelente trabajo manteniendo los comentarios al mínimo. Usando el ejemplo idSurface::Split(), miremos como se comentaría:

//divide el surface en surface frontal y trasera, el surface como tal mantiene intacto

//frontOnPlaneEdges y backOnPlaneEdges opcionalmente almacenan los índices de los bordes en el plane dividido

//retorna un SIDE_?

La primera línea es completamente innecesaria. Sabemos eso de toda la información de la definición de la función. La segunda y la tercera pueden valer algo. Podemos inferir las propiedades de la segunda línea pero el comentario elimina ambigüedad potencial.

El código de Doom es en su mayor parte magistral con sus comentarios los cuales lo hacen mucho más fácil de leer. Se que esto puede ser muy simple para algunas personas, pero definitivamente creo que hay un limpio y buen camino para hacer esto. Por ejemplo, que puede pasar si alguien cambia la función y elimina la constante del final? Entonces el surface *PODRIA* ser cambiado desde la función y ahora el comentario no concuerda con el código. Comentarios extraños afectan la exactitud de la lectura del código y lo hacen más feo.

Espaciado

Doom no pierde espacio vertical:

Este es un ejemplo de t_stencilShadow::R_ChopWinding():

Puedo leer el algoritmo entero en 1/4 de mi pantalla, dejando los otros 3/4s para entender donde ese bloque de código encaja relativamente con el código que lo rodea. He visto mucho código como este:

Este es otro punto que falla en “estilo”. Programé por más de 10 años con este último estilo, pero me forcé a cambiarme a la forma más estricta mientras trabajaba en un proyecto hace seis años. Estoy contento de haber cambiado.

Las últimas son 18 líneas comparadas a las 11 anteriores. Eso es casi el doble número de líneas para una funcionalidad casi “EXACTA”. Eso significa que el siguiente pedazo de código no encaja en la pantalla para mi. Que es el siguiente pedazo?

Ese código no tiene sentido sin el pedazo anterior for loop. Si no respeta los espacios verticales el código será mucho más duro de leer, más duro de escribir, más duro de mantener y será menos bonito.

Otra cosa que creo que no es solo estético en el código id es que *SIEMPRE* usan llaves aunque sea opcional. Creo que es un crimen saltarse las llaves. He visto mucho código como este:

Este es código feo, es peor que poner { } en cada línea. No pude encontrar en el código de id algún ejemplo donde se saltaran los { }. Omitir los opcionales { } hace que este ciclo while() consuma más tiempo del que necesita realmente. También esto hace la edición un dolor, que pasa si necesito insertar un if nuevo en else if(c>d)?

Plantillas al mínimo

id hizo un grandioso trabajo en el mundo C++. Ellos reescribieron todas las funciones STL requeridas. Yo personalmente tengo una relación de odio-amor con las STL. En Dyad las usé en debug de código para administrar recursos dinámicos. En release reuní a todos los recursos así se podían cargar más rápidamente y no usé ninguna funcionalidad STL. El STL es agradable porque proporciona estructuras genéricas rápidas, pero está mal porque usándolo muy a menudo es propenso al código feo y con errores. Por ejemplo, miremos esta clase std::vector<T>. Digamos que quiero pasar sobre cada elemento:

Esto se puede simplificar con C++11:

A mi personalmente no me gusta el uso de auto, creo que hace el código más fácil de escribir pero más difícil de leer. De pronto usaré el auto en los próximos años,  pero por ahora lo veo mal. Ni siquiera voy a mencionar las ridiculeces de algunos algoritmos STL como std:for_each o std::remove_if.

Eliminar un valor de un std::vector es una bobada también:

Carambolas, eso va a ser digitado correctamente por cada programador cada vez!

id elimina toda ambigüedad: Ellos hicieron sus propios contenedores genéricos, clase string, etc. Los escribieron mucho menos genéricos que las clases STL, muy seguramente para hacerlos más fácil de entender. Usan muy pocas plantillas y específicos asignadores de memoria. El código STL está tan lleno de plantillas sin sentido que es imposible de leer.

El código C++ puede convertirse rápidamente en una revoltura y fealdad sin un orden de parte de los programadores. Para ver que tan malas se pueden poner las cosas, mire nada más el código fuente del STL. Las implementaciones Microsoft y GCC STL son probablemente el código más horrible que he visto. Inclusive cuando los programadores tienen cuidado extremo haciendo su código plantilla lo más leíble posible, es todavía un completo desastre. Dele una mirada a  Andrei Alexandrescu’s Loki library o a boost libraries, estos libros fueron escritos por algunos de los mejores programadores C++ en el mundo y tuvieron mucho cuidado de hacerlo tan bonito como es posible y aún así todavía es código feo y básicamente ilegible.

id arregla este problema simplemente sin sobrepasarse en las cosas genéricas. Ella tiene un HashTable<V> y una clase HashIndex. La HashTable fuerza la llave para ser un carácter constante (const char *) y el HashIndex es un int->int pair.

Pueden ver el resto del artículo original en http://kotaku.com/5975610/the-exceptional-beauty-of-doom-3s-source-code

Gracias a Shawn McGrath  por permitirme traducir su artículo.

stringbuilder vrs concatenar strings C#

Usar concatenación de strings en lugar de stringbuilder es una mala práctica:

Concatenar strings trabaja de la siguiente forma, cada que adiciona algo al string,  una nueva dirección de memoria se asigna. El string anterior se copia en un nuevo lugar con la parte añadida. Esto es ineficiente. En cambio StringBuilder mantiene la misma posición de memoria sin realizar una operación de copia, esto es muy eficiente especialmente cuando se requieren hacer cientos de operaciones de adición de strings.

Error:

List valores = new List(){"Mi nombre ","es ","John ","Belalcazar!"};
string salida = string.Empty;
foreach (var valor in valores)
{
   salida += valor;
}

Correcto:
List valores = new List(){"Mi nombre ","es ","John ","Belalcazar!"};
StringBuilder SalidaBuilder = new StringBuilder();
foreach (var valor in valores)
{
SalidaBuilder.Append(valor);
}

 

 

Encontrar las tablas de mayor tamaño en SQLServer

Cómo se usa:

1. Si deseas ver todas las tablas en la base de datos actual del usuario con los tamaños más grandes:   EXEC sp_LargestTables [Sin parámetros]

2. Si deseas sólo ver 3 tablas en la base de datos actual del usuario con los tamaños más grandes:   EXEC sp_LargestTables 3

3. Si deseas sólo ver 20 tablas en la base de datos actual del usuario con los tamaños más grandes incluyendo tablas del sistema:   EXEC sp_LargestTables 20,1

Este es el script del store procedure:

 

IF EXISTS     (  SELECT 1 FROM master.dbo.sysobjects  WHERE name = ‘sp_LargestTables’ AND type = ‘P’     )

                DROP PROC sp_LargestTables GO

                CREATE PROC sp_LargestTables(@n int = NULL,@IsSystemAllowed bit = 0) AS

/*=========================================================================

CREATE DATE  : Hari N Sharma CREATION DATE  : 10-09-2007 LAST MODIFICATION DATE : 11-10-2007

PURPOSE : To get a list of User/System tables according to their size. =========================================================================*/

BEGIN  SET NOCOUNT ON  DECLARE @LOW int  SELECT @LOW = LOW FROM master.dbo.spt_values (NOLOCK) WHERE number = 1 AND type = ‘E’

 IF @n > 0 SET ROWCOUNT @n

 SELECT TableName,[Row Count],[Size (KB)] FROM  (   SELECT QUOTENAME(USER_NAME(o.uid)) + ‘.’ + QUOTENAME(OBJECT_NAME(i.id)) AS TableName,SUM(i.rowcnt) [Row Count],   CONVERT(numeric(15,2),(((CONVERT(numeric(15,2),SUM(i.reserved)) * @LOW) / 1024.0))) AS [Size (KB)]   FROM sysindexes i INNER JOIN sysobjects o (NOLOCK) ON i.id = o.id AND   ((@IsSystemAllowed = 1 AND o.type IN (‘U’, ‘S’)) OR o.type = ‘U’)   WHERE indid IN (0, 1, 255)   GROUP BY QUOTENAME(USER_NAME(o.uid)) + ‘.’ + QUOTENAME(OBJECT_NAME(i.id))  ) AS Z  ORDER BY [Size (KB)] DESC

 SET ROWCOUNT 0

END

GO

 

Thanks to Hari Sharma, original post: http://www.sqlservercentral.com/scripts/Administration/63646/

 

Validation Rules for fields / Reglas de validación para campos

Sometimes we need to be sure that certain data is entered to each field of our forms, web pages, etc. So we need to specify clearly what type of information can be typed and why. Take a look to this table, (you must adapt for your specific language), the explanation column can help you to document the field requirements.

Algunas veces necesitamos estar seguros que ciertos datos son ingresados para cada campo de nuestros formularios, páginas web, etc. Así que necesitamos especificar claramente que tipo de información puede ser digitada y por qué. Mire la siguiente tabla, (debe adaptarla a su propio lenguaje), la columna explicación puede ayudarle a documentar los requerimientos de campo.

To do this …	Validation Rule for Fields	Explanation
Accept letters (a – z) only	Is Null OR Not Like “*[!a-z]*”	Any character outside the range A to Z is rejected. (Case insensitive.)
Accept digits (0 – 9) only	Is Null OR Not Like “*[!0-9]*”	Any character outside the range 0 to 9 is rejected. (Decimal point and negative sign rejected.)
Letters and spaces only	Is Null Or Not Like “*[!a-z OR "" ""]*”	Punctuation and digits rejected.
Digits and letters only	Is Null OR Not Like “*[!((a-z) or (0-9))]*”	Accepts A to Z and 0 to 9, but no punctuation or other characters.
Exactly 8 characters	Is Null OR Like “????????”	The question mark stands for one character.
Exactly 4 digits	Is Null OR Between 1000 And 9999	For Number fields.
	Is Null OR Like “####”	For Text fields.
Positive numbers only	Is Null OR >= 0	Remove the “=” if zero is not allowed either.
No more than 100%	Is Null OR Between -1 And 1	100% is 1. Use 0 instead of -1 if negative percentages are not allowed.
Not a future date	Is Null OR <= Date()
Email address	Is Null OR ((Like “*?@?*.?*”) AND (Not Like “*[ ,;]*”))	Requires at least one character, @, at least one character, dot, at least one character. Space, comma, and semicolon are not permitted.
You must fill in Field1	Not Null	Same as setting the field’s Required property, but lets you create a custom message (in the Validation Text property.)
Limit to specific choices	Is Null OR “M” Or “F”	It is better to use a lookup table for the list, but this may be useful for simple choices such as Male/Female.
	Is Null OR IN (1, 2, 4, 8)	The IN operator may be simpler than several ORs.
Yes/No/Null field	Is Null OR 0 or -1	The Yes/No field in Access does not support Null as other databases do. To simulate a real Yes/No/Null data type, use a Number field (size Integer) with this rule. (Access uses 0 for False, and -1 for True.)

 

Information extracted from: http://allenbrowne.com/ValidationRule.html there you can find more specifications.