Amazon AWS

There are some amazon instances that can be launched only in an EC2-VPC. If you want to attach one of your new EC2-VPC instances to an elastic IP that has already been attached to an EC2-classic instance, you will have to move the Elastic IP from EC2-Classic to EC2-VPC.

Instance Types Available Only in a VPC

There are some instances that are only available in a VPC

• C4
• M4
• T2

List of instances

Elastic IPs are different for EC2-Classic and EC2-VPC

You can’t associate directly an Elastic IP address that you allocated for use with a VPC with an instance in EC2-Classic, and vice-versa.

More info…

Moving elastic IPs from EC2-Classic to EC2-VPC

• Only in the same region
• You can’t migrate an Elastic IP initially reserved for EC2-VPC
• The Elastic IP must be detached from any instance
• This migration has to be carried out from the CLI

move-address-to-vpc command

move-address-to-vpc

aws ec2 move-address-to-vpc --public-ip 54.123.4.56
Output:

{
  "Status": "MoveInProgress"
}

Codenvy: entornos de desarrollo en la nube.

“On-demand developer workspaces”

• Con el navegador es suficiente.
• Múltiples lenguajes de programación.
• No hay que instalar software en nuestros equipos.
• Fácil integración con repositorios.
• El equipo de desarrollo comparte el IDE además del código.
• Utilidades para el trabajo colaborativo.
• Haciendo un símil, es trasladar la filosofía de trabajo colaborativo con Google Docs al desarrollo.
• Se puede obtener feedback antes de un commit o merge.
• Elimina el “esto funciona en mi equipo”.
• Se acerca el desarrollo a los entornos finales de producción.
• Múltiples opciones de ejecución al alcance de un click, sin instalar nada.
• Muy fácil de probar, curva de aprendizaje pequeña.

Esquema desarrollo con IDE de escritorio vs Codenvy

Ver más en https://codenvy.com/solutions/workflow/

Esquema incorporación de un nuevo miembro del equipo

Despliegue de Spring Pet Clinic en un minuto

https://github.com/spring-projects/spring-petclinic

Conclusiones

Pros

Lo que más me gusta es la rapidez con la que te puedes poner a trabajar, además de todas las facilidades que ofrece para el trabajo en equipo.

Cons

Todavía en lenguajes como Java, en frameworks muy especializados como Spring, los IDE de escritorio tienen funcionalidades muy adaptadas que todavía no están implementadas.

Por ejemplo: ejecutar test unitarios, refactoring, plugins…

Sin embargo, para otros entornos de desarrollo donde el IDE no tiene tanto peso, va genial.

La integración con Maven no está completa pero dicen que lo estará en futuras versiones. https://github.com/codenvy/che/issues/105

Otros cloud IDEs

Codenvy es uno más, aquí una lista con valoraciones de otras opciones.

http://www.slant.co/topics/713/~cloud-ides

Todo esto es posible gracias a

En este post voy a intentar demostrar la sencillez de dos conceptos muy importantes en Spring:

• Inversion of Control (IoC) = Inversión del Control.
• Dependecy Injection(DI) = Inyección de Dependencias.

Inversion of Control & Dependency Injection

“Es el proceso mediante el cual los objetos definen sus dependencias, bien mediante argumentos en el constructor, argumentos en un método factoría o propiedades que se asignan una vez el objeto está creado.”

La definición de estas dependencias se puede hacer con xml, anotaciones o mediante código java.

Entonces aparece en escena nuestro amigo el contenedor:

 	org.springframework.context.ApplicationContext

Es el contenedor quien inyecta las dependencias al crear el bean.

Este proceso es el inverso a la creación de instancias o asignación de dependencias, tanto usando la creación directa de las mismas o un mecanismo como Service Locator Pattern.

Por resumirlo mucho: Es el contenedor quien hace el trabajo de crear instancias en lugar de las clases, de ahí el nombre Inversion of Control.(Inversión del control)

No mas “a = new A(….);” este trabajo sucio se lo dejamos al contenedor (IoC container).

Bean: Un bean es un objeto que es instanciado, ensamblado o gestionado por un IoC Container.

Una de las ventajas de usar un contenedor (IoC Container), es que la gestión de dependencias ya no se hace dentro de las clases. Cada clase o Bean es autocontenida, sólo tiene que preocuparse de su alcance, será el contenedor quien le proporcione las instancias de clases que necesita.

Alta cohesión y bajo nivel de acoplamiento.

Ejemplo

Este sencillo ejemplo muestra:

• La configuración minima para ejecutar un Spring Container
• Cómo funciona la IoC o DI a un nivel muy básico

Spring-01-Ioc-Di-concepts

Codenvy

Configuración mínima

