El día de ayer comencé a jugar con Ruby y termine creando un Hola Mundo la cual la subí a Heroku, a continuación mostraré los pasos que seguí y los errores con los que me encontré.

Preparando el ambiente

Para poder desarrollar una aplicación con Ruby ocupando Heroku como servidor, necesitamos instalar Ruby y Git ya que Heroku ocupa este control de versiones para subir tu aplicación.

Ruby

Lo primero que debemos hacer es instalar Ruby, para esto debemos bajarlo desde http://rubyforge.org/frs/?group_id=167, y descargar rubyinstaller-version.exe. Es muy sensillo, hacemos doble clic en el instalador, aceptamos la licencia y damos instalar.

GIT

Luego debemos instalar GIT, para esto nos dirigimos a http://git-scm.com/download y tenemos dos proyectos que implementan Git para Windows, yo utilice msysGit.

Cuando lo instalemos debemos tener presente lo siguiente:

  • ¿Cómo deseamos ejecutar GIT?

Existe tres formas de ejecutar GIT, utilizando un bach, el cual no ingresa un path en las variables de entorno de Windows, la otra forma es agregando el PATH a las variables de entorno, con lo que logramos ejecutar GIT por linea de comando. Yo utilice la segunda opción debido a que me gusta trabajar bajo Windows Power Shell.

  • Configuración de termino de linea:

Te recomiendo que utilices Checkout Windows-style, que es la opción por defecto.

Instalando las Gemas

Ya tenemos todos los software necesario para desarrollar, ahora debemos instalar las gemas necesarias para el desarrollo con Sinatra y Heroku, para esto debemos abrir la línea de comandos y ejecutar:

gem install sinatra
gem install heroku
gem install bundler

Con esto habremos instalado las gemas que necesitamos para el desarrollo. La última gema la utilizaremos para mantener las gemas utilizadas en nuestra aplicación.

Creando la Aplicación

Crearemos un Hola Mundo, para ello nos iremos a su editor de texto favorito (para mi Notepad++), y escribiremos lo siguiente:

require 'sinatra'

get '/' do
 'Hola Mundo'
end

La primera línea indica que utilizaremos Sinatra , es muy parecido a un include o using de PHP o C#. La siguiente línea indica que utilizaremos el comando GET de HTTP, Sinatra al ser un Lenguaje de Dominio Especifico (DSL), utiliza los comandos GET, POST, PUT y DELETE, bueno aquí estamos indicando que si llega un requerimiento GET a la ruta “/”, o sea, a la raíz del sitio realice lo que se encuentra dentro del “do end”, muy sensillo ;) .

Guardamos el archivo con el nombre que deseamos con extensión .rb (extensión de ruby) en mi caso lo nombre “hola_mundo.rb

Ahora para ejecutar nuestra aplicación nos dirigimos a la línea de comando, nos posicionamos en la carpeta donde guardamos el archivo y ejecutamos:

ruby hola_mundo.rb

Con esta línea iniciamos el servidor de ruby, y nuestra aplicación se alojará en http://localhost:PUERTO, donde el Puerto es el que remarque con color amarillo.

Subiendo nuestra aplicación a Heroku

Ya tenemos lista nuestra aplicación, ahora a subirla a Heroku, para ello debemos seguir con los siguientes pasos.

Claves SSH y subirlas a Heroku

Primero debemos crearnos una cuenta en Heroku, y luego debemos configurar las claves SSH, Heroku al igual que GitHub utilizan llaves publicas/privadas para establecer el login con sus repositorios. Para crear estas llaves te recomiendo usar GIT UI que viene dentro del paquete de msysGit, y te diriges al menú “Help/Generate SSH Key”, aquí existe un botón para generar la clave la cual te pedirá una palabra secreta que debes recordar.

Luego de generar la clave, la cual la almacenará en “%User%\.ssh\” debes subirla a heroku, para ello nuevamente a la linea de comandos ubicado en esta carpeta y ejecutar:

heroku keys:add id_rsa.pub

Con esto subiremos a heroku nuestras credenciales.

Configurar Heroku

Luego debemos crear un archivo de configuración para que heroku sepa cual es el archivo que levantará nuestra aplicación para esto creamos el archivo “config.ru” y agregamos las siguientes líneas

require 'rubygems'
require 'bundler'

Bundler.require

require './hola_mundo'
run Sinatra::Application

