Librebits - jordila_@i-ching:~/

Bits aleatorios de Software Libre / Libre Software ...

miNube Con OwnCloud : Bye,bye Dropbox !

En una anterior nota técnica en este blog hablábamos de La fanfarria del Cloud Computing o la última trending technology … Convengamos que ese mismo concepto que criticamos constructivamente ha facilitado una mejor conviencia entre dispositivos computacionales de diferente naturaleza ( PC, Tablet, teléfono smartphone , etc… )

El objetivo de este artículo es, desde lo paráctico, desmitificar la idea de la nube como algo etéreo e inasible . Bajándolo a la tierra. Veremos lo sencillo que resulta liberarnos de servicios que pueden atentar contra la seguridad y privacidad de nuestros datos, como es el caso de Dropbox , el servicio de computación cloud más popular.

Como reza Wikipedia OwnCloud es una aplicación de software libre del tipo Servicio de alojamiento de archivos, que permite el almacenamiento en línea y aplicaciones en línea (cloud computing)

Vayamos con las manos a la masa, y tratemos de instalar nuestra nube en nuestro propio servidor Debian GNU / Linux :

1
2
3
4

# Descargamos primero la llave asociada al software  ownCloud :

wget http://download.opensuse.org/repositories/isv:ownCloud:community/Debian_7.0/Release.key

(NOTA: Interesante sinergia acá, entre openSuse y Debian, en este caso… en la familia Linux )

1
2
3
4
5
6
7
# Agregamos la llave a apt para que pueda validar los ficheros :
sudo apt-key add - < Release.key


# añadimos los  repositorios ownCloud al servicio de builds de openSUSE  a nuestro apt _source lists_ al teclear :

echo 'deb http://download.opensuse.org/repositories/isv:ownCloud:community/Debian_7.0/ /' | sudo tee -a /etc/apt/sources.list.d/owncloud.list
1
2
3
# Finalmente, actualizamos la base de datos de paquetes e instalamos ownCloud y MySQL:
sudo apt-get update
sudo apt-get install owncloud mysql-server

Configuración MySQL

Vamos a configurar nuestro servidor ownCloud para que disfrute de una base de datos MySQL más robusta, en vez de la implementación SQLite por defecto. Para ello debemos configurar MySQL en primera instancia.

Teclear los siguientes comando para inicializar la base de datos y hacer más seguro el sistema:

1
2
sudo mysql_install_db
sudo mysql_secure_installation

Deberás introducir la clave de administración seleccionada durante la instalación de MySQL. Entonces se te preguntará por los ajustes de seguridad. Presiona Enter y selecciona yes para todos los parámetros excepto el primero (relativo a cambiar de nuevo la contraseña root)

Ahora, identificate en MySQL como usuario root tecleando:

1
mysql -u root -p

De nuevo, serás preguntado por la contraseña de administración MySQL.

Crea una base de datos mediante el comando :

1
CREATE DATABASE owncloud;

Crea y asigna privilegios al nuevo usuario MySQL para manejar la base de datos de operaciones de ownCloud:

1
GRANT ALL ON owncloud.* to 'owncloud'@'localhost' IDENTIFIED BY 'select_database_password';

Salir de MySQL tecleando:

1
exit

Sólo queda proceder a la instalación guiada, accediendo a la carpeta ( DocumentRoot ) que alberga tu nube ownCloud

Que lo disfrutes libremente y sin chusmeos.

Recursos :

Bonus:

No nos queda más que instalar certificados SSL (si no lo habíamos hecho ya) que nos faciliten un diálogo seguro con nuestro servidor OwnCloud, mediante https … pero eso ya será probablemente motivo de otro post / nota técnica en este mismo blog.

En Un Principio Fue La Linea De comandos-…GNU/Linux-Bash

Estos días he aprovechado cierto receso para enriquecer mi relación con mi sistema GNU / Linux . Esto es, hablarle, preguntarle… más y hacer menos click . Buscando una comunicación más fluida y harmoniosa.

Este proceso de enriquecimiento de la interacción se produce tras la inspiradora lectura de “En un principio fue la línea de comandos”

