Archivo de la categoría: Software Libre

Emular terminal desde PHP en Servidores Virtuales Gestionados (caso de Comvive)

Desde que trabajo en Pórtico Legal quería empezar a usar el sistema de control de versiones (yo siempre lo uso y aquí no tenían nada, una locura) y poder usarlo para los despliegues en preproducción y producción como solución intermedia hasta que tengamos algo más avanzado. Hasta la fecha se estaban haciendo mediante ftp con todos los problemas que eso supone, entre ellos los siguientes y sus posibles soluciones:

  • Mientras se ha subido un archivo y se está subiendo otro que depende de este la web se puede romper, lo más probable es que ocurra. Esto no se solventa completamente usando git sobre un único servidor pero se minimiza muchísimo.
  • Nunca se sabe que versión está en producción. En algunos momento se habían subido archivos por diferentes personas y una no sabía lo que había subido la otra.
  • Si se toca algo en el servidor un simple “git status” te lo va a chivar, y un simple “git checkout …” te va a solucionar la papeleta.
  • Se va a poder desplegar nuevas versiones simplemente etiquetando y haciendo un “git checkout tag

 

Aquí el problema venía por parte del hosting de comvive que al ser un VPS gestionado no te dan cuenta de shell. Para solucionarlo al final utilicé un pequeño script php que ejecutaba la orden que le pasas como parámetro:

<?php

$command = $_GET[“command”];

$res = execute($command, __DIR__ . ‘/..’);
echo “<pre>”;
echo “\nCódigo de salida: ” . $res[‘code’];
echo “\n” . $res[‘out’];
echo “\nSalida de error:\n” . $res[‘err’];
echo “</pre>”;

function execute($cmd, $workdir = null) {
if (is_null($workdir)) {
$workdir = __DIR__;
}

$descriptorspec = array(
0 => array(“pipe”, “r”), // stdin
1 => array(“pipe”, “w”), // stdout
2 => array(“pipe”, “w”), // stderr
);

$process = proc_open($cmd, $descriptorspec, $pipes, $workdir, null);

$stdout = stream_get_contents($pipes[1]);
fclose($pipes[1]);

$stderr = stream_get_contents($pipes[2]);
fclose($pipes[2]);

return [
‘code’ => proc_close($process),
‘out’ => trim($stdout),
‘err’ => trim($stderr),
];
}

 

La etiqueta pre la utilizo para que la salida se vea bien si la llamamos desde un navegador. Pues bien, una vez subido podemos ejecutar cualquier orden como:

https://dominio/path/script.php?command=orden

Pero como estarás pensando esto no es seguro. Lo que hice yo es meterlo en un directorio y en este meter un .htaccess para que sólo yo tuviera acceso.

Al final lo único que quería era poder usar git, así que me creé un shell script con wget para llamar a esta url. El script es tal que así:

#!/bin/bash

domain=””

command=”wget -qO – \”http://$domain/commands/command.php?command=git $*\” | sed ‘1d’ | sed ‘\$d'”
echo “Dominio: $domain”
echo “Parámetros: $*”
eval $command

 

Ahora sólo hay que darle permisos de escritura y en mi caso lo he llamado rgit y lo he puesto en el path por comodidad. Esta sería una salida de la orden “rgit status -s“, en este caso un status limpio:

Dominio: www.dominio.com
Parámetros: status -s
Código de salida: 0
Salida de error:

Lo suyo es que el directorio .git con todo el ínidice esté fuera del htdocs del servidor, para ello se puede usar el parámetro –work-tree de git. Si por algún motivo no puede estar fuera podéis utilizar de nuevo un .htaccess para que nadie pueda entrar:

 

deny from all

 

Y con esto he conseguido un rodeo para poder usar una “shell” remota a través de un script PHP. Espero que os sea de ayuda.

 

 

 

Evolución de la interfaz de usuario de Peak Hour

He recopilado algunas de las capturas de pantalla de la interfaz de usuario de Peak Hour. La verdad es que el cambio es importante.

Peak Hour 0.1.2

En esta versión sólo se soportaba la ciudad de Quito en Ecuador. La interfaz era súper simple, únicamente había un campo en el que indicábamos el Número de Placa.

 

