Psicofonías

(algo así como el blog de Psicobyte)

Feliz día de PI

En el momento de la publicación de este post, la fecha (en formato USA) es exactamente 3/14/15 - 9:26:53.

(3056 visitas a este artículo)

Sincronizando git sobre ssh

Es decir: Cómo trabajar en varios ordenadores con git, sin usar Github ni ningún servicio similar, usando en su lugar un servidor local y una conexión ssh.

Para este ejemplo, supondré que queremos usar un ordenador de escritorio y un portátil, pero es fácilmente extensible a cualquier número de ordenadores.

Primero vamos a crear un "repositorio central" en nuestro ordenador de escritorio. Para ello usamos la opción "--bare", que sirve para crear un repositorio sin directorio de trabajo ni archivos:

psicobyte@escritorio:~$ git init --bare proyecto.git

En un repositorio creado con la opción "--bare" no se puede trabajar, por lo que vamos a clonarlo en un proyecto con el que trabajar:

psicobyte@escritorio:~$ git clone ~/proyecto.git

Esto nos crea un directorio llamado "proyecto" con un clon del repositorio central (aún vacío). Aquí ya podemos trabajar normalmente, comitear y pushear como harías con cualquier otro. Por ejemplo:

psicobyte@escritorio:~$ cd proyecto
psicobyte@escritorio:~$ touch holamundo
psicobyte@escritorio:~$ git add holamundo
psicobyte@escritorio:~$ git commit -m "añadido archivo vacío de poca utilidad"

Como me avisa fernand0 en un twitter, al estar nuestro "repositorio central" vacío, la primera vez que hacemos push debemos hacerlo de este modo:

git push --set-upstream origin master

Esto es sólo para la primera vez, y hace que se "emparejen" las ramas master de los repositorios. En adelante se puede hacer push normalmente sin problemas.

Hasta ahora hemos trabajado en un sólo ordenador, pero queremos poder hacerlo también desde un portátil. Nada más fácil.

Para ello necesitamos tener acceso ssh al ordenador de escritorio desde el portátil, y sería una estupenda idea que el ordenador de escritorio tuviese una IP fija. si tenemos eso, sólo hay que clonarlo usando la dirección y la ruta del servidor por ssh de este modo:

En nuestro caso:

psicobyte@portatil:~$ git clone ssh://psicobyte@192.168.1.3/home/psicobyte/proyecto.git

Y ya podemos trabajar tranquilamente.

Naturalmente, usando servicios como no-ip o similares, podemos usar el servidor más allá de nuestra red local.

(3204 visitas a este artículo)

Cómo liberar software

Hace algún tiempo estaba yo soltando un rollo sobre compatibilidades entre licencias de software y alguien me dijo (más o menos): "Vale. Pero sin follones ni líos: Supongamos que yo he hecho un programa y quiero liberarlo. ¿Qué hago?".

Liberar un software puede llegar a ser tremendamente complicado e incluso, a veces, literalmente imposible. A menudo la cosa se complica por desacuerdos entre los autores, o con la empresa para la que trabajan, o líos legales con las distintas licencias que pueda tener un programa complejo...

Pero, en la mayoría de los casos, cuando dices "He hecho este programa y quiero liberarlo" es algo muy fácil, simple y rápido. De modo que, en adelante, supondremos que eres el autor del software y que no estás usando librerías ni código de otros autores.

Paso 1 Elegir Licencia:

Hay un montón de licencias libres para elegir, cada una de ellas con unas características propias. Algunas licencias son compatibles con unas pero con otras no. Si usas librerías o parte del código de otros, o si tu programa es una modificación del de otro, tendrás que usar su misma licencia o una licencia compatible con la suya. Si usas código de varias fuentes con licencias distintas, necesitarás encontrar una licencia compatible con todas ellas (y eso puede llegar a ser un lío tremendo en el mejor de los casos, o incluso imposible en el peor).

Pero sigamos suponiendo que todo el código es tuyo y no dependes de las licencias de otros. Entonces puedes elegir la licencia que quieras. Personalmente, te recomiendo que uses la licencia GPL. Es una licencia libre que permite todos los usos de tu software (incluso comerciales), permite redistribuirlo, modificarlo y crear software derivado, pero exige que todo ese software derivado se distribuya con esa misma licencia GPL. Esto es importante porque, de este modo, todas las mejoras, modificaciones o software derivado que hagan los demás de tu código también tendrán que ser libre (a esto, concretamente, es a lo que se llama "Copyleft"). Es también la licencia libre más usada y, de hecho, la que usa Linux.

Una vez elegida la licencia, tendremos que indicarla en cada uno de los archivos del código fuente. Veamos cómo.

Paso 2: Copyright.

Sólo la persona (o personas, si son varias) que tiene el copyright de un programa puede liberarlo. En principio, esa persona (o personas) es el autor (o autores) de ese programa.

Así que lo primero que tienes que poner en la cabecera de tu programa es un anota diciendo quién eres y que que tienes el Copyright, con algo parecido a esto:

