Nerver forget again. For timestamp 1353101513:
$ date -d "1970-01-01 + 1353101513 seconds" +"%F %T"2012-11-16 21:31:53Et voilí!
Categoría: Programación (Página 1 de 2)
Esta pregunta me ha hecho hoy Mr. Client*. Reconozco que no ha sido el primero pero supongo que tampoco será el último.
Mi primera respuesta es que mi religión me lo impide. Ya no recuerdo la última vez que usé FTP por cuenta propia. En caso de necesitar FTP siempre usaré SFTP y, si tengo acceso shell, SCP. No hay nada mejor que una consola y, si es posible, una sesión SSH.
Pero realmente no quería hablar de FTP, sino de clientes para estos servicios. No tengo nada en contra de ellos y si los usas me parece muy bien, pero voy a explicar porque tiendo a no usarlos si es que puedo cambiarlos por comandos en la consola o por acciones que pueda controlar directamente con el teclado. ¿Raro? ¿Arcaico? ¿Friki? Ni mucho menos, eficiente.
Y si el simple hecho de mover las manos entre el teclado y el ratón hace que seas más lento, podemos incluir el hecho de que para la mayoría de las acciones que tengas que hacer bastaría con repetir la misma acción (subir un fichero, copiar una carpeta, borrar un fichero, etc).
Ahí van un par de las preguntas más frecuentes:
«¿Y tienes que estar todo el rato conectándote? ¿Y la contraseña?»
Para esta pregunta, la solución está en este post en el que explica como crear un par de claves que te permita acceder al servidor de forma sencilla y segura.
La respuesta es sí, pero es que conectarme al servidor es una cosa muy sencilla. Además, para configuraciones habituales o que requieran de muchos parámetros, siempre podemos «Tunear» un poco nuestro ssh 😉
«¿Y cuando tienes que subir varios ficheros?»
El tema se pone interesante. Depende del caso, desde el más sencillo usando wildcards:
scp *.log host:/var/logO algo más complicado:
scp {script,config}.php host:/var/wwwO siempre está la opción de hacernos un mini-script que suba varios ficheros, aunque recordemos que siempre que podamos hacerlo en la misma conexión, ganaremos tiempo.
«Vale, ¿y cuando tienes que subir muchos ficheros? ¿Y carpetas?»
Para las carpetas, nada como la opción -r que permite subir ficheros de forma recursiva, incluyendo directorios.
Cuando tienes que subir muchos ficheros, automatización con un script o incluso usar un tar.gz, subir y descomprimir. Si realmente tienes que trabajar con cambios en muchos ficheros en distintos sitios, la mejor opción sería rsync lanzado manualmente (hasta el momento, no me he encontrado con este caso, pero bueno, será por opciones).
O puedo asegurar que si os gusta la velocidad, lo primero es aprender a no usar el ratón (que no quiere decir que no lo uséis) y luego, a automatizar los trabajos repetitivos. Conseguiréis ser más rápidos, eficientes y, como no, aprenderéis más cosas.
Que no se me enfade nadie, cada uno es libre de usar las herramientas como quiera. Sólo he dado mi propuesta que, además, vale tanto para Linux, Windows o Mac.
*: cariñosamente para el post de hoy 😉
Con este nombre, es como hemos bautizado a este nuevo proyecto y aventura en el que nos hemos metido. Quomai.
Queremos que suene mucho y fuerte entre todos vosotros y estamos trabajando muy duro para que en breve veáis la idea en funcionamiento.
Y así para empezar… os gusta el nombre? Y el logo?
Stay tuned!
Estos son algunos de los sitios donde daremos guerra:
Uno de los métodos más baratos y conocido para hacer debugging «en parejas» es el método denominado «el patito de goma». Creo que esta es la primera vez que se habla sobre él.
Es realmente sencillo y he tenido he podido comprobar (conmigo y con otros) como la eficacia de este método es elevadísima. Hay que seguir unos sencillos pasos:
- Conseguir un patito de goma, preferiblemente variedad baño (aunque se aceptan versiones tipo pirata, Sherlock Holmes o incluso ¡diablo!)
- Colocar el patito cerca nuestra, en el escritorio por ejemplo e informarle que vais a ver un poco de código, a ver si está de acuerdo.
- Explicar al pato qué es lo que se supone que hace el código y tras esto, entrar en detalle explicándolo línea a línea.
- En algún momento le dirás al patito lo que se supone que es lo siguiente a hacer y te darás cuenta que eso no es lo que realmente está haciendo tu código. El pato se mantendrá sentado serenamente, contento de saber que te ha ayudado en tu tarea.
Existen variantes al patito de goma, como otro tipo de peluches y objetos, pero su efectividad no está tan demostrada como con el patito de goma.
A petición de Mariotux, va este post sobre uno de los problemas que me he encontrado cuando he tenido que usar mocks en PHPUnit. Es uno de los errores ya reportados y se da al intentar comprobar llamadas a un método con distintos parámetros.
Supongamos que tenemos una clase como esta que queremos mockear:
class MyClass {
public function check($param) {
// Código
}
}En el caso concreto de querer comprobar si se realizan, por ejemplo, dos llamadas a esta función pasando $param = ‘one’ y una llamada con $param = ‘two’, es cuando nos encontremos el problema. Por ejemplo:
$mock = $this->getMock('MyClass');
$first = 'one';
$mock->expect($this->exactly(2))->method('check')->with($first);
$second = 'two';
$mock->expect($this->once())->method('check')->with($second);Aunque la clase que programemos realice correctamente las llamadas, PHPUnit nos indicará que se esperaban 2 llamadas a check, pero se han realizado 3 y, por lo tanto, no pasará el test.
Esta misma semana comentaba con Carlos Ble y hay posibles soluciones, como es generar una clase intermedia que separe ambas llamadas, siempre teniendo en cuenta que podamos hacer ese código y quizás no sea tan sencillo con código legado o con mucho acoplamiento.
A ver si en los próximos releases de phpunit-mock-objects se soluciona este problema.
Es posible que te encuentres en la situación (doy un par de ejemplos más abajo) en los que necesites que tu Android Emulator haga caso a tu /etc/hosts en vez de al DNS. Para este caso, lo que tienes que hacer es seguir estos dos sencillos pasos:
- Crear un fichero hosts en tu ordenador (o usar el que ya tienes en /etc/hosts)
- Remontar el emulador y copiar el fichero anterior
La necesidad de remontar viene porque si no, el dispositivo está como sólo lectura y por lo tanto es imposible escribir nada en él.
Supongamos que tenemos partimos de nuestro /etc/hosts, iríamos al directorio donde tenemos las tools del SDK y teclearíamos:
adb remount
adb push /etc/hosts /system/etc/También es posible coger el fichero hosts que tiene el emulador (por ejemplo, copiandolo a nuestro directorio /tmp):
adb push /system/etc/hosts /tmp¿Y en qué casos nos puede hacer falta? Bueno, yo en concreto lo he necesitado cuando estaba desarrollando una aplicación que se alimentaba de un webservice. Realizaba el desarrollo del webservice en paralelo y por lo tanto no estaba (todavía) en la máquina de producción. De esta forma, gracias al fichero hosts obligaba al emulador a buscar en mi entorno de desarrollo en vez de ir al de producción, haciendo que la aplicación tuviese un comportamiento transparente, en código, sobre dónde atacar.
Por defecto en bash sólo se pueden retornar enteros. ¿Qué hay que hacer entonces para que retorne un valor no entero?
El truco está en hacer un echo del valor y asegurarnos en la llamada de la función que se asigna a una variable. Es decir, nuestra función sería:
function retorna_texto {
echo -n "este es el valor a retornar"
}Y la llamada:
VALOR=$( retorna_texto )Ahora en ${VALOR} tendremos el texto tal y como queríamos
I have just pushed into GitHub a bash autocomplete script for symfony.
This script allows to autocomplete your first level option when calling to symfony script. It is easy to install (just copy one and call it manually if you do not have access rights). All steps and working issues are in the wiki. It also accepts custom actions.
This is a working example once script is corretly installed and invoked:
Assuming symfony is in current folder and [tab] y tab key press action, this is an example of how symfony_complete works:
$ ./symfony con[tab]figure:[tab][tab]
author database
$ ./symfony doctrine:a[tab]uthorWe are pleased to know what you think and any issue you have. You can find us on GitHub.
Related links:
- symfony_complete GitHub repository
- Biko2 GitHub repository
- My personal and biko2 related profile on GitHub
Una de las noticias de esta semana en el mundo PHP es sin duda toda la información acerca de HipHop for PHP por parte del equipo de desarrollo de Facebook. Una de las extensiones que ha salido a la luz por parte del equipo de front-end es la que han llamado XHP y, como ellos mismos rezan, «a new way to write PHP» (una nueva forma de escribir PHP).
La explicación de cómo funciona es muy sencilla. Intentan evitar que al desarrollar la parte de frontal, cuando nos «pegamos» con el XHTML, tengamos que unir código XHTML y PHP. En el ejemplo que muestran se ve más claramente.
De un código como:
Hello, .
Nos da como opción generar este otro:
Hello, {$_POST['name']};
} else {
echo
;
}No voy a negar que, de primeras, XHP parece más sencillo de seguir y de generar. Eliminar los tags de apertura y cierra de PHP aligera el código en gran medida. Además, eliminamos problemas con el XSS así como detectar problemas por malformación de XHTML en tiempo de parsing.
A mi personalmente me sigue gustando bastante más usar un motor de plantillas. Un motor real como XTemplates (sí, he dicho XTemplates, no smarty o similares). Separar el código PHP del HTML me parece bastante importante y necesito verlo con más claridad.
No obstante, hay que seguir el tema de cerca. Si es algo que la gente de Facebook ha visto que es necesario ya que aumenta el rendimiento, es evidente que en este tipo de entornos será uno de los puntos de referencia. Sin embargo, XHP como técnica para el resto de las webs donde no se reciban tantas peticiones como Facebook (si no recuerdo mal, sirven más doscientas mil millones de páginas al mes, sí, sí, 200.000.000.000), es posible que un objetivo que cumpla a primera vista es juntar el PHP con el HTML, algo que, repito, me parece bastante "sucio" si no hay una justificación clara. Pos supuesto, un motor de plantillas tiene sus desventajas, no vamos a negarlo 🙂
Lo dicho, XHP de momento me parece algo que puede provocar que el código sea más rápido pero a costa de hacerlo más guarro. Habrá que seguirle la pista para ver por dónde avanza, no lo descarto de primeras porque el objetivo de aumentar el rendimiento es muy importante, pero analizando el coste (ni monetario ni de recursos en este caso, jeje).
Enlaces:
Update: Muy muy muy interesante lo que comenta Rasmus en su web. Importante verlo.
Muchas veces considero que es una obsesión, pero de lo que estoy seguro es que muchas más veces gano tiempo pensando un poco y haciendo las cosas mejor y más rápidas.
El caso que voy a presentar ahora es lo que yo considero «la forma más rápida de descargarnos un dump de una base de datos». Añadamos como condición que tenemos que usar un protocolo cifrado, en este caso, SSL. Para cualquier de los dos ejemplos que voy a presentar, contamos que tenemos autentificación en el servidor remoto (ahora que sabemos cómo hacerlo).
Empecemos por el final. Cómo se nos ocurriría hacerlo directamente. Básicamente los pasos serían estos:
# Nos conectamos al servidor
ssh user@server.com
# Realizamos el dump de la base de datos
mysqldump -u mysqluser -p mysqldb > dump.sql
# Comprimimos los datos para reducir el tamaño de los datos a trasferir
gzip dump.sql
# Volvemos a nuestro ordenador
exit
# Copiamos el fichero a nuestro ordenador
scp user@server.com:dump.sql.gz .He hecho una prueba con una base de datos pequeña. Si únicamente contabilizamos el tiempo en realizar cada uno de estos comandos y los sumamos (es decir, no tenemos en cuenta ni el ssh inicial ni los tiempos entre comandos, incluído si nos vamos a tomar un café mientras hace el volcado o lo comprime), salen los siguientes tiempos:
- mysqldump: 2.2 segundos
- gzip: 0.5 segundos
- scp: 12.2 segundos
- total método 1: 14.9 segundos
Veamos ahora otra forma. ¿Y cómo es? Pues bien sencilla… ¿y si te digo que puedes agrupar todos los comandos en únicamente uno?
¿Cómo? Pues aprovechando que se pueden ejecutar comandos de forma remota con el comando ssh y que lo que devuelva ese comando, se retorna mediante la consola estándar (stdin). Además, teniendo en cuenta que también podemos llamar a gzip en línea mediante una tubería (denominada en inglés pipe, representada por la barra vertical: |). Si unimos todo esto, nuestro comando queda (ejecutado directamente desde nuestra máquina):
ssh user@server.com "mysqldump -u mysqluser -p mysqldb | gzip" > dump.sql.gzSi medimos el tiempo que le cuesta a este comando obtenemos para el método 2: 12.0 segundos
La diferencia puede parecer muy pequeña vista así, pero estamos hablando que es casi un 20% más rápido. Si este proceso (con el primer método) hubiese durado 4 horas (sí, os aseguro que se puede dar el caso), en algo más de 3 horas lo habríais terminado. Estos datos son muy variables, hay que tener en cuenta muchas cosas, pero que hagáis las pruebas que hagáis, en igualdad de condiciones, este nuevo método es mucho más rápido.
Y os aseguro que si hacéis la prueba con un proceso largo, en el que tendríais que esperar que terminase cada paso para iniciar el siguiente comando, ganaréis mucho tiempo sobre todo entre comando y comando.
La próxima vez que os toque algo como esto, usad este método y tomaros el café (o la comida) que os podréis tomar gracias a no tener que esperar, a mi salud.
Pensad un poco, esto es sólo un ejemplo, ¡hay muchas más opciones!