La historia de mis Linux

Antes de nada, estoy haciendo pruebas con el nuevo sistema de Telegram de blogs instantáneos Telegraph, y esta entrada la he publicado también a través de Telegram, en el nuevo canal de Learning the Force en Telegram.


Llevo usando Linux, prácticamente desde el primer día que entré en la universidad, y de eso ha pasado hace ya mucho tiempo.

Antes de entrar en la universidad, sabía que existía Linux, pero no había tenido la oportunidad de trastear un rato con el, o simplemente estaba muy cómodo con Windows. Pero eso cambio mi primera semana en la universidad. Nos dieron una clase de introducción a Linux para la asignatura de programación, ya que íbamos a tener que manejarnos con el sistema en las aulas de prácticas. Me llamó tanto la atención, que me apunté a una charla de iniciación del GUL (Grupo de Usuarios de Linux), donde se explicaban los comandos básicos y alguna cosa más interesante sobre Linux. No faltó mucho más que esa charla para engancharme.

Cuando llegué a mi casa ese mismo día, entré en Internet, y gracias al nuevo y flamante ADSL de 256kbps que me acababan de instalar (Si, ya os dije que de eso hacía muuuuucho tiempo), bajé mi primera distribución de GNU/Linux para instalarla en mi PC.

Mandrake

Según leí en su momento, Linux Mandrake era una de las distribuciones más sencillas de instalar, ya que en ese instante, no tenía demasiada experiencia como para instalar algo desde consola. Mandrake, estaba basado en Red Hat, pero simplificando todo el proceso de instalación, y haciendo más amigable para alguien como yo en ese momento.

Guardo un buen recuerdo de esta distribución, ya que es donde empecé a ver otro entorno que no fueran las típicas ventanitas.

Mandrake pasó a mejor vida en 2011, aunque dejando un sucesor llamado Mandriva, que al final también paso a mejor vida, dejando un proyecto abierto llamado OpenMandriva que aun sobrevive.

Red hat

Después de un tiempo con Mandrake, me atreví a dar el paso a algo más puro, y más estable: Red Hat

Mandrake estaba basado en Red Hat, por lo que no me supuso mucho cambio, sobre todo a la hora de instalar paquetes, y demás entorno. Durante mucho mucho tiempo, fue mi sistema operativo principal, excepto las veces que quería jugar una partida a algo, que inevitablemente tenía que volver a Windows.

Red Hat, a día de hoy se encuentra activo, y se ha orientado a empresas, ya que el servicio técnico que ofrece, es sin duda el camino a seguir para los que quieran ganarse la vida con proyectos de software libre.

Ubuntu

Resulta curioso que no probase ninguna otra distribución hasta la llegada del todopoderoso Ubuntu, ya que pasaron unos cuantos años entre que empecé usar Red Hat, e instalé por primera vez Ubuntu en su versión 8.04.

A estas alturas, poca gente no conoce Ubuntu. Es sin ninguna duda la distribución de Linux más usada por la gente del mundillo, y tiene multitud de sabores a su alrededor (Kubuntu, Ubuntu Gnome, Ubuntu Mate, Lubuntu…) como para estar días y días intentando elegir cual instalar. Su facilidad de uso e instalación, su soporte LTS, y las continuas actualizaciones hicieron de él, lo que es hoy en día.

Ubuntu está basado en Debian, una de las distribuciones más antiguas, y más estables que sigue existiendo a día de hoy, y que gracias a sus paquetes de tipo deb se ha ganado su puesto a pulso.

Sigo usando Ubuntu a día de hoy, en su sabor Lubuntu, que es perfecto para dispositivos antiguos, o con poca capacidad gracias a su escritorio ligero LXDE. Aunque tengo que reconocer que también a la hora de trabajar sigo usando Ubuntu en su variante de Ubuntu Mate, ya que a la hora de tener compatibilidad con nuevo software, hay que reconocer que una Ubuntu, no tiene competencia.

Debian

Debian. Para todos los metidos en el mundillo de Linux, es imposible no haber oído hablar de esta distribución. Desde mi punto de vista, la más estable, con menos fallos, y con toda la potencia de los paquetes deb, de los que Debian fue origen.

