Principios básicos Solid

Está Escrito:

"Porque somos hechura suya, creados en Cristo Jesús para buenas obras, las cuales Dios preparó de antemano para que anduviésemos en ellas." (Efesios 2:10)

Tomado de: Wikipedia

Solid es un acrónimo inventado por Robert C.Martin para establecer los cinco principios básicos de la programación orientada a objetos y diseño. Este acrónimo tiene bastante relación con los patrones de diseño, en especial, con la alta cohesión y el bajo acoplamiento.

El objetivo de tener un buen diseño de programación es abarcar la fase de mantenimiento de una manera más legible y sencilla así como conseguir crear nuevas funcionalidades sin tener que modificar en gran medida código antiguo. Los costes de mantenimiento pueden abarcar el 80% de un proyecto de software por lo que hay que valorar un buen diseño.

Inicial	Acrónimo	Concepto
S	SRP	Principio de responsabilidad única (Single responsibility principle) la noción de que un objeto solo debería tener una única responsabilidad.
O	OCP	Principio de abierto/cerrado (Open/closed principle) la noción de que las “entidades de software … deben estar abiertas para su extensión, pero cerradas para su modificación”.
L	LSP	Principio de sustitución de Liskov (Liskov substitution principle) la noción de que los “objetos de un programa deberían ser reemplazables por instancias de sus subtipos sin alterar el correcto funcionamiento del programa”. Ver también diseño por contrato.
I	ISP	Principio de segregación de la interfaz (Interface segregation principle) la noción de que “muchas interfaces cliente específicas son mejores que una interfaz de propósito general”.5​
D	DIP	Principio de inversión de la dependencia (Dependency inversion principle) la noción de que se debe “depender de abstracciones, no depender de implementaciones”.5​ La Inyección de Dependencias es uno de los métodos que siguen este principio.

S-Responsabilidad simple (Single responsibility)

Este principio trata de destinar cada clase a una finalidad sencilla y concreta. En muchas ocasiones estamos tentados a poner un método reutilizable que no tienen nada que ver con la clase simplemente porque lo utiliza y nos pilla más a mano. En ese momento pensamos "Ya que estamos aquí, para que voy a crear una clase para realizar esto. Directamente lo pongo aquí".

El problema surge cuando tenemos la necesidad de utilizar ese mismo método desde otra clase. Si no se refactoriza en ese momento y se crea una clase destinada para la finalidad del método, nos toparemos a largo plazo con que las clases realizan tareas que no deberían ser de su responsabilidad.

Con la anterior mentalidad nos encontraremos, por ejemplo, con un algoritmo de formateo de números en una clase destinada a leer de la base de datos porque fue el primer sitio donde se empezó a utilizar. Esto conlleva a tener métodos difíciles de detectar y encontrar de manera que el código hay que tenerlo memorizado en la cabeza.

O-Abierto/Cerrado (Open/Closed)

Principio atribuido a Bertrand Meyer que habla de crear clases extensibles sin necesidad de entrar al código fuente a modificarlo. Es decir, el diseño debe ser abierto para poderse extender pero cerrado para poderse modificar. Aunque dicho parece fácil, lo complicado es predecir por donde se debe extender y que no tengamos que modificarlo. Para conseguir este principio hay que tener muy claro como va a funcionar la aplicación, por donde se puede extender y como van a interactuar las clases.

El uso más común de extensión es mediante la herencia y la reimplementación de métodos. Existe otra alternativa que consiste en utilizar métodos que acepten una interface de manera que podemos ejecutar cualquier clase que implemente ese interface. En todos los casos, el comportamiento de la clase cambia sin que hayamos tenido que tocar código interno.

Como ya he comentado llega un momento en que las necesidades pueden llegar a ser tan imprevisibles que nos topemos que con los métodos definidos en el interface o en los métodos extensibles, no sean suficientes para cubrir las necesidades. En este caso no habrá más remedio que romper este principio y refactorizar.

L-Sustitucion Liskov (Liskov substitution)

Este principio fue creado por Barbara Liskov y habla de la importancia de crear todas las clases derivadas para que también puedan ser tratadas como la propia clase base. Cuando creamos clases derivadas debemos asegurarnos de no reimplementar métodos que hagan que los métodos de la clase base no funcionases si se tratasen como un objeto de esa clase base.

I-Segregacion del interface (Interface segregation)

Este principio fue formulado por Robert C. Martin y trata de algo parecido al primer principio. Cuando se definen interfaces estos deben ser específicos a una finalidad concreta. Por ello, si tenemos que definir una serie de métodos abstractos que debe utilizar una clase a través de interfaces, es preferible tener muchos interfaces que definan pocos métodos que tener un interface con muchos métodos.

El objetivo de este principio es principalmente poder reaprovechar los interfaces en otras clases. Si tenemos un interface que compara y clona en el mismo interface, de manera más complicada se podrá utilizar en una clase que solo debe comparar o en otra que solo debe clonar.

D-Inversión de dependencias (Dependency inversion)

También fue definido por Robert C. Martin. El objetivo de este principio conseguir desacoplar las clases. En todo diseño siempre debe existir un acoplamiento pero hay que evitarlo en la medida de lo posible. Un sistema no acoplado no hace nada pero un sistema altamente acoplado es muy difícil de mantener.