Luego configuraremos nuestras gemas utilizando Bundler, que es el administrador de gemas por defecto utilizado en Ruby 3.

Para ello debemos crear un archivo llamado “GemFile” el cual contendrá todas las gemas y sus versiones.

source :gemcutter
gem 'sinatra', '1.3.1'

Y ejecutamos bundle con la siguiente instrucción:

bundle install

Esto nos generará un archivo “Gemfile.lock”, el cual se debe subir a su repositorio.

Crear el Repositorio

Previo a subir el repositorio, debemos configurar dos variables globales de GIT,

git config --global user.email Your.Email@domain.com
git config --global user.name "Your Real Name"

Estas indican nuestro nombre y mail, el cual debe ser el mismo con el que nos creamos la cuenta en Heroku.

Luego debemos crear el repositorio de GIT, para ello ejecutamos:

git init
git add .
git commit -m "Iniciando repositorio HolaMundo"

Con esto se inicializará git y realizamos el primer commit.

Luego creamos la aplicación en heroku para ello ejecutamos


heroku create [nombreApp]

Donde, [nombreAPP] será el nombre que tendrá nuestra aplicación, en nuestro caso lo llamare HolaMundoAlabra. Al ejecutar esta linea de código heroku nos retornará la url y repositorio de git que se asigno a nuestra aplicación.

Luego debemos hacer push de nuestro código en el repositorio de heroku para ello ejecutamos

git push heroku master

Con esto subiremos a la rama principal nuestro código, aquí nos pedirá nuestra palabra secreta de nuestra clave SSH.

Ejecutando Aplicación

Luego estamos listos para ejecutar nuestra aplicación nos dirigimos a la url que nos dio http://holamundoalabra.heroku.com/ y listo ;) .

El código fuente completo lo puedes descargar desde http://alabra.codeplex.com/SourceControl/changeset/changes/357e82c58dd1

Solución de Problemas

Cuando realice esta prueba me ocurrieron varios problemas, para resolverlos puedes ver el log de heroku ejecutando:

heroku logs

Podrás ver el log completo de tu aplicación.

Referencias:

El Sábado 8 de Enero, junto a Rubén López (@spakinz), hemos realizado un Code Katas del problema String Calculator.

La idea de realizar este code katas, nació en la lista de correos de AltNet Hispano y en twitter, en donde propuse realizar este problema con la finalidad de practicar TDD y Pair Programing.

Ante esta propuesta, Rubén, se contacto y nos juntamos en la fecha propuesta a resolver este problema.

Cuando iniciamos nos pusimos de acuerdo en los siguientes puntos:

  1. Herramientas de desarrollo: Que IDE y herramientas usaríamos para resolver el problema.
  2. De que forma compartiríamos el código fuente: Como nos podríamos sincronizar para que ambos tuviéramos el código, así poder editar ambos, además de que manera nos comunicaríamos.

Definimos que usaríamos Visual Studio 2010 y Nunit para realizar pruebas unitarias. En cuanto a la forma de comunicación, decidimos usar Codeplex, donde hemos creado un proyecto llamado “Code Kata AltNet Hispano“, para mantener el código fuente con SVN y LiveMetting para comunicarnos.

Como resumen puedo decir que fue muy productiva la sesión, además de ser muy satisfactoria por varios elementos, primero me sirvió para practicar TDD, que es un punto que todavía me encuentro desarrollando. Luego me sirvió para tener una experiencia de programación en parejas, nunca lo había realizado y creo que ayuda un montón, muchas veces a uno se le olvidan las cosas o no sabe como resolver un punto en particular y aquí entra el otro compañero que te apoya e indica como solucionarlo. Aunque nos hemos demorado un poco más del tiempo estimado, al rededor de 1 hr con 20 minutos, creo que por ser la primera vez es un muy buen tiempo.

A continuación les dejo la grabación de la sesión (desde aquí pueden descargar el vídeo, o verlo en linea desde screencast) , el código fuente lo pueden descargar directamente de CodePlex http://ckaltnethispano.codeplex.com.

http://content.screencast.com/users/alabras/folders/AltNet%20Hispano/media/b2063d81-5b8d-4d5d-9d9d-dee99ab1accd/CodeKata_StringCalculator.mp4?downloadOnly=true