Nos da la clave de como algunos sistemas operativos (privativos, principalmente) nos han querido hacer creer que la terminal o línea de comando ( CLI ) era un vestigio del pasado. Con atractivos ( o no tanto) interfaces gráficos, bajo ese prisma, se quiere ocultar lo innegable: los sistemas computacionales son complejos. Como dice Eben Moglen,en cierto modo , el abuso del uso del ratón ( mouse ) deriva en una espasmódica relación del usuario con el sistema. A golpe de ratón . La interacción está, en ese caso, mediada por una capa de abstracción que no es posible más que mediante la asunción ( imposición? ) de ciertos valores y parámetros por defecto. El diseñador de la interfaz gráfica (GUI) ha tenido que, necesariamente, simplificar y realizar bastantes suposiciones para asumir valores por defecto .

Al dejar de controlar esos detalles en pro de la simplicidad, de “hacernos la vida más fácil” como usuarios, estamos renunciando no sólo a todo el potencial de nuestro (?) sistema, sino también a la posibilidad de una interacción libre de intermediarios.

Cuando era adolescente y cayó en mis manos el primer teclado Unix no en entendía nada, sentí temor… quería salir corriendo a por mi ratón! j,aj! Éste ha sido un hermoso proceso,… de reencuentro y reconciliación. a hablarle a mi computadora GNU / Linux… Pasé de hablarle con gruñidos a base de click, a susurrarle en la línea de comandos (Bash). Sintiendo el latido y el repiqueteo de las teclas…

Se encuentra fácilmente en la red de redes, LinuxCommand-TLCL.pdf, muy inspirador, ya en lo práctico, en este sentido. Estoy leyendo y practicando con él. Bienvenidos al apasionante mundo del GNU / Linux Bash Shell .

BONUS : por ejemplo, acabo de aprender como navegar más fácilmente entre directorios desde la línea de comandos,

Teclear toda la ruta del directorio con cd consume tiempo. Puedes simplemente usar pushd o popd para commutar hacia y desde dos directorios. Cuando estás en en un cierto directorio y deseas commutar a otro directorio, en vez de cd usa pushd

1
$ pushd /path/to/new/directory

Usando este comando, la ruta del directorio original será recordada para usar de vuelta mediante popd .Al acabar de trabajar en el nuevo directorio, para volver al directorio original, simplemente teclea :

1
$ popd

Fuente: http://www.linuxandlife.com/2013/04/some-tips-to-use-command-line-faster.html

Bonus :

Mejor no hacer como yo … no esperar a la edad adulta computacional para aprender a manejarse en la línea de comandos, ja,ja! Aquí tienen un par de pdfs de intro y con los motivos por los que es buena cosa aprender a manejarse en las “pantallas negras” de buen principio

001-Intro.pdf

002-Motivos.pdf

Cortesía de Elbinario.net

A Vueltas Con LinuX Containers (LXC) II

1
2
"Los servidores lo tuvieron todo. Los clientes, nada. Bienvenido al Cloud Computing"
(Eben Moglen , Free Software Foundation)

Lo prometido es deuda … reza el dicho popular.

En un post anterior nos zambullimos en la tecnología de virtualización ( subyacente a la trendy y cacareada Cloud ) En otras palabras, la Internet de siempre con una capa de abstracción de hardware : LinuX Containers LXC .

La fanfarria del Cloud Computing o la última trending technology

Con ese mero argumento, una vez más las grandes corporaciones (que conozco por experiencia) del sector infocomunicacional venden servicios que realmente los clientes no necesitan. Les encadenan a sus servidores, que se acumulan en campos de concentración de hardware, ventilados, aislados y con las máximas medidas de seguridad. Es la economía de escala … la misma que está agotando al Planeta que habitamos.

En Canadá algunas empresas se jactan de mantener esas granjas de servidores virtualizados de forma sostenible y limpia (!). Sin derroche de energía (que consumen cientos o miles de procesadores corriendo en paralelo). Aprovechan, dicen, las corrientes de aire frío (ártico). En fin.

(pseudo)Virtualizando Debian en un Debian GNU/Linux (host)

Disquisiciones aparte. Tratemos de crear un contenedor Debian albergado en nuestro Debian GNU/Linux (host del contenedor), o computadora-laptop de trabajo.

Por no repetir lo que viene detallado en los tutoriales referenciados, solo diré que he encontrado problemas con LXC en mi Debian GNU/Linux Jessie , siguiendo los pasos de la Wiki de Debian.

