Nuevo dibujo de la clase de Flash. Próximamente animaciones…
En este caso, un Corvette:

Aprovecho que estoy en clase de base de datos para publicar algunas funciones de bases de datos SQL, específicamente para MS SQL Server.
Son los apuntes de lo que va del semestre en Aplicaciones de bases de datos, pueden venir a mano como referencia, o para aprenderse alguna nueva. La mayoría tienen su respectivo ejemplo aplicado a la bd, aunque se entienden bastante bien fuera de contexto.

El script de la base de datos lo adjunto como enlace a continuación:
Base de datos (bd.sql) - 5,22 Kb

Mayúsculas y minúsculas:

Eliminar espacios:

Longitud de un valor en un campo:

Función sub string: args(string, inicio, longitud)

Función buscar índice de caracter: args(char, string[, a partir de cuál])

Función espacio:
-- SET @valor = SPACE(9)

Función convertir a string:

Declaración de variables:
Formato:
DECLARE @NombreVar tipo
SET @NombreVar = Valor
Ejemplo:

CONVERT:
CONVERT(Tipo, Campo o expresión, estilo)
El estilo en las FECHAS:
103 muestra: 23/05/1986
112 muestra: 19660523
114 muestra: hora

FUNCIONES CON FECHAS

DATEADD(partefecha (dd, mm, yy), número, fecha)

DATEDIFF(partefecha, fecha1, fecha2)
Resta la parte de la fecha = fecha2 - fecha1

DATEPART([dd,mm,y, dw(día de la semana)], fecha)

Redondear valores:

ISDATE(campo)
Devuelve 1 si el campo contiene una fecha válida, sino devuelve 0
Valor nulo no es de tipo fecha

ISNUMERIC(campo)
Devuelve 1 si el campo contiene un valor numérico, sino devuelve 0

IDENTIFICADOR UNICO:

La función NEWID solamente funciona para columnas que hayan sido declaradas como UNIQUEIDENTIFIER

FUNCIONES DEL SISTEMA
Generalmente llevan "@@" adelante. Para encontrarlas, en la ayuda se puede buscar el string @@ que nos va a mostrar la mayoría de las que hay.

@@ROWCOUNT
Devuelve el número de filas afectadas por la última instrucción
Queda en cero cuando hubo error o no se realizó la instrucción.

@@ERROR
Devuelve 0 si no hubo error, o distinto de cero con un código específico (véalo en el manual) con el error

@@IDENTITY
Muestra el último identity de la tabla. O sea, si por ejemplo hacemos una columna con valor int que va autoincrementando, y es identidad, al seleccionar éste valor, nos devuelve el último insertado.

Ver el usuario actual con el que se está logueado:

ESTRUCTURA IF

Ver mensajes del sistema:
Para usar la tabla master:

ó agregar la "ruta absoluta":

En la próxima clase, empiezo a ver vistas. Probablemente vaya publicando más apuntes más adelante.

Ésta imagen ha recorrido ya varios lugares donde se escribe respecto al tema, pero la posteo porque realmente representa la situación.

La noticia del "Sí" al OOXML en Uruguay ya se hizo eco en distintos portales de noticias alrededor del mundo.

En Barrapunto y Menéame publican la noticia, seguida de la discusión de muchos usuarios, ya que el tema da para hablar, y mucho.

En el blog de Rodolfo Pilas, presidente del UYLUG, escribe del tema, seguramente una experiencia más directa al haber sido uno de los representantes para el ODF:

"Así, mi País, Uruguay, se manifiesta como un polo tecnológico y se debaten politicas para la Sociedad de la Información y hasta se le da el nombre de “Uruguay Tecnológico” a esta actitud.

Entonces vemos que los propios actores de ese Uruguay Tecnológico consideran la especificación del formato de documento OOXML como aceptable para convertirse en estandard ISO y esa será la opinión de Uruguay al respecto."

Recomiendo seguir leyendo el post...

Desde Chile, hay bastante certeza de que el voto sea por SI, dada la situación entre Microsoft y el estado chileno. En El Diablo en los Detalles, detallan un poco el tema, acá y también en
Microsoft y OOXML: el costo de un voto afirmativo (en Suecia)

Y en el blog de Enrique Dans, postea una columna con información, planteando una situación Orwelliana en la lucha entre compañías, en:
Escribiendo sobre el proceso de estandarización del OOXML en Libertad Digital

