Categoría: Sin categoría

Video: Aplicaciones en tiempo real con python y postgres

Una charla de como montar aplicaciones en tiempo real con python y postgres. Tiempo real entendido como notificaciones de un chat, hacer algo cada vez que se actulice una tabla de la bd etc,…

El vídeo se hace un poco largo, seguramente con las transparencias llegaba para hacerse una idea general. Pero aún así se hace interesante por alguna de las técnicas que emplea:

  • Aboga por no usar frameworks en python. Con las librerías de hoy en día es sencillo montar una API Rest gestionando las llamadas de bajo nivel directamente
  • Usa las funciones de postgres de LISTEN y NOTIFY que combinadas con un trigger permiten que código cliente (psycopg2) sean notificados cuando algo pasa en la base de datos (se modifica una fila o lo que sea) y actuén en consecuencia (provocar un cambio en el navegador mediante websockets)
  • Para simplificar la API y el diseño de la bd, los datos se guardan como tipos nativos postgres (varchar, boolean,…), y se usa la función de postgres row_to_json para recuperarlos una cadena de texto con formato json.
  • Usa httpie para probar la API Rest. Si alguna vez usaste curl para esto enseguida verás que está bien conocer httpie.
  • A pesar de que la idea principal de la charla es montar una aplicación en tiempo real con el mínimo número de dependencias (complejidad) el proceso de build que monta no parece trivial. pip para dependencias en python, nodeenv (una especie de entorno virtual para node que se integra con el virtualenv de python), bower para las dependencias javascript de cliente,… Todo ello orquestrado por un Makefile.
  • No muestra como hacer la parte del frontend, pero en todo caso el código está en su repo

Comentarios al artículo de Complejidad y Reversibilidad de Kent Beck

Andrés me pincha para que lea y comente el último post de Kent Beck en su muro de facebook. Como todo lo que escribe Beck hay que leerlo con atención y se pueden sacar lecciones interesantes. Pero este artículo en particular se me hace complicado de leer porque creo que mezcla demasiadas cosas a la vez. Comienza con una teoría general sobre sistemas complejos y luego salta a prácticas concretas de facebook para atajarla en distintos estadios del desarrollo sin pararse a explicar que técnicas tienen sentido en según que contextos. Analicémoslo por tanto atendiendo al artículo como dos partes separadas.

Complejidad y Software

Software complexity es un término con definición propia en el mundo académico. En la práctica todo desarrollador tiene una noción intuitiva de que es complejidad y debería tener como principio el atajarla. Beck explica alguno de los elementos de la complejidad y cuales de ellos se puede intentar mantener bajo control en un producto como facebook. La cuestión es, si en otro tipo de productos software se puede o tiene más sentido atacar otro frente distintos al de la irreversibilidad. Personalmente se escapa de mis conocimientos esta reflexión pero apunto algunos elementos para el debate:

  • Estados. Atendiendo al producto como un todo (hardware, acciones del usuario, red,..) seguramente será difícil de atajar. Si nos quedamos con las acciones (interacción) del usuario me recuerda a la diferenciación entre mapa y camino de la que se reapropió Andrés atendidendo a Verplank.
  • Interdependencias. SOLID, KIS, Patrones, Modularidad o cualquier práctica de buen diseño entiendo que ayuda a disminuirla a no ser que se me escape algo.
  • Incertidumbre. Supongo que es el más complicado. Usuarios usando la aplicación en formas no previstas. Requisitos cambiantes,…
  • Irreversibilidad. Nada que decir, es en el que se centra Beck.

Atajar la Irreversibilidad

La segunda parte del artículo habla de algunas de las técnicas que usan en Facebook para combatirla. Algunas pueden ser consideradas de modernas como el Frequent Pushes (¿Continuous Delivery?) y otras como el Code Review llevan con nosotros mucho tiempo. Beck las enumera todas juntas pero creo que intentar ponerlas bajo una clasificación más o menos habitual en factorías de software tradicionales puede ayudar a decidir cuales pueden ser aplicables en cada caso. Dejo fuera (IRC y Data-informed decisions)

  • Desarrollo
    • Development servers
    • Code review
    • Correlation
  • Pre-Producción / Testing
    • Internal usage
    • Staged rollout
    • Advance countries
    • Shadow production
  • Producción
    • Frequent pushes
    • Soft launches
    • Dynamic configuration
    • Right hand side units
    • Double write/bulk migrate/double read