La primera vez que toqué una Debian, fue en los PCs que había en las aulas de informática de la universidad, con la versión Potato instalada (Para los que no lo sepan, los nombres de las versiones en Debian, llevan nombres de personajes de Toy Story: Potato, Sid, Woody, Jessie, Whezzy…), casi recién salida del horno y con el entorno XFCE. Por ese entonces la instalación no era demasiado sencilla, y yo no tenía los conocimientos necesarios, por lo cual la descarté como mi primer Linux a instalar.

Después de algunas frustraciones pasadas con Ubuntu, decidí pasarme a Debian, y fue una de las mejores decisiones que pude haber tomado: Mi PC no se colgaba ni queriendo, y podía con todo lo que le pedía. Acierto al cien por cien, y en mi PC sigue instalado como un campeón.

A día de hoy, si tuviera que recomendar una distribución para su día a día, definitivamente Debian sería mi elección sin ninguna duda.

Arch Linux

Llegamos hasta la actualidad. Arch Linux, es un concepto de distribución distinto de todos los demás que he tenido instalados: Los paquetes que llevan siempre están actualizados a su última versión estable liberada por cada desarrollador, en vez de tener una sola versión estable de los paquetes, que solo se actualiza a una nueva versión cuando los creadores de la distribución deciden que así sea.

Esta distribución no es para todo el mundo, ya que en cuanto se insertar el CD/USB de instalación lo único que te da, es un terminal, y a partir de ahí apáñatelas tu como puedas, por lo que el proceso es complejo para alguien no iniciado en el mundo de Linux.

Y os preguntareis: ¿Por qué instalar Arch Linux, cuando Debian funciona tan bien? La respuesta es más sencilla de lo que os imagináis: Me aburro. Simple y llanamente. Hacía mucho tiempo que no probaba nada nuevo en Linux. Estaba asentado en mi Debian que no fallaba ni aunque se le azotara con un palo, y necesitaba algo nuevo que probar.

Primero lo instalé en máquina virtual, para estar seguro del proceso que había que seguir para su instalación, y una vez teniéndolo claro, cogí mi antiguo portátil del trabajo, y repliqué paso a paso lo que había hecho, junto con alguna variación para los drivers gráficos.

Éxito total es lo que yo definiría al ver Arch Linux instalado y funcionando a la perfección. Y lo mejor de todo es que simplemente con el comando

pacman -Syu

el sistema se actualiza a la última versión de todos sus componentes, sin ningún problema adicional. Lo dicho un autentico éxito, que acaba de dividir mi corazón entre Debian y Arch Linux.

 

Espero que esta historia de mis Linux, os sirva como inspiración para entrar en un mundo increíble, y empecéis a olvidaros de una vez de esas ventanitas que tantos quebraderos de cabeza nos dan a los informáticos.

Share

ThyMeLeaf y el método de plantillado del futuro

Uno de los mayores incordios que tenemos los programadores full-stack (O comúnmente llamados “El que hace de todo”), es tener que coger el diseño de una web -que por supuesto no hemos diseñado nosotros, porque nuestra mente es más lógica que estética- y adaptarlo para darle el dinamismo que requiere una web hoy en día. Muchas veces este proceso es muy tedioso, sobre todo cuando se van haciendo pequeños cambios, que requieren una comparación exhaustiva de lo que ya hay adaptado, a los nuevos cambios estéticos que te pasan, y que al ser de contenido estático, puede llegar a ser una tortura encontrarlos.

Hace unos meses, cuando teníamos en mente un esbozo de lo que sería Origin Path, había que ir decidiendo la arquitectura que tocaría usar, y ya que parece que el concepto de SPA no parecía ni llamarnos demasiado la atención, ni de ser una buena opción de primeras, tocaba buscar un motor de plantillas con el que trabajar. Usar JSP me parecía ya desfasado si íbamos a hacer algo actual (Aun con las etiquetas de los distintos frameworks me parece anticuado), y aunque obviamente tuviese el mejor rendimiento, teníamos que buscar en una dirección que nos diese más facilidades a la hora de trabajar. Lo primero que te puede venir a la cabeza de motores de plantillas si vas a trabajar con java, es Velocity y Freemarker, ya que son probablemente los motores con más aceptación ahora mismo. Ya que ninguno de los dos terminaba de convencerme, hice una búsqueda sencilla al señor Google, a ver que me decía, y encontré algo que no conocía, que parecía repetirse bastante.

