Secciones

martes, 4 de febrero de 2020

Uso básico de GIT

 

Introducción: 


En la entrada de hoy voy a hacer un breve resumen de los comandos más usado en git, y unos guidelines para su manejo diario.

Creación de un repositorio si no existe (test)


** Create new repository in your repository manager **
cd $(your_repository_path)
git init
git remote add origin git@server_address:your_project.git
git add *
git commit -m "Initial commit, more info"
git push -u origin master:master
git checkout develop
git commit -a -m "Created develop branch"
git push origin devel:devel

Descarga de un repositorio ya existente (test with anterior)


**Clone the new repository and go to develop branch**
cd $(your_repository_path)
git clone git@server_address:your_project.git
cd $(your_project)
git config --global user.name "Your name"
git config --global user.email "your@email.com"
git branch -a
git checkout develop


Forma de trabajo:


En esta parte vamos a hablar de una forma eficiente para trabajar, separando las versiones estables de las de desarrollo, e intentando ser lo más claros posible a la hora de añadir cambios.

Referencias:
* Cheatsheet Aquí.
* Links aquí.
* Manuals & Reference aquí, aquí y aquí.

Resumen:

Git tips:
-------------------
    Note:   Edit variables $(var_name) assiming origin is the remote.
    Note2:  Terminal code prefix $

Basic:
----------------------------------------------------------------
· Clone with all submodules:                                   $ git clone --recursive $(url_repository)
· Create new branch:                                           $ git branch $(branch_name)
· Change to branch:                                            $ git checkout $(branch_name)
· Remove a branch:                                             $ git branch -d $(branch_name)
· Remove branch from origin:                                   $ git push :$(branch_name)
· Checkout a new branch from origin:                           $ git checkout -b $(branch_name) origin/$(branch_name)
· Add new file to repository:                                  $ git add $(file_or_macro)
· Remove file from repository:                                 $ git rm $(file_or_macro)
· Save edit changes in your PC:                                $ git commit -a -m "$(description)" 
· Update your repository from origin:                          $ git pull origin $(your_branch):$(their_branch)
· Share your changes                                           $ git push origin $(your_branch):$(their_branch)
· Create a new tag in current branch:                          $ git tag -a $(tag_name)
· Add a submodule:                                             $ git submodule add $(url_repository) $(relative_path)

Advanced:
----------------------------------------------------------------
· Show all files that changed in a commit:                     $ git diff-tree --name-only -r $(commit_id)
· Show a summary of files that were modified n commits ago:    $ git whatchanged -1
· Count how many files changed n commits ago:                  $ git whatchanged -1 --format=oneline | wc -l
· Check changes user since a date:                             $ git log --author="username" --oneline --shortstat --since=yesterday
 

Para los más avanzados:

En esta otra entrada, os hablo de algunas herramientas avanzadas. Buscar información, como sale en la chuleta del resumen anterior, el uso de stash, wiki in github with git, multiples remotes, y muchas cosas más.

Referencia: https://www.atlassian.com/git/tutorials/advanced-overview/

sábado, 26 de noviembre de 2016

Mi primera aplicación en Angular 2

Introducción:


Angular es un framework Open source mantenido por Google para desarrollar en Javascript y TypeScript aplicaciones web de una sola página basadas en el modelo vista controlador (MVC). Combinadas con el framework Electron, puede ser usadas para creas aplicaciones nativas en cualquier plataforma, utilizando otros recursos como scripts de python, c++, etc.

Este articulo va a resumir los detalles que aparecen en la web de documentación oficial, de forma resumida en el caso de TypeScript.

Requisitos:

  • Nodejs
  • npm
Para ver si los tienes instalados, ejecuta en el terminal:  
node -v
npm -v
Si no aparecen sus respectivas versiones, instalalos.

Crear un proyecto nuevo de forma manual:

 

En esta sección crearemos un proyecto de forma manual en unos sencillos pasos.

Crear los ficheros de configuración

 

Para crear un proyecto, necesitas una carpeta en el sistema, y crear unos ficheros de configuración:
  • package.json: Contiene todas las dependencias del proyecto manejadas por npm
  • tsconfig.json: Contiene la forma de compilar TypeScript para generar el Javascript final.
  • typings.json: Contiene las definiciones adicionales que no se encuentren de forma nativa.
  • systemjs.config.js: Contiene toda la información que se necesita para cargar el módulo.
Tienes un ejemplo de estos ficheros aquí

