domingo, 9 de noviembre de 2014

Buenas tardes lectores, hoy les traigo un pdf del proceso de normalización de base de datos, se transformó casi en una costumbre el hecho de pasar todas las entradas finalizadas de un tema a un formato pdf agregando ajustes, correcciones y extras para deleite de nuestros lectores, la idea es que les sea más cómoda la lectura de entradas relevantes de forma ordenada.
Esto no quiere decir que todas las entradas del blog esté en formato pdf ni que las mejores lo estén, simplemente que los hilos de entrada más relevantes (como calidad de software, bases de datos, proximamente patrones de diseño, y programación, si lo están).

Sin más preambulos les dejo los temas que abarcan y las entradas relacionadas a un click de distancia.

Primera Forma Normal (1FN) (ver entrada relacionada)
Segunda Forma Normal (2FN) (ver entrada relacionada)
Tercera Forma Normal (3FN) (ver entrada relacionada)
Cuarta Forma Normal (4FN) (ver entrada relacionada)
Quinta Forma Normal (5FN) (ver entrada relacionada)


Un saludo lectores y espero les haya gustado la entrada del día de hoy.

sábado, 8 de noviembre de 2014

En esta entrada hablaremos sobre la quinta forma normal, 5FN. Recomiendo por supuesto la lectura de las publicaciones anteriores 4FN y la publicación inicial del hilo de bases de datos aquí.


En entradas anteriores hablamos sobre el proceso de normalización, su importancia, hablamos sobre los 5 niveles anteriores (incluyendo el FNBC o BCFN), y hoy hablaremos sobre el último de los niveles, también quiero agregar que como el anterior, solo debe ser utilizado en caso de que la situación lo requiera.

Ésta no es tan complicada como la 4FN de hecho es bastante sencilla de explicar y se establece de la siguiente manera, una tabla se encuentra en 5FN si y solo si, se encuentra en 4FN y cumple el siguiente requisito:

  • No existen relaciones de dependencias no triviales que no siguen los criterios de las claves. Una tabla que se encuentra en la 4FN se dice que está en la 5FN si, y sólo si, cada relación de dependencia se encuentra definida por claves candidatas.
En otras palabras, cualquier relación de dependencia que haya en la tabla debe estar compuesta por un campo o un grupo de campos que sean clave primaria, y el resto de los campos no clave primaria dependan de los campos anteriores.

Por lo que no puede existir una relación de dependencia en la que no haya una clave primaria y sean simples campos, esto también está apoyado por la 3FN donde se prevee el problema de la dependencia transitiva.

Espero que hayan comprendido hasta éste punto las 6 formas normales (incluyendo la de B-C), quiero agregar como sugerencia la lectura del artículo de wikipedia de normalización.

Saludos!

miércoles, 5 de noviembre de 2014

En entradas anteriores vimos Factory Method, y en esta entrada veremos Abstract Factory un patron creacional que amplía el rango de Factory Method. También vimos ObjectPool y una introducción a los patrones de diseño.

Recomiendo leer como minimo el Factory Method para que les sea más sencillo el Abstract Factory.

Si vemos la explicación del Factory Method notaremos que es útil para la creación de objetos de clases subtipos de una en particular, pero si quicieramos tener más de un tipo de clase principal, deberíamos hacer uso de un patrón que lo soporte.

Podemos ver en wikipedia como se explica que si nosotros trabajaramos con botones, dependiendo de la plataforma tendríamos un gran tipo de objeto para botones en linux y uno para botones en windows, si nosotros quicieramos crear objetos de ambos tipos con un factory necesitaríamos utilizar este patrón.

La solución para este problema es simple, si vemos el código de ejemplo de la publicación de Factory Method veremos que la factoría nos permitía crear objetos del tipo de EjemploConcreto, ahora si quicieramos además poder crear de tipode clases OtroEjemploConcreto, bastaría con crear métodos factory para cada clase en particular.

podemos ver el código aquí:

http://pastebin.com/V0HS6fU2

y un diagrama del Abstract Factory extraído de wikipedia:


Un saludo para todos! espero que les haya gustado la entrada y nos veremos la próxima!

lunes, 3 de noviembre de 2014

En ésta entrada trataré de explicar de forma lo más simple posible la cuarta forma normal, 4FN que es bastante dificil de explicar, recomiendo por supuesto la lectura de entradas anteriores del tema FNBC, 3FN, 2FN, 1FN y la publicación introductoria al tema de hace un año.


La 4FN está relacionada con la dependencia multivalor, ésta es aquella dependencia que ocurre con los distintos valores que puede tener un campo y que depende de un valor de un campo x.

Esto es, cuando un campo tiene un valor x, otro campo puede tener alguno de muchos valores que dependan de ese valor de ese campo.

Una tabla está en 4FN si y solo si, la misma se encuentra en 3FN, además cumple con el siguiente requisito:



Para cada una de sus dependencias múltiples no funcionales, asumiendo X como el campo de único valor -cuyo dependiente campo es Y (de múltiples valores)-, éste campo X es clave candidata o grupo de claves candidatas.


En otras palabras tomando la idea de dependencia funcional multivalor, aquel campo con el valor que puede resultar en la dependencia de varios posibles de otro campo, es una clave primaria, o grupo de claves primarias.