Sin duda algunas de las técnicas como Staged Rollout es discutible en que fase van y son clasificables bajo esta óptica. La idea de intentar clasificarlas es sólo para poder compararlas con una forma de trabajo que nos resulte más cercana para a partir de ahí ver cuales podemos empezar a aplicar y en que punto de nuestro proceso.

Qué puedo aplicar y cómo si no soy Facebook

Más que técnicas concretas en realidad lo que Beck plantea es una cultura (o dos). El Desarrollo Ágil y el DevOp. Intentar aplicar alguna de sus estrategias de forma separada sin abrazar la filosofía subyacente creo que sólo produce desgaste. Con esto no quiero decir que tengas que hacer pair programming y tener un devop en tu equipo, pero sí al menos comprender que hay valor en los principio que proponen.

Para mi los pasos en ese camino son tres: Tests, Automatización y Monitorización.

Monitorización. Si no estás midiendo lo que sucede rendimiento, comportamiento de usuarios, … saber lo que está pasando o cuando un cambio no tiene el efecto previsto.

Automatización. Si hacer un despliegue es costoso e implica varios pasos, se harán pocos , se tardará más tiempo en tener feedback, se introducen más posibilidades de error y no hablemos de lo que supone revertir un mal cambio. Si no se automatizan los procesos se vuelve más complicado que todos los desarrolladores tengan el mismo entorno y este sea parecido a producción.

Tests. Probablemente la piedra angular. Estoy leyendo Working Effectively with Legacy Code, y en los primeros capítulos expone algunas cuestiones sobre tests que tienen relevancia para la «reversibilidad». En el libro comparan trabajar sin tests a hacer acrobacias sin red, y expone dos formas de introducir cambios en un sistema.

Changes in a system can be made in two primary ways. I like to call them Edit and Pray and Cover and Modify. Unfortunately, Edit and Pray is pretty much the industry standard. When you use Edit and Pray, you carefully plan the changes you are going to make, you make sure that you understand the code you are going to modify, and then you start to make the changes. When you’re done, you run the system to see if the change was enabled, and then you poke around further to make sure that you didn’t break anything. The poking around is essential. When you make your changes, you are hoping and praying that you’ll get them right, and you take extra time when you are done to make sure that you did.
Superficially, Edit and Pray seems like “working with care,” a very professional thing to do. The “care” that you take is right there at the forefront, and you expend extra care when the changes are very invasive because much more can go wrong. But safety isn’t solely a function of care. I don’t think any of us would choose a surgeon who operated with a butter knife just because he worked with care. Effective software change, like effective surgery, really involves deeper skills. Working with care doesn’t do much for you if you don’t use the right tools and techniques.
Cover and Modify is a different way of making changes. The idea behind it is that it is possible to work with a safety net when we change software. The safety net we use isn’t something that we put underneath our tables to catch us if we fall out of our chairs. Instead, it’s kind of like a cloak that we put over code we are working on to make sure that bad changes don’t leak out and infect the rest of our software. Covering software means covering it with tests. When we have a good set of tests around a piece of code, we can make changes and find out very quickly whether the effects were good or bad. We still apply the same care, but with the feedback we get, we are able to make changes more carefully.

En esencia, durante el desarrollo tener tests te permite probar y si no funciona revertir a coste casi cero. En producción el coste de revertir no es cero (al menos sin aplicar otras de las técnicas mencionadas) pero al menos te permite detectar errores de forma temprana.

 

 

 

 

Libro: Ready Player One

Ready Player One es sobre todo una buena lectura ligera para el verano. En un mundo futurista donde la energía resulta un bien escaso y grandes cantidades de población viven empobrecidas la única diversión, fuente de trabajo y vía de escape es OASIS. Una versión a lo grande de Second Life a la que los usuarios se conectan mediante aparatos de realidad virtual. En OASIS no importa quien seas o como seas, tu Avatar es lo que te representa. La historia cuenta como el protagonista del libro intenta resolver el reto planteado por el creador de OASIS a su muerte y quien lo consiga herederá su fortuna.

 