Los ciudadanos y las empresas usuarias de Internet adheridas a este texto manifestamos:

  1. Que Internet es una Red Neutral por diseño, desde su creación hasta su actual implementación, en la que la información fluye de manera libre, sin discriminación alguna en función de origen, destino, protocolo o contenido.
  2. Que las empresas, emprendedores y usuarios de Internet han podido crear servicios y productos en esa Red Neutral sin necesidad de autorizaciones ni acuerdos previos, dando lugar a una barrera de entrada prácticamente inexistente que ha permitido la explosión creativa, de innovación y de servicios que define el estado de la red actual.
  3. Que todos los usuarios, emprendedores y empresas de Internet han podido definir y ofrecer sus servicios en condiciones de igualdad llevando el concepto de la libre competencia hasta extremos nunca antes conocidos.
  4. Que Internet es el vehículo de libre expresión, libre información y desarrollo social más importante con el que cuentan ciudadanos y empresas. Su naturaleza no debe ser puesta en riesgo bajo ningún concepto.
  5. Que para posibilitar esa Red Neutral las operadoras deben transportar paquetes de datos de manera neutral sin erigirse en “aduaneros” del tráfico y sin favorecer o perjudicar a unos contenidos por encima de otros.
  6. Que la gestión del tráfico en situaciones puntuales y excepcionales de saturación de las redes debe acometerse de forma transparente, de acuerdo a criterios homogéneos de interés público y no discriminatorios ni comerciales.
  7. Que dicha restricción excepcional del tráfico por parte de las operadoras no puede convertirse en una alternativa sostenida a la inversión en redes.
  8. Que dicha Red Neutral se ve amenazada por operadoras interesadas en llegar a acuerdos comerciales por los que se privilegie o degrade el contenido según su relación comercial con la operadora.
  9. Que algunos operadores del mercado quieren “redefinir” la Red Neutral para manejarla de acuerdo con sus intereses, y esa pretensión debe ser evitada; la definición de las reglas fundamentales del funcionamiento de Internet debe basarse en el interés de quienes la usan, no de quienes la proveen.
  10. Que la respuesta ante esta amenaza para la red no puede ser la inacción: no hacer nada equivale a permitir que intereses privados puedan de facto llevar a cabo prácticas que afectan a las libertades fundamentales de los ciudadanos y la capacidad de las empresas para competir en igualdad de condiciones.
  11. Que es preciso y urgente instar al Gobierno a proteger de manera clara e inequívoca la Red Neutral, con el fin de proteger el valor de Internet de cara al desarrollo de una economía más productiva, moderna, eficiente y libre de injerencias e intromisiones indebidas. Para ello es preciso que cualquier moción que se apruebe vincule de manera indisoluble la definición de Red Neutral en el contenido de la futura ley que se promueve, y no condicione su aplicación a cuestiones que poco tienen que ver con ésta.

La Red Neutral es un concepto claro y definido en el ámbito académico, donde no suscita debate: los ciudadanos y las empresas tienen derecho a que el tráfico de datos recibido o generado no sea manipulado, tergiversado, impedido, desviado, priorizado o retrasado en función del tipo de contenido, del protocolo o aplicación utilizado, del origen o destino de la comunicación ni de cualquier otra consideración ajena a la de su propia voluntad. Ese tráfico se tratará como una comunicación privada y exclusivamente bajo mandato judicial podrá ser espiado, trazado, archivado o analizado en su contenido, como correspondencia privada que es en realidad. Europa, y España en particular, se encuentran en medio de una crisis económica tan importante que obligará al cambio radical de su modelo productivo, y a un mejor aprovechamiento de la creatividad de sus ciudadanos. La Red Neutral es crucial a la hora de preservar un ecosistema que favorezca la competencia e innovación para la creación de los innumerables productos y servicios que quedan por inventar y descubrir. La capacidad de trabajar en red, de manera colaborativa, y en mercados conectados, afectará a todos los sectores y todas las empresas de nuestro país, lo que convierte a Internet en un factor clave actual y futuro en nuestro desarrollo económico y social, determinando en gran medida el nivel de competitividad del país. De ahí nuestra profunda preocupación por la preservación de la Red Neutral. Por eso instamos con urgencia al Gobierno español a ser proactivo en el contexto europeo y a legislar de manera clara e inequívoca en ese sentido.

(Si te sientes cómodo y representado por este texto, dale toda la difusión que puedas y quieras: reprodúcelo, enlázalo, tradúcelo, compártelo, vótalo… todas esas cosas que puedes hacer con total tranquilidad y libertad gracias, precisamente, al hecho de que tenemos todavía una red neutral. Hagamos posible el seguir teniéndola)