Cuando un campo tiene un valor x, otro campo puede tener alguno de muchos valores que dependan de ese valor de ese campo, la tabla estaría en 4FN si el campo del valor x es una clave primaria o conjuntos de claves.

Por supuesto esta forma normal solo será útil cuando existan dependencias funcionales multivalor.

Un saludo, espero que se entienda, me haya explicado bien, y espero les agrade la entrada, para nuevas entradas puedes estar atento al blog, donde seguro la próxima será la 5FN y luego pretendo hablar sobre unas reglas de normalización escritas por Codd.

domingo, 2 de noviembre de 2014

En una de las entradas anteriores hablamos sobre Patrones de diseño, realizamos una introducción simple y ahora hablaremos sobre el Factory Method, un patrón creacional.

Sugiero ver el patrón anterior, el ObjectPool que incluye una explicación de los patrones creacionales y su razón de ser.

El factory method es un patrón de diseño creado para resolver el problema que sucita a la hora de crear instancias de muchos subtipos de clases que tengan particularidades, los detalles que incluyen pueden resultar innecesarios para el cliente que implemente dichas clases, de modo que se engloba el proceso de construir las instancias en una clase constructora.

Pueden ver un ejemplo del factory method en php en el siguiente enlace:


Espero que les haya gustado la idea, pd: la imagen fue sacada de wikipedia.

sábado, 1 de noviembre de 2014

Buenas tardes, en esta entrada hablaremos de la FNBC (Forma Normal de Boyce-Codd), recomendamos la lectura de 1FN 2FN 3FN y el artículo inicial, para tener un panorama de lo que se habla en esta entrada.

La FNBC es una forma normal que se puede considerar como una extensión de la tercera forma normal, establece un requisito extra.

Una tabla se encuentra en FNBC si y solo si se encuentra en 3FN (por lo que también se encuentra en 2FN y 1FN), y cumple el siguiente requisito:

No deben existir dependencias funcionales no triviales.

Esto quiere decir que todos aquellos campos que tienen campos que dependan de ellos, son claves primarias.
En otras palabras que la tabla no tenga campos de este tipo sin ser clave primaria, ya que de lo contrario habría una dependencia transitiva, no obstante tenga mucho cuidado al modificar esto ya que puede al hacer claves primarias a campos de este estilo crear un conflicto con la 2FN suponiendo que no todos los campos sean dependientes del mismo o que con ese campo hayan otros campos que no dependan de las demás claves primarias.

Ésta entrada es bastante simple y corta ya que no hay mucho que agregar a la explicación de FNBC, es bastante sencilla y simplemente una extensión de la 3FN.

Un saludo y espero les guste la entrada, en futuras entradas hablaremos de 4FN y 5FN.

jueves, 30 de octubre de 2014

Buenas, en la entrada de hoy hablaremos sobre el diagrama de actividades, también conocido como diagrama de flujo, es probable que usted ya lo conozca, es uno de los diagramas preferidos de la gente, aunque en lo personal concidero que para sistemas grandes este diagrama no aporta mucho, complica las cosas salvo que se lo haga muy generalizado.



El diagrama de flujos o actividades es una representación gráfica del proceso que realiza el programa, tiene una cierta cantidad de simbolos que representan situaciones posibles.
Este diagrama representa paso a paso el proceso que lleva a cabo el programa o la tarea en si a realizar.

Simbología
El diagrama comienza y finaliza con un ovalo o elipse que indica el comienzo y el final del diagrama.
Luego podemos apreciar ractángulos que representan una actividad o procedimiento.
El rombo representa una desición, una pregunta en particular y la bifurcación hacia dos posibles caminos.
El círculo representa un enlace de actividades con otras dentro de un procedimiento, el circulo puede conciderarse como un conector.
Luego se encuentran los triangulos, un triangulo boca arriba representa guardar un documento de forma temporal, mientras que el triangulo boca a bajo se refiere a guardar un documento de forma definitiva.

Hay distintos tipos de diagramas de flujo, podemos apreciar formatos verticales, horizontales o panorámicos, dependiendo de la forma en la que se establezca la disposición y el camino del diagrama.

Podemos apreciar a continuación el diagrama de flujo para un bucle For.

Un saludo y espero les haya gustado la entrada del día de hoy, pueden ver los diagramas anteriores como el diagrama de clases y el de casos de uso aquí.

miércoles, 29 de octubre de 2014

En esta entrada hablaremos sobre el patrón creacional Object Pool, recordemos que en la entrada anterior de este hilo vimos una introducción a los patrones en general, pueden apreciarla aquí (además de ver un índice de patrones)

En primera instancia hablaremos sobre los patrones creacionales, son aquellos patrones diseñados para solventar problemas enlazados a la creación o instanciación de objetos.

El patrón object pool está diseñado para almacenar instancias de los objetos, un cliente del Object Pool, solicita un objeto, el Object Pool lo devuelve, el cliente lo utiliza, y luego se lo devuelve al Object Pool, de modo que éste lo almacena y espera su próxima solicitud, cuando le solicitan el objeto nuevamente, el Object Pool lo devuelve y así continúa el ciclo, la idea de este patrón es reciclar un objeto. Como apreciará la utilización de este patrón implica que un objeto no se construye y destruye varias veces, sino que se recicla.

Pero hay que ser muy conciente de su funcionamiento, ya que es únicamente útil en situaciones donde el costo de crear una instancia sea relativamente alto, a diferencia del costo de mantenerla almacenada, de modo que solo es útil en ocaciones tales como clases de sockets o de recursos gráficos.