Peak Hour 0.1.2

 

Peak Hour 0.2

Es la primera versión en soportar más de un vehículo.

 

Peak Hour 0.2

 

Peak Hour 0.9.1

Las cosas cambian y la interfaz de Android también. La aparición de Material Design trajo un aire nuevo a la interfaz de apps y Peak Hour tenía que estar al día.

 

Peak Hour 0.9.1

 

Peak Hour 0.13

La versión 0.13 simplificó los menús añadiendo el cajón lateral que es mucho más accesible para el usuario.

 

Peak Hour 0.13

 

¿Cómo será Peak Hour en un futuro?. El tiempo nos lo dirá.

La experiencia de desarrollar una App Android en mi tiempo libre

Después de volver de Ecuador en donde estuve trabajando intensamente en un proyecto que me absorbía casi todo el tiempo decidí tomarme un descanso. En ese tiempo pensé en empezar a aprender a desarrollar apps en Android así que me puse a hojear la documentación oficial respecto al diseño y posteriormente empecé a hacer los ejemplitos que había en la documentación técnica. Entonces me dije, ¿por qué no intentas poner en práctica todo lo que vayas aprendiendo en una aplicación que tenga una utilidad real?, y así es como nació Peak Hour.

La primera versión era realmente sencilla pero me sirvió por un lado para aprender los conceptos básicos de Android (Activities, ciclo de vida de las mismas, tantear el IDE que por entonces decidí empezar con Eclipse aunque poco después migré a Android Studio, notificaciones, etc) y por otro tantear el mercado de apps y concretamente la de gestión de Pico y Placa y transporte en general. Estuve jugando con el código un par de meses o tres y para principios de 2015 ya tenía algo que más o menos funcionaba, el problema era que desde que había empezado a trabajar en Planeta Huerto no me quedaba mucho tiempo libre por lo que no fue hasta febrero de 2015 que presenté la app a mis compañeros de Ecuador.

La primera sensación fue decepcionante, a pesar que cuando estuve en Ecuador era muy cotidiano preguntarse entre los compañeros a quién le tocaba Pico y Placa, cuando se la envié a la gente de allí casi nadie la instaló, creo que no les parecía muy útil y eso me hizo replantearme si valía la pena seguir mejorándola. Después de este chasco la tuve medio abandonada durante unos cuantos meses, 5 o 6, en los que sólo hice un par de arreglos y poco más. En esos meses aproveché para hacer un par de cursos MOOC que me ayudaron mucho a entender como está diseñado Android, aprender muchísimo sobre todo de los patrones de diseño que utiliza el sistema, y detectar los problemas que tenía mi app y ver los errores que había cometido durante mi primer abordaje. Ahí es cuando dije, vamos a hacerlo un poco mejor y así también afianzas las cosas que has aprendido en los cursos. También me planteé que si quiero que la app sea utilizada masivamente tiene que ser más flexible y soportar las reglas de más ciudades a parte de Quito y así es como surgieró la versión 0.2 en las que se añadió el soporte multi-vehículo y la versión 0.3 en la que rediseñé completamente el manejo de reglas para que fuera muy sencillo añadir nuevas ciudades.

Estos dos cambios han resultado ser fundamentales, a partir de ese momento empezamos a crecer horizontalmente o lo que es lo mismo, se empezó a utilizar la aplicación en muchos otros sitios como Colombia, Brasil, Bolivia o Costa Rica, pero sobre todo en Colombia que es actualmente el mercado principal de la app. Es muy gratificante pensar que algo que tu has creado le está siendo útil a casi 300 personas, y eso es lo que te impulsa a seguir adelante. Ya os digo yo que por el dinero no es, de momento la app da para tomarse un poleo al mes y poco más, pero saber que toda esa gente no olvida su Pico y Placa y que seguramente se ha salvado de alguna multa gracias a la app, la verdad es que te alegra el día.

 

¿Y qué pasará con la app en el futuro?, pues de momento tengo planificados un par de cambios que ya tengo medio implementados y dependiendo de como vaya la cosa y si tengo tiempo hay muchas ideas en una libreta que parece que va siendo hora de ir sacándolas.

 

Ya os iré contando.