Problemas que también encontró el autor de LXC setup on Debian Jessie, gracias al cual pude por fin cumplir mi promesa de hacer correr mis máquinas (pseudo)virtuales no sólo en Ubuntu , sino también en mi Debian GNU/Linux(a continuación me fijaré en la parte que más útil me fue). A él mi agradecimiento.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
// Crear un  contenedor Debian (en /var/lib/lxc/) es simple:

# sudo MIRROR=http://http.debian.net/debian lxc-create -n sid64 -t debian -- -r sid -a amd64

// Inicia o para el contenedor de la siguiente forma :

# sudo lxc-start -n sid64 -d

# sudo lxc-stop -n sid64

// Puedes encontrar la dirección IP asignada al contenedor, recibida por el Servidor  DHCP tecleando, y su estado 

# sudo lxc-ls --fancy

..

A partir de aquí podemos seguir manejando nuestros LinuX Containers, como veníamos haciendo en el anterior post relacionado

Docker ? “It’s LinuX Containers , stupid !”

En lo práctico, pongamos que para desarrollar una aplicación web determinada necesitamos un stack de software (p.ej.: el clásico Linux+Apache+MySQL – LAMP) en unas versiones determinadas, por requisitos del entorno (p.ej.: PHP 5.3 y MySQL 5.1 ). Y sólo puede ser de este modo. En vez de tener que rehacer todo el stack de nuestro servidor de pruebas nos bastará con generar un LinuX Container que cumpla esos requisitos. El único condicionante es la base del stack. Está sujeta al kernel del sistema host (en mi caso, el de Debian 8 GNU/Linux ) Además, podré desarrollar cómodamente de forma ágile (ligera e iterativa), pues puedo usar para ello el comando lxc-clone para armar tantas maquetas o prototipos como requiera. Por ejemplo,

  • container LXCO = Debian GNU/Linux server

  • container LXC1 = Debian GNU/Linux server + AMP

(que podré clonar para otras aplicaciones que necesiten el mismo stack , p,ej. el LMS Moodle , Drupal CMS …)

  • container LXC2= LAMP + CMS Drupal

  • etc … (así sucesivamente)

BONUS : De paso he podido hacer una primera prueba satisfactoria con Docker , que me permitiría importar y exportar fácilmente aplicaciones a partir de un LinuX Container y bla,bla… pero de eso quizás hablemos en otro nota de este blog más adelante…

Openshift PaaS, Drupal CMS Y Git

Vamos a bucear un poco más en la PaaS de Red Hat Cloud (RHC).Openshift, El ‘Cloud’ libre para todos y todas (?).

Para ello hemos de cicunscribirnos a los parámetros del entorno que nos ofrece actualmente, a efectos de versionado, etc… Para lo que nos ocupa, una típica instalación LAMP (Linux+Apache+MySQL+Php) como es Drupal CMS, esto es :

1
2
Php v.5.4
MySQL v.5.5 ...

que es lo que RHC nos ofrece al momento de escribir estas palabras. Recordar que podemos disfrutar de tres instancias libre y gratuitas en nuestra cuenta Openshift . Sí, para siempre.

Vamos seguido el paso a paso de creación de la cuenta (remota) en el servidor RHC y la instalación de la herramienta (CLI) cliente rhc en local (bien detallado en el tutoria oficial).

Sigamos ahora los pasos del Drupal Quickstart para RHC oficial … A ver si somos capaces de encajar las piezas del puzzle.

[..]

Sea como fuere, cómodamente desde el panel de control de Openshift(RHCloud) , o mediante nuestro nuevo flamante CLI rhc en Bash

1
2
//  Drupal-quickstart  - CLI rhc
# rhc app create drupal php-5.4 mysql-5.5 cron

Nos permite disponer de un completo entorno de desarrollo ( soporta Git por defecto) de forma rápida y sencilla. En mi caso por ejemplo, armé rápidamente una instancia de Drupal8 para ir ‘jugando’ … en cuestión de minutos.

KISS – Keep it Simple Stupid

Bonus : Cómodamente también puedes ‘mapear’ de forma remota la carpeta con el código de tu desarrollo… gracias a sFTP, directamente en tu Navegador de archivos preferido ( Nautilus, Thunar…)

RECURSOS:

“Openshift and Drupal story true open-source collaboration and innovation”

“Drupal 7 | Openshift ”

“Drupal-quickstart | Github ”

