El Blog de Quique

Despedida

Quique — Sun, 24 Jan 2010 22:14:00 GMT

Hay situaciones en la vida que te la cambian completamente. Eso me pasó hace un año, ha sido un año duro y muy complicado, pero como se suele decir después de la tormenta llega la calma. Mi vida ha cambiado y por eso he tomado la decisión de cerrar una etapa, la cual me ha apasionado y tras varios años de trabajo como programador he decidido cerrar el visual studio y dedicarme a otras cosas.

Quiero agradecer a muchas personas en especial a mis amigos, a través de estas líneas, todo el apoyo que he recibido durante este año, y a mis compañeros de trabajo y jefes lo que me enseñaron, su tiempo y su dedicación.

“Las despedidas siempre duelen, aun cuando haga tiempo que se ansíen” (Arthur Schnitzler)

Mucha suerte a tod@s

Procedimientos almacenados y permisos

Quique — Mon, 19 Jan 2009 10:17:00 GMT

Como norma general mi cabeza tiende a olvidar a asignar los permisos a los usuarios en los procedimientos almacenados, en mis años de programador siempre que se ponía algo en producción fallaba por los permisos que yo no asignaba (y creo que el resto tampoco), así que tocaba asignarlos uno a uno, una labor encantadora...

Indagando he encontrado como resolverlo y de una forma facil asignar permisos a todos los usuarios (Quizás haya mas formas de resolverlo, estaría encantado de oírlas):

1.- Crear un rol en Sql server database que se llame por ejemplo db_spexecutor, en el que asignamos los usuarios de sql server que queramos.

2.- En la pestaña de seguridad buscamos los procedimientos almacenados

3.- Podemos ir mas facil de 1 en 1 asignando permisos de ejecucion.

Pero si seguimos pensando que esto es una lata...

1.- Crear un rol en Sql server database que se llame por ejemplo db_spexecutor, en el que asignamos los usuarios de sql server que queramos.

2.- Crear el procedimiento almacenado:

CREATE PROCEDURE spGrantExectoAllStoredProcs @user sysname
AS

SET NOCOUNT ON

-- 1 - Variable declarations
DECLARE @CMD1 varchar(8000)
DECLARE @MAXOID int
DECLARE @OwnerName varchar(128)
DECLARE @ObjectName varchar(128)

-- 2 - Create temporary table

CREATE TABLE #StoredProcedures(OID int IDENTITY (1,1),
StoredProcOwner varchar(128) NOT NULL, StoredProcName varchar(128) NOT NULL)

-- 3 - Populate temporary table

INSERT INTO #StoredProcedures (StoredProcOwner, StoredProcName)
SELECT ROUTINE_SCHEMA, ROUTINE_NAME FROM INFORMATION_SCHEMA.ROUTINES WHERE ROUTINE_NAME NOT LIKE 'dt_%' AND ROUTINE_TYPE = 'PROCEDURE'

-- 4 - Capture the @MAXOID value

SELECT @MAXOID = MAX(OID) FROM

#StoredProcedures

-- 5 - WHILE loop
WHILE @MAXOID > 0
BEGIN

-- 6 - Initialize the variables
SELECT @OwnerName = StoredProcOwner,@ObjectName = StoredProcName FROM StoredProcedures
WHERE OID = @MAXOID

-- 7 - Build the string
SELECT @CMD1 = 'GRANT EXEC ON ' + '[' + @OwnerName + ']' + '.' + '[' + @ObjectName + ']' + ' TO ' +@user

-- 8 - Execute the string
EXEC(@CMD1)

-- 9 - Decrement @MAXOID
SET @MAXOID = @MAXOID - 1

END

-- 10 - Drop the temporary table

DROP TABLE

#StoredProcedures

SET

NOCOUNT OFF
GO

Al ejecutarle nos pedira el usuario, le decimos el rol o un usuario en concreto y todos los permisos asignados de golpe.

Espero que os sirva.

Fuente: http://www.mssqltips.com/tip.asp?tip=1203

Sino sabes inglés no eres un programador

Quique — Tue, 30 Dec 2008 14:05:00 GMT