ThyMeLeafAlgo llamado ThyMeLeaf, por lo visto está empezando a ganar gran visibilidad y haciéndose un hueco, en el mundo de los motores de plantillas para Java. Dado que estábamos en busca y captura de uno nuevo, echarle un vistazo no nos iba a hacer daño, y podíamos encontrar algo interesante. Para lo que no estaba preparado, es para lo que me encontré, y me dejo bastante aturdido, ya que no era ni de lejos lo que me esperaba. En los motores de plantillas siempre sueles encontrar lo mismo, pero de distintas formas: Etiquetas de control de flujo, inclusión de otras plantillas en las propias plantillas, definición de tus propias etiquetas, etc… Y ThyMeLeaf, no es una excepción en esto.

El hecho es que la plantilla en si misma, es compatible con el diseño estático que puede hacer un diseñador, y a la vez con toda la parte dinámica que le damos los programadores, trabajando los dos sobre el mismo fichero. Esto puedo decir con toda sinceridad que no lo había visto NUNCA, y me sorprendió de una manera muy grata. Sin duda hizo que fuera la elección a usar en Origin path, y empezar a trabajar con ello.

Os voy a intentar poner un ejemplo para que veáis a que me refiero, con que es compatible con diseñadores y programadores trabajando sobre el mismo fichero. El ejemplo lo haré con spring MVC por detrás, para que podáis orientaros un poco en lo que voy haciendo.

Lo primero es crear un HTML estático, que tenga algún estilo para poder simular que un diseñador ha hecho una página genial, en vez de un programador sin ningún sentido del gusto.

 <html lang="es" xmlns="http://www.w3.org/1999/xhtml">

 <head>
      <title>Titulo de la aplicacion</title>
      <link rel="stylesheet" type="text/css" 
            media="all" href="../../css/propio.css" />
 </head>
 
 <body>
     <header>
         <h1 class="titulo">Pagina de thymeleaf</h1>
     </header>
 
     <table>
         <thead>
             <tr>
                 <th>Autores</th>
             </tr>
        </thead>
        <tbody>
            <tr>
                <td>Primero</td>
            </tr>
            <tr>
                <td>Segundo</td>
            </tr>
            <tr>
                <td>Tercero</td>
            </tr>
        </tbody>
     </table>
 
     <br/>
 
     <footer> Ejemplo de Thymeleaf </footer>
 
 </body>
</html>

Hasta aquí nada del otro mundo, un HTML con una tabla, un fichero de estilos situado dos niveles más arriba, y listo. El resultado del HTML al abrirlo en cualquier navegador, sin un servidor de por medio es el siguiente:

Salida1

Como veis nada del otro mundo. Ahora añadámosle unas cuantas etiquetas de ThyMeLeaf (Ya que ThyMeLeaf puede usar HTML a secas) que coge datos directamente desde un controlador implementado con Spring MVC:

<html lang="es" xmlns="http://www.w3.org/1999/xhtml"
       xmlns:th="http://www.thymeleaf.org">

<head>
    <title th:text="${title}">Titulo de la aplicacion</title>
    <link rel="stylesheet" type="text/css" 
          media="all" th:href="@{/css/propio.css}" href="../../css/propio.css" />
</head>

<body>
    <header>
        <h1 th:text="${actualPage}" class="titulo">Pagina de thymeleaf</h1>
    </header>

    <table>
       <thead>
           <tr>
              <th>Autores</th>
           </tr>
      </thead>
      <tbody>
          <tr th:each="autor : ${nombres}">
              <td th:text="${autor}">Primero</td>
          </tr>
          <tr th:remove="all">
             <td>Segundo</td>
          </tr>
          <tr th:remove="all">
             <td>Tercero</td>
         </tr>
      </tbody>
   </table>

 <br/>

 <footer> Ejemplo de Thymeleaf </footer>
</body>



</html>

Y al abrirlo directamente como un fichero HTML normal, el resultado sigue siendo el mismo.