Copio y pego de Microsiervos y aNieto2K, SentidoWeb haz lo mismo!.

Estos días he estado investigando cómo ejecutar un paquete de SQL Server Integration Services (SSIS), creado con Visual Studio 2008 y SQL Server 2005 y con esto me he encontrado:

Detalle del Problema (Contexto)

Se desea ejecutar un paquete SSIS desde un WebService programado en J2EE. El WebService no necesariamente, de hecho lo más probable que no, se encuentre instalado en el mismo servidor de SQL Server.

Opciones

Buscando solución al problema he encontrado con 4 formas diferentes de ejecutar un paquete SSIS, las cuales van desde crear una aplicación en .NET hasta ejecutar procedimientos almacenados. A continuación veremos cuales son:

  1. Programando en .NET: Utilizando el espacio de nombres Microsoft.SqlServer.ManagedDTS, se puede programar una aplicación que ejecute un paquete de SSIS. El problema, para nosotros es que solamente se puede ejecutar paquetes de forma local, o sea, que estén en el mismo servidor donde se encuentre aplicación. Ejemplo: pueden ver un ejemplo aquí: http://msdn.microsoft.com/en-us/library/ms403355.aspx.
  2. Usar la utilidad DTExec.exe: Este es un programa que a través de línea de comando es posible ejecutar un paquete SSIS, pueden ver los distintos parámetros aquí: http://msdn.microsoft.com/en-us/library/ms162810.aspx. Igual que la forma anterior solamente se puede ejecutar de manera local.
  3. Usar SQL Agent: Usando el procedimiento almacenado “sp_start_job”, se puede ejecutar un job el cual puede ejecutar un paquete SSIS. Por lo tanto se debe crear un job y luego llamarlo a través de T-SQL a través del procedimiento almacenado “sp_start_job”. Esta forma permite la ejecución remota, pero se debe instalar el agente de SQL Server, además el procedimiento “sp_start_job” solamente retorna si fue exitosa la ejecución del job, no si fue exitosa la ejecución del paquete SSIS.
  4. Usando xp_cmdshell: El procedimiento almacenado xp_cmdshell permite la ejecución de comandos de windows en SQL Server. Así se puede ejecutar la utilidad DTExec.exe, del punto dos, a través de este procedimiento almacenado. Hay que tener precaución, ya que la llamada de xp_cmdshell se ejecuta con los mismos privilegios de la cuenta de SQL Server, por lo que puede haber problemas de seguridad.

Probando Soluciones

Para resolver nuestro problema solamente podemos utilizar las opciones 3 y 4. A continuación veremos los pasos necesarios para llevar a cabo esta tarea.

Usando xp_cmdshell

Este comando, por seguridad, desde la versión de SQL Server 2005 viene desactivado por defecto. Para poder activarlo se debe ejecutar el siguiente código:

<pre>-- To allow advanced options to be changed.
EXEC sp_configure 'show advanced options', 1
GO
-- To update the currently configured value for advanced options.
RECONFIGURE
GO
-- To enable the feature.
EXEC sp_configure 'xp_cmdshell', 1
GO
-- To update the currently configured value for this feature.
RECONFIGURE
GO

Luego que tengamos habilitado este procedimiento almacenado, podemos ejecutar la utilidad “DTExec.exe”, aquí les muestro un código de ejemplo:

-- Variable donde almacenaremos la linea a ejecutar
declare @lineExecute varchar(8000)
-- Variable donde almacenaremos el nombre del Paquete
declare @packageName varchar(100)
-- Nombre del Servidor SSIS
declare @serverName varchar(100)
-- Parametros
declare @params varchar(8000)
<pre>
set @packagename = '"\File System\PackageName"'
set @servername = 'ServerName'
set @params = ''

set @lineExecute = 'dtexec /dts ' + @packageName + ' /ser ' + @serverName + ' '
set @lineExecute = @lineExecute + @params

--Ejecutando el comando
DECLARE @returnCode int
EXEC @returnCode = xp_cmdshell @ssisstr
-- Mostrando el resultado de la ejecución
select @returnCode

En este ejemplo hemos cargado el paquete a Integration Service, dentro de la carpeta “File System”. Ustedes pueden ejecutar el paquete desde diferentes ubicaciones, para ver todos los comandos pueden dirigirse aquí: http://msdn.microsoft.com/en-us/library/ms162810.aspx