El libro es una mezcla ligera de ficción ciberpunk con corporaciones tratando de resolver la búsqueda (no leas demasiado del enlace hay spoilers) y misiones al más puro estilo Dungeons & Dragons por el medio del mundo virtual.

 

Si te gustan películas ochenteras como Lady Halcon o los Goonies, eres geek/freak, jugaste al rol o estás enganchado a los MMORPG este libro te encantará.

 

Puedes comprarlo en tu tienda habitual y también hay gente que lo comparte.

Portátiles entre 600 y 700€ para CAD y Diseño

Estos días un amigo me pidió ayuda para comprar un ordenador. Los requisitos:

  • Ofimática, CAD y Diseño sin grandes necesidades
  • Entre 600€ y 700€
  • Pantalla de 15.6»

Échando un ojo a lo que había en el mercado empecé a hacer una hoja de cálculo. Descarté todas los que tuvieran una gráfica peor que una 820M y un micro peor que un i5-4210 porque son configuraciones habituales en ese rango de precios. Luego comparando precios, características y preferencias personales llegamos a esta lista.

Están separados dos rangos de precios los que están más cerca de 600 y los que están más cerca de 700, con mis preferencias resaltadas en amarillo. Si alguién está buscando un portátil así espero que le sirva. El hecho de hacer la hoja de cálculo ya lleva un buen rato, igual hay espacio aquí para hacer un scrapper. ¿Algún programador en la sala :P?

Buscando un portátil – Listado de candidatos entre 900 y 1150€

Decidido el tipo de procesador que queremos, podemos echar una ojeada a las páginas de distintas tiendas.

Lo mejor es entrar en varias, ver lo usables que son en función de como puedes filtrar los portátiles, y quedarse con aquellas en que la búsqueda sea más o menos rápida. Como mínimo porque nos dejan filtrar por rango de precios y tipo de procesador.

Después de ver varias yo he usado las siguientes porque me parecieron las más cómodas:

Lógicamente buscando en varias tiendas salen portátiles repetidos, pero está bien para comparar hay veces que de una tienda a otra el mismo portátil puede variar en 100€. Así que una vez escogido uno toca buscar una tienda fiable con el precio más barato.

De la búsqueda anterior me he quedado por distintos motivos con unos 25 portátiles. Esta es una tabla resumen:

Y por lo que se ve, hay varias decisiones clave que tomar (a parte del precio):

  • Resolución de la pantalla.[1] [2]Sin duda yo me iré a 1920×1080 antes que a 1366×768. Creo que la inversión merece la pena para el eclipse
  • Tarjeta gráfica. Tras leer un poco descarto las Ati RM9M265X que vienen con los Toshiba de la lista. Tienen muy buena pinta, sobre todo el P50B-11M, pero veo que podrían dar problemas con linux [1] [2] [3]. Hay que investigar un poco el resto de nvidia de la lista, por si es un factor clave para descartar más ordenadores o no. Aunque basándome en estas tres páginas las he clasificado
  • 8 o 16 de RAM. O ver si es ampliable a posteriori.
  • Si hay una diferencia real entre los discos duros de 5400 rpm y los de 7200 rpm
  • Si el VGA es fundamental o llega con HDMI. Con el uso que yo le doy al ordenador, teniendo en cuenta que cualquier pantalla moderna soporta HDMI y que cada vez más proyectores sólo tienen HDMI, la existencia de VGA no es un factor clave

Disco Duro

El rendimiento de un disco duro no viene sólo determinado por las rpm, pero averigüar el modelo concreto que monta cada ensamblador y comparar es una tarea demasiado complicada como para que la búsqueda compense. En general la gente parece notar diferencias entre los 7200 rpm y los de 5400 rpm [1] [2][3].

Los discos duros híbridos (con cache SSD) parecen dar un mejor rendimiento que los tradicionales [1] [2] [3], aunque también hay algunas opiniones a favor de los de 7200 sobre 5400 híbridos o de que depende del uso que se le de.

Así que como criterio para descartar portátiles elimino los de 5400 que no tiene cache ssd y/o no tiene 16 GB de RAM y no le doy relevancia a los hibridos sobre los de 7200 rpm.

