Etiqueta: IDE

Recargar el navegador desde Emacs

Aunque Emacs no suele aparecer entre los editores preferidos para desarrollo web sigue teniendo opciones que lo hacen interesante.

En este artículo vamos a comentar algunos «plugins» que nos ayudan a recargar el navegador automáticamente cuando hacemos cambios en el código. No todos funcionan en las últimas versiones de Emacs, pero los dejo en el artículo para saber lo que hay disponible, o al menos lo que no merece la pena probar.

Conclusiones

Para quien quiera ir directo al grano el que me parece más recomendable en este momento es Mini Kite Mode, que se comenta al final de listado y que descubrí a través de esta pregunta de stackoverlow. En las respuestas se mencionan algunos complementos para emacs para trabajar con desarrollo web que no he probado y que también podrían ser interesantes pero están todos desactualizados.

Listado de plugins

Impatient Mode

Uno de los limitantes de Impatient Mode es que hay que habilitar el impatient-mode por cada uno de los buffers que se quieran observar. Aunque supongo que se puede configurar de algún modo algún hook para que automáticamente habilite la observación en los buffers abiertos con determinadas extensiones.

Tras habilitar el modo M-x impatient-mode y lanzar el servidor M-x httpd-start tendremos en localhost un navegador que escuche los cambios http://localhost:8080/imp/

Otro de sus problemas es que lo que parece hacer, es cargar dentro de un iframe la web que estamos editando en emacs, y desde el código html/js en el que está empotrado el frame se hace un pooling cada cierto tiempo para ver si el contenido cambia y recargar. Empotrar tu código dentro de un iframe al final excepto para casos sencillos puede ser problemático y el sistema de pooling tampoco es muy efectivo en la práctica, porque cada pocas pulsaciones de teclas se hace un refresco de la página.

Skewer Mode

Para hacer funcionar Skewer Mode seguramente haya que hacer un par de pruebas, pero hay un vídeo y una pregunta de stackexchange que pueden ayudar.

La parte interesante de este modo es que permite abrir un buffer en modo REPL para javascript. De modo que podemos evaluar el código js directamente en emacs como si estuvieramos usando la consola del navegador. O podemos editar nuestra fuente javascript y relanzar una función o porciones de código al navegador.

Uno de los mayores limitante es que la recarga no es automática, y en el modo html funciona tag a tag. Es decir, no podemos reenviar el buffer entero al navegador, si no sólo los tags que nos interesen. Lo que hace es modificar el dom, para actulizar el contenido de los tags. No lo he encontrado especialmente cómodo, pero tiene algunas extensiones que podrían simplificar el trabajo como skewer-less o skewer-reload-stylesheets.

Emacs browser refresh

Browser refresh es una idea sencilla e interesante. Basicamente usa xdotool, una herramienta que permite scriptear movimiento de ratón y pulsaciones de teclas, para poner la ventana del navegador en foco y pulsar «F5», cuando le damos a salvar. El script original no funciona del todo bien, y aunque es fácil de arreglar es una solución «error prone». Si tenemos varias ventanas del navegador abiertas, o hemos cambiado de pestaña puede funcionar incorrectamente.

GC Refresh Mode

De nuevo una buena idea pero el código de GC Refresh Mode está desactualizado y no funciona. Al activar el modo M-x gc-refresh-mode pregunta la url a recargar, que puede ser un http://localhost o un file:///, abre esa uri en chrome en modo remote-debugging y sobreescribe C-x C-s para que al recargar se ejecute un script en python. El script en python es una implementación muy sencilla del Chrome Debugging Protocol que conecta a un socket con el que comunicarse con la instancia del navegador que abrió antes, busca la pestaña donde está la uri de interés y la recarga.

El problema es que Chrome ya no usa exactamente este sistema y el script no funciona. Este plugin está inspirado en la página de Save And Reload Browser del Emacs Wiki.

chrome-reload-page

