UML - Comportamiento: Diagrama de actividades o flujo

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í.

Read More

Patrones Creacionales: Object Pool

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:

http://pastebin.com/VEjUpHxN

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

Read More

Bases de datos: Tercera forma normal

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.

Read More

UML - Comportamiento: Diagrama de casos de uso

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,

Read More

Patrones de diseño.

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.

Read More

Un nuevo framework php se avecina (entrevista) @roodaka

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 :)

Read More

Bases de datos: Segunda forma normal

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.

Read More

Calidad en desarrollo de software (Paper)

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.

 Descargar PDF aquí

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!

Read More

UML - Estructura: Diagrama de clases

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!

Read More

Bases de datos: Primera forma normal

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.

Read More

Java en android, ¿Una decisión difícil?

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?

Read More

Un año y un mes

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.

Read More

Sockets en PHP (PHPSocketMaster)

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.

Read More

Grandes críticas a visual basic

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á

Read More

¿Por qué programo en php?

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é?

Read More

La realidad de MVC

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.

Read More

Buenas prácticas para programar en php TRADUCCIÓN

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.

Read More

PHPSocket Master (sockets con eventos en php)

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.

Read More

Buenas prácticas para programar en php

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.

Read More

El gran problema de los frameworks en php

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.

Read More

Wrappers en php

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.

Read More

La verdad de Singleton (php)

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.

Read More

Programación Orientada a objetos PHP

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)

Read More