Conceptos básicos de una app

 

  • Una clase es un modelo que define un conjunto de variables y métodos para operar datos y estados según un comportamiento.
  • Un componente es una parte de la descomposición de un sistema en funcionalidades o lógica mediante interfaces. Tiene un componente de abstracción más alto que una clase ya que no tiene estados. Cómo usarlos. Cada componente es reutilizable y pueden aceptar inputs definidos en la exportación de la clase.
  • Un modulo es una porción del programa, que realiza una o varias tareas para cumplor unos objetivos. Son convocados por otro del mismo o superior nivel.
  • Una directiva es una operación lógica básica.
  • Todos los componentes que no sean ficheros de configuración y la interfaz html estarán en la carpeta app.
  • El código HTML y CSS de un componente puede ser añadido inline de varias lineas usando la comilla \`
  • Además, se puede tener en un fichero separado e incluir con los tags templateUrl y array styleUrls respectivamente.

 

Nomenclatura

 

  • app es la carpeta que contiene todos los elementos de la aplicación.
  • Los nombre de los elementos (clases, módulos, servicios...) serán del tipo Mayuscula cada palabra sin espacios. Ej: SpecialSuperHeroService
  • Los nombres de los ficheros derivan del anterior por la regla del dash-case. Ej: special-super-hero.service.ts
  • *.ts es el nombre de cualquier clase.
  • *.components.ts es el nombre de cualquier componente.
  • *.services.ts es el nombre de cualquier servicio.

Instalar las dependencias definidas en los ficheros de configuración

 

Para instalar todo lo contenido en el package.json ejecuta:
npm install
Esto creara las carpetas:
  • node_modules: Contiene todas las dependencias de npm
  • typings: Contiene lo necesario para compilar TypeScript

Crear la aplicación

 

  • Crea la carpeta app. Los siguientes ficheros irán dentro de esta carpeta.
  • Crea el fichero app.module.ts, que contenta los módulos que requiere tu proyecto. [Más info](https://angular.io/docs/ts/latest/quickstart.html)
  • Crea un componente básico 'AppComponent', y añadelo en el fichero de modulos.
  • Crea el fichero main.ts que es el punto de entrada de la aplicación.

 

Aspecto y carga de las dependencias js en HTML

 

  • Crea en la carpeta base el fichero index.html con el aspecto estático de la aplicación.
  • Crea el fichero styles.css y dale el aspecto que quieras.

 

Ejecuta la aplicación

 

Si todos los pasos anteriores son correctos, solo te queda ejecutarla:
npm start

 

Tu primera edición

 

Si quieres cambiar un poco la web, solo tienes que ir al fichero app.components.ts y editarlo. Si cambias la etiqueta de entrada, no olvides cambiarla también en index.html

 

Un tutorial serio

 

Para que veas todo el potencial que ofrece esta herramienta, te recomiendo que sigas el tutorial Tour of Heroes en la página oficial. Tras hacerlo y asimilarlo, tengo ya preparada una versión completa. Puedes usar una versión online, si quieres saltarte el paso de aprenderlo o bajar el código del repositorio oficial.

 

Aspectos básicos

 

General

  • Las importaciones de componentes necesarios deben declararse en app.module.ts.
  • Todas las importaciones de clases necesarias deben declararse en el *.component.ts que las necesite.
  • app.component.ts debe ser usado para administrar la navegación por la aplicación a nivel global.
  • Las clases nuevas son *.ts; Los componentes son programados en el *.components.ts, se separan por el [principio de responsabilidad única](https://8thlight.com/blog/uncle-bob/2014/05/08/SingleReponsibilityPrinciple.html)
  • Decorator es un patrón de diseño que permite añadir dinámicamente funcionalidades a un objeto.
  • Promise es un elemento que permite obtener datos de forma asincrona, cuando esten listos.
  • Se puede añadir diversas etiquetas a un componente. Por ejemplo: selector, template, styles...
  • Las clases pueden tener atributos como number, string, o incluso otras clases.
  • Se pueden declarar valores constantes y arrays en app.component.ts
  • Toda directiva que empiece por ng es especial. ngModel, ngIfngFor...
  • La directiva ngModel puede usarse para que elementos de la interfaz editados sean propagados en tiempo real.
  • Se pueden añadir directivas a etiquetas HTML para que hagan algo en ejecución, por ejemplo, rellenar un objeto hero con valores del array heroes y su correspondiente callback:
<li *ngFor="let hero of heroes" (click)="onSelect(hero)>
  • Para todo fichero, al principio se usarán los imports, al final los exports, y en medio el código que lo componga.
  • En el ciclo de desarrollo se puede usar objectos mock (Ad-hoc para una funcionalidad) para definir datos que necesitamos para probar la funcionalidad.
  • Alternativamente podemos usar un InMemoryWebApiModule, simulando peticiones HTTP a un API en memoria.
  • Dicho API se puede sustituir por uno real

Ciclo de vida

El ciclo de vida (o Component Lifecycle) es un conjunto de callbacks que son llamados en distintos momentos de la ejecución cuando suceden eventos.
  • Necesitas importarlos de @angular/core
  • OnInit: Init

Avanzado

  • Crear variables o funciones private o publicas, solo afecta a la compilación para ver cosas, no se ve influenciada la salida en javascript. Sin embargo puede ser una buena práctica usarlas para asegurarnos que la implementación y uso se ajusta al diseño.

 

Generar documentación [Inestable]

 

Si te gusta tener las cosas bien documentadas, entonces vas a necesitar esta herramienta. Typedoc genera la documentación a partir de TypeScript. NO FUNCIONA bien DE MOMENTO! Tan pronto como salga de beta y de menos problemas lo actualizaré

 

Instalación

 

npm install --save-dev @types/core-js        # Local Install working with Angular2JS
typedoc -v                                    # Check installation

 

Usage

 

Usarlo es tan sencillo como teclear:
typedoc --out <path/to/documentation/>
Por ejemplo:
mkdir doc               # Crear path doc
typedoc --out doc app   # Generar
En una próxima entrada enseñaré como meter este repositorio en una aplicación nativa usando el framework electron

sábado, 29 de octubre de 2016

¿Por qué cambiar (o no) a Diaspora*?

https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgzFIYFQVyW5dZ_wCifAhEX3rJzmP-e0HPRrOPN2D-lHTaFnKj48lpTOq66K8y1RC4OypZTnOryv2nW_JGwVf8Vt_md1ftavxs1wmic13IqGVZ0GUbDG-S50plMSf5CTM2fLZ3nGRvIfJcd/s1600/diaspora-logo-1.png
Red social de software libre

Diaspora* es una red social alternativa a Facebook o twitter. Desde luego no tiene tanta gente como esas redes sociales, lo cual es positivo ya que no está en el punto de mira de las grandes empresas para monetizar (al menos de momento) y me atrevería a decir que tiene tantos usuarios como Google+ :-D

Mi colega Rubén lo analiza muy bien en su blog mascandobits, así que te recomiendo que ojees la entrada. Además, está muy relacionada con los operadores de telefonía, que tanta guerra han dado para cobrar por todo a las empresas que ganan dinero en internet, y que puedes ver como nos van a usar para ganar dinero. Parece ser que todo el mundo se sube al barco de traficar con datos, y si ponen a nuestra disposición una herramienta (que seguro no será de software libre ni podrás renunciar a los derecho que otorgue que exista), es porque algo van a ganar estos también.

No obstante, aunque es muy interesante el tema y estas noticias, hay ciertos conceptos que quizás es mejor explicar explicitamente aquí para que no nos lleven a equívocos.
  • ¿Qué es un pod exactamente?  La comunidad forma pods, o servidores, en los que subes la información, y puedes descargartela, borrarla, o editarla. Por desgracia, su mantenimiento no es gratuito, y al no exprimirte como producto se tiene que mantener de alguna forma. Normalmente se pone dinero entre los usuarios para pagar los servicios. JoinDiaspora por ejemplo sería un pod.
  • ¿Es necesaria una red social? No sé si alguna vez habeis tenido cuenta en facebook u otra red social, puedes organizar la información como quieras sin atarte a una empresa en tu propio ordenador. No obstante, a veces quieres compartirla con tus conocidos, amigos o familiares, y Diaspora busca de alguna manera cubrir este nicho sin explotarte. Puede ser necesaria y puede no serlo, puesto que hay una necesidad en la gente, es mejor intentar cubrirla de forma que les proteja de abusos de personas que codician lo que otras tienen.
  •  ¿Qué es eso de la nube? Conviene aclarar un poco este concepto. Es la palabra de moda, que no te engañen, la nube es que tus datos y/o archivos están en el ordenador de otro. Ten en cuenta que aceptas unos terminos cuando te das de alta en un servicio, la mayoría no los lee, y que puede ser que esos datos de dejen de pertenecer, como es el caso de Facebook.
  • ¿Por qué es importante la privacidad y que ganan las empresas con ella? Los datos son solo eso, datos, pero cuando se recompilan un montón, y se usa el data mining, se puede sacar valiosa información de nosotros. ¿Qué me gusta? Inofensivo si te sugiere cosas, pero se puede enfocar a venderte productos y subir la probabilidad de que "piques". Se puede usar la información para ofrecerte viajes o compras por un precio que diagnostican y estás dispuesto a aceptar, porque te conocen, que no tiene porque ser el mejor precio. Llegan a controlar que páginas has visitado y pueden subir artificialmente los precios si saben que tienes un vuelo un puente, y has visitado webs de hoteles, te pueden encaminar a donde quieran.
  • ¿Quien puede ver lo que publico? En Diaspora existen los grupos, es decir, puedes hacer que tus post, fotos, etc. las veas solo tú, tus amigos del institito, que no verán mis padres por ejemplo y viceversa. ¿No sería genial que las fotos embarazosas que publicas para que vean solo tus padres no lo vean tus amigos para que se mofen? Además, hay plugins para publicar de otras formas PUBLICAS tu información, tu sabrás donde quieres depositarla y de que manera. Pero se puede integrar fácilmente en Tumblr, Facebook, Twitter...
  • ¿Qué pasa si me quiero llevar la información a otro sitio, o simplemente borrarla? Es bueno el poder eliminar siempre que quieras la información, y parece que Diaspora tiene los mecanismos necesarios para esto. Porque si decides hacerte una cuenta y subir un montón de fotos y pasados dos años, quieres cerrar la cuenta, te puedes llevarme las fotos y post, y esas fotos se van a destruir. ¿Infalible? Como todo, no lo creo, pero es una apuesta más segura que otras. Si absolutamente todo el código que se ejecute entre tu ordenador y los servidores, fuera software libre, se podría auditar, y aun con todo esto, siempre corres el riesgo de que alguien no autorizado acceda de alguna forma a la información. Asumo que se toman las medidas necesarias.
  • ¿Subo entonces, mi vida privada, a la nube? Es tu elección. De todas formas esto no es un alegato para que subas tu vida privada a internet. Corre en otros ordenadores, administrados por personas. Los servidores siempre pueden ser hackeados, atacados, alguien puede coger tu información y por muchas medidas de seguridad que haya, en algún punto de la cadena puede fallar, así que el sitio más seguro sigue siendo, un ordenador aislado de internet. Pero acuerdate de hacer copias de seguridad encriptadas, porque sino podrías perder tus valiosos recuerdos, valiosos para ti, y por supuesto, para las empresas.
Si quieres saber más sobre la fundación que está detrás. Informate. En la Wikipedia tienes más.

FIltros personalizados para adblock

¿Cansado de la publicidad indeseada e intrusiva? ¿Te horroriza usar servicios como Tumblr, Twitter, o Facebook y encontrarte con entradas patrocinadas, y muchas veces repetidas hasta la saciedad, carentes de internet? Pues estás de enhorabuena, con el fantástico plugin de Firefox/Chrome adblock plus, y un filtro personalizado, podrás hacerlo. Tienes unos jugosos tutoriales aquí. Además, puedes suscribirte a filtros extra.

Como crear un filtro

Para crear un filtro (una vez instalado el plugin claro), solo tienes que ir a preferencias de filtros (Ctrl + Mayus + E) y seguir estos pasos en la pestaña de Filtros personalizados:
  1. Añadir grupo de filtros
  2. Asignarle un nombre
  3. Click en añadir filtro (Activado)
  4. Añadir la regla de filtrado
Las reglas son simples, si quieres saber más acerca de ellas echa un ojo a este tutorial.

Facebook

Yo no recomiendo usar Facebook, tanta publicidad, tanto comercio con tu información, perder el control de tu vida digital (a pesar de las herramientas para que no ocurra), es un problema mayor que la publicidad (quitada por defecto) que además ahora tiene los post promocionados. Para librarte de ellos la solución más fácil es suscribirte a un filtro:

  1. Ir a preferencias de filtros (Ctrl + Mayus + E)
  2. Pulsa en la pestaña de suscripción de filtros
  3. Añadir otra suscripción de filtros
  4. Titulo: "facebook annoyances blocker"
  5. Ubicación: "https://easylist-downloads.adblockplus.org/fb_annoyances_full.txt"
A veces no funciona bien, al menos en Castellano. Asi que he añadido una regla extra que de momento funciona:

  • facebook.com##._5g-l, ._5g-l ~ *

Tumblr

Se ha vuelto recurrente la aparición de un montón de post patrocinados, que se repiten mucho, además de no ser de mi interés para nada. Con este filtro podrás librarte de ellos.
  1. Crea un grupo de filtros "Tumblr sponsored"
  2. Añade la regla"www.tumblr.com##div.image-ad"
Espero que sea de ayuda.Y recuerda, escribe fácilmente filtros con el tutorial oficial.

domingo, 17 de julio de 2016

Interfaces multiplataforma basadas en electron

 

Introducción:

Cada vez queda más patente la necesidad de hacer aplicaciones multiplataforma
que se adapten a dispositivos de todos los tamaños de la forma más general posible para evitar en la medida de lo posible el tener que hacer varias versiones distintas y poder ahorrar tiempo y dinero.

Uno de los principales problemas que han tenido los desarrolladores de iOS, ha sido el ver como con el paso de los años, una única interfaz de tamaño determinado ha sufrido cambios y han tenido que adaptarse en este proceso. Por su lado, Android, abordaba esta temática con su sistema de layouts, no era ni es un sistema perfecto pero facilitaba bastante el desarrollo en un ecosistema tan variado como lo es el de Android.

Mientras tanto, Apple fué sacando sobre la marcha un sistema de constrains (restricción) que desde mi punto de vista era una chapuza que no solucionaba ni facilitaba la vida a los desarrolladores. Únicamente los más veteranos y centrados profesionalmente en esta tarea sacaron provecho en su trabajo. Sin duda, este sistema era insuficiente para los que no teníamos tantos desarrolladores con experiencia para afrontar desarrollos de un nivel de calidad alto.

Entre todo este jaleo, y aun siendo bastante reticente al paso web para usar como interfaces, me he fijado en la tecnología que ofrece electron y en sus posibilidades. La conocí a traves del editor de Software libre, Atom, y está enfocada a hacer interfaces siguiendo el MVC (modelo vista controlador)
que es justo la pieza que me faltaba en el desarrollo de aplicaciones multiplataforma (Android, iOS, escritorio...) donde se busca delegar la lógica de negocio a una librería en C++, scripts python, o directamente en una libreria javascript, puede tener sentido utilizar algo tan extendido como es la combinación de JS, HTML, Bases de datos, json, y muchas otras tecnologías web, que aun (a mi parecer) lejos de ser perfectas y todo lo ordenadas
y estrictas como a mi me gusta en un desarrollo, con una metodología adecuada y una buena organización creo que sería posible delegar algo tan importante como es hoy en día lsa interfaces rápidas y visualmente atractivas a una parte de una aplicación.

Estas tecnologías combinadas con la versión 2 del framework Angular 2  promete ser una poderosa herramienta para afrontar este reto. Este utiliza MongoDB para manejo de datos, Express.js como framework de servidor, y utiliza Nodejs como ayuda del entorno de ejecución. Angular pone énfasis en la programación declarativa, esto es el QUE quiero hacer, y no tanto COMO lo quiero hacer. De esta forma se puede generar interfaces de usuario que sin entrar en la complejidad del funcionamiento, pueden ser el complemento a
aplicaciones que si lo sean. La wikipedia ofrece algo más de información.

Con el tiempo os contaré mis impresiones tanto en los aciertos como en los fracasos, para todo aquel que pueda estar interesado en estos temas pueda tener un experiencia en la que apoyarse para tratar de usar esta tecnología
en la resolución de este complejo problema. Mi idea es utilizarlo en varios proyectos que tengo entre manos y que explicaré más adelante. Como ya he comentado, este post trata de rellenar el hueco de la parte `bonita` que deje en pendiente en el post de aplicaciones multiplataforma. También me gustaría experimentar con una idea del proyecto GNU llamada guile. Pero es algo que aun está en desarrollo y que aun no he podido explorar a fondo para sacar
conclusiones. Vi este proyecto interesante y estaré pendiente a los avances
que se den para ver lo que me puede interesar.

Cosas que te interesa saber sobre este framework

  • El fichero main es el encargado de crear el objeto BrowserWindow. Puede haber varios y cada uno de estos objetos funciona en un proceso independiente con su propio ciclo de vida de aplicación. 
  • Cada brower tiene un ciclo de vida que si ya lo has utilizado, tiene cierto
    parecido al de Android, aunque lógicamente es distinto.
  • Existe gestión de input de usuario muy parecido al de Java de Android. Con eventos onClick, funcioner declaradas inline en los variables. En Java se podían declarar antes de ser usadas, en javascript no lo sé, así que tengo TODO  comprobar si se puede o no. Quizá no tenga sentido al ser interpretado o no haya diferencia.
  • Existe gestión de excepciones y cuelgues para reaccionar ante problemas en la ejecución de una aplicación.
  • El fichero renderer es el encargado de actualizar la interfaz y de recoger los
    eventos que suceden en ella.
  • Tu aplicación puede tener un menu superior customizado a tu gusto, o puedes crearla sin menu. Solo ventana.
  • La aplicación es capaz de acceder al sistema de ficheros del ordenador mediante el file manager del S.O
  • También puede acceder al protocol handler para realizar acciones en otras aplicaciones, como por ejemplo lanzar un juego en Steam.
  • Al igual que una web puedes acceder a información del ordenador, como sistema operativo, versión, y de la aplicación.
  • Puedes personalizar los shortcuts de tu aplicación, en las referencias hay una pequeña guia para no sobreescribir los del sistema operativo que lo ejecute.
  • Al igual que iOS y Android, puedes crear dialogos para dar o recibir información.
  • También se puede crear un icono de aplicación para colocar en la barra de notificaciones.
  • Está a disposición del desarrollador un modulo para comunicar distintos procesos, ya sea de forma asíncrona o síncrona. 
  • Para más información puedes utilizar las demos del Electron API demos v1.0 (link) que contiene demos interesantes de lo que puedes hacer con electron y todo dentro de una aplicación generada con Electron.

 Organización

Una posible organización del proyecto debería estar más o menos organizada así:
  • README.md, Información de la aplicación.
  • LICENSE,md, Licencia
  • index.html, página web de la interfaz del proyecto.
  • renderer.js, renderizador de la web para los cambios a lo largo del tiempo.
  • assets, carpeta con todas las imagenes y otros recursos necesitados por la app.
  • scripts, carpeta con todos los scripts en javascript necesitados por la app.
  • node_modules, carpeta con las dependencias de la app instaladas con npm

Conclusión

Espero que con esta entrada os hayais introducido en conceptos e ideas básicas del MVC para uso de interfaces y en el futuro podamos evaluar lo fácil o no que son de usar y si ahorran tiempo de desarrollo frente a otros métodos de interfaces. Alternativamente puedes hacer distinción usando MVP.

martes, 12 de julio de 2016

Software libre, hoy más importante que nunca


FSF Logo
Es un tema que está bastante trillado, pero que sigue sin entenderse completamente. Es como el funcionamiento de los punteros, muchos programadores saben usarlo, y con el paso del tiempo siguen aprendiendo cosas sobre ellos y puliendo su conocimiento. Con el Software libre ocurre lo mismo, voy a intentar arrojar un poco de luz sobre el tema. AVISO: Esta entrada va a mi rollo, puede no coincidir totalmente con la postura de la FSF u otros seguidores del software libre.

El llamado internet de las cosas, es....., el software está en todos lados, en pequeñas piezas de hardware que pueblan nuestra casa. Hasta que no llegó GNU + Kernel de Linux, no había ningún sistema operativo libre, todos eran privativos. Un S.O libre permitió el desarrollo de una gran comunidad como es la actual. El ecosistema se dividió en muchas distros distintas, algunas recomendados por la FSF por estas libre de programar y drivers privativos, y otras que no. Muy pocas son las que lo cumplen, y a veces se sacrifican valores para mejorar la experiencia del usuario, comprensible pero no es lo más adecuado.

Un problema habitual para los que juegan en GNU/Linux, es que los drivers gráficos más potentes son privativos, y las alternativas libres, que sacan funcionalidad gracias a la ingeniería inversa del hardware, los usuarios se ven obligados a elegir entre potencia y rendimiento, o ética, y muchas veces pierde la ética. Hay que valorar la libertad, y comenzar a exigir standares abiertos, APIs abiertos a hardware y programas libres para que cualquiera pueda mejorarlo y utilizarlo, en su máximo potencial, sin depender de una empresa o grupo.

Describo a continuación las principales premisas que infiero de las charlas y documentos que hay sobre el software libre.
  • La premisa cero es, compartir es bueno, compartir debe ser legal, una ley que lo prohibe es antisocial y carece de valor ético. Pero ser libre implica mucho más, como vamos a ver. No tiene que ver con canciones o peliculas, deben ser compartibles y libres, pero no tienen porque ser gratis. Sin DRM, ni otras limitaciones que te impiden utilizarlo, obviamente.
  • La primera premisa es mantener las 4 libertades de los usuarios, la posibilidad de usar, estudiar, distribuir, y adaptar el código que ejecutes. No estás obligado a ello, pero tienes que tener la posibilidad.
  • La segunda premisa es respetar las licencias, nombra a los autores, mezcla software con licencias compatibles, no te apropies del trabajo que no es tuyo, haz lo que debes si usas software libre, etc.
  • La tercera premisa es exigir privacidad, aunque no tengas nada que ocultar, las empresas, gobiernos, y otras personas no pueden monetizar o aprovechar tu información privada. Empresas y webs se dedican a hacerlo, como whatsup, facebook, instagram, entre otras. Si las usas, hazlo con precaución, y si navegas, usa extensiones como No-script, libreJS, ghostery, usa redes tor, etc.
  • La cuarta premisa es, intenta no usar software privativo. No sabes lo que hace, no puedes saber que realmente hace lo que dice, puede tomar datos sobre ti sin decirtelo, puede espiarte, no puedes adaptarlo a tus necesidades... Hoy en día es casi imposible, pero es importante intentarlo. Yo fallo muchas veces en este punto, y espero mejorarlo.
  • La quinta premisa es, software libre no es software gratuito. Puedes vender tu copia, o vender una copia que consigas, siempre que la sigas distribuyendo como software libre que respete las libertades del usuario. De esta forma nadie queda atado al autor original si se sigue respetando la licencia, y podrás adaptar el código a tus necesidades, resolver bugs, mejorarlo y venderlo, etc. Este punto tiene muchos matices, dedica unas horas a leerte el FAQ y las licencias. Pagar es un detalle pequeño respecto a si respeta o no tu libertad, esto último es más importante.
  • La sexta premisa es, el mundo no cambia de la noche a la mañana, día a día puedes desarrollar software libre, participar en proyectos, instruir, quejarte a las empresas que pretenden que ejecutes código sin verlo, etc. Es dificil llevar a cambio el cambio pero el esfuerzo merece la pena.
  • La séptima presima, por mucho que me duela, es que si usas software privativo, eres un ejemplo de alguien que no está dispuesto a hacer un esfuerzo en favor de su libertad. A día de hoy, no existen alternativas libres tan buenas y eficientes como algunos programar privativos. Hay que comenzar a cambiar, yo mismo uso para jugar software privativo, a veces en mis trabajos no he tenido más remedio que usarlo, es un aspecto a mejorar por cada uno de nosotros.
  • Otra premisa importante es, que se deben aplicar las anteriores de forma legítima. Obligar al usuario a hacer ingenieria inversa para modificar el comportamiento del código NO es legitimo, hay que dar el código fuente e instrucciones razonables para hacerlo. En la práctica, se tiene que recurrir a estudiar el funcionamiento del software privativo, con ingeniería inversa, para poder desarrollar software libre. Es más costoso, pero es lo justo, es un buen trabajo muy demandado, y desde luego, legal. Lo ilegal debería ser no facilitar especificaciones para poder hacer tu propio software con la comunidad.
Algunas preguntas que puedes hacerte:
  •  ¿Qué puedo hacer yo? Puedes colaborar, estudiar, ir adaptandote a estas premisas poco a poco e instruir a los demás de forma no agresiva. Es un tema complejo que conlleva aceptar una ética, y conseguir el cambio poco a poco. Es más fácil dejar de lado el tema, pero considera lo importante que es esto.
  • ¿Es necesario usar licencias en mi código? Por supuesto que si, cuesta algo de trabajo leer sobre ellas y elegirlas, pero usar GPL o cualquier otra licencia libre, evitará que empresas puedan legalmente apropiarse de tu trabajo, contribuiras al desarrollo de la comunidad, y conseguiras que la gente pueda aprovechar tu trabajo para hacer obras derivadas.
  • ¿Quien tiene el control de lo que hace mi ordenador, el programa, o el programador/usuario? El software libre hace que tengas TU el control sobre el programa. Si no puedes verlo, no puedes estar seguro de que hace lo que te dicen que hace.
  • ¿El software en si mismo es bueno o malo? Obviamente no es malo, dependerá de como se use y como se puede utilizar, que se puede hacer con él, etc. El creador y el usuario son los que pueden usarlo para el bien o para el mal.
  • ¿El software libre implica que tenga que leer y comprender todo el software que utilizo? Obviamente no, es un problema inabordable, pero la comunidad es grande, y hay organismos que lo vigilan, si detectas algo raro, tu mismo puedes leerlo, hay muchos métodos a parte de auditar el código para evitar leerlo todo por ti mismo, no estás solo.
  • ¿Por qué llamarlo GNU/Linux y no solo Linux? El software libre empezó con con GNU, aportó gran cantidad de código, la ideología, etc. En su momento necesitaba un kernel donde ejecutar todo el código, un kernel que fuera de software libre. En un momento dado, Linus Torvalds licenció como software libre el kernel de Linux, y juntos, GNU/Linux, se convirtió en lo que es ahora.
  • ¿Sabías que la / de GNU/Linux es para que NO SE MUERDAN? Parrafo 2. Gracias por el aviso Iñaki.
  • ¿Los no programadores pueden colaborar? Por supuesto que si, alguien puede dar ideas, reportar bugs, y ayudar a los programadores aunque no lo haga directamente, participando en las decisiones, o incluso contratando a alguien que desarrolle lo que necesita. El que quiera colaborar es libre de hacerlo de cualquier manera.
  • ¿Existe diferencia entre código abierto y código libre? Si, hay una gran diferencia, el movimiento que representa la FSF no sólo busca poder leer el código, sino en cumplir con las 4 libertades, para modificarlo, compartirlo, etc. Por eso es importante que siempre se respeten estas libertades.
  • ¿Tiene un desarrollador la obligación de compartir el código? Obviamente no, tienes esa libertad pero no tienes porque ejercerla. Si te cansas de desarrollar un código y lo compartes, puedes dejar de mejorarlo, y otros usuarios podrán hacerlo o no, los usuarios no van a estar atados a ti por siempre como sucede en el software privativo, pero si mejoras un código para ti mismo o tu empresa, y no quieres compartirlo con la competencia, siempre que no distribuyas el binario, no tienes porque compartir el código de esas mejoras.
  • ¿Me puedo fiar del software como servicio? Si una actividad puedes ejecutarlo tu mismo, en local, siempre va a ser mejor que confiar en sitios que ejecuten el código de lo que tu haces, para poder ser libre. No todo se puede ejecutar en local, para comunicarte, necesitas hacerlo con otros, pero existen mecanismos para cercionarte con quien hablas, si hay terceros escuchando la comunicación, etc. Utiliza siempre Https, ssh, y otros cifrados para impedir que perjudiquen tu libertad.
  • ¿Debo desconfiar de todo lo que sea Smart? Como ya hemos dicho antes, cada vez más hardware controla nuestra vida, termostatos inteligentes, contadores de luz y gas que monitorizan datos, móviles con GPS y triangulación que te localizan exactamente (sino claro no funcionarían los telefonos), etc. Esta información es muy valiosa para las empresas, para facturar la luz basta con 1 lectura al mes, no cada segundo, con lo que se puede averiguar y/o aproximar patrones de consumo, cuanta gente hay... Desconfia de todo lo que no puedas auditar, ¿Imposible? Improbable más bien, complicado, pero toma las precauciones necesarias.
  • ¿Debe ser la educación sobre software libre? Por supuesto que si, muchas escuelas y universidades usan licencias de windows, packs ofimáticos de pago por licencia, software privativo en las prácticas que te obligan a usarlo para aprobar. Esto debe cambiar, y debe hacerse poco a poco. Debería ser ilegal por ser anticompetitivo, y antieducativo, porque no puedes ver como se hacen las cosas y te obligan a pagar por algo que te quita libertad. Por inercia social la universidad forma usando software privativo, porque se usa en el mundo laboral, y vicerversa. Lo ideal, y a lo que tenemos que ir, es a una sociedad ética donde cada uno se forme con software libre, y si se quiere, en una empresa, te formen y paguen por usar software privativo. No es lo ideal, pero no se puede obligar a que otros no lo hagan, esto iría en contra de la libertad que se busca defender. Tienes más información para la educación en este post.
  • ¿Puedo poner una licencia de explotación distinta a la GPL durante un tiempo y luego licenciar el código como GPL? Si eres dueño del código, puedes hacer lo que quieras. Esto incluye liberar el código con distintas licencias en distintos momentos, así que nada impediría que tengas software propietario, tuyo, y luego lo liberes. Tengo mis dudas, si sería posible aplicar a la GPL un tiempo de explotación donde no se deje compatir durante un periodo de tiempo (pongamos 3 años), para permitir la explotación comercial y que luego pase a ser un derecho. Técnicamente esto iría en contra de las libertades de los usuarios, aunque suena razonable para una empresa que desarrolla código único y especial. Nada te impide crear tu propia licencia, así que podría ser una solución de equilibrio para la situación actual de Software libre vs software privativo. He de añadir que seguramente a la FSF esto le parecería aberrante (no tengo la certeza y aún no lo he preguntado), pero en la práctica podría ser útil hacia un mundo de licencias libres.
  • ¿Cuando se considera una obra derivada de una con licencia GPL, y tengo que licencias el resto de código como GPL? ... (Falta investigación)
  •  ¿Cómo puedo hacerme de la FSF? Visita su web y hale, para adentro.
  • ¿Existe realmente San Ignucio? ¿Es la religión verdadera? Existe, efectivamente, y la wikipedia explica todo muy bien. No puedo asegurar de que sea la verdadera, pero da algunas respuestas a la vida. Por suerte no requiere el celibato, aunque es muy dificil llevar una vida pura como exige su camino. Una lástima que no bendigan agua para exorcizar ordenadores poseidos por el demonio privativo.
Una charla completa interesante, para bien o para mal, en youtube con codec privativo:



No olvides pasarte por esta entrada para aprender un poco más sobre las licencias. Si quieres saber más, puedes adquirir el libro de ensayos Richard en la web de la FSF. También hay muchas universidades con información abundante sobre el tema.

Licencia de este post, CC no derivados porque es una opinión o punto de vista.

Enlaces de interés:
- Diferencia SW libre y Open Source, fuente genbeta, via RDCH106

domingo, 3 de julio de 2016

Compilando con CMake


¿Que es?

Es una herramienta para multiplataforma para generar Makefiles a partir de scripts y poder compilar proyectos escritos en C, C++, Objective-C o Fortran usando un lenguaje más elevado que el propio Makefile o proyectos de IDEs comunes.

¿Para que sirve y porque usarlo?

Tiene capacidad para generar proyectos de Eclipse, Visual Studio, o plain Makefiles a partir de dichos scripts (CMakeLists.txt) para facilitar el desarrollo de un proyecto. Además, al estar orientado a cualquier plataforma y enfocado a facilitar la crosscompilación mediante toolchains, facilita la compilación en cualquier plataforma GNU/Linux, MAC y Windows con cualquier target (x86, ARM).

Hay que tener en cuenta que no hace magia, el propio código siempre tiene que estar adaptado a cada plataforma, tener precondiciones para que funcione en todas, etc. No obstante, usar CMake facilita mucho la adaptación si tienes en cuenta ciertos detalles que se adquieren con la experiencia.

Organización

A la hora de organizar un proyecto, lo primero que se tiene que tener claro es como lo vamos a organizar. Recomiendo usar control de versiones git, ya sea administrado por nosotros mismos o usando uno de los servicios populares: Github o Bitbucket. Sugiero utilizar diversas carpetas para separar conceptualmente las distintas partes del código, por ejemplo:

Proyecto general:

Constará con la configuración del proyecto en lineas generales, y la organización del código. Se recomienda tener unos ficheros básicos en la carpeta raiz del proyecto:
  • CMakeLists.txt principal que configure el proyecto usado por CMake.
  • README.md que explique que hace el proyecto, autores, datos de interés...
  • Contributing.md, fichero opcional para informar al que quiera contribuir en el proyecto.
  • License, fichero con la licencia del código, aunque este en las cabeceras de el source code, es importante dejarlo claro.
Y las carpetas con el contenido separado del proyecto:
  • Modules: Carpeta con las distintas librerias, bien sean estáticas o dinámicas que componen nuestro proyecto. Contendrán todo el código de la librería separado conceptualmente en distintas sublibrerías si procede. No debe contener ejecutables.
  • 3rdParty: Carpeta con todo el código de terceros, ya sea en submodulos de git
  • Samples: Carpeta con minimo código para crear ejecutables de ejemplo de funciones básicas de la libreria, o ejemplos complejos ilustrativos.
  • Test: Carpeta con todos los test unitarios para probar los módulos si son necesarios. Esta carpeta es opcional. Por ejemplo usando GTests
  • cmake, carpeta con los módulos y otros scripts de cmake utiles para compilar el proyecto.
Módulo individual: 

Será todo aquel en un subdirectorio del proyecto general. Puede ser un ejecutable o una librería de nuestro proyecto general. Se sugiere que conste con:
  • CMakeLists.txt: Fichero con la configuración de ese subproyecto concreto.
  • src: Carpeta con todos los ficheros *.cpp, *.c, *.m del subproyecto.
  • include: Carpeta con todos los ficheros *.h, *.hpp del subproyecto
Por supuesto, esto es un esquema recomendado, cada proyecto tiene sus propias pautas, normalmente explicadas en el README, la wiki, o la página oficial del proyecto. Yo por ejemplo siempre utilizo una carpeta build fuera de el código fuente. Las razones varias, aunque con gitignore puedes evitar añadirla al repositorio, ayuda a no hacerlo. Eclipse da problemas si tiene build anidado en el source. Ayuda a separar diversas compilaciones si necesitas copias sin emborronar la carpeta del código.

Por ejemplo, yo suelo tener una carpeta con el proyecto que contiene:

  • git, carpeta con todos los repositorios relacionados con el proyecto.
  • doc, carpeta con toda la documentación o referencias relacionadas.
  • build, carpeta con todas las plataformas compiladas, pruebas, Doxygen documentation output, etc.
Variables importantes:

CMake dispone de muchos comandos y variables importantes, que pueden ser consultadas en su referencia, y que nos ayudarán a configurar nuestro proyecto. Por supuesto, puedes crearte tus propios comandos, o macros si lo prefieres, llamar a ejecutables como hacen los Makefiles, y muchas cosas más.
  • CMAKE_CONFIGURATION_TYPES, configura Release, debug... en proyectos como VS
  • PROJECT_BINARY_DIR, variable que apunta a la base de la carpeta build
  • CMAKE_VERBOSE, información extra al generar el proyecto-
  • CMAKE_DEBUG_POSTFIX, sufijo en el caso de target debug
  • CMAKE_CURRENT_SOURCE_DIR, el proyecto donde se ejecuta el actual CMakeLists.txt  

Comandos importantes:
  • cmake_minimum_required(VERSION 2.8.8), versión minima probada de los scripts
  • PROJECT(${PROJ_MAIN_NAME}), Crea un proyecto con el nombre de la variable PROJ_MAIN_NAME.
  • ADD_SUBDIRECTORY, añade una subcarpeta al script actual, para revisar su CMakeLists.txt
  • ADD_EXECUTABLE, A partir del código proporcionado después del comando PROJECT, crea un ejecutable.
  • ADD_LIBRARY, lo mismo que ADD_EXECUTABLE pero creando una librería estática o dinámica según la opción proporcionada. 
  • LINK_DIRECTORIES, provee paths que contentan librerías que necesita el proyecto
  • TARGET_LIBRARY, provee el nombre de las librerías necesitadas.
  • MESSAGE, comando para printear información, datos o variables.
Para los más avanzados:

Tengo un pequeño repositorio en Github de código abierto llamado CMake-supporter. Utilizado como submodulo en un repositorio o simplemente copiando el código en la carpeta cmake, puede ser usado para manejar toolchains que compilan código en C++ para iOS y Android, también tiene templates de los proyectos principales y está perfectamente documentado como usarlos. Si no tienes mucha idea de CMake, pueden serte de utilidad tanto para no pensar en organizar un proyecto, como para aprender n poco sobre este sistema.

Un ejemplo:

 
Puedes ver el funcionamiento de un proyecto de prueba más avanzado que lo usa como submodulo en este repositorio. Simplemente haz:
git clone --recursive https://github.com/vgonisanz/cmake-supporter-sample
Configura y ejecuta el proyecto, y trata de compilarlo.

Trabajo futuro:

A parte de que mejoraré CMake-supporter, y el ejemplo, estoy pensando como generar automáticamente con unos pocos datos la estructura del proyecto, ya adaptada para no tener que copiar los templates y renombrar a mano, crear las carpetas, etc. Os mantendré informados.

Otros enlaces utiles:
  • http://www.cmake.org/cmake-tutorial/
  • http://outcoldman.com/en/archive/2014/05/02/xcode-and-cmake/
  • http://voices.canonical.com/jussi.pakkanen/2013/03/26/a-list-of-common-cmake-antipatterns/

martes, 21 de junio de 2016

Notación Húngara y otros estilos de programación

¿Alguna vez te ha ocurrido, leyendo código, que encuentras letras aleatorias delante de los nombres? ¿Te mosquea no saber que pasa por la cabeza del desarrollador para usar estas letras de formas incoherentes? No te preocupes más, en la entrada de hoy arrojo algo de luz a esta cuestión.

Probablemente te has encontrado código como (Systems Hungarian notation):
  • AccountNum : variable is a long integer ("l");
  • arru8NumberList : variable is an array of unsigned 8-bit integers ("arru8");
  • szName : variable is a zero-terminated string ("sz"); this was one of Simonyi's original suggested prefixes.
  • bReadLine(bPort,&arru8NumberList) : function with a byte-value return code.
  • arrlstCbomPagedDetails : ArrayList in java.
  • arrStudents : variable is an array in Java of object used for students;
  • rwPosition : variable is a int with a position in a Table;
La razón es sencilla, se utiliza para abreviar el tipo de variable con el nombre, y así, en programas grandes o con variables globales, el programador puede identificar rápidamente de que tipo es. Se utiliza en C y C++, pero sobre todo en lenguajes poco tipados como Javascript.

Las reglas más normales son:

Prefix Type Example
b boolean bool bStillGoing;
c character char cLetterGrade;
str C++ String string strFirstName;
si short integer short siChairs;
i integer int iCars;
li long integer long liStars;
f floating point float fPercent;
d double-precision floating point double dMiles;
ld long double-precision floating point long double ldLightYears;
sz Old-Style Null Terminated String char szName[NAME_LEN];
if Input File Stream ifstream ifNameFile;
is Input Stream void fct(istream &risIn);
of Output File Stream ofstream ofNameFile;
os Output Stream void fct(ostream &rosIn);
S declaring a struct struct SPoint
{
C declaring a class class CPerson
{
struct name or abbrev declaring an instance of a struct SPoint pointLeft;
SPoint ptLeft; // or abbrev. (be consistent)
class name or abbrev declaring an instance of a class CPerson personFound;
CPerson perFound; // or abbrev. (be consistent)

Y por delante:

Pre-prefix Type Example
u unsigned unsigned short usiStudents;
k constant formal parameter void fct(const long kliGalaxies)
r reference formal parameter void fct(long &rliGalaxies)
s static static char scChoice;
rg array (stands for range) float rgfTemp[MAX_TEMP];
m_ member variable of a struct or class char m_cLetterGrade;
p pointer to a single thing char *pcGrade;
prg dynamically allocated array char *prgcGrades;

Pros:
  • Reglas mnemotécnicas
Contras:
  • Más farragoso
  • Renombra las variables

Como en todo, hay gente a favor, y gente en contra. Decide por ti mismo. Si quieres más información pasate por aquí

Si buscas otros estilos o formas de hacer las cosas, cada maestrillo tiene su librillo, pero recomiendo usar alguno de los siguientes:
Y algunos consejos para la programación segura:

Fuente, y esta

jueves, 19 de mayo de 2016

StoryTelling y como crear tu propia aventura online



https://c1.staticflickr.com/3/2930/14134388517_b65d0cae99_b.jpg

Se conoce como Story telling al acto de transmitir una historia o relatos de longitud variable. Puede usar cualquier medio de comunicación, puede ser un breve escrito con palabras e imagenes, una improvisación contada sobre un escenario, o incluso relatos web interactivos.

Tradicionalmente se han usado fábulas, cuentos, anécdotas y otras narraciones para tratar de educar, entretener, y transmitir la cultura de unos individuos a otros, siempre desde el respeto y la tolerancia a los puntos de vista de los demás. Pero No por esto se van a transmitir relatos "políticamente correctos" que no puedan molestar a posibles receptores. Hay que aprender a que no siempre vas a estar de acuerdo con lo que oyes o lees y que si algo no te gusta, o lo ignoras, o lo discutes. De hecho, cerrarte solo a los que opinan puede ser muy negativo ya que puede provocar ideas sectarias o falta de tolerancia.

http://www.martinarmenta.com/wp-content/uploads/2014/12/El-Viaje-del-H%C3%A9roe-4.png


Normalmente un relato cuenta con un argumento, personajes y punto de vista narrativo. Se puede, por tanto, usar técnicas tradicionales, como el punto de vista de el viaje del héroe, o usar tu propio punto de vista y estilo.

Las nuevas tecnologias nos han cambiado la forma de hacer historias, aunque el transfondo sea el mismo. Una muy querida amiga, estudió sobre esto y realizo su proyecto fin de master haciendo una herramienta de autor en la que desde una web, cualquiera que quiera hacer un breve relato siguiendo el camino del héroe puede hacerlo, solo tienes que acceder a su sitio web.

Por otro lado, existen alternativas OpenSource para hacer tus propia como twinery, donde usando una web y sencillos grafos, podrás crear tu propia historia y generar una web para disfrutarlo.

Como curiosidad, quiero hacerte notar que hay muchas formas de expresar sentimientos y transmitir historias, como la poesia callejera, por poner un ejemplo:
Subi al arbol mas alto
que tiene la alameda
y vi miles de ojos
dentro de mis tinieblas
Famoso verso de Lorca, citado en la canción Puta de Extremoduro, que desconocía hasta que me lo chivó un ángel. Cualquiera, sea informático, cantante, o poeta, puede aportar su granito de arena cultural, ahora más fácil, gracias a la tecnología.

lunes, 16 de mayo de 2016

Instalar un servidor de Minecraft en una Raspberry pi 2 modelo B

Hoy os voy a resumir como instalar, configurar, y utilizar un servidor de Minecraft. Para ello vamos a utilizar una imagen ya preconfigurada que encontramos en el foro de Raspberri Pi. Aunque me basaré en este post más actualizado y con la última versión.

Necesitaremos:
- 1 Raspberri Pi 2 Modelo B.
- Alimentación por USB, ya sea por enchufe o por un puerto que de corriente.
- Tarjeta SD de al menos 4 Gbs.
- Cable ethernet a un router

Usaremos la versión 2 de raspberri pi simplemente porque es más potente y tiene un Gb de RAM. Los modelos anteriores limitaban mucho el número de jugadores y tenían LAG a causa de la poca RAM que se podida dedicar al servidor. La imagen viene preparada para NO iniciar el cliente gráfico, ya que perderiamos rendimiento. Además está overclockeada para aprovechar mejor el Hardware.

Pasos para la instalación:
1º  Descargar la versión de la imagen MinecraftPIV3.0

2º La descomprimimos y volcaremos a la tarjeta SD con Win32DiskImage si usas Windows o con el comando dd si estamos en Linux:

sudo dd if=raspberripiv3.img of=/dev/sdX

Con X el identificador de la tarjeta. Alternativamente podemos usar usb-imagewriter que está en los repositorios oficiales.

3º Introducimos la tarjeta SD y enchufamos la tarjeta.

4º Nos conectamos remotamente a la raspberri pi. Si tienes una pantalla fisicamente conectada puedes ver su IP directamente, sino, basta con ver los clientes conectados al router y buscar el que se llame MineCraftPi. Por comodida, si sabes la MAC de la raspberri, puedes asignarle una IP fija para conectarte por SSH siempre a la misma.

5º Nos logueamos con el nombre de usuario pi y el password raspberri . Si usas ssh, por ejemplo PUTTY en Windows o el comando ssh en Linux, usa la ip y el puerto 22.

6º Cambiamos el usuario y ejecutamos build tools para compilar el servidor y tomate un café en los 55 minutos que tarda.

git config --global --unset core.autocrlf
sudo java -jar /opt/MineCraft/BuildTools.jar
 

Si te da un error del tipo java : Exception in thread "main" org.eclipse.jgit.api.errors.JGitInternalException: Invalid ref origin/master 

6.1º  Borra el contenido de la carpeta:

sudo rm -fr /opt/MineCraft/*

6.2º Baja de nuevo BuildTools

sudo wget https://hub.spigotmc.org/jenkins/job/BuildTools/lastSuccessfulBuild/artifact/target/BuildTools.jar

6.3º Tomate un café en los 60 minutos que le costará descargarlo y compilarlo.

6.4º Vuelve a ejecutar BuildTools

sudo java -jar /opt/MineCraft/BuildTools.jar

7º Ejecuta por primera vez el servidor con el comando:

sudo java -Xms400M -Xmx915M -jar ~/work/minecraft_server.1.8.8.jar

8º Espera hasta que genere las propiedades y el eula.txt y se cierre automáticamente

9º Edita el eula para poner a true la variable

sudo nano ~/eula.txt

Con estos pasos podreis lanzar un servidor de Minecraft. Solamente tendreis que configurar el mundo por los métodos habituales.

NOTA: La raspberri anda justa de RAM, así que si no haceis que el mundo sea más pequeño de lo standard, puede que no funcione bien la IA de los NPCs y monstruos.

  


sábado, 30 de abril de 2016

Como hacer una copia de seguridad de Windows 10 y restaurarla correctamente

Antiguamente lo más cómodo para hacer copias de seguridad era simplemente usar una de las varias opciones que había para hacer una copia, y al restaurarla en otro ordenador normalmente no daba ningún tipo de problemas. Desde que Se introdujo el sistema UEFI, particiones GPT, y ha ido evolucionando la seguridad en Windows, cada vez es más complicado y menos intuitivo hacerlo correctamente.

Para hacerlo de forma sencilla me he basado en 2 aplicaciones gratuitas:
- AOMEI Backupper standard
- AOMEI Partition Assistance

Para hacer la copia de seguridad hacemos lo siguiente:
- Abrir AOMEI Backupper standard
- Pulsar en la pestaña de Backup
- Elegir la opción deseada, en mi caso prefiero hacer particiones, así que elijo Partition Backup
- Step1; Elegir la partición para usar.
- Step2; Elegir en donde la vamos a guardar, por ejemplo un disco secundario de datos.
- Dale a aceptar y esperar a que termine. Si es muy grande la partición tardará varias horas.

Problema: Al restaurarla en otro disco, la partición no arranca porque no tenemos el sistema de boot.

Para solventar esto, los pasos a seguir son:
- Abrir AOMEI Partition Assistant Standard
- Borrar la partición con Delete partition.
- Crear un nuevo disco que sea Basic MBR.
- Aplicar los cambios, y tendremos el disco listo.

Para restaurar la copia de seguridad hacemos lo siguiente:

- Abrir AOMEI Backupper standard
- Darle a Restore, eligiendo el backup a restaurar del paso siguiente.
- Elegir donde restaurarlo, eligiendo el disco que hemos preparado como Basic MBR
- Darle a Next, y esperar a que termine el proceso. Seguramente querreis expandir el disco para ocupar todo en el de destino.
- Abrir AOMEI Partition Assistant Standard
- En el disco destino, boton derecho rebuild MBR
- Ahora al arrancar, saldría un error del tipo: status-0xc000000e

Arreglar el boot a mano:
- Usar un disco de Windows 7/8/10 y arrancarlo desde el DVD o el USB bootable
- Elegir opciones avanzadas y abrir un terminal.
- Usar el comando diskpart
- Ver las particiones: list vol
- Seleccionar la del disco que queremos arreglar (En mi caso la 2): sel vol 2
- Poner una letra, temporalmente uso la M: assign letter=M:
- Salir de diskpart: exit
- Comprobar el estado del bcd con: bcdedit
- El campo device y el osdevice seguramente salgan en blanco, es lo que debemos editar.
- Comando: bcdedit /set {default} device partition=M:
- Comando: bcdedit /set {default} psdevice partition=M:
- Comprobar que está correcto con bcdedit
- Reiniciar eligiendo el nuevo disco, et voila!

Espero que haya sido útil.


jueves, 25 de febrero de 2016

Enfoque nativo en el desarrollo de aplicaciones móviles

Alternativamente podríamos titular esta entrada como hacer aplicaciones móviles multiplataforma y no morir en el intento.

Introducción


A la hora de hacer aplicaciones, el 90% de los dispositivos Android usan solo Java, y la mayoría de iOS usa Objective-C/Swift frente al uso de código C++ en ambas. Este sistema puede servir para muchos casos, pero implica en tener que codificar en 2 plataformas distintas. Por otro lado, si se separa el diseño en un SDK en C++ que contenga la lógica, y se usa un modelo vista – controlador, delegando el aspecto y la interacción a la parte móvil, conseguimos programar la lógica solo una vez, en C++, y tener separadas las interfaces en en cada plataforma. Se puede dar una vuelta de rosca más, y usar una web o framework que genere la misma interfaz para Android e iOS, aunque por el momento no hay una herramienta lo suficientemente potente o consolidada que ofrezca unos resultados de calidad.

Este enfoque no llama nada la atención si alguna vez has utilizado QT para hacer la interfaz de tu librería, en lugar de usar directamente ventanas de OpenGL o interfaces a tu S.O de escritorio. Incluso, puede usarse QT para hacer aplicaciones Android e iOS, pero aun no veo maduro el tema. Y por supuesto este diseño sirve para estos casos tradicionales en escritorio, hay muchas formas de afrontar esta problemática, pero voy a centrarme más en el caso concreto de los sistemas móviles.

Dropbox por ejemplo, utiliza este sistema porque creen que tiene muchas ventajas, puedes leer más sobre como hacen sus diseños en esta entrada.

Diseño


El diseño separa 2 grandes partes:
  • Por un lado, a nivel de aplicación, la interfaz o capa de presentación y el front-end, encargado de la comunicación al usuario con la librería encargada de la lógica.
  • Por otro lado, a nivel de motor, el back-end que procesa la entrada desde front-end para recibir y enviar todos los datos necesarios para el correcto funcionamiento a la capa de aplicación. 

Como se puede ver en la ilustración, la App Android y la App de iOS pueden diferir en lógica y elementos. Al ser 2 S.O distintos cada uno tiene sus peculiaridades, aunque ya he dicho antes que hay frameworks que pueden facilitar este desarrollo y podría ser delegada esta tarea en ellos.

Los front-end serán las capas encargadas de “traducir” el lenguaje de aplicación al nativo. En el caso de Android consistirá en una interfaz JNI que cambie funciones y valores de Java a C++ y viceversa, haciendo un uso correcto del back-end. En el caso de iOS la interfaz será entre Objective-C/Swift y C++. Aunque tengan diferente sintaxis o diferentes patrones de diseño, es deseable que sean calcados, para tener un conocimiento homogeneo del funcionamiento para todas las plataformas.

Añadir que en la parte de front-end, además de hacer llamadas a nativo, es deseable poder recibirlas. De esta forma se pueden hacer callbacks o llamadas asíncronas que notifiquen eventos en la capa de presentación. La forma más sencilla de hacer esto es proveer al inicio de la aplicación de un puntero a función, o callback que sea llamado de forma asíncrona y la aplicación pueda procesar esas peticiones usando threads o hilos coordinados.

Habitualmente uso la siguiente terminología:
  • Front-end de Android, InterfaceFromCJNI para llamadas de C++ a Java, e InterfaceToCJNI para las llamadas de Java a C++
  • Front-end de iOS, InterfaceFromONI para llamadas de C++ a Objective-C e InterfaceToCONI para el otro sentido. Usando un singleton y delegates tan comunes en iOS, se pueden unir en una sola clase.
  • Back-end, es conjunto, en C++ y lo suelo colocar como un Facade con llamadas estáticas por su versatilidad y flexibilidad si se rediseña el SDK.
  • Core o lógica serán todas las llamadas encargadas de la gestión lógica de la aplicación deseada. Algunas directamente llamadas desde la fachada, pero no tienen porque estar todas. De esta forma puedes hacer distintas fachadas en función de las configuraciones al exterior.

Diferencias


Pros:

  • Ahorras el programar la lógica en distintos lenguajes 2 veces.
  • Más fácil reciclar el código para usar también en escritorio y otros S.O
  • Separación lógica de diferentes comportamientos.
  • Con algo de código extra puedes adaptar un mismo core para aprovecharlo en distintos proyectos.
  • Permite la gestión externa de errores mediante logs y variables.

Contras:

  • Back-end vs core puede ser redundante.
  • Toda la lógica tiene que tener un puente hasta el core, muchas veces código repetitivo.
  • No es común el perfil de programador


Logs a bajo y alto nivel

 

Aunque hoy en día cualquier programa se puede debugear con muchas herramientas, gdb, eclipse, Visual Studio, Xcode... No hay que subestimar el uso de logs estratégicamente colocados en nuestro código. Por varias razones:
  • Dan información util.
  • Ayudan a aislar errores de forma rápida.
  • Son rápidos, no necesitas parar la ejecución.
  • En Release también funcionan.
Por ejemplo, podemos conseguir que los logs de warnings comenten que esperaban algún dato o estado y que se ha seguido ejecutando a pesar de ello. Se puede informar errores producidos en la ejecución, y se puede terminar o no con ella. O simplemente se puede informar de que se pasan por diversos Checkpoints o zonas, para saber que partes se han ejecutado y que otras partes no.

Los logs toman una especial importancia en plataformas móviles, porque son más dificiles de debuguear que los ejecutables normales, cuesta más tiempo hacerlo, y a veces es un verdadero quebradero de cabeza.

Por supuesto esta información no sustituye el uso de debuggers, pero es complementaria y muy útil si son colocados de forma estratégica. Además, si usas alguna macro, se pueden mostrar o dejar de mostrar según interese con el cambio de alguna definición. Una de mis headers favoritos para logs es este.


Peculiaridades de Android

 

Android es una de las plataformas móviles más extendida actualmente. Por desgracia, el ecosistema Android cambia constantemente y las herramientas de desarrollo se han ido adaptando a lo largo del tiempo. Además, hay una gran fragmentación de dispositivos, no es algo intrínsicamente malo, pero seo hace que haya que testear muchos dispositivos diferentes y el diseño de interfaz tiene ciertas peculiaridades. Por cierto, aunque lioso al principio, una vez comprendido es fácil de usar y potente, en el caso de iOS no es así, porque al principio contaban solo con 1 tipo de dispositivo, y el número ha ido creciendo a lo largo del tiempo, y los parches para adaptarse a todos ellos con el diseño de una interfaz son un desastre.

Cosas que debes saber antes de desarrollar en Android
  • Normalmente necesitas saber Java, usar C++ es complicado y engorroso al principio.
  • Para manejar una librería C++ necesitas usar JNI, es decir, traducir llamadas y variables de java a C++
  • En Java tienes que cargar la librería dinámica (*.so) de C++, Ejemplo 
  • Para realizar llamadas de C++ a Java puedes usar un puntero a función y recoger mensajes, como podeis ver aquí.
  • El verdadero reto es crear las llamadas desde C++ usando JNI
  • Una buena estrategia puede ser usar todo librerías estáticas, y crear una librería dinámica forzando al compilador que meta todo el código para evitar problemas con factorias. Para GNU en Cmake deberías TARGET_LINK_LIBRARIES(cmakeproject -Wl,--whole-archive yourcpplibrary -Wl,--no-whole-archive)
Para sabes más sobre JNI mira la documentación oficial, o busca tutoriales.


Peculiaridades de iOS

 
iOS es otra de las plataformas más extendidas. Es más dificil publicar aplicaciones en la store que en Android, debido a sus multiples restricciones en los procesos de validación. Normalmente los dispositivos son más caros, y sus usuarios están más dispuestos a pagar. Hace unos años era más fácil hacer interfaces, porque no había variedad de tamaños, pero ultimamente han salido diversos modelos, y se han sacado de la manga los constrains y auto-layouts para lidiar con diversos dispositivos. Habiendo usado los de Android e iOS, me quedo sin duda con Android. El sistema de APPLE no está nada pulido, da muchos comportamientos imprevistos, y la teoría no se corresponde para nada con la práctica. En Android no es tan complicado.

Cosas que debes saber antes de desarrollar en iOS.
  • Objective-C es una variante de C/C++, su integración es sencilla y no necesitas un JNI.
  • El standard de ficheros de *.m, pero si lo renombras a *.mm aceptará código C.
  • Solo se puede linkar librerías estáticas, por temas de seguridad (según ellos)
  • El ejecutable final debe tener por tanto todas las librerias, y su configuración es totalmente manual.
  • Es recomensable usar variables user-defined en el proyecto, combinadas con $(SRCROOT) y paths relativos puede tener proyectos multiusuario sin tener que cambiar la configuración de forma manual entre ordenadores.
Con toda esta información espero que os podais hacer una idea de como hacer unos diseños eficientes. Para cualquier sugerencia o retoque, aportación de información y bibliografía, poneos en contacto conmigo.

viernes, 19 de febrero de 2016

Conexión SSH con vuestro NAS Synology

Introducción: 

Para realizar una conexión por SSH a vuestro NAS synology, hay una serie de aspectos que debereis tener en cuenta y que describo a continuación.

Como habilitar el servicio:

Para activar el servicio SSH solo teneis que ir a:
  • Control panel > Terminal & SNMP > Enable SSH at port 22
No te recomiendo usar telnet, ya que la conexión no está protegida como el caso de ssh.

Como utilizar servicio:

Para utilizar el servicio, teneis que conectaros obligatoriamente con el usuario admin. Este usuario tendrá la contraseña del usuario administrador del NAS. Aunque no te podrás conectar con este.

Comando
ssh admin@IPtoNAS
Ejemplo usando un DDNS habilitado
ssh admin@vgonisanz.synology.me
Alternativamente puedes usar un cliente como putty o fireSSH

¿Por que no cambiar el puerto 22 por defecto?

Muchas personas, están tentadas de cambiar el puerto por defecto para "despistar" a atacantes que llaman a ips al azar y tratan de loguearse con contraseñas por defecto. Yo lo intenté cuando el NAS me avisaba de la cantidad de IPS que bloquea que intentan entrar. ¿Es efectivo? En realidad no.

La razón es que aunque el puerto por defecto sea el 22, los atacantes probaran con varios puertos, no solo con 1. Así que aunque no todos, seguirán llegando. No se pueden abrir puertos por debajo del 1024. La razón es que estos están reservados solo a conexiones de administradores de sistemas.Es decir, usando el puerto 22, solo se podrá abrir el puerto con acceso root, si está en el puerto 9999, se podrá abrir sin serlo. En este caso, con un simple script que imite ssh escuchando el puerto 9999, se podría robar tus contraseñas.

Si quieres sabes más del tema te recomiendo consultar este post.

¿Cómo proteger para evitar ataques?

Por defecto, synology viene configurado para bloquear N intentos fallidos en un periodo de tiempo T. Lo encontraras en:
  •  Control Panel > Security > Auto-block
Además, puedes poner IPs que no se bloqueen, por si a veces olvidas la contraseña y no tienes acceso físico al NAS. Es efectiva, fácil de activar (de hecho viene por defecto), y dificilmente entrarán en el sistema con unos pocos intentos a menos que hayas puesto tu admin con un password del tipo "1234", "qwer", "password".... No deberías usar ninguna de este articulo. Puedes hacerlo de forma "casera" como recomiendo la fundación Mozilla, o puedes usar un gestor de contraseñas.
Menu de auto bloqueo

Una solución algo peor, de la que hablo en el punto anterior, es cambiar el puerto, por ejemplo, al 9999. Aunque disminuyen, porque no todos prueban varios puertos, el sistema persistirá.

Una solución más elegante, es el bloqueo de regiones. Normalmente no te vas a teletransportar, ni viajar a paises como China, o Zimbabwe. Puedes hacer reglas en el firewall de forma sencilla que permitan solo acceder de tu pais, o denegar de ciertos paises.

  • Control Panel > Security > Firewall > Create...
Ahora no se podrá acceder desde China, a menos que usen proxys
 Y bueno, la solución más compleja es utilizar Port Knocking, descrito en este tutorial. Básicamente se configuran las tablas de sistema para aceptar solo conexiones que sigan un patrón. Dista de ser un método trivial, pero si te animas a implementarlo aquí tienes un tutorial que lo explica paso a paso.

Espero que todo esto te sirva para manejar como un profesional tu NAS a distancia.

lunes, 15 de febrero de 2016

Ajustando las mirillas del CSGO

Introducción:

En este tutorial de juegos vamos a enseñaros a como personalizar a vuestro gusto las mirillas en el CSGO usando comandos de consola. Es importante tener configurada una mirilla con la que nos sintamos cómodos y nos ayude a jugar mejor. Existen varios parámetros ajustables, tamaño, grosor, estática, que varíe… ¡Comenzamos!

Creador de parámetros de mirillas ONLINE:

En esta web podrás ajustar los parámetros de tu mirilla de manera automática, y podemos ver el resultado en la pantalla. Tiene una imagen con distintos contrastes para que podamos valorar como se va a ver nuestra mirilla en zonas brillantes, oscuras, y encima de los distintos modelos de CT y T del CSGO. Es muy útil para que puedas buscar la que más se adapta a tus necesidades.
Una vez creada tu mirilla, basta con que copies el comando de la zona inferior a la derecha en la consola. Recuerda que para usar la consola tiene que activarla en las opciones, y pulsar la tecla º para mostrarla. Si no consigues verla, añade el parámetro -console a las opciones de lanzamiento del CSGO.

Ejemplos:
  • Para una mirilla únicamente un punto:
cl_crosshairsize “0”;cl_crosshairdot “1”;cl_crosshairthickness “0.7”
  • Mirilla minimalista (Tipo Half Life):
cl_crosshairalpha “209”;cl_crosshaircolor “5”;cl_crosshaircolor_b “125”;cl_crosshaircolor_r “124”;cl_crosshaircolor_g “255”;cl_crosshairdot “0”;cl_crosshairgap “-1”;cl_crosshairsize “1”;cl_crosshairstyle “4”;cl_crosshairusealpha “1”;cl_crosshairthickness “0.5”;cl_fixedcrosshairgap “-1”;cl_crosshair_outlinethickness “0”;cl_crosshair_drawoutline “0”;
  • Mirilla variable y grande:
cl_crosshairalpha “164”;cl_crosshaircolor “5”;cl_crosshaircolor_b “50”;cl_crosshaircolor_r “50”;cl_crosshaircolor_g “207”;cl_crosshairdot “1”;cl_crosshairgap “0”;cl_crosshairsize “4”;cl_crosshairstyle “3”;cl_crosshairusealpha “1”;cl_crosshairthickness “1”;cl_fixedcrosshairgap “0”;cl_crosshair_outlinethickness “0”;cl_crosshair_drawoutline “0”;
  • Mirilla alto contraste no dinámica:
cl_crosshairalpha “201”;cl_crosshaircolor “5”;cl_crosshaircolor_b “182”;cl_crosshaircolor_r “153”;cl_crosshaircolor_g “74”;cl_crosshairdot “0”;cl_crosshairgap “-2”;cl_crosshairsize “2”;cl_crosshairstyle “4”;cl_crosshairusealpha “1”;cl_crosshairthickness “0.5”;cl_fixedcrosshairgap “-2”;cl_crosshair_outlinethickness “0”;cl_crosshair_drawoutline “0”;
  • Versión dinámica:
cl_crosshairalpha “201”;cl_crosshaircolor “5”;cl_crosshaircolor_b “182”;cl_crosshaircolor_r “153”;cl_crosshaircolor_g “74”;cl_crosshairdot “1”;cl_crosshairgap “-2”;cl_crosshairsize “1”;cl_crosshairstyle “3”;cl_crosshairusealpha “1”;cl_crosshairthickness “1”;cl_fixedcrosshairgap “-2”;cl_crosshair_outlinethickness “0”;cl_crosshair_drawoutline “0”;

Y mi favorita:

cl_crosshairstyle "4";

cl_crosshairdot "0";

cl_crosshairgap "-2";

cl_crosshairsize "1.5";

cl_crosshairthickness "0.25";

cl_crosshairalpha "255";

cl_crosshairusealpha "1";

cl_crosshaircolor "5";

cl_crosshaircolor_r "255";

cl_crosshaircolor_g "255";

cl_crosshaircolor_b "255";

cl_crosshair_drawoutline "1";

cl_crosshair_outlinethickness "0.25"
Espero que les haya resultado útil este tutorial. Un saludo.

Licenciando tu código

Usar licencias en nuestro código nos ayuda en muchos aspectos. Impide que otro se apropie de tu trabajo indebidamente, y nos da crédito, de cara a buscar un trabajo o poder desarrollar un rol como diseñador/programador en el futuro. Por eso, es importante colocar en las cabeceras, que tipo de licencia rige el código fuente, para que los demás puedan utilizarlo y respetarlo al mismo tiempo (si es permisiva claro).

Hay muchos tipos de licencia, me inclino especialmente por las de código abierto, ya que respetan las 4 libertades de los usuarios definidas por Richard Stallman. Es más,la página de GNU ofrece un completo listado e información útil sobre licencias, clasificandolas compatibles, incompatibles con GPL, y licencias no libres. Si tienes dudas, mira sus recomendaciones.

Libertades del software libre
Tipos de licencia más comunes actualmente (2016):
A chart illustrating compatibility relationships between different free software licenses.  For details, see the FSF's license list page.
Evolución

 En la parte final de los enlaces, tienes un ejemplo de que lineas poner en los headers para asignar a tu código la licencia, por ejemplo, apache:

/**
* Copyright [2016] [vgoni]
*
*   Licensed under the Apache License, Version 2.0 (the "License");
*   you may not use this file except in compliance with the License.
*   You may obtain a copy of the License at
*
*         http://www.apache.org/licenses/LICENSE-2.0
*
*   Unless required by applicable law or agreed to in writing, software
*   distributed under the License is distributed on an "AS IS" BASIS,
*   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
*   See the License for the specific language governing permissions and
*   limitations under the License.
**/

Que puedo hacer y que no cuando uso software libre:

En función de tus dependencias, podrás licenciar tu código de una u otra manera, como este suele ser un tema lioso, trato de resumirlo con un sencillo ejemplo. Supongamos que crear un proyecto A, que no sabes como licenciar, y tiene una dependencia B+ΔB con otra licencia, siendo ΔB los cambios que hayas realizado en la dependencia (pueden ser nulos).

  • Si B tiene una licencia GPL, entonces A y ΔB debe ser GPL obligatoriamente.
  • Si B tiene una licencia LGPL, entonces tu A puede ser cualquier otra, incluso software privativo, y ΔB debe ser liberado como LGPL.
  • Si B tiene una licencia MIT o Apache, entonces tu A y tu ΔB puede ser cualquier otra, incluso software privativo.

Espero que todas estas indicaciones te ayuden a elegir sabiamente la licencia que más se adecue a tu código. Todas tienen pros y contras, si quieres que algo se expanda si y solo si como software libre, derivados incluidos, GPL, si quieres lo contrario, MIT/Apache, intermedio, LGPL. Elige bien pequeño padawan.