Problemas Encontrados

Cuando ejecute el código anterior el servidor me arrojo el siguiente error:

“Description: The version number in the package is not valid. The version number cannot be greater than current version number.”

Y más adelante mostraba lo siguiente:

“Description: Package migration from version 3 to version 2 failed with error 0xC001700A “The version number in the package is not valid. The version number cannot be greater than current version number.”.”

El problema que ocurre es que dentro de el servidor donde ejecutaba la consulta existía 2 instancias de SQL Server, una con la versión 9.00 (SQL Server 2005) y otra 10.0 (SQL Server 2008). Como Intregration Service no tiene instancias, se ejecutara la primera utilidad de “DTEXEC” que encuentre. Así como hemos desarrollado nuestro paquete SSIS en Microsoft SQL Server Integration Services Designer Version 10.0, solamente podemos ejecutarlo en versiones posteriores a la 10.0.

Para solucionar este problema he encontrado 3 formas:

1. En ves de llamar a la utilidad por el nombre (línea 14), llamarlo por la ruta completa, de la siguiente forma:

set @lineExecute ='C:\Program Files\Microsoft SQL Server\100\DTS\Binn\DTExec.exe /dts ' + @packageName + ' /ser ' + @serverName + '   '

2. Renombrar el antiguo ejecutable de la utilidad “DTExec.exe”, Ej: C:\Program Files\Microsoft SQL Server\90\DTS\Binn\DTEXEC_Old.exe

3. Modificar la variable de sistema “Path” y agregar antes de la ruta “C:\Program Files\Microsoft SQL Server\90\DTS\Binn”, la ruta de la instancia correcta “C:\Program Files\Microsoft SQL Server\100\DTS\Binn”

Usando SQL Agent

Próximamente crearé un nuevo post explicando esta solución.

Referencias:

Como siempre, cualquier critica, pregunta o sugerencia no duden en comentar…

Template de Proyecto

En: How to

22 Nov 2010

Hace unas semanas atrás estuve leyendo sobre buenas practicas en Software Configuration Manager, y existe algo que me gustaría destacar.

¿Cuáles deben ser las carpetas que debemos crear cuando iniciamos un proyecto?

Esta duda la tenía hace mucho tiempo y existe un punto importante que me “abrió los ojos”, “Código + Herramientas = Producto“. Si un producto de software no solamente se compone de código fuente, si no que también de las herramientas utilizadas. La combinación de ambas generan el producto de software.

A que nos referimos con Herramientas

Herramientas es todo aquello utilizado para concebir el producto, puede ser librerías, software, componentes, etc. Estas deben ser almacenadas dentro del repositorio, ya que sin ellas el producto no existe.

Ahora no hay que ser extremos en esta metodología, me refiero a que no deberíamos incluir por ejemplo instalador del IDE, SO, pero si debemos indicar que IDE se utilizo, SO, compiladores, inclusive hasta las características de la maquina donde se desarrollo, solo si es relevante.

Además de las herramientas, debemos incluir la documentación, así nuestro template quedaría de la siguiente manera:

Esto lo podemos ver en varios proyectos opensource,

Ejemplos:

Como siempre cualquier comentario, critica, sugerencia será bienvenida….

En mi trabajo, un cliente, nos ha pedido que lo ayudemos para mejorar su proceso de administración de configuración de software. Es en este sentido que nos encontramos trabajando en mejorar apoyado de las mejores practicas.

Qué es la Administración de Configuración de Software (Software Configuration Managment – SCM)?

Es la tarea de seguimiento y control de los cambios producidos en el sofware.

Buenas Practicas

Dentro de las mejores practicas, podemos englobar en los siguientes grupos:

  1. Workspace: Se define como el lugar donde los desarrolladores construyen, depuran y prueban componentes de software
  2. Codeline: Es el conjunto de código fuente necesario para producir el software. Típicamente un codeline se ramifica
  3. Branch:  Un branch es la creación de un codeline a partir de otro codeline, el cual contiene políticas y responsable.
  4. Propagación de cambios: Cada vez que se crean ramas se debe propagar los cambios realizados en la rama a otros codelines existentes
  5. Builds: Un builds es la construcción de un software a partir de los códigos fuentes originales.
  6. Proceso.