El objetivo de este principio es el uso de abstracciones para conseguir que una clase interactue con otras clases sin que las conozca directamente. Es decir, las clases de nivel superior no deben conocer las clases de nivel inferior. Dicho de otro modo, no debe conocer los detalles. Existen diferentes patrones como la inyección de dependencias o service locator que nos permiten invertir el control. 

Arquitectura orientada a servicios

Está Escrito:

No temas, porque yo estoy contigo; no desmayes, porque yo soy tu Dios que te esfuerzo; siempre te ayudaré, siempre te sustentaré con la diestra de mi justicia. (Isaías 41:10)

Tomado de: Wikipedia

La Arquitectura Orientada a Servicios (SOA, siglas del inglés Service Oriented Architecture) es un estilo de arquitectura de TI que se apoya en la orientación a servicios. La orientación a servicios es una forma de pensar en servicios, su construcción y sus resultados. Un servicio es una representación lógica de una actividad de negocio que tiene un resultado de negocio específico (ejemplo: comprobar el crédito de un cliente, obtener datos de clima, consolidar reportes de perforación)

El estilo de arquitectura SOA se caracteriza por:

• Estar basado en el diseño de servicios que reflejan las actividades del negocio en el mundo real, estas actividades hacen parte de los procesos de negocio de la compañía.
• Representar los servicios utilizando descripciones de negocio para asignarles un contexto de negocio.
• Tener requerimientos de infraestructura específicos y únicos para este tipo de arquitectura, en general se recomienda el uso de estándares abiertos para la interoperabilidad y transparencia en la ubicación de servicios.
• Estar implementada de acuerdo con las condiciones específicas de la arquitectura de TI en cada compañía.
• Requerir un gobierno fuerte sobre las representación e implementación de servicios.
• Requerir un conjunto de pruebas que determinen que es un buen servicio.

El desarrollo e implementación de una arquitectura SOA se rige por los principios descritos en el manifiesto SOA. Por otra parte la aplicación de la orientación a servicios se divide en 2 grandes etapas:

• Análisis orientado a servicios (Modelado de servicios)
• Diseño orientado a servicios, El diseño orientado a servicios cuenta con 8 principios de diseño que se aplican sobre cada uno de los servicios modelados, esto principios de diseño son:
• Contrato de servicio estandarizado: Los contratos de servicio cumplen con los mismos estándares de diseño.
• Bajo acoplamiento: Los servicios evitan acoplarse a la tecnología que los implementa y a su vez reducen el acoplamiento impuesto a los consumidores.
• Abstracción: Los contratos presentan la información mínima requerida y la información de los servicios se limita a los expuesto en el contrato.
• Reusabilidad: Los servicios expresan y contienen lógica de negocio independiente del consumidor y su entorno, por lo tanto se convierten en activos de la empresa.
• Autonomía: Los servicios deben tener un gran control de los recursos tecnológicos sobre los cuales están implementados.
• Sin estado: El servicio reduce el consumo de servicios al delegar el manejo de estados (sesiones) cuando se requiera.
• Garantizar su descubrimiento: Lo servicios cuentan con metadata que permite descubrirlos e interpretar el servicio en términos de negocio.
• Preparado para ser usado en composiciones: Los servicios pueden hacer parte de una composición sin importar el tamaño y complejidad de la misma.

Origen

Los modelos de desarrollo han ido evolucionando con el paso de los años. En los años 80 aparecieron los modelos orientados a objetos, en los 90 aparecieron los modelos basados en componentes y en la actualidad han aparecido los modelos orientados a servicios.

Aunque la arquitectura orientada a servicios no es un concepto nuevo (si bien fue descrita por primera vez por Gartner hasta en 1996), sí se ha visto incrementada su presencia en la actualidad, en gran medida debido al aumento de uso de servicios web. Con la llegada de éstos, la arquitectura SOA ha hecho que el desarrollo de software orientado a servicios sea factible. Aunque los servicios web usan con frecuencia SOA, SOA es neutral e independiente de la tecnología utilizada y por tanto no depende de los servicios web, aunque estos la popularizan.

Principios

No hay estándares en relación a la composición exacta de una arquitectura orientada a servicios, aunque muchas fuentes de la industria han publicado sus propios principios.

Algunos de los principios publicados son los siguientes:

• Contrato de servicios estandarizados: los servicios adhieren a un acuerdo de comunicación, según se define en conjunto con uno o más documentos de descripción de servicios.
• Acoplamiento débil de sistemas: los servicios mantienen una relación que minimiza las dependencias y sólo requiere que mantengan un conocimiento de uno al otro.
• Abstracción de servicios: más allá de las descripciones del contrato de servicios, los servicios ocultan la lógica a los demás.
• Reutilización de servicios: la lógica se divide en servicios con la intención de promover la reutilización.
• Autonomía de servicios: los servicios tienen control sobre la lógica que encapsulan, desde una perspectiva de diseño y ejecución.
• Servicios sin-estado: los servicios minimizan el consumo de recursos aplazando la gestión de la información de estado cuando sea necesario.
• Descubrimiento de servicios: los servicios se complementan con los metadatos mediante los cuales se pueden descubrir e interpretar la eficacia.
• Composición de servicios: servicios están compuestos por partes eficazmente, independientemente del tamaño y la complejidad de la composición.
• Granularidad de servicios: una consideración de diseño para proporcionar un ámbito óptimo y un correcto nivel granular de la funcionalidad del negocio en una operación de servicio.
• La normalización de servicios: los servicios se descomponen a un nivel de forma normal para minimizar la redundancia. En algunos casos, los servicios se desnormalizan para fines específicos, como la optimización del rendimiento, el acceso y agregación.
• Optimización de servicios: los servicios de alta calidad son preferibles a los de baja calidad.
• Relevancia de servicios: la funcionalidad se presenta en un nivel de granularidad reconocido por el usuario como un servicio significativo.
• Encapsulación de servicios: muchos servicios están consolidados para el uso de SOA. A menudo, estos servicios no fueron planificados para estar en un SOA.
• Transparencia de ubicación de servicios: se refiere a la capacidad de un consumidor de servicios para invocar a un servicio independientemente de su ubicación en la red. Esto también reconoce la propiedad de descubrimiento (uno de los principios fundamentales de SOA) y el derecho de un consumidor para acceder al servicio. A menudo, la idea de la virtualización de servicios también se refiere a la transparencia de ubicación. Aquí es donde el consumidor simplemente llama a un servicio lógico, mientras que un SOA habilita la ejecución del componente de la infraestructura, normalmente un bus de servicios, que mapea este servicio lógico y llama al servicio físico.