Leyendo blogs en el RSS atrasados por culpa de mis vacaciones y otras cuestiones, me encuentro un post de Scott Hanselman, en el que se comenta si hace falta saber inglés para programar. Esta es una cuestión que siempre está en mi cabeza y creo que en la de muchos. Quizás no te haga falta saber inglés para programar, aunque siempre se aprende, ya que todo el framerwork de desarrollo está en inglés por ejemplo: using System; Lo usamos como si fuera español estando en ingles, y sabemos su significado.

Pero, ¿hay que ir más allá? Yo creo que sí (incluso por abrirte puertas), creo que los que quieren estar a la ultima y avanzar deben tener mucho más nivel que lo basico del idioma de Shakespeare, para poder leer los comentarios de la MSDN en ingles (lo siento odio el traductor ese que tienen), leer blogs (aunque creo que en este sentido hemos mejorado bastante habiendo cada vez más difusión en español), escuchar conferencia, escribir o simplemente poder comunicarte con alguien fuera de tu país en este mundo cada día más global.

El problema que reside en España, es que llevamos toda la vida estudiando inglés y toda la vida sin tener ni idea de inglés.

Como resumen, nivel de ingles alto para programar creo que no, cada vez hay más documentación en español, pero nivel alto para estar a la última en programación, indispensable. ¿Lo mejor? creo que nivel medio como minimo para ser un programador

¿Qué opináis?

DataSets, DataTables y cambios continuos

Quique — Thu, 11 Dec 2008 23:18:00 GMT

Siempre recordaré cuando jugábamos de pequeños, en todos los grupos siempre había un "listillo" o "aventajado" que cuando estábamos en plena partida siempre se inventaba alguna nueva regla o norma para intentar ganar, eso siempre nos obligaba a hacer cambios en nuestras estrategias, para intentar ser el ganador del juego.

Algo parecido me ha pasado desde que trabajo con datos, primero con los recordsets de VB y ahora con los datasets y datatables del Visual Studio .net; es decir, siempre accediendo a los datos de las consultas a través de cadenas de texto, pero claro siempre hay un "listillo", en estos casos los administradores de bases de datos o los jefes o cualquier persona con poder suficiente para decirte: "bien ahora que tienes el campo Codigo de la tabla clientes que seguro que usas en 3 sitios muy concretos, se va a llamar Id_Cliente, así que en 1 hora estará todo cambiado, así que venga a por ello". Tu como buen, rápido y eficiente empleado ctrl + h o replace "Codigo" por "Id_cliente", justo cuando lo vas a hacer cumpliendo plazos (te sientes el rey del mundo), te das cuenta de que "mierda a quien se le ocurriría poner como campo principal de la tabla proveedores Codigo también", mi gozo en un pozo, ahora toca revisar todos los códigos y ver donde se puede cambiar. Tras las 8 horas de rigor llega el jefe y te pregunta: "Que ya acabaste eso?, si es un cambio sencillo, se hace de 2 patadas", y tu acordándote de la persona que le cambio los pañales.

Seguro que esta situación la hemos vivido, la vivimos y la viviremos muchos desarrolladores en nuestro dia a día.

Una forma que hace tiempo "descubrí" se trata de un pequeño truquito, que gracias al EDM averiguamos, es, crear un enumerador por cada tabla de la BBDD con todos los campos de la misma, entonces cuando queremos acceder a un campo tenemos que hacer algo como:

String field = dTable.Rows[0][Clientes.Codigo.ToString()].ToString() //Accedemos al valor de la fila 0, de la columna código de un datatable

Si ya tenemos una clase con los datos de las columnas (segun el modelo de aplicacion que usamos en Maldivas) , podemos insertar un enumerador que se llame por ejemplo Fields y que contenga lo de antes. Esto tiene una pega y es que los que useis FxCop os dara un warning en la definición de la clase por tener el enumerador dentro de la clase, entonces nos quedaria así:

String field = dTable.Rows[0][Clientes.Fields.Codigo.ToString()].ToString()

Con esto podemos estar preparados para cuando llegue el malvado administrador de base de datos o tu jefe y diga: "Cambia el campo", y con un simple refactoring del enumerador, tendríamos en todos los sitios del programa nuestro campo cambiado.