Multiplica Las Posibilidades De Drupal CMS : Proyectos Sandbox (Ej.: ‘Bootstrap Everywhere’

Intro

Lo maravilloso de la mundial y activa comunidad Drupal son cosas como las que siguen…

Estamos iniciando un proyecto Drupal7 en el que Bootstrap theme puede servirnos Hay otros temas más propios de Drupal como Omega , Zen , etc… que bien podrían servirnos.

Lo interesante de Bootstrap en este caso es, entre otras cosas, que lo hemos manejado en el equipo en otros contextos, y facilita un lenguaje común para las tareas de Theming .

En las que, desde el principio, queremos que nuestro Tema elegido mantenga compatibilidad con módulos Panels y Panel Everywhere .

Pero… ay! Parece que Bootstrap no la ofrece.

Acudimos entonces a la contribución de mpv , que elaboró una Sandbox para solventar precisamente esta cuestión : Bootstrap Everywhere

(un proyecto Sandbox no es más que código Drupal alternativo, que no ha sido empaquetado en un módulo como tal )

Veamos si somos capaces de encajar la piezas del puzzle

Dev

Drupal 7 Bootstrap Everyhwere sandbox](https://www.drupal.org/project/1719916)

by mpv

0.– En nuestro caso, los pre-requisitos son disponer de Bootstrap 2 theme,(ojo, no la v3!) instalado previemente, que es con el cual el proyecto Sandbox _Bootstrap es compatible.

1.– Así pues Bootstrap theme ( las versiones se alinean con las del popular framework , ej.: 7.x-2.2 <—> Bootstrap 2.3.2 ) (activamos —> default theme , o creamos un sub-theme)

2.– habilitamos los módulos Panels y Panels Everywhere cómodamente via ‘drush dl ’ y ‘drush en

// así tenemos un sitio ‘operativo’ con contenido aleatorio para test, previamente instalado el módulo devel 3.– drush devel generate 20

3.– seguimos las indicaciones de mpv para instalar, como un tema más,Bootstrap Everywhere básicamente el comando ‘git clone <…>’

Epílogo

El extenso y rico ecosistema de software y módulos de Drupal CMS se ve multiplicado por los proyectos Sandbox . De esta forma, el Content Management Systema se construye por capas :

1.– core – núcleo ( Do no hack the core! ) 2.– contrib modules ( los más populares, como Views acaban integrándose en el core ) 3.– proyectos Sandbox , ‘no modularizados’… que acaban multiplicando las posibilidades

Gracias mpv

Aprendizajes De Una Actualización Remota De Sistema Fallida: ‘Screen’

Estamos conectados al servidor remoto en producción por sesión SSH .

Decidimos que es hora de actualizar los paquetes de nuestro sistema servidor ( Debian GNU / Linux ) en el que alojamos los flamantes últimos desarrollos web de nuestros clientes para disfrute del gran público internauta.

1
2
//secuencia actualización de repositorios fuente y paquetes
# apt-get update && upgrade

El sensible proceso en lote se inicia normalmente…

CRASH! Ocurre… Broken pipe , por el motivo que fuera perdimos la conexión remota en el peor momento.

Tardamos un tiempo en recuperar la conexión SSH , lo que hace que se vea afectado el proceso en el momento de la interacción: que nos solicitaba si queríamos mantener no determinados archivos de configuración del sistema servidor Web LAMP , justo en el momento del CRASH! .

En la reconexión algo ,se ve enseguida, no anduvo . Chequeamos la disponibilidad de los servicios web alojados: NOT FOUND . Desastre confirmado. En un primer diagnóstico quedaron afectados (desconfigurados) los paquetes MySQLServer … bla,bla.

Inspiramos.Expiramos.

Acudimos a la comunidad, como no… via IRC. En #Debian lo primero que nos sugieren es que deberíamos usar siempre la utilidad screen para este tipo de operaciones ( apt-get upgrade ) críticas.

Lección aprendida.

A Vueltas Con LinuX Containers ( LXC ) I

Tras unos días de vacaciones hemos vuelto a los teclados cono energías y fuerzas renovadas.

Esta vez vamos a emprender el viaje a la virtualización de entornos. Hasta ahora nuestra experiencia se reducía a algunos contactos con VirtualBox. Así lograbas una completa máquina virtual en la que correr otros sistemas operativos y/o entornos, que podrían ser diferentes al tuyo (Host).

La experiencia fue agridulce, pues si bien es un adelanto poder disponer de ‘entornos virtuales’ en tu computadora, se hacía bastante pesado, el proceso de creación de la máquina virtual (consumiendo muchos recursos), por no hablar del proceso de exportar luego el trabajo realizado en ello.

Últimamente se habla mucho en la red de redes de Docker, que como reza la entrada correspondiente en Wikipedia es un proyecto de código abierto que automatiza el despliegue de aplicaciones dentro de contenedores software, proveyendo de una capa adicional de abstracción y automatización de virtualización del sistema operativo en Linux

Mmh… what? Pues que ahora podemos fácilmente empaquetar en contenedores nuestros entornos de desarrollo (virtualizados) e intercambiarlos sencillamente como cromos entre servidor-PC- portátil etc, crearlos, clonarlos, destruirlos con una línea de comando… ? Veamos…

El caso es que Docker basa su potencia en LXC :LinuX Containers. Así que … principiemos por el principio.

Mi agradable sorpresa ha sido el comprobar como sencillamente puedo crear una máquina (pseudo) virtual , con unos pocos comandos, en mi computadora. Esa (pseudo) máquina hábilmente, gracias a LXC reutiliza el mismo Kernel de la máquina que la alberga (Host). Ecología de recursos. De ahí lo de pseudo .

El caso es que uno de los pocos contras del proceso con LXC es que el nuevo sistema (pseudo) virtualizado (obviamente) debe basarse en el mismo Kernel de la máquina Host.

El primero que me habó de LXC fue mi amigo hk … compartiendo conmigo el concepto de como uno puede usar esta técnica para correr diferentes servicios interconectados entre sí via IP (paralelamente en el mismo Host).

Seguiré los pasos de Stéphane Graber para, este vez desde Ubuntu 14.04 (el hijo díscolo ) en vez de Debian Jessie (su padre), por comodidad.

En un alarde de originalidad, copio y pego los comandos, y los adapto a mi gusto, traduciendo los comentarios que clarifican los pasos a dar .

Inspiramos.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
# Crear "p1" : container usando el template "ubuntu" y la version de Ubuntu
# and architecture as the Host (mi compu _real- ). Con "-- --help" listamos todas las opciones all available options.

$ sudo lxc-create -t ubuntu -n p1

# Iniciar el container (en background)
$ sudo lxc-start -n p1 -d

# Entrar al container en una de los siguientes formas

##  'Attach' a la consola del container' (ctrl-a + q para detach)
$ sudo lxc-console -n p1

## Bash directamente en el container (cortocircuitando el login de consola), requiere >= 3.8 kernel
$ sudo lxc-attach -n p1

## via SSH
$ sudo lxc-info -n p1
$ ssh ubuntu@<ip según lxc-info>

# Stop container, de una de las siguientes formas
## Stop desde él mismo
$ sudo poweroff

## Stop limpiamente desde 'fuera'
$ sudo lxc-stop -n p1

## Kill desde 'fuera'
$ sudo lxc-stop -n p1 -k

Bien.. Expiramos. Ya armamos nuestro primer, simple y ligero contenedor Linux – LXC .

Como dice Stéphane, “habrás notado que habiualmente todo funciona tal cual en Ubuntu (en Debian GNU/Linux hay que usar algunos comandos más… parece, para los cgroups y la parte de red… )” “los kernels Ubuntu soportan todas las facilidades que requiere LXC , y los paquetes configuran un bridge y servidor DHCP que los containers usan por defecto” … Todo ello, obvio, configurable y bla,bla…

Parece que trabaja en Canonical… ;–) (más adelante trataremos de repetir el proceso en Debian GNU / Linux (!), pero eso será en otro post … )