SOA y los Servicios Web

Hay que tener cuidado cuando se manejan estos términos y no confundirlos. Web Services (WS) engloba varias tecnologías, incluyendo XML, SOAP, WSDL, UDDI…los cuales permiten construir soluciones de programación para mensajes específicos y para problemas de integración de aplicaciones.

En cambio SOA es una arquitectura de aplicación en la cual todas las funciones están definidas como servicios independientes con interfaces invocables que pueden ser llamados en secuencias bien definidas para formar los procesos de negocio.

En SOA la clave está en la interfaz, puesto que define los parámetros requeridos y la naturaleza del resultado. Esto significa que define la naturaleza del servicio y no la tecnología utilizada. Esta función permite realizar dos de los puntos críticos: los servicios son realmente independientes y pueden ser manejados.

WS es el estándar apoyado por la industria (Microsoft, IBM, BEA, Oracle, Sun y otros), por empresas de distintos rubros, no tecnológicas (Ford, United Airlines, KPMG, Daimler-Chrysler), agrupadas en un comité conocido como Web Services Interoperability (WS-I). Este organismo tiene por principal objetivo asegurar que los grupos de trabajo que definen las especificaciones sobre WS utilizan estándares adecuados, a la vez que monitoriza el avance de sus trabajos; no define ni desarrolla estándares.

SOA y los microservicios

Artículo principal: Arquitectura de microservicios

Los microservicios son una interpretación moderna de la arquitectura orientada a servicios usada para construir sistemas distribuidos. Los servicios en una arquitectura de microservicios​ son procesos que se comunican con otros a través de una red para conseguir el objetivo final. Estos servicios pueden usar protocolos simples (típicamente HTTP con REST o mensajería liviana como RabbitMQ o ZeroMQ). 

Capas de software

SOA define las siguientes capas de software:

• Aplicaciones básicas: sistemas desarrollados bajo cualquier arquitectura o tecnología, geográficamente dispersos y bajo cualquier figura de propiedad;
• De exposición de funcionalidades: donde las funcionalidades de la capa aplicativa son expuestas en forma de servicios (generalmente como servicios web);
• De integración de servicios: facilitan el intercambio de datos entre elementos de la capa aplicativa orientada a procesos empresariales internos o en colaboración;
• De composición de procesos: que define el proceso en términos del negocio y sus necesidades, y que varía en función del negocio;
• De entrega: donde los servicios son desplegados a los usuarios finales.

Diseño y desarrollo de SOA

La metodología de modelado y diseño para aplicaciones SOA se conoce como análisis y diseño orientado a servicios. La arquitectura orientada a servicios es tanto un marco de trabajo para el desarrollo de software como un marco de trabajo de implementación. Para que un proyecto SOA tenga éxito los desarrolladores de software deben orientarse ellos mismos a esta mentalidad de crear servicios comunes que son orquestados por clientes o middleware para implementar los procesos de negocio. El desarrollo de sistemas usando SOA requiere un compromiso con este modelo en términos de planificación, herramientas e infraestructura.

Elementos de una arquitectura SOA, por Dirk Krafzig, Karl Banke, y Dirk Slama.7​

Cuando la mayoría de la gente habla de una arquitectura orientada a servicios están hablando de un juego de servicios residentes en Internet o en una intranet, usando servicios web. Existen diversos estándares relacionados a los servicios web; incluyendo los siguientes:

• XML
• HTTP
• SOAP
• REST
• WSDL
• UDDI

Hay que considerar, sin embargo, que un sistema SOA no necesariamente utiliza estos estándares para ser "Orientado a Servicios" pero es altamente recomendable su uso.

En un ambiente SOA, los nodos de la red hacen disponibles sus recursos a otros participantes en la red como servicios independientes a los que tienen acceso de un modo estandarizado. La mayoría de las definiciones de SOA identifican la utilización de servicios web (empleando SOAP y WSDL) en su implementación, no obstante se puede implementar SOA utilizando cualquier tecnología basada en servicios.

Lenguajes de alto nivel

Los lenguajes de alto nivel como BPEL o WS-Coordination llevan el concepto de servicio un paso adelante al proporcionar métodos de definición y soporte para flujos de trabajo y procesos de negocio.

Beneficios

El gran beneficio de SOA es la agilidad que proporciona a las organizaciones que la usan. Las características propias de SOA permiten a las organizaciones la capacidad de controlar un problema de forma general, permitiendo una respuesta más rápida y eficaz y por tanto adaptarse de la mejor forma a los cambios.8​