I Workspace

  1. No comparta workspaces: El área de trabajo tiene un solo propósito, es el área de edición/compilación/pruebas para un solo desarrollador si se comparten las áreas de trabajo trae confusión a las personas, compromete la capacidad de los sistemas SCM para identificar la actividad del usuario.
  2. No trabaje fuera de workspaces controlados.
  3. No usar jello views: un archivo usado en su workspaces no debiera modificarse a menos que usted explícitamente lo realice. Una “vista de gelatina” es cuando un archivo es modificado por un proceso externo. Por lo tanto dentro de los worksplaces debe estar todas las herramientas, paquetes, necesarios para que la solución pueda ser compilada.
  4. Manténgase sincronizado con el codeline: Como el desarrollo de software es un trabajo en equipo es importante.
  5. Realice Check in a menudo.

II Codeline

  1. Por cada codeline una política: Especifica cuando es permitido realizar check in sobre el codeline.
  2. Por cada codeline un responsable: Resuelve y orienta cuando en ciertos casos la política del codeline queda ambigua, orientando a los programadores sobre excepciones a la política del codeline.
  3. Tenga un codeline principal (trunk o mainline): Provee el destino final para todos los cambios, y representa la principal línea de evolución del software.

III Branches

  1. Cree un branch solo cuando sea necesario: Cada Branch requiere más trabajo, propagar cambios, compilación, etc.
  2. Cree un branch cuando tenga políticas incompatibles: Se debe crear un branch si los usuarios necesitan distintas políticas de check in.
  3. Cree branch just in time: O sea cree el branch cuando lo va a usar para evitar la necesidad de propagación de código.
  4. Ramificar en vez de congelar: Ramifico si requiero que no se modifique el codeline, para no detener a los que se encuentran trabajando.

IV Propagación de Cambios

  1. Pasar los cambios originales de una rama que ha evolucionado lo antes posible: Es mucho más fácil de combinar un cambio de un archivo que está cerca del antepasado común de lo que es la de integrar un cambio de un archivo que ha variado considerablemente. Usted puede reducir al mínimo la complejidad de la combinación al hacer cambios original en la rama que es la más estable.
  2. Propagar a menudo y tempranamente: Siempre y cuando no se viole la política de un branch intente propagar lo antes posible.
  3. Elegir a la persona adecuada que realice el merge: Cualquier persona puede realizar un merge, pero existen dos personas que harán un mejor trabajo, estos son el dueño de los cambios y el dueño de código original.

V Builds

  1. Código + Herramientas = Producto: Para generar un software es necesario el código fuente pero además todas las herramientas utilizadas para el desarrollo, ya sean software, componentes, etc. Debe documentar el uso de todas las herramientas, incluido el SO, compiladores, rutas de ejecutables.
  2. Separe el código fuente de los objetos generados por el build: Esto se refiere a que el código fuente es el que se debe mantener en un repositorio, pero no el resultado de un build.
  3. Check in a todo el fuente original: Mantenga todos las herramientas utilizada en el desarrollo en el repositorio, recuerde que Código + Herramientas = Producto.
  4. Usar herramientas comunes o existentes de build: Todos los implicados en el desarrollo deberían utilizar las mismas herramientas de build, recuerde que Código + Herramientas = Producto.
  5. Realizar buils constantemente: Realizar buils constantemente y sobre todo automatizables genera dos beneficios, por un lado se obtiene los problemas de los check in tempranamente y se pueden actualizar las librerías utilizadas por otros desarrolladores de manera temprana.
  6. Mantenga logs y output  de build: Esto debido a que en proyectos largos, cuando se actualizan herramientas puede existir errores, manteniendo los logs y outputs se puede ver el historial de buils y detectar los problemas de integración.

VI Proceso

  1. Distinga entre requerimiento de cambio y conjunto de cambio: “Qué hacer” y “lo que se hizo” son entidades diferentes. Por ejemplo, un informe de error es un “qué hacer” y una corrección de errores es “lo que se hizo”. El proceso de SMC debe distinguir entre los dos.
  2. Rastree los conjuntos de cambio: Cada historial de revisión es útil en un contexto, como cada archivo contiene su propia revisión esta tiene sentido cuando se sabe el conjunto de cambios realizados. Esto es una manifestación visible de una etapa de desarrollo. Por lo que se debe mantener el paquete de cambios realizados.
  3. Rastree las propagaciones del conjunto de cambio: Una ventaja clara de seguimiento de paquetes es que se hace muy fácil de propagar los cambios lógicos (por ejemplo, correcciones de errores) de un codeline a otro, pero esto no es suficiente, debe mantener un registro de los paquetes propagados, con el fin de responder la pregunta ¿Es la solución para el bug X en la versión del codeline Y?
  4. Todo debe tener un dueño: Todo, política, proceso, producto, documento, componente, codeline, branch, tareas dentro del sistema SCM debe tener un responsable.
  5. La documentación debe actualizarse constantemente: Ante cada cambio de políticas, procedimientos se debe actualizar la documentación.