Basándose en la idea de GC Refresh Mode hace algún tiempo escribí un ejemplo de código (funcional) que acabó de subir a github.

Este script usa el Chrome debugging protocol para recargar la pestaña. El script lleva empotrado el código de python del fork de max-weller de chrome_remote_shell para ahorrar trabajo.

Mini Kite Mode

Mini Kite Mode es la más funcional de las opciones de este artículo.

Se puede instalar directamente desde MELPA. Para usarlo añadiremos a nuestro .emacs, las siguientes líneas.

(require 'kite-mini)
(require 'kite-mini-console)
# Automatically Turn on the mode for your buffer of choice.
(add-hook 'js-mode-hook (lambda () (kite-mini-mode t)))
(add-hook 'css-mode-hook (lambda () (kite-mini-mode t)))
(add-hook 'html-mode-hook (lambda () (kite-mini-mode t)))

El segundo require sólo es necesario si queremos abrir un buffer de Emacs como una consola js en modo REPL (similar a la consola de DevTools). Y los hooks permiten activar el modo para los buffers de interés en tener que activarlo a mano M-x kite-mini-mode

Una vez en un buffer (y través a ver lanzado chrome / chromium en modo remote debug) simplemente conectamos con

M-x kite-mini-connect

Si la pestaña que tenemos abierta es con la que queremos interactual podemos simplemente pulsar intro. A partir de ese momento podemos lanzar la consola de js, enviar una región al navegador para que sea evaluada, o recargar la pestaña.

El mayor problema, de esta herramienta, y en realidad de todas las que usen el Remote Debug, es que sóla una herramienta puede estar conectada mediante el protocolo a la vez, y las DevTools hace uso de este sistema también. De modo que si kite está conectado y se abren las DevTools kite se desconectará. Y si son las DevTools las que estan activadas cuando hacemos kite-mini-connect, kite no llegará a conectar.

Para simplificar un poco el flujo he editado el fichero de ~/.emacs.d/elpa/kite-mini-20160508.406/kite-mini-el para que antes de hacer el reload salve el buffer, quedando así

(defun kite-mini-reload ()
(interactive)
(save-buffer)
(kite-mini-call-rpc
"Page.reload"
(list :ignoreCache t)))

De este modo al pulsar C-c C-r, primero salva y luego recarga. El siguiente paso, sería que mientras esté conectado, pulsar C-x C-s salve el buffer y recargue, pero por ahora con esto me llega.

21 mayo 2017 Añadir comentario

Atom: Autocompletado de código en python

Al margen del «Code Completion» de PyCharm, y algún otro, el resto de editores/IDEs proveen autocompletado a través de librerías o «servicios externos». Para el caso de python hay fundamentalmente dos, rope y jedi. Rope está más enfocada a Refactoring y Jedi a Autocompletado, por tanto las dos son complementarias. En la actualidad varios editores que usaban rope están migrando a jedi, su autor ha hecho una comparación defendiendo su librería.

Además de estas librerías cada editor suele proporcionar un plugin base para autocompletado (autocomplete-plus en atom, auto-complete en emacs) y plugins adicionales para cada lenguaje concreto que actúan como wrapper de las librerías base (rope, jedi,…). Por ejemplo en atom tenemos autocomplete-python que es un wrapper para jedi.

Instalación

Primero hay que instalar jedi sea a nivel global como en el ejemplo, o dentro de un virtualenv.


sudo pip install jedi

Luego se instala el plugin de autocomplete-pyhon (que es el más actualizado de los varios que hay). Si usas virtualenv también debería funcionar sin problemas pero si usas algo como virtualenvwrapper donde tu módulo está en un directorio distinto al «entorno virtual de python» puedes haber más problemas.

Lanzado atom desde un virtualenv activado siempre funciona correctamente. Si lo lanzas de otra forma hay que configurar la opción de configuración Python executable path del plugin con algo como:


PATH_TO_VIRTUALENV_WRAPPERS_FOLDER/$PROJECT_NAME/bin/python

o

PATH_TO_VIRTUALENV_WRAPPERS_FOLDER/$PROJECT/bin/python

Donde PATH_TO_VIRTUALENV_WRAPPERS_FOLDER es la ruta absoluta al directorio donde se guardan todos los entornos virtuales de virtualenwrapper y $PROJECT_NAME y $PROJECT son cadenas que debes escribir tal cual. Son variables que entiende el plugin. De la documentación parece deducirse que lo que hay que usar es $PROJECT pero a mi me ha funcionado sólo con $PROJECT_NAME. Además el directorio padre que se añade a atom a través del «Add project folder» debería llamarse igual que el virtualenv para que $PROJECT_NAME tome el valor correcto y puedas usar la misma configuración para distintos proyectos.

Uso

Por la naturaleza dinámica de python muchas veces jedi no es capaz de detectar el tipo de datos de un objeto. Pero podemos ayudarlo documentado el método. Por ejemplo en un caso como el del ejemplo siguiente con una vista de pyramid, jedi no será capaz de determinar el tipo de datos del parámetro request.


@view_config(route_name='my_route')
def my_route(request):
pass

Pero si hacemos lo siguiente si que autocompletará correctamente los métodos de request:


def cultivos_get(request):
"""
:type request: pyramid.request.Request
"""
pass

No lo he probado con python 3 para ver si soporta el type hinting pero este issue me hace suponer que si.
Teclas principales

  • Sugerencias de autocompletado. Ctrl+space Cursores y tab/intro para escoger y aceptar sugerencia
  • Go to definition: Ctrl+Alt+G
  • Show usages: Ctrl+Shift+P show usages
  • Renombrado en varios ficheros a la vez: Con el cursor encima del símbolo. Ctrl+Shift+P rename

Conclusiones

Las funcionalidades que proporciona son de todas formas muy justas porqué a no ser que documentes los métodos, la mayoría de veces no es capaz de inferir el tipo de datos de una variable. Además las funciones de autocompletado normal de atom incluyen habitualmente opciones que no tienen porque corresponder con métodos o propiedades reales del objeto. Y si se desactiva el autocompletado normal para los ficheros python, tendremos muy pocas sugerencias.

8 mayo 2016 Añadir comentario

Aptana. Un IDE para desarrollo web

Hace unos meses escribía en el blog que estaba buscando un IDE para desarrollo web el cliente. Al final no me he dedicado tanto a web-cliente como pensaba y he estado jugando más en la parte de backend sobre todo con nodejs.

Dado que es el primer IDE (para web) que pruebo y tampoco tengo gran experiencia en desarrollo web me resulta difícil hacer una buena revisión, pero aquí van algunos pros y contras de programar Javascript en Aptana desde el punto de vista de alguien que viene de Java+Eclipse.

Contras

* El debugger de Apata es incompatible con la última versión de firebug por lo que debes instalar una más antigua. Tuve unos cuantos problemas intentando instalarlo y no he sido capaz de hacer un cambio en el código y recargar la página sin tener que relanzar todo firefox a través del debugger. En resumen el debugger no he sido capaz de hacerlo funcionar de una forma cómoda y he vuelto a firebug.
* El preview de la página cuando está puesto el código del google analytics hace que se cierre aptana.
* Para que el Code Assist funcione correctamente, hay que tener unos ficheros de documentación en un formato especial (ScriptDoc), y practicamente ninguna librería los tiene.
* En el «Save Action» sólo se pueden quitar los trailing spaces, estaría bien que permitiera al menos reformatear el código
* No es capaz de navegar por ocurrencias correctamente. Si marco una variable no soy capaz de moverme entre las apariciones de esa variable (Ctrl + .) como en java. Tampoco es capaz de encontrar desde donde se llama a una función (aunque este es un problema genérico de los lenguajes dinámicos). Aquí hay un listado de funcionalidades aunque no está del todo actualizado. No he probado a documentar las funciones con ScriptDoc, tal vez así el editor sea más inteligente.
* La documentación es escasa
* Así como cuando programo en Java todo el equipo usa Eclipse, con web no pasa lo mismo. Así que la idea de tener que crear workspaces y proyectos dentro del workspace llenos de directorios de configuración ocultos me resulta conceptualmente incómodo.

Pros

* Me gusta la consola interactiva. Puedo probar código sin tener que abrir la consola javascript del navegador.
* Me gusta el Content Assist de html, creo que funciona bastante bien.
* Al margen del problema con el debugger, me gusta la funcionalidad de preview ( https://wiki.appcelerator.org/display/tis/Side-by-Side+Previewing ). Me permite poner en dos pestañas paralelas mi código (html, css, js) y el navegador empotrado de aptana, al salvar uno de los ficheros la previsualización se recarga automáticamente. Está bien para ir viendo como queda. Una pena que no haya encontrado forma de debuguear desde el preview.
* Me gusta el «Go To Declaration (F3)», aunque se equivoca de vez en cuando, si por ejemplo has estado haciendo pruebas en otro fichero, poniéndolo a las funciones el mismo nombre puede saltar a la que no es.
* Me gusta la buena integración (heredada de eclipse) con el escritorio. Poder copiar un fichero en el explorador de archivos y pegarlo en una vista de aptana, o copiar un snippet de código de una página web y pegarlo en Aptana creando automáticamente un nuevo fichero
* El sistema de templates para no arrancar proyectos como una página en blanco funciona bien.
* Es relativamente fácil, extender la funcionalidad a través de Snippets y Rubles. Aunque los Rubles hay que escribirlos en Ruby

Enlaces de interés sobre aptana

* Una revisión genérica de Aptana.
* Documentación sobre html, css, y javascript

Conclusiones

Me da la impresión de que la mayoría de opiniones favorables vienen de gente que lo uso en su día cuando no había opciones libres/gratuitas mejores. Además da la impresión de que el proyecto está muerto desde que lo compró Appcelerator.

Creo que el caso de uso más favorable para Aptana es que ya estés usando el IDE en el backend (ruby, php, python) y sólo toques ocasionalmente el cliente por lo que no te merece cambiar de entorno.

26 junio 2014 Añadir comentario

IDE para desarrollo web en cliente

Estoy buscando un IDE (o editor de código) para desarrollo web centrado en el cliente (JavaScript, HTML y CSS). Tras duckduckgodear un poco ya tengo una lista de los entornos que voy a me gustaría probar, no necesariamente en este orden:

  • Webstorm. De jetbrains. No es libre ni gratuito pero sale muy bien parado en las comparativas.
  • Sublime Text. Tampoco libre ni gratuito, pero al igual que el anterior muy bien valorado.
  • Eclipse. Con plugins para desarrollo web o la versión pre-empaquetada.
  • Emacs. Que nunca decepciona cuando inviertes suficiente tiempo en él.
  • Aptana. Lo he estado usando para python y va aceptable.
  • NetBeans. A pesar de que nunca lo he usado tiene críticas entusiastas.
  • Brackets. Un editor libre creado por Adobe con muy buena pinta. (actualizado 26/Junio/2014)
  • Atom. Un editor libre creado por GitHub, basado en nodejs. También con muy buena pinta, pero por ahora sin binarios para Linux. (actualizado 26/Junio/2014)
  • Mozilla Web IDE. Todavía parece bastante verde, y no tengo claro que sea lo que busco, pero parece que Mozilla ha intentando montar un IDE directamente en Firefox. El target principal de aplicaciones es su sistema para moviles FirefoxOS pero debería valer para la web.(actualizado 26/Junio/2014)

Por ahora voy a empezar con Aptana e iré contando. ¿Vosotros que usais?

 

13 noviembre 2013 2 Comentarios