Otra de sus ventajas es la independencia de las plataformas e infraestructuras tecnológicas, lo que le permite integrarse con sistemas y aplicaciones diferentes de forma sencilla. Gracias a esta independencia SOA es su arquitectura flexible que permite la reutilización de las tecnologías existentes. Así que, una empresa no necesita realizar un cambio integral para adoptar SOA.9​

Los beneficios que puede obtener una organización que adopte SOA son:

• Mejora en los tiempos de realización de cambios en procesos
• Facilidad para evolucionar a modelos de negocios basados en tercerización
• Facilidad para abordar modelos de negocios basados en colaboración con otros entes (socios, proveedores): facilita la integración de sistemas y aplicaciones diferentes, lo cual mejora la comunicación y la capacidad de respuesta con sistemas externos
• Poder para reemplazar elementos de la capa aplicativa SOA sin disrupción en el proceso de negocio
• Facilidad para la integración de tecnologías disímiles
• Mejora en la toma de decisiones: la organización dispone de mayor información y más actualizada, lo que le permite una respuesta rápida y eficaz cuando surgen problemas o cambios
• Aplicaciones flexibles: la orientación a servicios permite desarrollar aplicaciones con independencia de las plataformas y lenguajes de programación que realizan los procesos
• Aplicaciones reutilizables y adaptables: permite que las aplicaciones existentes para ser reutilizadas y adaptadas a nuevos entornos con facilidad. Así conseguimos optimizar los recursos empleados en su desarrollo
• Reducción de costes: el coste de ampliar o crear nuevos servicios se reduce considerablemente tanto en aplicaciones nuevas como ya existentes
• Riesgo de migración: al adaptar SOA a partir de una tecnología existente se siguen utilizando los componentes existentes, por lo que se reduce el riesgo de introducir fallos.

¿Que es un GIT?

Está Escrito:

Porque tú me sacaste del seno materno; me hiciste confiar desde los pechos de mi madre.A ti fui entregado desde mi nacimiento; desde el vientre de mi madre tú eres mi Dios.

(Salmos 22:9-10)

Tomado de: Wikipedia

Git (pronunciado "guit"²​) es un software de control de versiones diseñado por Linus Torvalds, pensando en la eficiencia y la confiabilidad del mantenimiento de versiones de aplicaciones cuando éstas tienen un gran número de archivos de código fuente. Su propósito es llevar registro de los cambios en archivos de computadora y coordinar el trabajo que varias personas realizan sobre archivos compartidos.

Al principio, Git se pensó como un motor de bajo nivel sobre el cual otros pudieran escribir la interfaz de usuario o front end como Cogito o StGIT. ³​ Sin embargo, Git se ha convertido desde entonces en un sistema de control de versiones con funcionalidad plena. ⁴​ Hay algunos proyectos de mucha relevancia que ya usan Git, en particular, el grupo de programación del núcleo Linux.

El mantenimiento del software Git está actualmente (2009) supervisado por Junio Hamano, quien recibe contribuciones al código de alrededor de 280 programadores. En cuanto a derechos de autor Git es un software libre distribuible bajo los términos de la versión 2 de la Licencia Pública General de GNU.

Caracteristicas:

El diseño de Git se basó en BitKeeper y en Monotone. ⁵​⁶​ Originalmente fue diseñado como un motor de sistema de control de versiones de bajo nivel sobre el cual otros podrían codificar interfaces frontales, tales como Cogito o StGIT.⁷​ Desde ese entonces hasta ahora el núcleo del proyecto Git se ha vuelto un sistema de control de versiones completo, utilizable en forma directa.⁸​

Linus Torvalds buscaba un sistema distribuido que pudiera usar en forma semejante a BitKeeper, pero ninguno de los sistemas bajo software libre disponibles cumplía con sus requerimientos, especialmente en cuanto a desempeño. El diseño de Git mantiene una enorme cantidad de código distribuida y gestionada por mucha gente, que incide en numerosos detalles de rendimiento, y de la necesidad de rapidez en una primera implementación.

Entre las características más relevantes se encuentran:

• Fuerte apoyo al desarrollo no lineal, por ende rapidez en la gestión de ramas y mezclado de diferentes versiones. Git incluye herramientas específicas para navegar y visualizar un historial de desarrollo no lineal. Una presunción fundamental en Git es que un cambio será fusionado mucho más frecuentemente de lo que se escribe originalmente, conforme se pasa entre varios programadores que lo revisan.
• Gestión distribuida. Al igual que Darcs, BitKeeper, Mercurial, SVK, Bazaar y Monotone, Git le da a cada programador una copia local del historial del desarrollo entero, y los cambios se propagan entre los repositorios locales. Los cambios se importan como ramas adicionales y pueden ser fusionados en la misma manera que se hace con la rama local.
• Los almacenes de información pueden publicarse por HTTP, FTP, rsync o mediante un protocolo nativo, ya sea a través de una conexión TCP/IP simple o a través de cifrado SSH. Git también puede emular servidores CVS, lo que habilita el uso de clientes CVS pre-existentes y módulos IDE para CVS pre-existentes en el acceso de repositorios Git.
• Los repositorios Subversion y svk se pueden usar directamente con git-svn.
• Gestión eficiente de proyectos grandes, dada la rapidez de gestión de diferencias entre archivos, entre otras mejoras de optimización de velocidad de ejecución.
• Todas las versiones previas a un cambio determinado, implican la notificación de un cambio posterior en cualquiera de ellas a ese cambio (denominado autenticación criptográfica de historial). Esto existía en Monotone.
• Resulta algo más caro trabajar con ficheros concretos frente a proyectos, eso diferencia el trabajo frente a CVS, que trabaja con base en cambios de fichero, pero mejora el trabajo con afectaciones de código que concurren en operaciones similares en varios archivos.
• Los renombrados se trabajan basándose en similitudes entre ficheros, aparte de nombres de ficheros, pero no se hacen marcas explícitas de cambios de nombre con base en supuestos nombres únicos de nodos de sistema de ficheros, lo que evita posibles, y posiblemente desastrosas, coincidencias de ficheros diferentes en un único nombre.
• Realmacenamiento periódico en paquetes (ficheros). Esto es relativamente eficiente para escritura de cambios y relativamente ineficiente para lectura si el reempaquetado (con base en diferencias) no ocurre cada cierto tiempo.