En Boycott Novel también miran hacia el sur con decepción en un análisis de la problemática detrás del formato OOXML en Suecia, Malasia, la corrupción, una petición por ODF en el Reino Unido, y comentan que "Microsoft se mandó una Suecia en Uruguay".

1. El mundo está lleno de problemas fascinantes esperando ser resueltos.
2. Ningún problema debería ser resuelto dos veces.
3. El aburrimiento y la monotonía son malvados.
4. La libertad es buena.
5. La mala actitud no es un substituto para la competencia.

Los Hackers resuleven problemas y construyen cosas, y creen en la libertad y la ayuda mútua voluntaria. Para ser aceptado como un hacker, tienes que comportarte como si tuvieras esta actitud tú mismo. Y para comportarte como si tuvieras la actitud, tienes que realmente creer en la actitud.
Pero si crees en cultivar actitudes hacker simplemente como una forma de obtener aceptación en la cultura, perderás el punto.
Convertirse en el tipo de persona que cree en éstas cosas es importante para tí - para ayudarte a aprender y mantenerte motivado. Como con todas las artes creativas, la forma más efectiva de volverse un maestro es imitar la mente de los maestros - no solo intelectualmente sino emocionalmente también.
O, como dice el moderno poema Zen:

Seguir el camino:
mira al maestro,
sigue al maestro,
camina con el maestro,
ve a través del maestro,
conviértete en el maestro.

Así que, si quieres ser un hacker, repite las siguientes cosas hasta que las creas:

1. El mundo está lleno de problemas fascinantes esperando ser resueltos.
Ser un hacker es muy divertido, pero es un tipo de diversión que requiere mucho esfuerzo. El esfuerzo lleva motivación. Los atletas exitosos obtienen su motivación de una satisfacción física en hacer que sus cuerpos actúen, presionándose a través de sus propios límites físicos. Similarmente, para ser un hacker debes obtener una emoción básica al resolver problemas, afinando tus habilidades, y ejercitando tu inteligencia.
Si no eres el tipo de persona que se siente así naturalmente, necesitarás convertirte en una para lograrlo como hacker.
De otra forma encontrarás tu energía de hacking debilitada por distracciones como el sexo, el dinero, y la aprobación social.
(También debes desarrollar un tipo de fe en tu propia capacidad de aprendizaje - una creencia de que aunque no sepas todo lo que necesitas para resolver un problema, si resuelves solo una parte y aprendes de eso, vas a aprender lo suficiente como para resolver la siguiente parte - y así, hasta que termines.)

2. Ningún problema debería ser resuelto dos veces.
Los cerebros creativos son valiosos recursos limitados. No deberían ser gastados en re-inventar la rueda cuando hay tantos nuevos problemas fascinantes esperando ahí afuera.
Para comportarte como un hacker, tienes que creer que el tiempo pensante de otros hackers es precioso - tanto que es casi un deber moral para tí compartir información, resolver problemas y luego dar las soluciones para que otros hackers puedan resolver nuevos problemas en vez de tener que volver a problemas viejos perpetuamente.
Nótese, sin embargo, que "Ningún problema debería ser resuelto dos veces." no implica que tengas que considerar todas las soluciones existentes sagradas, o que hay una sola solución correcta a un problema dado. Regularmente, aprendemos mucho sobre el problema que no sabíamos antes, estudiando el primer intento a una solución. Está bien, y es a menudo necesario, decidir que podemos hacerlo mejor. Lo que no está bien es barreras técnicas artificiales, legales o institucionales (como código fuente cerrado) que previenen una buena solución de ser re-usada y forzan a la gente a re-inventar ruedas.
(No tienes que creer que estás obligado a dar todo tu producto creativo, aunque los hackers que lo hacern son los que obtienen el mayor respeto de otros hackers. Es consistente con los valoes de hacker de vender suficiente de ello para mantenerte en comida y alquiler y computadoras. Está buen usar tus habilidades de hacker para apoyar a una familia o inclusive volverte rico, mientras no olvides tu lealtad a tu arte y tus compañeros hackers mientras lo haces.)