Vayamos por segundo container que albergue querido Debian. Básicamente lo que haremos será usar otro template de container. Es decir :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
## creamos el container debian, forzando la arquitectura 
$ sudo lxc-create -t debian -n p2 -- -a i386

## iniciamos el container debian 32bits
$ sudo lxc-start -n p2 -d

## lo chequeamos,

$ sudo lxc-info -n p2
Name:           p2
State:          RUNNING
PID:            5828
IP:             10.0.3.118
CPU use:        1.88 seconds
BlkIO use:      49.66 MiB
Memory use:     85.56 MiB
KMem use:       0 bytes
Link:           vethV01VLC
 TX bytes:      1.79 KiB
 RX bytes:      5.69 KiB
 Total bytes:   7.48 KiB

## notar que, para acceder a él si es necesario por esta via, obtenemos su dirección IP

NOTA: los diferentes containers , dijimos, tendrán siempre de base el mismo Kernel, que comparte con el Host que los alberga. En nuestro caso

1
2
3
## Verificamos el sistema y Kernel del Host (común a los containers)
$ uname --all
Linux RainbowWarrior 3.13.0-37-generic #64 [...]

Bla,bla … para mi uso y propósito personal, instalaré la pila – stack LAMP (Linux+Apache+MySQL+Php). Voilà. Ya tengo mi servidor Web personal de bolsillo ultraligero…