Tarjeta gráfica

En esta página tenemos un listado de las diferentes gráficas de nvidia. Siendo las que nos interesan, ordenadas de mayor rendimiento a menor:

Tras investigar un poco no he sido capaz de determinar que tarjeta gráfica necesito o cuales son las ventajas reales de unas sobre otras si no te dedicas a jugar. Entre lo poco que he creido entender está que si vas a trabajar con resoluciones altas (como es mi caso al usar monitor extendido) debería priorizar la cantidad de RAM sobre la velocidad de la misma. Es decir mejor 4GB de RAM DDR3 que 2GB de RAM DDR5. Si te vas a dedicar a jugar es mejor priorizar al reves.

Además revisando las especificaciones de las tarjetas, la 740, la 840, la 850 y supongo que la 845 también, tienen soporte para la misma resolución, así que entre estas creo que cualquiera es suficiente para mis requisitos, por lo que puedo descartar los portátiles más caros cuya diferencia principal sea mejor gráfica.

 Conclusiones

Con el listado final de 8 ordenadores donde todos cumplen los requisitos que me había fijado quedan pocas decisiones para descartar.

  • Fundamentalmente si sacrificar rendimiento a cambio de quedarme con mountain en formato ultrabook. Lo que no me interesa en este momento teniendo en cuenta que mi portátil actual es de 2.9 kg y eso no me molesta.
  • Si 16 de RAM es un requisito. Que en principio para mi no lo es, aunque que sea ampliable a 16 sí.
  • Si alguna review de alguno de los modelos que quedan aporta algo muy negativo que lo descarte o algo muy positivo que le de puntos sobre los más económicos

Resto de artículos de esta serie

Buscando ordenador portátil – Micros

En el último artículo veiamos que para encontrar un ordenador portátil adecuado (en rendimiento y presupuesto) uno los factores más importantes era el micro. Centrándonos en los Intel, la wikipedia nos da un buen punto de entrada. Lo primero a saber es que existen varias generaciones.

  • La 5 generación de nombre Broadwell (o Intel Core 5th Gen) salió (aproximadamente) en Enero de 2015 y utiliza tecnología de 14nm
  • La 4 generación de nombre Haswell (o Intel Core 4th Gen) salieron en Junio de 2013 y utiliza tecnología de 22nm
  • La 3 generación lleva por nombre Ivy Bridge y es de 2012 así que la descartamos en el análisis.
  • Por el medio tenemos el Haswell-E (Agosto de 2014) y el Ivi Bridge-E (Septiembre de 2013) de los que sólo hay versiones i7 también en 22nm.

Hasta donde he podido entender a pesar de ser un logro tecnológico importante hasta finales de año probablemente no tenga mucho sentido comprar un ordenador con micro de 5 generación. Tras la generación la forma de clasificarlos es por «familia» o «gama» (o «product line»). Donde las fundamentales para portátiles como el que buscamos serían:

  • i3. Los de gama baja.
  • i5. Gama media. En versón mobile, tienen 3M de cache, 2 cores y TDP de entre 11.5 y 47 con muy pocos siendo de 47.
  • i7. Gama alta. En versión mobile, tienen entre 4 y 8M de cache, los hay de 2 y de 4 cores y TDP de entre 11.5 y 47 siendo la mayoría de 47.

Tanto los i5 como los i7 tienen Hyperthreading, Virtualización por hardware (VT-x) y Turbo Boost. Hay otras tecnologías (menos importantes para nuestro caso) como VT-d que dependen del modelo concreto y no de ser i5 o i7. Además hay que tener en cuenta que en algunos portátiles se montan micros de desktop y no de mobile. Por ello al final es necesario consultar las características concretas de cada micro. Para orientarnos con los modelos es bueno saber que suelen tener cuatro números y a continuación 1 o más letras. El primero de los números hace referencia a la generación, y las letras del final depende. Si son:

  • K, X, S o T se refieren a modificaciones concretas sobre el micro
  • Una M significa que es versión mobile con dos cores (aunque puede tener otro sufijo en lugar de la M y ser mobile igual)
  • MQ o HQ significa que es mobile pero tiene cuatro cores. La diferencia entre HQ y MQ es que los HQ van soldados a la placa (más difíciles de cambiar por tanto, pero mi impresión es que ligeramente superiores para el mismo modelo) y los MQ no.
  • U e Y significa que son pensados para ultrabooks porque tienen un menor consumo. Y menor consumo que U