3. El aburrimiento y la monotonía son malvados.
Hackers (y las personas creativas en general) nunca deberían estar aburridos o tener que tratar con trabajo estúpido y repetitivo, porque cuando sucede ésto significa que no están haciendo lo que sólo ellos pueden hacer - resolver nuevos problemas. Ésta pérdida afecta a todos. Por lo tanto el aburrimiento y la monotonía no son sólo indeseados sino realmente malvados.
Para comportarte como hacker, tienes que creer en ésto lo suficiente como para querer automatizar los pedazos aburridos tanto como sea posible, no sólo para tí, sino para todos los demás (especialmente otros hackers).
(Hay una excepción apartente a ésto. Los hackers harán cosas a veces que pueden parecer repetitivas o aburridas para un observador como ejercicio para limpiar la mente, o para adquirir una habilidad o tener alguna experiencia en particular que no puedes obtener de otra manera. Pero ésto es por elección - nadie que pueda pensar debería ser forzado a una situación que lo aburre.)

4 - La libertad es buena.
Los hackers son naturalmente anti-autoritarios. Cualquiera que pueda darte órdenes puede detenerte de resolver cualquier problema por el cual estés fascinado - y, dada la forma en que trabajan las mentes autoritarias, generalmente encontrarán alguna razón estúpida para hacerlo. Así que la actitud autoritaria debe ser contrarrestada dondequiera que la encuentres, más si asfixia a tí y a otros hackers.
(Ésto no es lo mismo que pelear contra toda autoridad. Los niños deben ser guiados y los criminales retenidos. Un hacker puede estar de acuerdo en aceptar algunos tipos de autoridad para obtener algo que quiere más que el tiempo que gasta siguiendo órdenes. Pero eso es una carga limitada y consciente; el tipo de rendimiento personal que quieren los autoritarios no está en oferta.)
Los autoritarios buscan la censura y el secreto. Y desconfían de la cooperación voluntaria y el compartir información - sólo les gusta la 'cooperación' que controlan. Asi que para comportartse como hacker, tienes que desarrollar una hostilidad instintiva a la censura, secreto, y el uso de la fuerza o la decepción para obligar a adultos responsables. Y tienes que estar dispuesto a actuar en esa creencia.

5. La mala actitud no es un substituto para la competencia.
Para ser un hacker, debes desarrollar algunas de éstas actitudes. Pero adquirir una actitud solamente no te convertirá en hacker, más de lo que te hará un atleta campeón o una estrella de rock. Volverse un hacker tomará inteligencia, práctica, dedicación, y trabajo duro.
Por lo tanto, tienes que aprender a desconfiar de la actitud y respetar la competencia de todo tipo. Los hackers no le permitirán a los posers desperdiciar su tiempo, pero adoran la competencia - especialmente la competencia hackeando, pero competencia en lo que sea es valiosa. Competencia en habilidades demandantes que pocos pueden dominar es especialmente bueno, y la competencia en habilidades demandantes que involucran agudez mental, habilidad y concentración es lo mejor.
Si reveras la competencia, disfrutarás desarrollarla en tí mismo - el trabajo duro y la dedicación se volverán un tipo de juego intenso en vez de una monotonía. Ésta actitud es vital para volverse un hacker.

Texto original:
http://www.catb.org/~esr/faqs/hacker-howto.html#attitude
Basado en la revisión 1.35 del 21 de marzo de 2007.

A través de LinuxUruguay y el blog de "Perro" Boksar, me entero que el paisito dice que sí al formato de Microsoft.
27 de agosto de 2007, Uruguay, ha decidido votar SI al formato ECMA-345 presentado a ISO y denominado ISO/IEC DIS 29500

Si bien se puede considerar "una derrota" para el software libre en el país, todavía falta la decisión en el resto del mundo. India y China ya dijeron que no. En Suecia Microsoft compró el voto.
Y ahora en Uruguay, parece que también.

Una carta publicada en LinuxUruguay respecto al tema, de Perro Boksar de UYLUG:

Gente, UY ha resuelto votar SI con tarjetita postal... solo 2 votos por la negativa. Está claro que ayer nos topamos con un comité totalmente cooptado por MS.

Respecto a quienes votaron qué, pues podemos decirles que IBM y UyLUG fueron NO Con Comentarios... ahora, la realidad es que UNIT adaptó los sistemas de votación para que se pudiera emitir un voto por la afirmativa sin considerar comentarios técnicos sólidos, permitiendo que se trate de irrespetuosos a quienes presentaron información sobre funciones sobre última hora del viernes alegando que no deberían ser tomadas en cuenta a la hora de votación por "entrar fuera de plazo"... cómo argumentar contra eso?