Copyright 2013 Allan Psicobyte.

(si hubiera más de un autor se pondría una línea como esa por cada uno de ellos)

Después de la nota de copyright se pone un pequeño texto que indique concretamente la licencia que estamos usando. Suele haber un texto estándar para cada una de ellas, y en el caso de la GPL es este:

This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.

You should have received a copy of the GNU General Public License
along with this program. If not, see <http://www.gnu.org/licenses/>.

Paso 3: Archivo con la licencia

Además de poner el texto con copyright y licencia en cada uno de los archivos del código fuente, es conveniente acompañarlo con otro archivo que contenga el texto completo de la licencia. Por tradición, ese archivo es de texto plano y se llama README (así, en mayúsculas y sin extensión) o, mejor, LICENSE. El texto de la licencia, en el caso de ola GPL, se puede copiar de la versión que hay en la página del proyecto GNU (tal cual, sin modificar nada).

Paso 4: Publicar el código:

Lo siguiente es poner todo esto en algún lugar público al que se pueda acceder. Lo puedes poner para descargar como un archivo comprimido en tu página personal, usar tu propio servidor FTP o el método que prefieras pero, lo más recomendable con diferencia, es usar alguno de los muchos repositorios de Software Libre o forjas que existen. Estos sitios te permiten fundir el proceso de desarrollo, producción y distribución en uno sólo, y suelen estar dotados de herramientas muy útiles.

Hay muchos diferentes y, dependiendo del sistema de control de versiones que uses (y, si no usas ninguno, deberías hacerlo), preferirás uno u otro. Sourceforge, por ejemplo, es un clásico que usa subversion, aunque últimamente el que está pegando fuerte es github, que usa git y tiene un montón de herramientas de tipo "red social" que sirven de mucha ayuda.

Además, siempre que distribuyas el programa deberá ir acompañado del código fuente o, en su defecto, de un enlace o texto indicado cómo conseguirlo.

Por último, dependiendo de cómo sea tu programa, es una buena idea incluir algún aviso sobre la licencia en la documentación, la ayuda (el clásico "Acerca de..."), el manual, etc.

Y con esto, ya eres un programador de Software Libre. Enhorabuena.

(Publico este texto simultáneamente en mi blog y en el de la Oficina de Software Libre de la Universidad de Granada)

(23347 visitas a este artículo)

Bug en Youtube

(Seguro que este nuevo bug de Youtube ya lo conoce todo el mundo, pero yo me he dado cuenta mientras les enseñaba un poquito de HTML a los niños del Campus Infantil de Software Libre).

Al usar el enlace "insertar", que permite copiar un trozo de código (un iframe) para poner el vídeo en tu propia página web, a la URL que contiene ese código le falta el protocolo (el http:), lo que hace que falle estrepitosamente y el vídeo insertado no se vea.

Por ejemplo, donde pone
src="//www.youtube.com/embed/P4r_jICx4lU"

debería poner
src="http://www.youtube.com/embed/P4r_jICx4lU"

Agregándole ese "http:" ya funciona perfectamente.

NOTA: Me cuenta Penyaskito en el facebook que "No es un bug en absoluto, todo lo contrario."//" permite incrustar los contenidos con el mismo protocolo que esté usando la página "padre" (http o https). Esto evita las típicas alertas de "contenido no seguro", y las nuevas versiones de los navegadores son bastante estrictas con eso, por lo que el video no se vería si la página está sobre https si lo incluyes con http. Es recomendable hacer lo mismo con el resto de recursos (css y js) que incluyes en tus páginas."

(7883 visitas a este artículo)

Censuras, re-censuras, y autores

Cuando un fotógrafo hace una foto, se curra (entre otras cosas) un encuadre en el momento de tomarla y, si le hace falta, lo ajusta luego en el laboratorio o el ordenador.

Y está muy feo enmendarle el trabajo.

Además, cuando enlazas una foto (por la razón que sea) es conveniente en lo posible enlazar a la galería original del autor, que para eso el mérito es suyo.

Estos días corre por facebook esta imagen, supuestamente censurada por esta red social:

Foto de Styush recortada

La foto que, supuestamente, facebook ha censurado (y que, pese a ello, no hace más que aparecer por facebook) está recortada de un modo que hace sospechar que ya ha sufrido de algo muy parecido a esa censura pacata que, se supone, se pretende denunciar.

Lo triste es que la versión recortada se ha hecho tan popular que ya es más fácil de encontrar que la original, con lo que estás fastidiando doblemente al autor: Primero por quitarle el mérito al no referenciarlo, y segundo por mutilar su foto sin advertirlo, traicionando su intención estética original.

Aquí te dejo esa foto supuestamente censurada por facebook, sin recortar y en su propia galería. Sin caer en lo mismo que pretenden denunciar y respetando al autor:

Foto de Styush recortada

Que a lo mejor me equivoco, porque está en ruso, pero intentarlo y buscar un poquito no es tan difícil, coño.

(7402 visitas a este artículo)
Posts Posteriores (2/42) Posts Anteriores
PCMS 2004