Por ejemplo un  i7-4600M, es un i7 de cuarta generación mobile con dos cores mientras que un i7-4770HQ es un i7 de cuarta generación mobile con 4 cores. Otro ejemplo, un i5-4210Y consumirá menos que un i5-4210U que consumirá menos que un i5-4210M. Pero generalmente a menor consumo también menor velocidad de reloj y peor rendimiento.

GPU

Los micros actuales llevan «incluida» una tarjeta gráfica en el propio micro, y por tanto sería algo a considerar a la hora de escoger micro pero por ahora vamos a obviarlo.

Conclusiones

Lo que hemos visto en este artículo nos permite identificar a grandes rasgos las diferencias entre un micro y otro. Pero la pregunta más importante a resolver es al final si escoger un i7 con cuatro cores o un i5 con dos. Entender si para un caso concreto como el de escoger un ordenador para desarrollo es mejor más cores o más velocidad de reloj es algo que resulta difícil de responder. ¿Alguna opinión? Pero teniendo varias aplicaciones, incluidos servidores y máquinar virtuales funcionando a la vez, sin ser ninguno de los procesos muy intensivos, parece lógico pensar que más cores aunque sea reduciendo la velocidad es la decisión acertada. Para tratar de reducir el precio en la página de intel vemos que los modelos i7 del 470x al 472x serían buenas opciones, aunque como siempre al final dependerá de como cada fabricante monte el portátil.

Referencias

Resto de artículos de esta serie

Buscando un portátil – Impresiones sacadas de foros y reviews

Tras pensar un poco en los requisitos que debería cumplir mi futuro portátil una búsqueda en DuckDuckgo y google usando combinaciones de palabras entre best, laptop, linux, 2014, 2015, programmer, developer,… Dan un montón de enlaces para hacerse una idea general del mercado y ajustar requisitos.

Sacando de la lista los de 17 pulgadas, compañías que no venden en España, y los que tienen hilos en los que se quejan claramente del funcionamiento en linux. Los más populares parecen ser:

  • En ultrabooks, la Serie T (T440 por ejemplo) o S (S220 por ejemplo) de Thinkpad, y en menor medida también los Yoga y la serie X (especialmente el X1 Carbon y el x240). Pero hay que tener cuidado con con algunos modelos cuya distribución de teclado es bastante mala. Yéndose a un thinkpad con linux esta página puede ser de ayuda.
  • Tras los ultrabook de Thinkpad el entusiasmo parece recaer en Dell XPS 13 Developer Edition con Ubuntu preinstalado. Lo más leído es que es muy parecido en rendimiento y prestaciones a los MacBook. Pero en la web de Dell ya no parece disponible.
  • En cuanto a worksation de los mejor valorados está el Thinkpad W540, que con una docking station y la nueva tecnología de puerto Thunderbolt permitiría conectar varios monitores. El punto negativo es que lleva una nvdia con tecnología optimus a la que por ahora no se puede sacar mucho partido en linux por lo que hay que quedarse con la intel integrada. Y no es precisamente barato.
  • Otras workstation bien valoradas con ventajas y contras parecidos al W540 son el HP Zbook 15 y el Dell precision m3800 developer edition con ubuntu preinstalado.
  • En portátiles con Linux preinstalado la compañía system76 tiene productos interesantes como el Gazelle Professional, pero con los gastos de envio y aduanas puede complicarse un poco
  • En el sector medio, están el lenovo Y50. La línea de Asus N550JK (como el DS71T). Los Asus S551LN (como el 4500U) que si se puede comprar con 16 GB de RAM tiene muy buena pinta.

Otras consideraciones

Si se quiere meter más criterios en la búsqueda:

Impresiones generales