Honestamente luego de ver lo sucedido ayer, ver el sello de UNIT/ISO Certified en alguna empresa o producto solo me hará pensar en cuanto dinero/presión habrá tenido el empresario/fabricante.

Solo me queda la esperanza que a nivel mundial se logre una negativa, y lamento que mi país no aporte nada a ese resultado

Mis felicitaciones a mis colegas de Argentina que han logrado una abstención en tan corto plazo!

Perro
UyLUG/LinuxTeros

En el blog de Perro se puede leer las experiencias de la votación como testigo directo:

"Tristemente esta desición ha sido tomada en base a una votación en la cual fue más el apuro por levantar la mano que por tratar de comprender los problemas planteados al formato… tal es así, que en un momento de la reunión los representantes de Microsoft(Pablo García) y Soluziona han tratado al representante de IBM Rodrigo Baraibar de irrespetuoso por presentar comentarios al formato el viernes pasado a última hora, alegando que estaba “fuera de fecha” :/"

Post completo:
UNIT dijo SI a OOXML - ISO/IEC DIS 29500

Se puede leer más al respecto en Comunidad.org.uy, donde hay bastante información del formato, sus errores, conflictos, inconsistencias e incompatibilidades.

Para los visitantes de otros países, pueden visitar http://www.noooxml.org/delegations para conocer la delegación de su país y hacer la petición en contra del formato.

Como sigue siendo costumbre los últimos viernes de cada mes se realiza la conferencia técnica de la RTE.
Nuevamente voy a dar mi presentación sobre el patrón Singleton en Java y C#. Además se va a repetir la introducción a patrones de diseño y el patrón Factory.
Intentaremos hacer algunas cosas diferentes para que no se aburran los que ya vieron la presentación...

Quinto encuentro de la RTE

Esta vez se repetirán los temas de la anterior, para quienes se la perdieron, y se suma la charla de tecnología xBase y BDD.

Temario:

1. ¿Qué son los patrones de diseño?
2. Patrón Factory (Fábrica)
   Ambos temas serán expuestos por Mauricio López.
3. Patrón Singleton (Instancia única)
   Presentado por Fernando Briano.
4. Tecnología xBASE y bases de datos.
   Orador: Darío Fernández.

El lugar, como en las charlas anteriores:
Sala de Conferencias de CEI, ubicada en Arturo Santana 594 y San Carlos (Maldonado).

Así que ya saben, si están cerca, están invitados a asistir.

# Los lunes apestan.

# Los lunes fueron, son y siempre serán.

# A nadie le gusta el lunes.

# A cualquiera que sí le gusten los lunes es un despiadado inmortal o gerente y por lo tanto no cuentan.

# Nunca le preguntes a nadie cómo está un Lunes.

# Todos tienen permitido quejarse un lunes.

# Nunca intentes terminar una tarea urgente un Lunes. Si se entera, lo vas a lamentar.

# Si los Lunes te marcan, estás terminado.

# Nadie vence a los Lunes. Nunca.

# De alguna manera, siempre parecen haber más lunes que viernes.

# Los Lunes, siempre es tu culpa, y no hay forma de arreglarlo.

# Todo lo que era una pequeña irritación el Viernes siempre crece a una insoportable mortificación para el Lunes.

# Llamar enfermo un Lunes sólo significa más problemas para el Martes. Los Lunes no pueden ser evitados.

# Los Lunes nunca olvidarán lo que tienes que hacer.

# Si el Lunes fuera una persona sería un policía de tránsito loco. No realmente malo, solo muy poderoso, y altamente vengativo.

# Saber que se viene la mañana del Lunes tiene una forma de arruinar los Domingos en la noche.

# El Martes es uno de mis días favoritos solamente porque es el punto en el cual el Lunes está lo más lejos posible.

# Si hiciste algo útil un Viernes, vas a tener que hacerlo de nuevo el Lunes.

# Al Lunes le encanta verte sudar.

# En muchos lugares, Lunes es considerada una mala palabra y no debería ser utilizada en compañía cortés.

# Los Lunes nunca deberían ser afrontados sin café.

Traducido de:
http://kludgespot.blogspot.com/2007/05/20-things-i-learned-from-mondays.html
Con permiso de Kludge Spot, bajo licencia Creative Commons.