Ahora llega el momento de los "menos trabajadores" que estarán pensando, ya pero claro yo que tengo 1000 tablas de 1000 campos cada una, tengo que mantener eso....¡¡¡INMANTENIBLE!!! Para eso tenemos una herramienta que se llama CodeDom, desde la cual se puede generar código simplemente leyendo información de la base de datos, generando el fichero de código a través de los datos obtenidos de las columnas.

Otra ventaja que tenemos con este metodo es que tenemos un "intellisense" para poder acceder de forma facil a los campos que queremos que contenga la fila.

Otra forma de resolver este metodo es creando constantes de tipo string y con el nombre del campo como valor de la constate. Esto tiene algunos problemas, mucho lio, muchas variables, y que perdemos ese intellisense que con el otro caso tendríamos.

Espero que os sea de utilidad y si conoceis otros metodos que sirvan para resolver este tema, me encantaria comentarlo con vosotros.

Los analistas no son dioses (pero casi)...

Quique — Tue, 09 Dec 2008 18:43:00 GMT

Una pregunta que siempre me hago a mi mismo es: ¿Se debe dedicar mucho tiempo a analizar los requerimientos de una aplicación? o ¿es mejor pasar mas rápido y volver siempre atrás para no perder mucho tiempo en analizar?, con esto me refiero también a los sprint planning meeting de scrum.

Una cosa que no me gustan y que me ponen de mala leche, son los continuos cambios y el "volver" siempre a re-re-re-re-re-hacer lo mismo, porque un analista o analista-programador, por no querer "perder" mucho tiempo dice el primer día: "Hay que hacer las cosas así A-B-C", (como dijo mi profesor de autoescuela), la primera impresión es la que cuenta. El 2º día cuando lo ve dice: "pero como está hecho esto asiiii no sirve porque es B-A-C", ya pero me dijiste que lo hiciera así pero bueno a re-hacer toca. 3º Día: "Como esta echo asiiiiiiii si es C-A-B ahora que me acuerdo " aggggggg otra vez noooooo. No hubiera sido más fácil que el analista tomara aire, pensara 10 min, reflexionara un poco todos los aspectos y dijera: "Después de analizarlo fríamente, despacio tienes que hacerlo así: D-J-K" , hubiera ahorrado mucho tiempo, dinero y quebraderos de cabeza.

Sé que los analistas no son dioses, pero deberían serlo?, con esto que ahorraríamos? muchas veces creo que tiempo, esfuerzo y sobre todo alguna reprimenda a muchos desarrolladores por no tener algo tan sencillo y rápido que se hace en 1 día (sabiendo que es lo que hay que hacer y cómo hacerlo claro).

Enumeradores, desarrolladores y cambios en aplicaciones

Quique — Fri, 21 Nov 2008 17:54:00 GMT

Una de las cosas que menos me gustan cuando he desarrollado aplicaciones son los cambios en cadenas de texto, sobre todo en los ComboBox y demas objetos similares, lo tipico del: "En vez de que ponga Izquierda que ponga Izda", entonces habia que buscar todos y hacer cambios, si es poco usado va rapido pero si se usa mucho mas tiempo...

Se que mucha de esta funcionalidad se puede resolver con controles heredados, pero no es el fondo del asunto, supongamos que ...

Cargar estos valores fijos en un combo a la antigua usanza tendriamos que hacer:

Combo.Items.add("Izquieda")

Combo.Items.add("Derecha")

Combo.Items.add("Ambas")

Pero porque no usar otro metodo:

Creamos un enumerador:

public enum Mano

{Izquierda,Dercha,Ambas}

Usamos su nombre como cadenas, ademas es constante en todo el programa y ademas es facil hacer refactoring?

foreach (Mano item in Enum.GetValues(typeof(Mano)))

{Combo.Items.add(item.ToString());}

Con el enumerador podemos hacer comparaciones con los datos (poniendo el ToString() al campo del enumerador):