Revisando foros y reviews me quedo con algunas ideas, basadas en impresiones personales y seguramente poco objetivas y sesgadas por las páginas en las que entré.

  • Para tener menos problemas en linux se prefiere Intel y Nvidia sobre Amd y Ati. Aunque las nvidia con tecnología optimus tampoco funcionan bien ahora.
  • También hay que tratar de evitar Broadcom en chipset para wireless.
  • Los discos duros SSD parecen gustar, o al menos combinar un SSD pequeño con otro magnético y se recomienda irse a 16GB de RAM
  • No escoger ninguna resolución de pantalla por debajo de 1366×768
  • En cuanto a fabricantes en los reviews de revistas Lenovo y Dell parecen los más recomendados y luego HP y Asus. En los foros Lenovo, Asus y MSI aparecen bastante, y con Dell y HP hay opiniones contrapuestas, hay a quien le gustan mucho y quien ha tenido muy malas experiencias

Conclusiones

Es bastante complicado escoger un ordenador simplemente en base a las reviews y las opiniones. Para acertar con lo que se necesita manteniendo un precio lo más bajo posible, como mínimo hay que conocer los diferentes micros.

En general las reviews y los foros parecen bastantes inclinados hacia las gama alta y los ultraportátiles cuando en general, sobre todo si esperas una vida útil para un ordenador de trabajo de 4 o 5 años. Pudiendo luego reciclarse el ordenador hacia usuarios con menos requisitos y comprar otro de gama media para otro ciclo de trabajo.

Al principio valoraba mucho tener 1 Tb de disco duro, ahora me inclino más hacia un SSD de 500GB o un SSD pequeño y otro magnético mayor o incluso uno externo.

Referencias

Recomendadores y «certificaciones» linux para portátiles

Resto de artículos de esta serie

Buscando un portátil para programar

Ha llegado el momento de comprar un portátil nuevo para trabajar y la elección no es fácil. Demasiadas marcas, modelos y siglas para hacer una compra medianamente informado, así que antes de volverme muy loco, si alguno de mis estimados lectores tuviera alguna sugerencia sería muy de agradecer.

Precio: En torno a 1.000€, si es menos mejor.

Sistema operativo: Tiene que ser usable con linux al 100%

Objetivo principal, poder ejecutar a la vez:

  • Una máquina virtual con Tomcat (geoserver) y postgresql, que se llevaría 2 o 3 GB de RAM
  • Eclipse o emacs
  • Un virtualenv con una aplicación en python
  • Chrome con las dev tools
  • Firefox con un par de pestañas
  • Un par de cosas más, como un par de terminales, el reproductor de música, pidgin,…

Requisitos hardware:

  • 8 o 16 GB de RAM
  • 1 TB de disco duro
  • Pantalla de 14 o 15 pulgadas
  • Gráfica que no se coma RAM del ordenador. Si tuviera salida para dos pantallas sería ideal
  • Si tuviera VGA y HDMI por compatibilidad con distinta cacharrada sería preferible pero no imprescindible
  • Virtualización por hardware
  • El 90% del tiempo estará conectado a la electricidad, con teclado y pantalla externa, así que no hace falta que tenga mucha batería ni poco peso (mientras esté por debajo de 2.6kg)

Resto de artículos de esta serie

Compilando y depurando un plugin de ejemplo para gvSIG 2.1 desde Eclipse

Joaquín del Cerro ha publicado un artículo explicando como compilar y depurar un plugin de ejemplo para gvSIG 2.1 con NeatBeans. He adaptado sus instrucciones para Eclipse que es mi IDE habitual. Este artículo no es tan detallado como el suyo así que seguramente tendrás que consultar los dos, especialmente los pasos previos que comenta Joaquín para que todo funcione.

Una vez que tenemos los «previos» realizados, creamos un nuevo workspace en eclipse, por ejemplo workspace-gvsig-landregistry.

Nos aseguramos de que tenemos instalados en eclipse:

Abrimos la perspectiva de eclipse de SVN Repository Exploring, desde Window -> Open perspective -> Other, o cualquier otro de los sitios desde los que se puede abrir.

Y añadimos el repositorio del plugin desde File -> New -> Repository Location o el icono correspondiente. Como URL usaremos:

http://devel.gvsig.org/svn/gvsig-plugintemplates/org.gvsig.landregistryviewer/trunk/org.gvsig.landregistryviewer/

Seleccionamos el repositorio que acabamos de añadir y en el menú contextual escogemos Check out as maven project