NOTA2: en línea lo siguiente más simple probablemente sea la Raspberry Pi con Raspbian ;–)

Es por ello que nos viene como un guante el siguiente comando para procesar un clon.

1
2
3
4
5
6
7
8
## pre-condición al clonar : el _container_ a clonar deber estar en stop
$ sudo lxc-stop -n p2

## clonamos 'p2' , nuestro 2º container Debian mínimo con LAMP
$ sudo lxc-clone -o <container original: 'p2'> -n <nombre del nuevo container>

## en nuestro caso, parametrizando lo anterior ..., y lo llamamos lamp1
$ sudo lxc-clone -o p2 -n lamp2

A estas alturas del partido… tenemos 3 instancias LXC en juego

1.– p1 : Ubuntu clon del sistema Host común

2.– p2 : Debian GNU/Linux

3.– lamp2 : Debian GNU/Linux + LAMPhp + phpMyAdmin …

1
2
##podemos comprobar el estado operativo de cada container LXC
$ lxc-ls --fancy

… al que, por ejemplo, puedo acceder en

1
http://10.0.3.85/phpmyadmin/

Voilà.

:–)

BONUS : LXC Web Panel para Ubuntu desde el que poder cómodamente gestionar todos los containers LXC …

¿Un Buscador Para Mi Sitio Web (Estático)?

Cuando inicié mi último proyecto me decanté por el reto de desarrollar un sitio Web estático para un fondo audivisual de 20 videos y 400 bellas imágenes de la Patagonia. Sopesé los pros y contras, frente alternativas CMS como Drupal. De hecho estuve varios meses desarrollando maquetas en ese completo CMS. Completo y complejo. Con el tiempo y el conocimiento de los últimos avances en HTML5 y CSS3… decidí apostar por la filosofía no-CMS. ‘Delegando’ en servicios Web o pre-desarrollo en mi sistema GNU/Linux las capacidades que mi ‘CMS no-CMS’ iba a echar en falta.

En (casi) todos los aspectos, el desarrollo salió ganando… El Video y la imagen se manejan con gran sencillez en HTML5 . Puedes armar tu ‘YouTuVe’ y Flickr con facilidad. Una hermosa galería / carousel por acá… y Voilà!

Obviamente la contrapartida es el procesado, indexado de las imágenes etc… Nada que un script GNU/Linux y alguna buena librería como FFMPEG no pueda solventar.

Reconozco que no evalué bien el aspecto del buscador de contenidos propio del sitio. Obviamente el sitio web estático no puede beneficiarse de la potencia (a cambio de mayor complejidad) de una base de datos que indexe el contenido a medida que se sube

Llegados a ese punto, la primera y poco elaborada alternativa es usar, como decíamos servicios de terceros.

Google Custom Search … desde luego es el mejor buscador. Si bien, como es sabido en la era “Post Snowden”, poco o nada respetuoso con la privacidad. Ofrecen un servicio en el que (a partir de ) 100 U$S retiran la insidiosa publicidad de los resultados de búsqueda. Pasemos página