Acerca del Control de Versiones

¿Qué es un control de versiones, y por qué debería importarte? Un control de versiones es un sistema que registra los cambios realizados en un archivo o conjunto de archivos a lo largo del tiempo, de modo que puedas recuperar versiones específicas más adelante. Aunque en los ejemplos de este libro usarás archivos de código fuente como aquellos cuya versión está siendo controlada, en realidad puedes hacer lo mismo con casi cualquier tipo de archivo que encuentres en una computadora.

Si eres diseñador gráfico o de web y quieres mantener cada versión de una imagen o diseño (es algo que sin duda vas a querer), usar un sistema de control de versiones (VCS por sus siglas en inglés) es una muy decisión muy acertada. Dicho sistema te permite regresar a versiones anteriores de tus archivos, regresar a una versión anterior del proyecto completo, comparar cambios a lo largo del tiempo, ver quién modificó por última vez algo que pueda estar causando problemas, ver quién introdujo un problema y cuándo, y mucho más. Usar un VCS también significa generalmente que si arruinas o pierdes archivos, será posible recuperarlos fácilmente. Adicionalmente, obtendrás todos estos beneficios a un costo muy bajo.

Sistemas de Control de Versiones Locales

Un método de control de versiones usado por muchas personas es copiar los archivos a otro directorio (quizás indicando la fecha y hora en que lo hicieron, si son ingeniosos). Este método es muy común porque es muy sencillo, pero también es tremendamente propenso a errores. Es fácil olvidar en qué directorio te encuentras, y guardar accidentalmente en el archivo equivocado o sobrescribir archivos que no querías.

Para afrontar este problema los programadores desarrollaron hace tiempo VCS locales que contenían una simple base de datos en la que se llevaba el registro de todos los cambios realizados a los archivos.

Figure 1. control de versiones local.

Una de las herramientas de control de versiones más popular fue un sistema llamado RCS, que todavía podemos encontrar en muchas de las computadoras actuales. Incluso el famoso sistema operativo Mac OS X incluye el comando rcs cuando instalas las herramientas de desarrollo. Esta herramienta funciona guardando conjuntos de parches (es decir, las diferencias entre archivos) en un formato especial en disco, y es capaz de recrear cómo era un archivo en cualquier momento a partir de dichos parches.

Sistemas de Control de Versiones Centralizados

El siguiente gran problema con el que se encuentran las personas es que necesitan colaborar con desarrolladores en otros sistemas. Los sistemas de Control de Versiones Centralizados (CVCS por sus siglas en inglés) fueron desarrollados para solucionar este problema. Estos sistemas, como CVS, Subversion, y Perforce, tienen un único servidor que contiene todos los archivos versionados, y varios clientes que descargan los archivos desde ese lugar central. Este ha sido el estándar para el control de versiones por muchos años.

Figure 2. Control de versiones centralizado.

Esta configuración ofrece muchas ventajas, especialmente frente a VCS locales. Por ejemplo, todas las personas saben hasta cierto punto en qué están trabajando los otros colaboradores del proyecto. Los administradores tienen control detallado sobre qué puede hacer cada usuario, y es mucho más fácil administrar un CVCS que tener que lidiar con bases de datos locales en cada cliente.

Sin embargo, esta configuración también tiene serias desventajas. La más obvia es el punto único de fallo que representa el servidor centralizado. Si ese servidor se cae durante una hora, entonces durante esa hora nadie podrá colaborar o guardar cambios en archivos en los que hayan estado trabajando. Si el disco duro en el que se encuentra la base de datos central se corrompe, y no se han realizado copias de seguridad adecuadamente, se perderá toda la información del proyecto, con excepción de las copias instantáneas que las personas tengan en sus máquinas locales. Los VCS locales sufren de este mismo problema: Cuando tienes toda la historia del proyecto en un mismo lugar, te arriesgas a perderlo todo.

Sistemas de Control de Versiones Distribuidos

Los sistemas de Control de Versiones Distribuidos (DVCS por sus siglas en inglés) ofrecen soluciones para los problemas que han sido mencionados. En un DVCS (como Git, Mercurial, Bazaar o Darcs), los clientes no solo descargan la última copia instantánea de los archivos, sino que se replica completamente el repositorio. De esta manera, si un servidor deja de funcionar y estos sistemas estaban colaborando a través de él, cualquiera de los repositorios disponibles en los clientes puede ser copiado al servidor con el fin de restaurarlo. Cada clon es realmente una copia completa de todos los datos.