pom.xml en el cual vamos a declarar los paquetes de Spring que necesitamos

Sólo con spring-context ya nos basta.

Por dependencias transitivas, nos descargará también los paquetes del “core container”

<dependencies>
  	<dependency>
   	<groupId>org.springframework</groupId>
    	<artifactId>spring-context</artifactId>
    	<version>4.1.6.RELEASE</version>
	</dependency>
  </dependencies>  

Configuraciones

application-context.xml

      <!-- A simple bean definition -->
   <bean id="messageBean" class="me.itnotes.Message">
       <!-- collaborators and configuration for this bean go here -->
        <property name="message" value="Hola mundo. "/>
   </bean>

Pojo

public class Message {

  private String message;

	public String getMessage() {
		return message;
	}

	public void setMessage(String message) {
		this.message = message;
	}
	
	public void processMessage(){
     message=" Este es el mensaje que tengo: " +message;
   }
}

Runner

public class Runner {

	public static void main(String[] args) {
	//Creamos el applicationContext con lo definido en application-context.xml
	ApplicationContext applicationContext = new ClassPathXmlApplicationContext("/application-context.xml");   
	//Obtenemos el bean que se nos ha creado
	Message message = (Message) applicationContext.getBean("messageBean");
    //LLamada a un metodo tonoto del bean
    message.processMessage();
    System.out.println(message.getMessage());
    //Cerrar el applicationContext
    ((ConfigurableApplicationContext)applicationContext).close();
         
	}

}

Este post es continuación del anterior y pretende explicar de una forma menos “técnica” las diferencias entre un sistema de gestión de contenidos o CMS dinámicos como Wordpress y un sistema de publicación de contenidos estáticos como Jekyll.

CMS dinámico, Wordpress

¿Cómo funciona?

Simplificando mucho. A partir de unas plantillas, desde una aplicación web y siguiendo unos sencillos formularios, vamos creando las diferentes páginas o post de nuestro sitio o blog. Además en Wordpress hay múltiples plugins que podemos instalar en nuestro sitio y nos dan una funcionalidad adicional a la de publicar información.

Toda esta información se guarda en la base de datos de WP y cada vez que un visitante solicita una de nuestras páginas, Wordpress genera el html que se verá en el navegador.

Aunque no lo parezca, porque como usuarios nos parece sencillo y seguramente nuestro proveedor de WP nos evite preocuparnos por estas cosas, hay una base de datos, una aplicación web que tiene que estar funcionando, versiones de esta aplicación, backups…, en el fondo una cierta complejidad asumible.

La alternativa, sistema de publicación estático, Jekyll

Un sistema de publicación estático es una vuelta a los orígenes, kiis, una vuelta a simples páginas html. Las páginas html que se muestran cuando un usuario entra en nuestro sitio web están ya construidas, no hay ningún programa que las monte según llegan las peticiones.

Entonces, si se trata de hacer páginas html ¿Dónde está el truco o la novedad?

Hacer un sitio web programando html + CSS + Javascript, es largo, tedioso y puede llevarnos a errores, ya que en un sitio web muchas partes se repiten(cabeceras, pie, estilos) y el código html no es que sea muy legible. Es en este punto donde un sistema de publicación estático nos puede servir de ayuda.

• Como todos los frameworks, nos aporta una estructura y orden que facilita el mantenimiento.
• Plantillas. Podemos definir un estilo y formato que se aplicará a todas las páginas que se generen.
• El contenido está separado del diseño. El contenido lo forman archivos de texto, sólo los textos que queremos aparezcan en nuestro sitio web y que no son comunes al resto del sitio.
• Lenguaje de marcado. Mediante una sintaxis muy sencilla podemos especificar un formato al contenido. (Títulos, negritas, enlaces)

¿Cual es la ventaja frente a un Wordpress?

• La sencillez de llevar nuestro sitio web completo en un pendrive por ejemplo

• Una vez creado y compilado nos basta con subir los archivos a cualquier servidor para que estén inmediatamente accesibles.

• El coste, alojar un sitio estático tiene un coste marginal hoy en día.

• La escalabilidad. Los recursos necesarios para servir un sitio estático están órdenes de magnitud por debajo de los necesarios para un CMS.
• Seguridad: No hay bugs o vulnerabilidades más allá de las del servidor de archivos. Servir contenido estático es mucho más seguro. Un CMS es una capa adicional que proteger.

• Versiones: Una vez que el sitio estático está creado no hay problemas de versiones que actualizar. Es autocontenido.
• Backup: Tan sencillo como hacer una copia de archivos a un disco.
• Limpieza del html generado.
• Son tantas las ventajas que incluso Wordpress tiene plugins para exportar un sitio web a contenido estático.

¿Y cuales son los inconvenientes?