El buscador DuckDuckGo ofrece acá la alternativa en el sentido de la privacidad. Principalmeente, por lo que entiendo, se nutre de resultados de búsqueda de Bing y Yahoo! principalmente … ‘anonimizando’ la búsqeda. Tras algunas pruebas, resulta muy sencillo re-utilizar este simpático buscador. Pero los resultados no son los esperados… ( en su #IRC me dicen que es cuestión de ‘moverse’ por las diferentes redes sociales.. para que así los mencionados motores de búsqueda acaben ‘encontrándonos’).

Así pues, si no queremos depender tanto de terceros… tendremos que ser más imaginativos…

Buscando, buscando… por los caminos del software-libre encontré TipueSearch … ¿será lo que necesitamos?

Drupal : Harmonizando Los Módulos Panels

Iniciamos un nuevo proyecto Web.

En este caso nos decantamos por Drupal, dado que el cliente debe ser capaz de autogestionar la edición de contenidos del sitio con cierta facilidad. Convengamos que en un escenario así, Drupal sobresale por su interfaz. Ello nos facilita la decisión estratégica en este caso, por encima de otras consideraciones, como la ligereza y agilidad de las herramientas de desarrollo escogidas.

Bien, adelante con Drupal CMS. Y en que entorno… Surje la propuesta de usar Bootstrap, en cuanto al theming (diseño)…por aquello de trabajar en un lugar común en el equipo. Usaremos también los módulos Drupal Panels y PanelEverywhere . No tengo experiencia en ellos… así que me despierta la curiosidad su funcionamiento. Parece que facilitan enormemente el maquetado web, y de forma muy visual.

Mmh… y como se cocina todo esto en su conjunto ?

La apasionada comunidad drupal (una vez más) acude a nustro rescate. Los compañeros de Gcoop parece que han trabajado este tema precisamente, a fondo. Creándose su propio Bootstrap-Panels-Everywhere…

En chat reciente me cuentan que siguen usándolo casi un año después… Desde nuesra ignorancia, como novatos que somos, veamos pues si logramos que nos sea de utilidad a nosotros también. Tendremos que poner todo nuestro empeño.

Gh-pages : Publicar Sencillamente Muestras De Tu Proyecto

En muchas ocasiones simplemente requieres de una forma sencilla de publicar muestras de un proyecto web ágilmente. O quizás publicar información relativa al mismo (con una demo), o documentación… Conectarse al servidor en el que publicas los trabajos acabados , crear el servidor virtual Apache (Vhost), reiniciarlo….bla,bla. Tedioso.

Para ese viaje no nos hacían falta esas alforjas, Sancho… (diría Don Quijote)

Si usas repositorios de desarrollo web en Github.com, hay una alternativa muy cómoda, una vez uno se ha acostumbrado a trabajar con el flujo git (ver posts anteriores).

La esencia del funcionamiento de gh-pages está en definir una rama (branch) que alojará aquello que queramos publicar asociado al proyecto. Cuando hagamos el

1
$ git push origin gh-pages

correspondiente, Github se encargará de publicarlo, relacionándolo a nuestra cuenta personal(o de organización) en diferentes posibilidades según elijamos en cuanto al nombre de dominio (DNS). Inmediatamente podemos mostrar el resultado al mundo desde él.

No voy a entrar en el detalle operativo, en el mismo Github se ofrece un tutorial y documentación muy ilustrativo de como proceder, paso a paso, acá

Como dicen, simplemente edita, push y tus cambios ya son públicos en Internet.

Oli nos cuenta como adaptar el flujo de trabajo de ambas ramas master y gh-pages de forma síncrona.

Actualmente, por ejemplo, estoy trabajando acá :

https://github.com/jordila/CSS3-Accordion

Aunque probablemente, si transcurre mucho tiempo desde el día de hoy, ese proyecto haya mutado… Así que prueba a ver este,

http://rendro.github.io/CSS3-Accordion

Que es el original, del cual hice el fork . O este otro.

https://blueimp.github.io/Gallery/

De hecho ese mismo mecanismo es en el que se basa la publicación de este Blog que estás leyendo. Uso Octopress. Basado en la tecnología de publicación Jekyll. La misma que usa el propio Github.com para sus páginas.

Bonus : para asociar documentación a un proyecto, recomiendo el uso de la wiki que nos ofrece Github.com. De forma muy cómoda y sencilla podemos ir desarrollándola, también mediante un flujo de trabajo git en formato markdown . El repositorio wiki del proyecto convivirá en paralelo con nuestro código. Siendo ambos distinguibles así, a la hora de clonarlos en tu compu localmente :

1
2
3
4
5
6
7
8
git clone https://github.com/TU_USUARIO/TU_REPOSITORIO.wiki.git    

# clona tu wiki localmente


git clone https://github.com/TU_USUARIO/TU_REPOSITORIO

# clona tu repositorio localmente