Hay situaciones en donde el costo de utilizar este patrón es mayor al costo de no utilizarlo, y hay situaciones en las que es al reves.

Un ejemplo de object pool en php:


Saludos, espero les haya gustado la entrada y sigan pendientes de las siguientes entradas.

martes, 28 de octubre de 2014

Buenas tardes lectores, en esta entrada hablaremos sobre la tercer forma normal, del proceso de normalización. Recomiendo completamente la lectura de las entradas anteriores Primera forma normal, Segunda forma normal y la entrada de hace casi un año que comenzaba éste hilo de entradas aquí.


Recordemos que el proceso de normalización es un proceso sumamente importante que preve problemas futuros con una base de datos cuando la misma adquiera gran cantidad de registros. El proceso consta en verificar y diseñar las distintas tablas para que cumplan los requisitos de cada uno de los niveles (hasta el nivel que queramos llegar), cuando todas las tablas cumplen los requisitos de un nivel, se dice que la base de datos está en ese nivel, de lo contrario hablamos que tales tablas están en ese nivel.

La tercera forma normal es para muchos el final del camino, ya que a no ser que hablemos de una gran base de datos de gran importancia y que pueda darse el caso que se necesiten los demás niveles, la mayoría de las bases de datos que se ven terminan sus tablas en 3FN.

Una tabla está en 3FN si y solo si se encuentra en 2FN, y cumple con las siguientes características:

No existe ninguna dependencia funcional transitiva entre los campos que no son clave.

Primero explicaremos qué es una dependencia funcional transitiva, recordemos que hay campos que dependen de otros, y que en las FN anteriores los campos debían depender de la clave primaria.

La dependencia funcional transitiva ocurre cuando un campo B depende un campo A, y un campo C depende de un campo B, de modo que se asume que el campo C depende transitoriamente del campo A.

A  B  C, B depende de A, C depende de B, entonces C depende de A.

Veamos la siguiente tabla con los siguientes campos:

fecha_nacimiento, edad, conducir

fecha de nacimiento es la clave primaria en nuestra tabla, vemos que con la fecha de nacimiento podemos conocer la edad, y con la edad podemos saber si tiene la suficiente para poder conducir, entonces podemos deducir solo con la fecha de nacimiento si puede conducir o no, esto es una dependencia funcional transitiva.

De modo que una tabla que tenga dependencias de este tipo no está en 3FN, en cambio si la tabla no tiene dependencias transitivas entonces está en 3FN.

Podemos observar claramente si un campo tiene dependencias de este tipo observando que, si un campo que no es clave primaria, depende de otro campo que no es clave primaria, entonces es muy probable que haya una dependencia transitiva (asumiendo que el segundo campo que no es clave primaria si tenga una dependencia sobre una clave primaria.)

Un saludo para todos y espero les haya gustado la entrada. Sigan al tanto para ver nuevas entradas al respecto.

domingo, 26 de octubre de 2014

Algunas entradas atras vimos el diagrama de clases, y hoy veremos el diagrama de casos de uso de UML, perteneciente a la categoría de diagramas de Comportamiento.

El diagrama de casos de uso permite establecer de forma gráfica el comportamiento del sistema para con los distintos actores que aparezcan en nuestro sistema.
Un diagrama de casos de uso realizado correctamente permite ver de forma simple y organizada nuestro sistema, de una forma visualmente rápida.

Este diagrama está compuesto por algunos pocos componentes y resulta de los diagramas más sencillos de realizar, no obstante para gran cantidad de actores puede volverse complejo y dificil de diagramar, bastante extenso.

Lo primero a conciderar en uno de éstos diagramas es la existencia de los actores, los actores son aquellas personas que utilizaran nuestro sistema, no las personas en particular, pero si el tipo de persona, en la imagen anterior vemos como sería un diagrama de un restaurante, los actores en este caso son el chef y el crítico, aunque se podrían agregar muchos más actores tales como el mesero, y los demás clientes regulares, todos los clientes estarían representados por un actor.

Luego tenemos las distintas tareas que se pueden realizar en nuestro sistema, dentro de un circulo, para indicar que tarea realiza cada actor se debe marcar con una linea.

Pueden haber tareas compartidas, pero no pueden existir dos circulos para la misma tarea.

El objetivo de este diagrama es entonces el de mostrar de forma ordenada las distintas tareas del sistema y quien las realiza, simple y sencillo.

En lo personal concidero que éste debería ser el primer diagrama que uno realize a la hora de diseñar un sistema, ya que le deja las cosas claras para el resto de los diagramas.

Un saludo lectores! y espero que les haya gustado,

sábado, 25 de octubre de 2014

En esta entrada comenzaremos el hilo de Patrones de Diseño, y comenzaremos hablando sobre una introducción a patrones de diseño, en entradas anteriores hablamos sobre el mal uso que se le da a singleton, y en esta entrada hablaremos sobre los distintos patrones.

El arquitecto Chritopher Alexander dijo en su libro:

"Cada patrón describe un problema que ocurre una y otra vez en nuestro entorno, además incluye una solución para ese problema, de tal manera que usted pueda usar esa solución un millón de veces y más".
Si bien Christopher hablaba de patrones de edificios, no se aleja mucho de la idea de patrones en la industria del software, cuando un problema aparece una cantidad de veces bastante importante, se define un patrón del problema, y se busca una solución que aplique a todos los casos y casos futuros.