Si no tenemos el conector de maven-svn instalado, nos pedirá instalarlo. En la ventana previa al checkout nos aseguraremos de que la opción «All projects» está activada

Puede tardar un ratito en descargar, sobre todo si tiene que descargar muchas dependencias. Cuando acabe, pasamos a la perspectiva Java y ya tendremos los proyectos correspondientes al plugin configurados en el workspace.

Si no tienes la opción de Build automatically activada, haz un build all. A continuación pon un punto de ruptura para comprobar que todo funciona correctamente en el punto que indica Joaquín (método createWindow de la clase LandRegistryViewerExtension).

Tras lanzar gvSIG en modo debug,


./gvSIG --debug --pause

configuramos el debugger. En Debug Configurations, añadiremos una nueva configuración del tipo Remote Java Application

En name pondremos lo que queramos, por ejemplo org.gvsig.landregistryviewer.app, en project org.gvsig.landregistryviewer.app.mainplugin y en port 8765. Si antes de crear la configuración de debug seleccionamos el proyecto org.gvsig.landregistryviewer.app.mainplugin en el package explorer nos rellenará automáticamente name y project.

Al darle a debug debería abrirse gvSIG y pararse la ejecución en el punto que hemos marcado.

Libro: Javascript. The definitive guide. David Flanagan.

Hace poco terminé de leer JavaScript. The definitive guide, de David Flanagan (la sexta edición). El libro tiene unas mil página aunque la segunda parte es una guía de referencia (que viene bastante bien para cuando trabajas off-line).

El libro cubre tanto el core del lenguaje como la API de cliente, es decir las funcionalidades que proporcionan los navegadores, y también tiene un capítulo sobre jQuery. A pesar de ser de 2011 está orientado hacia HTML5 y ECMAScript 5, así que cubre cosas como la API de Geolocalización, WebWorkers, WebSockets, Client Side Databases, …

Empecé a leerlo, sin conocer demasiado javascript y con la idea de adquirir buenas prácticas de desarrollo en javascript y en ese sentido me decepcionó un poco. El libro está bien, pero es poco opinativo. Javascript es un lenguaje muy amplió de por sí, y creo que cuando empiezas con él, es necesario que te fijen un par de ideas claras en la cabeza y no que te presenten todas las opciones disponibles. Por ejemplo, presenta muchos ejemplos de código donde enseña a lidiar con las diferencias entre navegadores, o como gestionar eventos, cuando en la práctica la mayoría usamos una librería tipo jQuery que nos abstraiga de esos problemas.

Mi próxima lectura seguramente será Javascript, the good parts, de Douglas Crockford, que es bastante más corto, y más orientado a promocionar buenas prácticas que a orientarse en el lenguaje. Cuando lo lea podré comparar, pero me da la impresión de que es mejor leer primero el de Crockford y luego el de Flanagan.

Supongo que las partes más interesantes variarán según para que tengas que usar javascript, para mi lo mejor del libro seguramente es:

  • Que dedica bastante tiempo al Cross Origin y problemas relacionados. Por ejemplo en la sección 13.6.2, 18.1.6. En la 22.3 que explica la API para que un script pueda pasar mensajes a otro objeto Window. Y en la 18.2 explica como gestionar JSONP.
  • El capítulo 18 en general, donde habla de Ajax (y algo de Commet) es bastante útil para aclarar conceptos.
  • El capítulo 10, es el típico sobre expresiones regulares, pero la verdad es que este merece la pena leerlo. Está bastante bien explicado incluido algunos conceptos avanzados que suelen obviarse.
  • Los capítulos del 6 (Objetos), 7 (Arrays), 8 (Funciones) y 9 (Clases), son para mi la parte central del libro. Conviene leerlos con calma y repasarlos para entender como funciona Javascript. En él tratan temas como los constructores y prototype, el hoisting, closures, o los atributos de las propiedades de los objetos o sparse arrays

Este libro es una muy buena opción si ya sabes algo de Javascript y quieres adquirir fundamentos más sólidos en el lenguaje. Si buscas un libro de introducción al desarrollo web o a la programación en javascript seguramente haya opciones mejores.

 

Otras críticas al libro