Figure 3. Control de versiones distribuido.

Además, muchos de estos sistemas se encargan de manejar numerosos repositorios remotos con los cuales pueden trabajar, de tal forma que puedes colaborar simultáneamente con diferentes grupos de personas en distintas maneras dentro del mismo proyecto. Esto permite establecer varios flujos de trabajo que no son posibles en sistemas centralizados, como pueden ser los modelos jerárquicos.

¿Que es DDL y DML?

Está Estrito:

pero El conserva su sacerdocio inmutable puesto que permanece para siempre.(Hebreos 7:24)

Tomado de: Dar10comyr

[MYSQL] DDL y DML - Consultas Basicas

SQL: El lenguaje de consulta estructurado (Structured Query Language) es un lenguaje declarativo de acceso a bases de datos relacionales y permite especificar diferentes tipos de operaciones en estas.

• Una de las caracteristicas es el uso del calculo y el algebra para realizar consultas y recuperar la informacion que nos interese
• Existen 2 tipos de lenguajes en su manejo DDL y DML:

1. DDL (Data Definition Language) Lenguaje de Definicion de Datos
2. DML (Data Manipulation Language) Lenguaje de Manipulacion de Datos

QUE ES DDL?
Es el lenguaje que se usa para crear bases de datos y tablas, modificar sus estructuras y sus permisos y privilegios.

Los comando mas comunes son:

CREATE TABLE - ALTER TABLE - DROP TABLE - CREATE INDEX - DROP INDEX

QUE ES DML?
Es el lenguaje que se usa para modificar y obtener datos de una base de datos.

Los comando mas conocidos son:

SELECT - UPDATE - DELETE - INSERT INTO

---

---

Comandos DDL

CREATE TABLE

1. CREATE TABLE gente{
2. nombre VARCHAR(20),
3. fecha DATE
4. }

ALTER TABLE

1. ALTER TABLE autos RENAME coches;

Se utiliza para modificar los atributos de la tabla, como su nombre, el tipo de variables de sus columnas, eliminar columnas, agregarlas, etc
Mas info en: http://dev.mysql.com/doc/refman/5.7/en/alter-table-examples.html

DROP TABLE

1. DROP TABLE gente;
3. -- para eliminar el error en caso de no existir
5. DROP TABLE IF EXITS gente;

---

---

Comandos DLL

SELECT

1. SELECT * FROM hibernate.personas;

"Select" nos permite seleccionar para ver las columnas y sus registros
El * es un comodin que indica que quiero ver todas las columnas de la tabla.
De lo contrario para ver una especifica lo escribo: "nombreDeLaTabla.nombreDeLaColumna"
Se separan con comas si quiero utilizar mas de una tabla a mostrar.
"hibernate.personas" es "laBasedeDatos.nombreDeLaTabla" de la cual quiero ver los resultados.
Del mismo modo, se separan con comas si quiero ver resultados de mas de una tabla.

INSERT INTO

1. INSERT INTO nombre_de_la_tabla ( Columna1, columna 2, …. ) VALUES ( Valor1, valor2, ….) ;

UPDATE

1. UPDATE nombre_de_la_tabla SET nombre_de_la_columna = 'nuevo_valor' ;
   

   Tiene mas sentido utilizar un UPDATE junto con la clausula WHERE indicandole que modifique el campo de una columna donde exista cirta condicion o el valor exacto.

   UPDATE auto SET precio = 990099 WHERE id = 5 ;

DELETE

1. DELETE FROM nombre_de_la_tabla WHERE nombre_de_la_columna = > 1 ;
   

   idem anterior, tiene sentido junto con la clausula WHERE indicandole que elimine el campo de una columna donde se cumpla un valor exacto o una condicion, ej ,ayor a 1.

¿Que es un CRUD?

Está Escrito:

¿Quién como el sabio? ¿y quién como el que sabe la declaración de las cosas? La sabiduría del hombre ilumina su rostro, y la tosquedad de su semblante se mudará.(Eclesiastés 8:1)

Tomado de :Wikipedia

En informática, CRUD es el acrónimo de "Crear, Leer, Actualizar y Borrar" (del original en inglés: Create, Read, Update and Delete), que se usa para referirse a las funciones básicas en bases de datos o la capa de persistencia en un software.

En algunos lugares, se utilizan las siglas ABM para lo mismo ("Alta, Baja y Modificación"), obviando la operación de "obtener"; el acrónimo ABC para "Altas, Bajas y Cambios"; ABML siendo la última letra (L) de "listar, listado o lectura"; ABMC siendo la 'C' de "Consulta"; o bien CLAB que sería la traducción literal del acrónimo ("Crear, Leer, Actualizar y Borrar").

También es usado el ABCDEF: "Agregar, Buscar, Cambiar, Desplegar (listar), Eliminar, Fichar (Ficha, cédula o Reporte de un registro)".

En programación, crear, leer, actualizar y borrar ( con el acrónimo CRUD) son las cuatro funciones básicas de la persistencia de Bases de Datos. Términos alternativos son usados a veces cuando se definen las cuatro funciones básicas de CRUD, como “recuperar” en vez de “leer”, “modificar” en vez de “actualizar” o “destruir” en vez de “borrar”. CRUD se usa también a veces para describir convenciones de interfaz de usuario que facilita la vista, búsqueda y modificación de la información; a menudo se usa en programación de formularios (forms) e informes (reports). El término fue popularizado por primera vez por James Martin en su libro del año 1983 Managing the Data-base Enviroment. El acrónimo puede extenderse a CRUDL para cubrir el listado de gran cantidad de datos que conllevan una complejidad tal como paginación cuando los registros de datos son demasiado grandes para alojarse fácilmente en memoria.