Como anuncia wikipedia, un patrón para serlo debe cumplir ciertas características, una de ellas es que debe comprobar su efectividad resolviendo el mismo problema en situaciones anteriores, y otra es la re-usabilidad, que significa que el patrón debe ser aplicado en futuras ocasiones donde el contexto varíe.

Por lo general un patrón está compuesto por cuatro partes:

El nombre: que nos sirve como descripción del problema y la solución que abarca dicho patrón.
El problema: el problema que trata de resolver y para el que fue diseñada la solución (por este motivo mi publicación en queja de la utilización del patrón mvc en la web)
La solución: además de ser la solución al problema, hay que aclarar que no es específica a una situación en concreto, recordemos que los patrones tratan de resolver problemas que ocurran varias veces en situaciones diferentes, funciona prácticamente como una plantilla.
La consecuencia: nos referimos con esto, a los resultados de aplicar el patrón y a los compromisos que conlleva la utilización de dicho patrón.

Los patrones que serán abarcados en las futuras entradas serán los siguientes:

Patrones Creacionales:
Object Pool
Factory Method
Abstract Factory
Builder
Prototype
Singleton
Model-View-Controller

Patrones Estructurales
Adapter
Bridge
Composite
Decorator
Facade
Flyweight
Proxy

Patrones de comportamiento
Chain of Responsibility
Command
Interpreter
Iterator
Memento
Observer
State
Strategy
Template Method
Visitor

Espero que les haya gustado la entrada, y espero verlos leyendo sobre cada patrón a medida que los publique.

viernes, 24 de octubre de 2014

Buenas tardes lectores, en esta entrada (la nº 100) pensaba hacer algo diferente, por lo que realizaré una entrevista a Cody Roodaka, desarrollador de un framework (PHPmini) orientado a objetos en php, el framework aún no es público pero considero que será un gran framework, que realmente vale la pena ver.

El framework entre otras prestaciones tiene la capacidad de implementar componentes que den soporte mejorado a las aplicaciones diarias que se desarrollen, y utiliza una versión alterada de MVC.

Sin más pasemos a las preguntas.

¿Por qué razón se te dio por desarrollar un framework?

Pues, principalmente por necesidad e inconformidad. Originalmente inicié el Framework habiéndome frustrado en la búsqueda de un núcleo adecuado para tres proyectos personales.
Requería de algo que me permitiera programar cómodo, pero que no me limite en funcionalidad y flexibilidad, o que represente exceso de consumo de RAM injustificado. No me agradaron completamente los Frameworks más conocidos como CodeIgniter y Kohana, por lo que decidí construir (en primera instancia, de manera privada) el mío propio.

¿Ha sido una tarea dura/larga?

Pues, si bien no me surgieron problemas serios, el Framework sufrió reescritura tras reescritura, ya sea porque no me convence algo, u olvidé algún concepto, siempre renuevo su código -y la de todos sus componentes- para acercarme más a lo que quiero lograr; algo complejo, ligero y relativamente fácil de usar.
Algo que he de destacar es que quiero programar sin mirar el código de nadie más. Sí he escuchado, analizado y escrito conceptos complejos de Alexander, Ignacio Rostagno y otros programadores, pero sin mirar su código o preguntarles cómo lo harían. Y no fue hasta que le mostré el progreso a Alexander que mantuve esa ideología. Esto lo hago tanto por mera auto-superación, como por la búsqueda de un funcionar "único".

¿Cuál es la ventaja de tu framework contra los populares frameworks actuales (como yii, codeigniter, etc.)?

Buena pregunta. Todos son buenas bases para comenzar a programar, Pero muchos dejan atrás extensibilidad, flexibilidad y facilidad de uso por una mayor complejidad. A mi parecer, ese es un error gravísimo ya que la esencia de un framework es reducir el tiempo de desarrollo, y si para comenzar a crear una aplicación tengo que aprender a usar dicho framework como si programara en otro lenguaje, deja de ser redituable.
Mi punto de vista con respecto a la pregunta en concreto, es que mi framework apunta a ser utilizado con facilidad y comodidad.

¿Cuándo crees que estará publicada al menos la primer versión?

Mi meta personal es que para Noviembre del corriente año, el Framework ya esté dentro de un repositorio público en Github.

¿Qué nivel de seguridad crees que tenga tu framework para con ataques conocidos como rfi, lfi, sqli, xss, etc.?

Por suerte, mis conocimientos y amigos en el tema, como Alexander y Ernesto me permiten saber dónde y qué reforzar en materia de Seguridad. He de considerarle, modestias aparte, Seguro.
De por sí, la estructura del Framework inhibe LFI y RFI, y el funcionamiento de mi librería de bases de datos valida por sí misma todas las entradas.

¿Cuáles crees que sean los puntos débiles de tu framework?

Siempre hay cosas que mejorar, Alex, lo sabes. Opino que aún está muy verde como para decir "hay una falencia X". Además, no he hecho las pruebas que me permitan saber esa clase de cosas. Por otro lado, supongo que eso saldrá a la luz cuando sea probado por terceros.

¿Cómo maneja las vistas tu framework?, en algunos frameworks como codeigniter no cuentan con gestor de plantillas