Salida2

Como podéis ver, al no ser atributos estándar de HTML, el navegador simple y llanamente los ignora, y el diseñador podría trabajar igualmente con el sin tener ningún problema, únicamente con la condición de no tocar ningún atributo de etiquetas que empiecen por th:. Ahora pasemos esta misma plantilla sin ningún cambio a través de un servidor con Spring MVC y ThyMeLeaf, y la salida es la siguiente:

Salida3

¡¡Magia!! El título de la página, la cabecera, y el listado de nombres, ha cambiado por completo. Simplemente pasando unos cuantos atributos a través del ModelMap de SpringMVC hemos conseguido todo un contenido dinámico.

La etiqueta th:text ha sustituido el texto que contiene la etiqueta en la que se aplica. Con th:each hacemos que la etiqueta donde se aplica, se repita tantas veces como la longitud de la lista de nombres que le pasamos, y dentro del td, volvemos a aplicar un reemplazo del texto. En los siguientes td se usa th:remove=”all” que lo que hace, es eliminar de la salida toda esa etiqueta y su contenido (Si solo quisiéramos eliminar la etiqueta, pero no su contenido podríamos usar th:remove=”tag”), consiguiendo así dinamizar la página en función de los datos que se le pasen. Además con la etiqueta th:ref del link para el css, sustituye la ruta estática al css por una que se pueda entender en servidor.

Ahora mismo, tanto diseñador como programador pueden trabajar sobre el mismo archivo y pudiendo ver los dos, resultados instantáneos sin tener que ir adaptándolo cada vez que haya un cambio estético. Como podeis ver, esto va a evitar un tiempo enorme a la hora de tener que cambiar diseños, haciendo así, mucho más dinámico el desarrollo de la web.

A cada conjunto de etiquetas en ThyMeLeaf, se le llama dialecto, y ya existen muchos para poder hacer cualquier cosa. En el caso de Origin Path, estoy usando el dialecto SpringSecurityDialect para usar Spring security, y LayoutDialect para poder realizar layouts complejos con plantillas más reutilizables. Por supuesto, puedes crearte tus propios dialectos para usarlos como en cualquier otro motor de plantillas, a través de toda la aplicación.

Como podéis ver, es una mejora enorme respecto a los sistemas tradicionales de plantillas, que sin duda ha llegado para quedarse, y en mi caso, para ser el motor principal que voy a usar en proyectos de este tipo. Espero que os haya sido útil, y que hayáis visto, que no solo de JSPs, Velocity y Freemarker vive el programador Java.

Share

El vicio de Docker

¿Alguna vez os habéis encontrado una tecnología/gadget tan versátil que os gustaría que estuviera todo ahí? Algo así como el smartphone actual, donde si pudieras, pedirías que con pulsar una sola tecla en la pantalla, que te preparase el café, te leyese las noticias, te pusiera en la cama la ropa que te vas a poner ese día, y que además te teletransportase al trabajo. Pues eso mismo me pasó a mi con Docker.

Docker

En una entrevista de trabajo que tuve, me hablaron de Docker por primera vez, como una forma de virtualizar aplicaciones, pero que no requería un OS completo de por medio. Para mi eso era toda una novedad, ya que me habría venido muy bien para virtualizar los servidores que uso para CoResponde en vez de tener que configurármelos uno a uno con todos los pequeños detalles. Solo crear una imagen de Docker especifica con todas las configuraciones, y lanzar contenedores de esa imagen en otros servidores. Más fácil imposible.

Desde el momento que empecé a enredar más a fondo con ello, vi que si pudiera, Dockerizaria hasta las sartenes de la cocina. Su potencia me sorprendió, y el rendimiento era extremadamente bueno.

Debo deciros antes de nada, que Docker está pensado para ejecutar en máquinas Linux, por lo cual si queréis hacerlo desde Windows o Mac, debereis usar una máquina virtual intermedia para poder funcionar. Pero por supuesto, esto no tiene ningún sentido, ya que si vamos a usar Docker, es porque no queremos hacer una virtualización tradicional. Así que si quieres usar Docker, ya estás tardando en pasarte a Linux.