Crea tu propio USB booteable con varios sistemas operativos

Está Escrito:

!!Oh profundidad de las riquezas de la sabiduría y de la ciencia de Dios! !!Cuán insondables son sus juicios, e inescrutables sus caminos! 

(Romanos 11:33)

 

Tomado de: El Grupo Informatico

Si has intentado alguna vez instalar algún sistema operativo sabrás que se suele usar un disco con la imagen grabada para que podamos ejecutarla al inicio de nuestro equipo y posteriormente instalar el sistema operativo deseado.

Desde hace un tiempoel uso de los CD/DVD ha ido cayendo en picado hasta casi su obsolescencia en este campo ya que la mayoría de equipos portátiles por ejemplo ya no tienen unidad lectora de CD/DVD.

Cómo grabar una ISO en un USB

El uso de USB se ha expandido hasta estos campos donde es posible tener un sistema operativo en un pendrive, una memoria USB booteable es una memoria con la cual podemos instalar o probar el sistema operativo que tenemos dentro.

Las ventajas de tener varios sistemas en una misma memoria, hace posible que si tenemos problemas con nuestro sistema actual podamos tener un modo de recuperar el sistema operativo o buscar errores.

WinsetupfromUSB, ten varios SO en un mismo pendrive

Esta herramienta nos ayudará a poder instalar en nuestro USB varios sistemas y que estos sean accesibles cuando arrancamos el equipo.

Este software soporta varios sistemas operativos, soporta  instalaciones de 32 y 64 bits, cuando instalamos alguna distribución de Linux, nos incorpora la utilidad Antivirus Rescue.

Requisitos de WinsetupfromUSB

Los requisitos para poder ejecutar y hacer funcionar WinsetupfromUSB son muy básicos y fáciles de cumplir.

1. Un equipo que soporte arrancar mediante una unidad USB
2. Una memoria USB de al menos 8 GB de espacio, cuanto más tamaño más sistemas operativos podremos agregar.
3. Una o varias imágenes iso de nuestros sistemas operativos
4. Descargar la herramienta WinsetupfromUSB

Instalación y configuración de WinsetupfromUSB

Lo primero que debemos hacer es descargar la herramienta WinsetupfromUSB que podrás descargarla al final de este post.

Una vez descargada tan solo deberemos descomprimir el archivo y veremos varios archivos uno para la versión de 32 bits y otro para la versión de 64 bits, te recomendamos que uses la versión igual a la de tu equipo.

Cuando ejecutemos la versión que queramos nos encontraremos con una ventana la cual es muy intuitiva y de tal forma podremos ir seleccionando las imágenes iso de los sistemas que queramos instalar. Deberás añadir las imagenes iso de una en una. 

Cuando hayamos elegido las iso requeridas tan solo tendremos que hacer clic en “GO” para comenzar la creación del USB Boot.

Cuando pulsemos en “GO” nos aparecerá un mensaje donde nos dirá que todas las particiones serán eliminadas.

Seguidamente nos parecerá otro mensaje donde podremos ver que la memoria que va a ser formateada perderá todos los datos, tan solo tendremos que pulsar en Sí. Si tuvieras  problemas con las unidades USB deberás tener en cuenta el formato que eliges.  

Una vez hayamos acabado nos aparecerá un mensaje de confirmación y ya podremos contar con nuestro USB booteable con varios sistemas operativos. Ahora tan solo deberás iniciar desde USB en el equipo que quieras instalar el sistema operativo.

1. Descarga WinsetupformUSB para Windows

¿Te ha sido útil este tutorial? ¿Conocías la existencia de los USB boot?
 

¿Cómo enviar Bitcoins desde una billetera de papel?

Está Escrito:

No os ha sobrevenido ninguna tentación que no sea humana; pero fiel es Dios, que no os dejará ser tentados más de lo que podéis resistir, sino que dará también juntamente con la tentación la salida, para que podáis soportar. (1 Corintios 10:13)

Tomado de: 99bitcoins

Hoy vamos a aprender a enviar con seguridad los bitcoins que residen en tu billetera de papel Bitcoin. Más precisamente, vamos a decirles qué hacer, y entonces usted sabrá cómo hacerlo.

Para gastar los fondos en tu billetera de papel, necesitarás:

•  una conexión a internet
•  una cartera de software (es decir, electro, Bitcoin Core, o un Blockchain.info cuenta)
•  unos 15 minutos

Envío de bitcoins de una cartera de papel puede resumirse en un par de pasos:

1. Barrido (o importación) de la clave privada de la billetera de papel en la cartera de software.
2. Envíe los bitcoins utilizando la cartera de software a la dirección del destinatario.

Los bitcoins que estás enviando necesita ser emitida como una nueva transacción por internet. La transacción se agregarán entonces a la blockchain, que acredita los bitcoins que está enviando a la dirección del destinatario Bitcoin. Esto es cómo se transfieren los bitcoins.

Pero no quiero gastar todos los Bitcoins en mi cartera de papel

No tienes que si no quieres. Usted puede enviar una parte de ellos a quien sea, y la cantidad sobrante se almacenarán en su cartera de software. La cartera de papel se agotarán todos los fondos, aunque sólo algunos de los bitcoins pasas.