Las vistas fueron uno de los muchos dolores de cabeza que he tenido. No quería poner a RainTPL y ya, eso no tenía razón de ser. Quería algo más dinámico, algo realmente útil.
Cuando comencé a plantearme la idea, me enfoqué en la Modularidad, tanto de CSS como de JS para lograr ese anhelado dinamismo. El componente por sí mismo actúa como Gestor de Plantillas, Archivos CSS, JS y de idiomas con una sencilla implementación que, a mi parecer, es muy cómoda.
Algo a destacar también, es su versatilidad a la hora de trabajar con AJAX.

Para ir cerrando la entrevista, ¿Qué opinas del blog std-io.com?

Pues, como siempre dije, el blog reboza de información que supera mis conocimientos. Te has esmerado mucho con su desarrollo y te ha ido estupendamente. Mis más sinceras felicitaciones, amigo.

Agradecemos desde ya tu predisposición a responder nuestras preguntas, y agradecemos la colaboración a nuestro blog.

Muy bien, ahora que respondió nuestras preguntas daré mi franca opinión, tuve la suerte de poder ver el código que está en desarrollo, y en una entrada anterior explicaba por qué los frameworks son horribles, este framework en particular tiene la flexibilidad necesaria para no contradecir conceptos básicos como lo es la esencia de objetos en poo.

Yo creo que deben probarlo, RainTPL (su gestor de plantillas) cuenta con un sistema de cacheado y además deja una vista clara y limpia, muy ordenada. La forma de manejar los modelos es muy buena, y los controladores no dejan nada que desear. Considero un framework limpio, claro con sus objetivos, minimalista que no consume casi recursos, muy bien estructurado, y recomendable.

Estaré esperando su lanzamiento, y les recomiendo que lo prueben.

Saludos! nos veremos en la próxima entrada :)

jueves, 23 de octubre de 2014

En ésta entrada hablaremos sobre la segunda forma normal en el proceso de normalización de bases de datos. Puedes leer la Primera forma normal, si no la haz leído te recomiendo hacerlo.

Continuamos entonces con el hilo de bases de datos haciendo referencia al proceso de normalización, algo que es casi fundamental a la hora de diseñar una base de datos es tener en cuenta el tema de normalización.

La segunda forma normal hace referencia a la dependencia funcional absoluta, sobre todo cuando haya más de una clave primaria, habíamos visto que para estar en 1FN era necesario que todos los campos sean directamente dependientes de la clave primaria.

Primero, una tabla está en 2FN si y solo si la misma se encuentra en 1FN y cumple con el siguiente requisito:

los atributos que no forman parte de ninguna clave dependen de forma completa de la clave principal. Es decir que no existen dependencias parciales. (Todos los atributos que no son clave principal deben depender únicamente de la clave principal).

Esto quiere decir, que si tienes dos claves primarias, es necesario que cada campo de la tabla que no sea clave primaria dependa de todas las claves primarias, si un campo solo depende de una o algunas (pero no todas) las claves primarias ese campo es erróneo.

Imaginemos una tabla con los siguientes campos:

id_proyecto dni_empleado horas_trabajadas nombre_empleado

(donde dni_empleado e id_proyecto son claves primarias)
como podrán apreciar, las horas trabajadas en el proyecto son dependientes del id del proyecto y del dni del empleado, no podemos saber las horas trabajadas únicamente teniendo el id_proyecto o el dni_empleado, ya que no podremos saber con uno solo de esos cuantas horas trabajó en ese proyecto, por lo que ese campo es correcto, depende de todas las claves primarias de la tabla y no tiene dependencias parciales, pero veamos el campo nombre_empleado, el mismo es erróneo, ya que depende del dni_empleado pero no tiene ninguna dependencia con id_proyecto (no tiene nada que ver el nombre de un empleado con el id de un proyecto) de modo que ese campo no debe estar en esa tabla para que esa tabla esté en 2FN, ya que tiene dependencias parciales.

Un saludo para todos los lectores y espero les haya gustado la explicación breve y simple de 2FN, sigan pendiente del blog para ver las siguientes formas normales.

miércoles, 22 de octubre de 2014

Bienvenidos lectores! hoy les traigo un paper en formato pdf relacionado con calidad en desarrollo de software, la idea de este pdf es agrupar algunas de mis entradas (quizá las más importantes) relacionadas con el hilo "El arte de programar".

Éste pdf reúne varias cosas, conceptos muy importantes a tener en cuenta, y por supuesto desde el punto de vista del software como actividad económica, agrupando las razones por las que aplicar cada criterio tanto así como una visión industrial de lo que todos conocemos como programación.

Programación como actividad económica, una visión del software como un trabajo.
Criterios de calidad, los criterios generales para medir cuándo un código es de calidad.
Calidad y balance, cuando corresponde aplicar los criterios y por qué.
Dificultades de aplicar calidad, existiendo la calidad por qué no es tan sencillo aplicarla y hay tan poco código de calidad abierto al público.
Por supuesto incluye una descripción detallada de cada criterio de calidad en particular, además una explicación extra para cada uno, y lecturas complementarias.

Recomendamos leer todo el hilo del Arte de programar (véase indice) si te gustó el pdf.

También comentamos que el próximo pdf estará relacionado con el proceso de normalización y ya se encuentra en el laboratorio de corrección de documentos, esperando los ultimos ajustes para ser publicado.