• El más importante, en un CMS, los contenidos están disponibles tan pronto como damos a guardar. En un sistema de publicación estático es necesario compilar, crear el sitio y subirlo al servidor. Si se usa Jekyll + Github este proceso está bastante automatizado.

• Plugins: La riqueza de plugins que tiene actualmente Wordpress para dar una funcionalidad adicional a mostrar información. Por ejemplo: formularios, tienda online… Aunque con la evolución de Javascript y componentes cada vez las páginas estáticas van a poder disponer de más funcionalidades.

• La curva de aprendizaje: El éxito de Wordpress es, además de su difusión, la facilidad para que usuarios sin formación técnica creen sus sitios web. Crear contenido con un sistema de publicación estático requiere una formación muy por encima de la que requiere un Wordpress.

Conclusiones:

• Los sistemas de publicación estáticos no son rival para CMS como Wordpress, pero tienen un una oportunidad gracias a la sencillez de conceptos que los sustenta, y más especialmente con el auge de Javascript + APIs REST.
• Un equipo podría diseñar plantillas para Jekyll, de la misma manera que se diseñan para Wordpress, crear un sistema de publicación como tiene Github (ver post anterior) y así poder crear contenido estático de mucha calidad y sobre todo muy barato de mantener.
• Entre otras cosas a mi me sirve para crear y publicar este blog. ;-)

Jekyll como alternativa a Blogger y Wordpress

Cuando me decidí a crear este blog empecé mirando herramientas como Blogger y Wordpress. Estudié las plantillas, formato de edición y en el caso de Wordpress también proveedores y costes.

Sin saber bien como fui a dar con Jekyll y toda la gama de blogging estático y generacion de contenido estático

¿Por qué Jekyll?

Me interesé por la generación de contenido estático principalmente por:

1. Crear un blog sin una base de datos por detrás y basado en contenido estático, algo tan simple como html + css + Javascript.
2. La limpieza del código html generado.
3. La posibilidad de aplicar este conocimiento y forma de generar html a otros proyectos web.

Jekyll no es la única herramienta con la que generar html, lo que la hace particular es que Github crea automáticamente el contenido estático del blog a partir de contenido almacenado en el control de versiones.

Cómo funciona Jekyll

Jekyll convierte en un sito estático plantillas de Markdown o Textile y Liquid. También soporta front-end frameworks como Bootstrap

Después de instalar Jekyll y para empezar a crear nuestro blog, se puede hacer un fork de alguna plantilla que nos guste y esté disponible en Github o simplemente descargarla en la carpeta que vayamos a emplear en nuestro disco.

También podemos crear una plantilla desde cero.

Está programado en Ruby, pero esto no es un problema, no necesitáis saber Ruby, es muy intuitivo todo. Simplificando mucho, esto es tan sencillo como una carpeta con una estructura de archivos donde hay una subcarpeta llamada posts que es de donde Jekyll toma los documentos que convertirá en posts de nuestro blog.

GitHub + Jekyll

https://help.github.com/articles/using-jekyll-with-pages/

Para que github genere en username.github.io tu blog o sitio estático, a partir de un sistema de archivos en formato Jekyll, debes crear una rama llamada gh-pages. Cada vez que hagas push a esta rama, GitHub generará una versión estática del contenido de dicha rama.

Pros

• Documentos limpios y plantillas sencillas.
• Generación de contenido estático: rápido, fiable, barato…Se aloja en cualquier servidor de archivos. No hay mantenimiento, ni vulnerabilidades.
• Como es html, lo puedes llevar hasta en un pendrive.
• Pese a todo el trabajo que haga jekyll por detrás, sólo se edita texto plano.
• Posibilidad de extender y adaptar si sabes programar.

Cons

• No es intuitivo para los que no están habituados a programar.
• La edición de posts requiere entender sistemas de marcado como Markdown o Textile, que no son difíciles. No hay que tener alergia a la consola o las configuraciones en texto. Por ejemplo meter una imagen requiere moverla a la carpeta y luego enlazarla. Un título se crea poniendo “#” Delante de la frase.
• Para crear un nuevo post hay que publicar el nuevo contenido, no es como darle a un botón. Si se emplea Github, se pueden editar archivos existentes, pero para crear nuevos posts hay que hacer push.
• No tiene la riqueza de plugins de Wordpress. Por ejemplo para comentarios hay que emplear Discuss.

Conclusiones

Como he dicho al principio, es una forma barata y eficaz de tener un blog. He aprendido mucho acerca de la generación de contenido estático y una vez que le coges el truco no se me hace difícil el editar los posts. Aunque sigo adelante he de advertir que esto no es para gente que no sea habilidosa con la consola, Git…

Nos vemos en los siguientes posts. ;-)