Ahora entramos en la chicha de Docker. Esto es como funcionaría una máquina virtual tradicional, con su sistema operativo completo corriendo por encima de un sistema de virtualización o hypervisor elegido.

stackvm

Solo con el sistema operativo completo, el rendimiento se reduce dramáticamente. Sin embargo, este es el stack de Docker.

stackdocker

Con esto nos quitamos de en medio todo el sistema operativo de la máquina virtual, y el motor de Docker usará los recursos nativos de la máquina, junto con los binarios y librerías estrictamente necesarios para poder correr las aplicaciones que se requiera.

El funcionamiento de Docker es relativamente sencillo: Se basa en imágenes que contienen todo lo necesario para ejecutar una, o varias aplicaciones, y lanzar contenedores (Instancias) de estas imagenes. Contruir una imagen propia es tan sencillo como crear un fichero de texto plano llamado Dockerfile en el cual, se configura la aplicación que quieras correr.

Ej. de fichero Dockerfile

FROM buildpack-deps:jessie-scm

# A few problems with compiling Java from source:
# 1. Oracle. Licensing prevents us from redistributing the official JDK.
# 2. Compiling OpenJDK also requires the JDK to be installed, and it gets
# really hairy.

RUN apt-get update && apt-get install -y --no-install-recommends \
 bzip2 \
 unzip \
 xz-utils \
 && rm -rf /var/lib/apt/lists/*

RUN echo 'deb http://httpredir.debian.org/debian jessie-backports main' > /etc/apt/sources.list.d/jessie-backports.list

# Default to UTF-8 file.encoding
ENV LANG C.UTF-8

# add a simple script that can auto-detect the appropriate JAVA_HOME value
# based on whether the JDK or only the JRE is installed
RUN { \
 echo '#!/bin/sh'; \
 echo 'set -e'; \
 echo; \
 echo 'dirname "$(dirname "$(readlink -f "$(which javac || which java)")")"'; \
 } > /usr/local/bin/docker-java-home \
 && chmod +x /usr/local/bin/docker-java-home

ENV JAVA_HOME /usr/lib/jvm/java-8-openjdk-amd64

ENV JAVA_VERSION 8u72
ENV JAVA_DEBIAN_VERSION 8u72-b15-1~bpo8+1

# see https://bugs.debian.org/775775
# and https://github.com/docker-library/java/issues/19#issuecomment-70546872
ENV CA_CERTIFICATES_JAVA_VERSION 20140324

RUN set -x \
 && apt-get update \
 && apt-get install -y \
 openjdk-8-jdk="$JAVA_DEBIAN_VERSION" \
 ca-certificates-java="$CA_CERTIFICATES_JAVA_VERSION" \
 && rm -rf /var/lib/apt/lists/* \
 && [ "$JAVA_HOME" = "$(docker-java-home)" ]

# see CA_CERTIFICATES_JAVA_VERSION notes above
RUN /var/lib/dpkg/info/ca-certificates-java.postinst configure

ENTRYPOINT /usr/lib/jvm/java-8-openjdk-amd64/bin/java -version 

Este es el código del Dockerfile para tener un contenedor con java 8 instalado.

Lo primero que se puede observar es el siguiente texto :

FROM buildpack-deps:jessie-scm

Esto indica que estás heredando de la imagen con nombre buildpack-deps y la versión jessie-scm. Casi la totalidad de las imágenes de docker, heredan de una más básica (Existen imágenes de Ubuntu o Debian básicas muy útiles de las cuales partir), y van añadiendo funciones extra.

Todo lo demás son intrucciones de que debe tener instalado nuestra imagen, excepto la orden final, que debe ser un ENTRYPOINT o CMD que es la orden que se ejecuta cuando se inicia una instancia de esta imagen. En el ejemplo anterior simplemente se ejecuta un java -version que mostraría simplemente la versión de java. Este parámetro de entrada, puede ser sustituido por nuestro propio punto de entrada para una imagen propia.

Para convertir este archivo Dockerfile en una imagen lista para ejecutar, simplemente con ejecutar este comando desde el propio directorio donde se encuentra el Dockerfile, crearemos una imagen:

docker build -t imagen-java .

En este caso, estamos construyendo una imagen con nombre imagen-java, diciéndole que nuestro fichero Dockerfile, se encuentra en el directorio actual. Dependiendo de todo lo que hayamos definido en el fichero, tardará más o menos tiempo, y al final si ejecutamos

docker images

veremos que ya tenemos nuestra imagen lista.

A partir de aquí ya tenemos lo básico para empezar a trabajar con ella. Lo siguiente es lanzar un contenedor de docker. Un contenedor no es más que una instancia de esta imagen base, y que será equivalente a nuestra máquina virtual tradicional para poder entenderlo bien. Para lanzar un nuevo contenedor solo necesitamos el siguiente comando:

docker run --name container-java imagen-java

Y listo, ya tenemos nuestro primer contenedor creado, y veremos como por pantalla nos sale la versión de java que configuramos en nuestra imagen base.

Los contenedores de Docker se paran, en cuanto no tienen una aplicación en primer plano ejecutándose. Esto significa que si lanzas un proceso que empieza y termina, como por ej. el contenedor lanzado antes con java -version, en cuanto se acabe de ejecutar, el contenedor se para, y tendrías que volver a ejecutarlo con

docker start container-java

ya que no habría que crear otro, solamente re-arrancar el ya creado.

Por supuesto esto es algo demasiado básico que no nos sirve para nada, ya que no tenemos ninguna aplicación real corriendo.

Llegados a este punto, toca explicar que es Docker Hub. Docker Hub es una plataforma, donde almacenar y poner disponibles imágenes de Docker pre-compiladas, para poder ejecutar desde cualquier sitio. Resumiendo: Si ejecutamos

docker run tomcat:8.0

primero se comprobará que no tenemos disponible en local una imagen con ese nombre, irá a docker hub, comprobará que existe una imagen con ese nombre y versión, se la bajará a tu equipo, y después lanzará un contenedor que se quedará ejecutando un servidor tomcat versión 8. Como podéis ver la simplicidad de esto es infinita, y nos permite lanzar contenedores extremadamente rápido.

Hay que tener en cuenta, que estos contenedores son como máquina virtuales, y los puertos que usan las aplicaciones dentro, están aislados, por lo cual si queremos que estén accesibles en la máquina, debemos mapearlos. La sintaxis es la siguiente:

docker run <nombreimagen> -p <puerto externo>:<puerto del contenedor>

Un ejemplo de esto con un contenedor de tomcat sería

docker run tomcat:8.0 -p 80:8080

Con esto mapeamos el puerto por defecto del tomcat del contenedor, a nuestro puerto 80 de la máquina, por lo que con acceder a http://localhost/  estariamos ejecutando ya todo lo que contenga nuestro tomcat.

Se pueden tener múltiples contenedor de la misma imagen, por lo que tener dos servidores a la vez sería tan fácil como

docker run tomcat:8.0 -p 81:8080

y ya tendríamos otro tomcat corriendo en la misma máquina. Por supuesto, tiene que ser en un puerto distinto, ya que nuestro puerto 80 estaría ocupado por el contenedor anterior, y crearía un conflicto.

 

Espero que os haya servidor de ayuda, y a pesar de que no es un tutorial completo, hayáis echado un vistazo a una de las tecnologías que más me ha impresionado en los últimos tiempos.

 

Share

Concepto de orientación a objetos

Probablemente el concepto que más me costó comprender cuando empecé a programar fue la orientación a objetos. El primer día de programación, van y me sueltan tan tranquilamente la definición estándar: Un objeto es una instancia de una clase. Ajam… si… muy bien… No se vosotros pero yo me quedé exactamente igual que estaba. Para mi en ese momento, una clase no era más que un archivo con cierto formato, donde yo ponía ordenes, y al compilarlas se ejecutaban una detrás de otra. Pero claro, eso se queda muy lejos de lo que es realmente programar.

Tardé bastante tiempo en entender claramente el significado de que era un objeto, y cómo usarlo. Y estoy seguro de que no he sido el único que ha estado tan perdido en este sentido. Pero un día, no se muy bien cómo, me di cuenta de que era, y cómo funcionaba. Fue un flash instantáneo que me vino a la mente, y de repente todo cobró sentido. Era un concepto tan simple que no sabía como había podido no entenderlo. Bueno, si lo se: Me estaban metiendo tantas cosas nuevas en la cabeza, que comprender en profundidad todo, era casi imposible. Pero a partir de ese momento todo fue viento en popa.

Por eso hoy, os voy a intentar enseñar cómo comprendí la orientación a objetos, y que siempre uso de ejemplo cada vez que intento explicarle a un alumno mío, que no tiene ni idea de que es un objeto.

Voy a dar por hecho que sabéis los conceptos de clase (Al menos con saber, burdamente explicado, que es un fichero donde se mete código y se ejecuta, suficiente), el de función o método (Definición simple: Una forma de agrupar instrucciones para hacer más legible el código), y la de variables (Esta lo siento, pero si no sabes lo que es una variable es que estás en el día 0 de aprender a programar xD), para explicaros la forma de entender la orientación a objetos

Esto es una clase

Clase coche

A partir de ahora, para vosotros esta clase es intocable, el código que escribáis en ella, NO PODÉIS EJECUTARLO. Hay formas de hacerlo obviamente (El concepto de static me costó comprenderlo bastante más, y no voy a meterme ahora con ello), pero por ahora para tener las cosas claras, ese código es intocable.

La cosa es que necesitamos ejecutar código de esa clase, y acceder a la variable que hay en ella para cambiarla, o ver que valor tiene. Aquí es cuando entra el concepto de objeto. Mi propia definición de objeto: Un objeto, es una copia usable de una clase. Dicho así, suena casi tan raro como la definición original de objeto, así que vamos a desarrollarlo un poco.

Para poder usar ese código hacemos una copia de nuestra clase:

Clase cocheClase coche

 

 

 

 

 

 

 

Hasta aquí todo bien, ya tenemos nuestra copia usable. La cosa es que, en esta copia, para vosotros, no es visible su código realmente, solo podrás hacer cosas con el, pero no ver las instrucciones que ejecuta. Por lo cual podría resumirse en que ahora mismo tienes esto:

CLASE   –   OBJECTO

Clase coche

Objecto coche

 

 

 

 

 

 

 

Esta es la mejor imagen para definir un objeto, porque literalmente ES un objeto: Una cosa con la que podemos hacer algo.

Ahora a ese objeto le podemos decir que haga cosas. En nuestro caso, tenemos un objeto de la clase coche por lo cual podemos llamar a los métodos que tiene:

LLAMADA AL MéTODO/función ARRANCAR DEL OBJETO

arrancar

Por supuesto, podemos crear tanto objetos como queramos. Podemos tener un array de esos objetos por ej:

Objecto cocheObjecto cocheObjecto cocheObjecto coche

Y podemos decirle al segundo solamente que arranque.

Objecto cochearrancarObjecto cocheObjecto coche

Así es como lo veo yo, y al menos a mi me sirvió para captar de forma crucial el concepto de objeto, y por ahora, parece que mis alumnos también consiguen captarlo y entenderlo, por lo cual, algo de bueno tiene que tener verlo así.

Espero que a vosotros también os sirva para entenderlo si estáis empezando. Y si tenéis que enseñarle a alguien este concepto, tener una idea de cómo simplificar el proceso para que lo aprendan.

Share

Starting the Force

Por fin me he decidido a arrancar mi propio blog. Era algo que tenía en mente desde hace muchísimo tiempo, pero a lo que no había dedicado el tiempo necesario hasta ahora mismo. Y por casualidades de la vida es un 4 de Mayo cuando arranca (Para los que no lo sepáis, el día de Star Wars. May the fourth be with you).

Necesitaba un lugar donde poder hablar de todo lo que voy aprendiendo sobre tecnología, sin que se pierda en la memoria y pueda compartirlo con toda la gente.

Cada día estoy aprendiendo algo nuevo, y guardarme todo ese conocimiento para mi, me ha terminado por resultar egoísta, así que es hora de que podáis ver lo que me interesa, aunque no siempre será de tecnología, sino de de una variedad de cosas que podría sorprenderos de alguien a quien se le considera un geek con todas las letras.

En unos días iré escribiendo unos post que tengo pendientes desde tiempos inmemoriales, y que espero que sea de interés general.

May the Force be with you

Share