Para cerrar la entrada nos gustaría que opinara sobre ¿qué tema te gustaría que publicaramos nuevas entradas?, envía tu sugerencia a alexander171294@gmail.com, o a nuestro twitter @std_io, también puedes comentarlo en ésta entrada.

Un saludo para todos los lectores!

martes, 21 de octubre de 2014

Buenas lectores, hoy hablaremos de UML (Lenguaje Unificado de Modelado) en particular sobre el diagrama de clases. UML se divide en tres grandes grupos de diagrama (Estructura, Comportamiento, Interacción) y veremos cada diagrama de cada grupo a lo largo de las futuras entradas. En particular recomiendo leer la entrada introductoria al tema aquí.

En primera instancia tengo que aclarar que es uno de los diagramas que más me gustan y uno de los pocos que realmente utilizo, no es precisamente el primero a realizar, pero es bueno que conozcan su existencia desde el principio.

El diagrama de clases representa las clases que tendrá nuestro sistema (siempre y cuando el sistema sea orientado a objetos), creando una visión simple y sencilla de las distintas clases del sistema, podemos apreciar en la siguiente imagen extraída de wikipedia como se ve un diagrama de clases.


 Cada clase se ve representada por un recuadro el cual en su cabecera debe estar su nombre en un recuadro interno, luego en el siguiente recuadro interno se encuentra la lista de atributos de la clase, (propiedades) los cuales deben su nombre estar precedido por un + o - dependiendo si son públicos o privados, en los anteriores casos la primer letra debe estar en mayusculas, luego sigue la lista de funciones en un recuadro interno nuevo, también deben ser precedidos por un + o - dependiendo si son publicos o privados, el +/-nombre_funcion() debe tener ese formato, se deben agrupar aquellas funciones publicas por un lado y privadas por el otro escribiendo primero los púlbicos y luego los privados, lo mismo ocurre con las propiedades. De esta forma se representan las distintas clases.



Ahora veremos las relaciones que hay entre las clases y como se representan, usaremos la imagen de arriba para especificar de que hablamos.

Las clases pueden tener relaciones simples como lo vemos entre la clase universidad y trabajador, al lado de la tabla trabajador hay un 1 lo que significa que esa clase esta relacionada de forma que solo 1 de esas pueda estar relacionada con una universidad, de modo que un trabajador pueda estar relacionado con una sola universidad y no más de una. En cambio el asterisco al costado de universidad indica que en esa relación la universidad en si puede tener 0, 1 o la cantidad que sea de trabajadores, también se podría escribir 1..* lo que significaría que podría tener 1 o más trabajadores, 0..1 por lo que podría tener ninguno o un solo trabajador, etc. Para relaciones simples la dirección se indica con una flecha sobre la linea de relación.

La siguiente relación que veremos es la que indica una flecha vacía (sin relleno) como se puede apreciar entre trabajador y persona, y estudiante y persona, ambas indican una flecha hacia persona, esta relacion representa "es un" quiere decir, trabajador es una persona, estudiante es una persona, o entre doctor y trabajador, doctor es un trabajador, en este caso la dirección está indicada por la flecha vacía, también puede significar "es un tipo de".

Luego tenemos la relación "tiene un" conocida como agregación, está representada por un diamante vacío, en el diagrama podemos ver como trabajador tiene un departamento.

 Luego para continuar tenemos composición, es una relación que representa el todo/parte, podemos ver entonces como funciona en la relación departamento/universidad, todos los departamentos pertenecen a una universidad.

La flecha con la linea punteada, es una relación de dependencia donde una clase depende de la otra, como por ejemplo en la imagen doctor depende de departamento.

Eso es todo para esta entrada y espero les haya gustado, un saludo!

lunes, 20 de octubre de 2014

En ésta entrada explicaré la primera forma normal para que sus bases de datos queden normalizadas y sean de calidad. Pero antes quiero enlazar la entrada inicial de éste hilo de entradas, hace ya casi un año estaba publicando la primera entrada de éste hilo y no es hasta hoy que puedo continuarlo, ahora que terminé las entradas referentes al Arte de Programar (al menos hasta el momento) puedo dedicar nuevas entradas a cosas importantes también como lo es crear una base de datos normalizada.


Les recomiendo ver ésta entrada del año pasado para tener un panorama de lo que hablaremos aquí.

No obstante comenzaré haciendo la introducción, y es que si hablamos de normalización usted debe comprender la importancia de normalizar su base de datos, cuando usted diseña un sistema x, y diagrama la base de datos, es probable que cometa una cierta cantidad de errores estúpidos que lo lleven a tener una base de datos inestable, inconsistente, y con varios problemas.

Normalizar la base de datos es como comprar un seguro a largo plazo, con una base de datos normalizada usted se asegura que en un futuro no tendrá problemas típicos de las bases de datos, cuando usted tenga la base de datos rellena de datos.

Tenga en cuenta la importancia de normalizar la base de datos al comienzo antes de tener datos cargados, y es que si luego tenemos la base de datos rellena de registros, hacer cambios puede conllevar la ardua tarea de alterar una cantidad significativa de registros, por lo que llevará a un costo muy superior al que puede tener normalizar la base de datos de entrada.

Para poder comprenderlo puede ver la imagen del post, notará que hay niveles de normalización, y cuanto más superior sea el nivel de normalización de la base de datos mejor será su base de datos.