if (Combo.Text == Mano.Izquierda.ToString()) {//Operaciones}

Con refactoring podemos cambiar en todo el programa Izquierda por Izda, y solventarlo rapidamente.

Para los que os pregunteis, ya y como hago yo para hacerlo con frases en vez de palabras: "Mano izquierda", pues bien lo mismo pero con un "truquito"

public enum Mano

{Mano_Izquierda,Mano_Dercha,Ambas}

Al cargar simplemente hacemos un replace:

foreach (Mano item in Enum.GetValues(typeof(Mano)))

{Combo.Items.add(item.ToString().Replace("_", " "));}

Y claro siempre que queramos usar el enumerador hay que poner el replace..

El fondo del asunto es el de acceder a una forma facil al enumerador para poder usarlo de "otra forma".

Espero que os sea de utilidad....

Union Vs Union All

Quique — Thu, 20 Nov 2008 21:47:00 GMT

El otro día en un curso sobre las novedades de SQL Server 2008 con los chicos del CIIN, hablando sobre los operadores Union salió a relucir. ¿Es lo mismo dos sentencias Unidas por un Union que por un Union ALL?

A primera vista las sentencias no dan error, pero no es lo mismo poner Union que Union ALL.

¿Diferencia?, básicamente cuando concatenamos con un Union el resultado nos saca sólo los resultados distintos, en cambio con el Union ALL, nos selecciona todos los registros, aunque este duplicado.

Con una tabla con datos: 1,2,3,4,5,6,7
Otra tabal con datos: 2,3,8,9,0

El resultado con Union seria: 1,2,3,4,5,6,7,8,9,0
El resultado con Union ALL seria: 1,2,2,3,3,4,5,6,7,8,9,0

Para resultados en los que tenemos claro que no se van a repetir los valores es conveniente usar Union ALL, debido a que Union hace un distinct de los datos, penalizando el rendimiento.

Interesante diferencia...

PD.1.: Union no sirve para campos Text y NText, pero si sirve el Union ALL (gracias Juan Ignacio).

VS Team Database RC1

Quique — Wed, 19 Nov 2008 22:47:00 GMT

Una herramienta del Visual Studio, que todos sabemos que existe y creo que ha pasado desapercibido en Geeks, si me equivoco corregirme (será que le usamos todos), es que Microsoft ha liberado VSTS 2008 Database Edition GDR Release Candidate:

http://www.microsoft.com/downloads/details.aspx?FamilyID=bb3ad767-5f69-4db9-b1c9-8f55759846ed&displaylang=en

Así que si alguno estáis usando alguna CTP, Agosto o Septiembre, podéis descargarla, han mejorado alguna cosa, y algún error sigue habiendo, a ver si van mejorando. Ya os iré comentando alguna cosa sobre ella.

Mi primer post…

Quique — Wed, 19 Nov 2008 22:19:00 GMT

Quiero empezar esta aventura en Geeks, saludando a tod@s.

Primero dar las gracias a Rodrigo y a la gente de Plain, por darme la alternativa, como se suele decir en los toros. Tampoco me quiero olvidar de mis compañeros y mis jefes tanto de Energy Watch, como de Oran (de ser bien nacido es ser agradecido como se suele decir).

Espero estar a la altura de este blog, mi idea es de comentar cosas sobre desarrollo , C#, Sql server, Team Database, DevExpress, Resharper y en general cualquier Add-In que cae en mis manos, aunque sin olvidarnos de todo lo nuevo con lo que Microsoft nos “obsequia” cada poco tiempo.

Sobre mi rápidamente:

Tengo 28 años, Vivo en Solares, empecé con esto del desarrollo con 11 años haciendo cursos de Basic, Lotus, DBase III… Hasta que no empecé la carrera de Ing. Informática no empezó a interesarme realmente el desarrollo. Llevo 6 años trabajando. Estuve a punto de “quemarme” pero ahora disfruto el doble (siempre que no me toque limpiar la fibra óptica, o buscar un toro de 3000 Kg ;-)…).

Otro aspecto que me apasiona es discutir con mi jefe y mis compañeros, hace la jornada más “agradable” (el día que no hayas discutido con tu jefe es un día perdido).

No os quiero aburrir más, asi que lo dicho, un saludo a todos.