Referencia

Update: Me he encontrado con un articulo, escrito por Luix, en el cual explica sobre patrones para la Administración de Configuración de Software, aquí lo dejo: http://es.debugmodeon.com/articulo/patrones-en-gestion-de-configuraciones-software-i

El otro día en el blog de Scott, me encontré con un listado de los Shortcuts de Visual Studio 2010, para ser descargados en formato PDF, en A4 y y Legal.

Deben tener en consideración el lenguaje que desean descargar [CSharp = C#, VB = VB, FSharp = F#, CPP = C++)]

Aquí les dejo el link de Descarga.

Fuente: ScottGu’s Blog

http://weblogs.asp.net/scottgu/archive/2010/07/29/visual-studio-2010-keyboard-shortcuts.aspxScoyy

Una de las funcionalidades interesantes que he descubierto hace poco, incluida desde la versión del framework 3.0, es la posibilidad de extender otras clases a través de Extension Methods.

Como Implementar

La implementación es bastante sencilla y requiere de una clase estática y que el método que se desea incluir también lo sea y que el primer parámetro reciba el tipo que se desea extender precedido del modificador this.

Ejemplo

A continuación mostraré un ejemplo extendiendo la clase DateTime agregándole dos métodos uno que obtenga el primer día del mes de la instancia y otro que obtenga el último día.

/// <summary>
    /// Contiene extensiones para DateTime
    /// </summary>
    public static class DateTimeExtension
    {
        /// <summary>
        /// Obtiene el primer día del mes
        /// </summary>
        /// <param name="dateTime"></param>
        /// <returns></returns>
        public static DateTime FirstDayOfMonth(this DateTime dateTime)
        {
            return dateTime.AddDays((-1 * dateTime.Day) + 1);
        }
        /// <summary>
        /// Retorna la fecha con el último día del mes
        /// </summary>
        /// <param name="dateTime"></param>
        /// <returns></returns>
        public static DateTime LastDayOfMonth(this DateTime dateTime)
        {
            return dateTime.AddDays(dateTime.AddMonths(1). FirstDayOfMonth().Subtract(dateTime).Days - 1);
        }
    }

De igual modo pueden bajar el código fuente desde el sitio en codeplex alabra.codeplex.com

Referencias:

El pasado 26 de Junio, se ha comenzado la creación de un framework para realizar validaciones de objetos de negocio, utilizando TDD.

Con la ayuda de Fabio Maulo, quien realizo las primera implementación, ya se ha logrado un gran avance.

Existe una serie de Issue por resolver y muchas cosas más que iran ocurriendo, así que si quieren participar y no saben como les dejo un screencast realizado por Jorge Gamba y Fabio Maulo donde se explica como crear un repositorio en CodePlex, subir el código usando Mercurial y crear un Fork para enviar contribuciones.

Además ya nos hemos juntado 3 veces en lo que denomina “ALT.NET Café“, que es una sesión a modo des conferencia. A continuación les dejo los videos y links para que sigan el proyecto.

Construyendo un Framework desde 0 usando TDD – Parte 1

AltNetHispano.Vale – Parte 2

AltNetHispano.Vale – Parte 3

Inicio

En: General

20 Jul 2010

Iniciamos este blog, veremos que resulta, ojala sea de ayuda para alguien… :)

ALT.NET Hispano
  • Alejandro Labra: Hola Javier, Hace mucho tiempo que no realizo un SSIS, y haybdia no se como se debe realizar. Lam [...]
  • Javier Moreira: Por favor necesito programar un SISS en el lenguaje c# por favor dame código para poder realizar es [...]
  • Pedro Fuentealba: Estimado Alejandro en primer lugar gracias por atender mi solicitud Te cuento que llevo muy po [...]
  • Josue: Que tal man... mira fijate que al ejecutar me da este error. The File option cannot be specified [...]
  • Alejandro Labra: Hola hz: Creo que por aquí puedes encontrar la respuesta a tus problemas: * http://toddmcderm [...]

Twitter

Posting tweet...