El primer nivel es el 1FN. Debe saber que cuando hablamos de normalizar la base de datos, nos referimos a normalizar cada una de las tablas de la base de datos, y todas estas reglas o formas normales son para procesarlas en tablas particulares.

Una tabla está en 1FN si y solo si:

Una tabla está en Primera Forma Normal si:
  • Todos los atributos son atómicos. Un atributo es atómico si los elementos del dominio son indivisibles, mínimos.
  • La tabla contiene una clave primaria única.
  • La clave primaria no contiene atributos nulos.
  • Los Campos no clave deben identificarse por la clave (Dependencia Funcional)
Analicemos un poco lo que quiere decir, el primer punto, los atributos son atómicos, significa que un campo no posee varios valores, solo posee uno y solo un valor, y que ese valor no puede ser dividido en dos campos, en otras palabras con un ejemplo sencillo, podemos decir que un campo "Nombre y Apellido" no es atómico ya que cuenta con dos valores tales como el nombre y el apellido, y puede ser dividido en dos campos, uno llamado nombre y el otro llamado apellido.

El segundo punto hace referencia a que la tabla tiene una clave primaria que es clave primaria porque si valor no se puede repetir y es único, lo que quiere decir es que no habrá dos registros con el mismo valor para ese campo llamado clave primaria.

El tercer punto es bastante obvio, la clave primaria no puede contener un valor nulo, como puede pasar en otros campos, en la clave primaria no puede haber un valor nulo, tiene que haber un valor x.

El cuarto punto hace referencia a que cada campo debe estar basado en la clave primaria, en otras palabras, supongamos que tengo una tabla usuarios y yo pongo de clave primaria color de pelo, y el resto de los campos son dni, nombre, apellido, etc. esto sería completamente erróneo, ya que por el color de pelo no puedo deducir el nombre, el apellido y el dni de la persona, en cambio si pusiera de clave primaria DNI, esto sería correcto ya que el nombre, el apellido y el color de pelo se puede obtener basándose en el DNI, entonces todos los demás campos están identificados por esa clave primaria.

Esto es, a grandes rasgos, los requisitos que debe tener una tabla para conciderarse estar en 1FN.

Cada forma normal tiene un objetivo, el objetivo de esta forma normal es eliminar los valores repetidos dentro de una Base de Datos.

Un saludo para todos los lectores y espero les agrade la entrada.

sábado, 18 de octubre de 2014

Buenas tardes lectores, hoy les traigo otra entrada relacionada con el tema de los lenguajes de programación, java en android, ¿por qué lo eligieron?, empecé con las razones por las que uso php, luego hablé un poco de visual basic, y ahora hablaré sobre Java.


Hacía varios días que esta entrada estaba a la espera de ser redactada, y recién hoy que estaba husmeando un poco el framework de un amigo que realmente se ve muy muy prometedor, tengo que admitir que si su framework ve la luz mi publicación de los frameworks son una basura tendrá que ser retractada, analizando su código me surgieron algunas preguntas sobre como encararía ciertos aspectos, que para avisarles me dejó realmente satisfecho, al final de la charla surgió el gran dilema del a industria y quizá el soporte en el cual está apoyada esta entrada. ¿Mi código debe ser a prueba de idiotas, o para gente que tenga conciencia de lo que programa?

viernes, 17 de octubre de 2014

Buenas tardes a todos, se que ésta es una entrada que sale un poco de la regularidad, pero es para anunciar con gran alegría que el blog cumple un año y un mes, y para festejar este año y mes decidimos cambiar el diseño del blog, como recordarán el anterior diseño es éste:


Ésta será una entrada para saludar y agradecer a las distintas personas de la red que apoyan y siguen diariamente día a día el proyecto.

jueves, 16 de octubre de 2014

Buenas tardes lectores, mientras espero para ver el lanzamiento del satelite geoestacionario argentino arsat-1, voy a escribir una publicación para compartir mi manual para trabajar con sockets en php.


En este manual utilizaremos la librería PHPSocketMaster que pueden ver su repositorio oficial aquí, para realizar clientes, servidores y servidores para websockets en php, entre otras cosas.

martes, 14 de octubre de 2014

Buenas tardes lectores, realmente ayer no tenía absolutamente nada para publicar :'( hoy por suerte y mañana también tengo un par de entradas que seguro les gustará, un poco sobre criticas a visual basic, como siempre me destaco por criticar varias cosas de la mejor manera posible y la manera más razonable, hoy hablaremos sobre visual basic :), quiero agradecer y mandar un saludo a Javier G. del blog ww.codigo.ga


En la red siempre hay muchas criticas, y sobre todo una pelea atroz entre la gente que ama un lenguaje que usa y defiende a muerte, y gente que odia al lenguaje solo porque no le gusta, no lo probó, o por lo que dicen los demá

domingo, 12 de octubre de 2014

Buenas tardes lectores, hoy quiero hablar de un tema que resulta sin darme cuenta es algo importante para mi como programador, la elección de un lenguaje de programación es una de las cosas más importantes en la vida de un programador, y hoy les traigo la razón por la que yo programo en php.


Quizá es un tema relativamente recurrente en mi blog ya que en entradas anteriores publiqué mi decisión definitiva de cambiar de lenguaje que pueden ver en este enlace, entonces ¿Por qué no cambié?


sábado, 11 de octubre de 2014