Sin embargo, usted puede realizar un paso adicional y devolver la cantidad sobrante a su cartera de papel (aunque para la seguridad, quizá debería generar una nueva cartera de papel y enviarlos a eso en su lugar).

O puedes simplemente poner todos los bitcoins de tu billetera de papel en su cartera de software sin enviarlos a nadie. Es su decisión.

Cosas importantes a considerar

Carga de bitcoins a una cartera de papel es fácil — los envías a la dirección de la cartera papel. Pero los gastos pueden ser arriesgado si se hace incorrectamente. Incorrectamente importación/barrer las claves privadas o malentendido lo que haces puede resultar en una pérdida parcial o total de los bitcoins.

Asegúrese de que entiende:

• Importar vs barrer una cartera de papel: si aún no conoces la diferencia, visite el enlace a la izquierda. Es importante saber si usted debe importar o barrer tu billetera de papel y por qué. Adelante — esperaremos. 
• Verificar sus acciones: es mejor verificar cada paso del proceso se realiza correctamente. Cuando realiza una transacción en Bitcoin como recibir o transferir fondos, usted puede verificar cada paso a través de la blockchain para asegurarse de que lo pensé que estaban haciendo en realidad sucedió. Algunas grandes herramientas en línea para hacer esto son blockchain.info, blockr.io, y blockexplorer.com. Estos sitios web tienen un campo de búsqueda donde usted puede copiar/pegar la clave pública (a.k.a. Bitcoin dirección) de su cartera de papel, y de las transacciones y saldo total se mostrará. 
• Estar seguro: Recuerde siempre mantener el seguro clave privada y segura. La clave privada de la cartera de papel nunca debe compartirse; se utiliza para gastar los fondos de la cartera de papel. Pero la clave pública puede ser compartida con nadie; Esto es cómo usted y otros envían bitcoins a su cartera de papel.

Cómo gastar Bitcoins de tu billetera papel
1. salga tu billetera de papel
El primer paso es tener tu billetera de papel Bitcoin cerca — tendrás acceso a lo escrito en él. La cartera de papel de Bitcoin consiste en un par de claves público y privado, que se muestran como una larga secuencia de números y letras, y sus correspondientes códigos QR (las plazas con todos los puntos en ellos). A continuación es un ejemplo papel generado utilizando bitaddress.org:

Tienes dos opciones para obtener los bitcoins de tu cartera de papel a su cartera de software; escanear el código QR o escribir manualmente la secuencia de letras y números a mano. Los códigos QR simplemente mostrar las claves públicas y privadas como imágenes separadas que pueden ser leídos y traducidos por una cámara o webcam. Por supuesto, escanear un código QR es mucho más fácil que escribir en un montón de letras y los números.


Muchos Bitcoin cartera clientes y servicios proporcionan construido en lectura de códigos QR y Mostrar funcionalidad. Pero si tu billetera no puede escanear un código QR, usted puede descargar una aplicación de escáner de código QR independiente. Estas aplicaciones automáticamente pondrá la dirección escaneada al portapapeles de la computadora (o dispositivo) que puede pegarse en la aplicación de su cartera.

2. revisar el saldo de la cartera papel (opcional)
Si desea comprobar cuántos bitcoins son los primeros en tu billetera de papel, exploración/pegar o escribe de tu billetera papel (podrá catalogarse como “Dirección de Bitcoin” o “Load & Verify”) en un servicio del explorador de blockchain como Blockchain.info, blockr.io, o blockexplorer.com. Tenga cuidado de no analizar accidentalmente la clave privada. Se mostrará el saldo actual de su cartera de papel.

3. cargar la clave privada en un cliente de cartera de Software mediante una importación o barrido
A continuación son ejemplos usando el Blockchain.info billetera web (importación/barrido), Electrum cliente (importación/barrido) y el Bitcoin Core cliente (sólo importación). Si usas otra cartera cliente o servicio, los pasos que se detallan a continuación deben ser relativamente similares.

Telegram estaría cerca de lanzar su propia criptomoneda

Está Escrito:

(Jesucristo) El respondió y dijo: Escrito está: No sólo de pan vivirá el hombre, sino de toda palabra que sale de la boca de Dios. (Mateo 4:4)

Tomado de: Aporrea

Telegram, el principal competidor de WhatsApp en el servicio de mensajería móvil, estaría a punto de lanzar su propio blockchain y una criptomoneda que buscará emular a lo realizado hasta el momento por el Bitcoin, de acuerdo con una publicación que Anton Rozenberg, un ex empleado de la compañía hizo en sus redes sociales.

La plataforma llevará por nombre “TON” se especula que las siglas harán referencia a “The Open Network” o “Telegram Open Network”; y que buscará mejorar la tecnología Blockchain; la criptomoneda, podría llamarse “Gram”.

De acuerdo con un reporte de Bloomberg, Telegram cuenta con 180 millones de usuarios alrededor del mundo, sin embargo, las transacciones de esta criptodivisa, se realizarían bajo distintos servicios de mensajería, y facilitaran su uso.

Pavel Durov, cofundador de Telegram ha mencionado a los medios en diversas ocasiones su interés por ayudar a la economía de la gente; se podría transferir dinero a la plataforma sin problemas, y al igual que muchas divisas virtuales, no estaría controlada por ningún gobierno o institución.

El éxito de esta teórica criptodivisa aún es una incógnita. Habrá que esperar los resultados.