Buenas tardes lectores, el otro día estaba pensando en razón de (creo) una charla que tuve con un amigo y me cuestioné la utilidad de este patrón de diseño MVC, ya que resulta que suele ser el as bajo la manga de cualquier programador en php para decir que su código responde a un patrón que le asegura la robustez



Desde ya que decir que el patrón mvc asegura la robustez en un código es una falacia, mvc aplicado a la web es una total mentira y ahora explicaremos el porqué de esto.

viernes, 10 de octubre de 2014

Buenas tardes lectores, les traigo aquí el fruto de mi esfuerzo, hace un par de días publiqué una entrada en la cual dejaba un enlace a una web de buenas prácticas en php (ver entrada aquí) y decidí que era un muy buen material que me gustaría que estuviera en nuestro idioma, por lo que puse manos a la obra y a traducir.


jueves, 9 de octubre de 2014

Buenas tardes, los que me conocen y siguen el blog sabrán que rara vez publico código, pero hoy traigo un proyecto que me llevó bastante tiempo y me costó un poquito realizar y me gustaría compartir con ustedes.


El proyecto lo comencé, porque desde que hice las distintas versiones de mi bot de irc en php, siempre tuve la mala suerte de decidir crear nuevas clases una y otra vez para manipular los sockets ya que ninguna me convencía pero no deceaba perder demaciado tiempo en el desarrollo de una clase manipuladora de sockets siendo mi proyecto en realidad un bot para irc.

miércoles, 8 de octubre de 2014

Buenas tardes lectores, hoy traigo algo muy interesante que me llamó la atención, es un blog que publican las "buenas prácticas" para programar en php.-

¿Con qué me refiero a buenas prácticas? al hecho de poner " o ', en que situaciones usar cada una, cuando usar o no tal o cual cosa, el punto es que aprendas como programar de buena manera para que tu código cumpla los requisitos básicos para empezar a pensar en calidad de software.

Buenas tardes lectores, le estoy sacando un jugo bárbaro a mi paper de programación orientada a objetos y hoy publicaré algo que noté tratando de utilizar un framework muy conocido y uno de los que se concideran mejorcitos, como en un par de entradas anteriores saco este texto de mi paper que pueden descargar desde la sección de nuestros pdfs.


martes, 7 de octubre de 2014



Buenas tardes, hoy traigo otra publicación extraída de mi paper de programación orientada a objetos, que pueden ver y descargar desde la sección de nuestros pdfs.


Algo sumamente interesante que encontré en python y que no había visto en php son los wrappers, los wrappers son una forma de trabajar muy particular, donde si hay una cierta cantidad de funciones que realizan una cierta tarea ya sea de validado de parámetros o lo que sea, se quita el código de cada una de las funciones y se lo mete en una función extra, luego se llama a esa función y se le pasa como parámetro la función particular que requiere de estas tareas.

lunes, 6 de octubre de 2014

Desde hacía bastante tiempo que quería publicar mi opinión sobre singleton, y hoy aquí está, quiero agregar que este texto es parte de un paper que publiqué hace unos días llamado Programación orientada a objetos en php (puedes verlo en la lista de nuestros pdf).




Singleton es una forma de manejar las clases, que evita la creación de múltiples instancias, en cualquier momento uno puede obtener la instancia que se creó originalmente, de modo que en cualquier lugar tienes acceso a la instancia, sin necesidad de ir llevando la variable que tiene la instancia de un lugar al otro, simplemente se adquiere la instancia utilizando una función estática.
Buenas tardes a todos los lectores, hace mucho no publicaba nada, pero hoy decidí desarrollar y llevar adelante un nuevo pdf sobre programación orientada a objetos.


Hablaremos sobre varias cosas, además de una introducción para iniciados en el tema de la programación orientada a objetos hablaremos sobre la falencia de Singleton, y el error que representa, sobre Wrappers, mi property nunca puede faltar, sobre Factory en php, y sobre el gran problema que tienen hoy en día los framewroks (referido al gran error que tienen en el concepto de programación orientada a objetos)

martes, 29 de julio de 2014

Buenas tardes lectores, en la entrada del dia de hoy hablaremos sobre un tema que siempre es interesante para debatir, la diferencia entre un programador y alguien que escribe codigo.

Cualquiera puede escribir un par de lineas de codigo, hasta un programa entero si se quiere, pero no cualquiera en realidad puede programar, hay una gran diferencia y de eso quiero hablar.

Buenos días, voy a continuar mi trilogía de documentos relacionados con la programación, les recuerdo que deben leer primero Introducción a la programación I y también Introducción a la programación II

Requisitos para comprender este documento:

Conocer los conceptos básicos de Introducción a la programación I.
Tener conocimiento de un lenguaje. Y manejarlo con fluidez.
Llevar al menos un año programando.
Haber trabajado de programador en algún proyecto o más de uno.



lunes, 28 de julio de 2014

Buenos días, voy a continuar mi trilogía de documentos relacionados con la programación, les recuerdo que deben leer primero Introducción a la programación I y también Introducción a la programación II

Requisitos para comprender este documento:

Conocer los conceptos básicos de Introducción a la programación I.
Tener conocimiento de un lenguaje. Y manejarlo con fluidez.
Llevar al menos un año programando.
Haber trabajado de programador en algún proyecto o más de uno.


Subscribete al RSS Follow me on Twitter!