Por fin me pongo en marcha con este proyecto tan completito y a la vez tan inútil que llevo meses intentando empezar.
Voy a fabricarme un anemómetro digital casero con la sana intención de medir el viento reinante en la zona donde vivo y sopesar si merece la pena montarme un generador eólico de “pinipon“, que por supuesto también estaría amparado bajo la filosofía del HUM.

Mi primera idea era la que suele aparecer en todos los sitios en los que te explican como construir un anemómetro casero de cazoletas. Al conjunto rotatorio que forman las 3 cazoletas con el rodamiento se le incorpora un imán que al pasar por el sensor de efecto hall cierra un circuito que permite contabilizar una vuelta. Si calculas las vueltas por segundo ya tienes una medida de velocidad base que comparar con la velocidad del viento.
Es algo relativamente sencillo pero tiene un problema. No mide la dirección del viento. Se necesita una veleta adicional para medirlo.

Para construir una veleta también había varias opciones, las mas simples con 8 sensores magnéticos como el comentado antes te permitían saber -mas o menos- la dirección del viento de entre 8 posibilidades. Bastante patético.
Sin embargo la aproximación mas directa era la del potenciómetro. Un potenciómetro rotativo al que se le incorporaba la veleta, va quedando siempre en una posición determinada dependiendo de la dirección en que sopla el viento. Para cada posición la resistencia ofrecida por el potenciómetro es distinta por lo que mediante un simple conversor analógico digital de resolución suficiente podemos obtener un amplio abanico de valores que nos indiquen la dirección exacta del viento.
Desde luego parece la mejor solución si no fuera porque los potenciómetros normales que existen en el mercado no superan en el mejor de los casos los 270º de giro, por lo que siempre quedaría una zona muerta de 90º en la que no podríamos medir el viento.
Por supuesto hay potenciómetros de 360º, incluso los hay sin tope para que puedan girar locos, pero su precio en España es mayor que el de un kit de veleta completo comprado en USA, y yo, además de pasarlo bien haciendo inventos, espero también que no me arruine con ellos.

Seguí investigando y leyendo sobre el tema hasta que di con un curioso invento: un anemómetro que combina en el mismo aparato la captación de la velocidad y dirección del viento. Se llama Rotorvane Anemometer y hasta hace unos años vendían un kit para hacértelo tu mismo. Ahora RayMarine les ha comprado la patente y ya no se puede ver libremente que tecnología usan, aunque explican a grandes rasgos como funciona el invento.

Se trata de un anemómetro de cazoletas tradicional en el que una de sus cazoletas tiene una asimetría aerodinámica con respecto a las otras dos. Esto hace que a una velocidad de viento constante, la velocidad angular del conjunto varíe en determinado momento de cada giro dependiendo de por donde sopla el viento. Es decir, existe una diferencia entre la velocidad media del conjunto y la velocidad instantánea en algún punto de cada giro. Si sabes en que punto del giro se produce esa diferencia, sabes de donde viene el viento. Enrevesado, pero muy inteligente.
Afortunadamente el mundo esta lleno de frikis y James Derrick, que hizo el proyecto en 1999 (no ha llovido ni na), lo documentó de manera escueta, lo que me permite entender un poco mejor cuales son los pasos a seguir.

Lo que se me ocurrió a continuación fue fantástico y constata que tengo algún tipo de fijación con los ratones de ordenador. El principio por el que funcionan los ratones de bola es que un disco con perforaciones pasa por delante de un puente óptico que al ser interrumpido se interpreta como movimiento. Un ratón es capaz de dar distancia recorrida en 2 ejes mediante este principio y ademas el sistema es circular, así que me bastaría acoplar un disco perforado y engancharlo al sensor óptico de un ratón para que la circuitería del mismo me fuese diciendo el movimiento que realiza el rotor del anemómetro. La información me llegaría por el puerto PS/2 y un programa podría calcular la velocidad a partir de esos datos.

Así que me puse manos a la obra para hacer alguna pequeña prueba. Desmonté el ratón, enganché la rueda dentada al rodamiento y la uní a un pequeño motor de DC mediante una goma de transmisión, conecté el motor a la línea de 5V de mi fuente de alimentación de pruebas intercalando un potenciómetro para controlar la velocidad de giro y conecté el cable al puerto PS/2 de mi servidor Linux.
En el servidor hice un pequeño programa en C que abre el /dev/psaux y se pone a leer de el. Ayudandome de la información que encontré en la página de Computer-Engineering he podido configurar el ratón para que actúe a la máxima capacidad de muestreo (200 muestras por segundo) y máxima resolución (8 counts por mm) y me ha permitido saber para que sirven cada uno de los 4 bytes que envía el ratón en cada muestreo. El programa acumula todos los movimientos que le llegan del eje Y y va calculando la velocidad media cada segundo.

Los tiempos se toman en microsegundos (usec) y la velocidad lineal real de la rueda, que no tiene por qué ser la velocidad del viento cuando el invento esté montado, se calcula una vez por segundo y se hace a partir de los siguientes datos:

Velocidad es la velocidad calculada tics por microsegundo. Se multiplica por 1000000 para tenerla en tics por segundo.
La rueda de mi ratón tiene exactamente 40 agujeros. Esto quiere decir que cada agujero representa aproximadamente 9 grados de circunferencia (360/40 = 9). Al multiplicar por 9 los tics por segundo, consigo la velocidad en grados por segundo. Como 1 grado = 0.0174 radianes (2*Pi/360), multiplico y obtengo la velocidad en radianes por segundo.
¿Para que necesito la velocidad en radianes / segundo?, porque esta es la velocidad angular y para averiguar la velocidad lineal de un punto del borde del disco dentado tengo la fórmula:

v = r * w (uve igual a erre por omega)

donde omega es la velocidad angular y r el radio de la circunferencia. Como el radio de la rueda de mi ratón mide 0.9 cm multiplico por esa cantidad y obtengo la velocidad en cm/s. Ahora solo queda multiplicar por 3600 segundos/hora y dividir por 100000 cm / Km y obtenemos la velocidad en Km/h.

Por supuesto esta expresión y otras partes del código se pueden simplificar, pero lo dejo así por motivos didácticos… vamos que si la simplifico no me entero ni yo de por qué he hecho lo que he hecho

Con este montaje y estos cálculos he logrado que la rueda alcance los 50Km/h. Supongo que si le meto 12V o quemo el motor, o consigo mas velocidad, pero no me preocupa demasiado ya que teniendo en cuenta que el anemómetro entero va a tener un radio de giro de 5 cm, para la misma velocidad angular, la velocidad del punto central de una cazoleta tendría que ser de ¡mas de 300 Km/h!

¡Esto no ha hecho mas que empezar! Os mantendré informados de los progresos.

-Se positivo- le dijo el Protón al Electrón.
-No puedo- respondió el. -Va contra mi naturaleza-
-Inténtalo- insistió.
-¡No!, si me vuelvo positivo, saldría disparado y tu te quedarías en un Catión-, apuntó acertadamente.
-¿Y que tiene de malo?- replicó el Protón.
-Pues que tu te quedarías con la sal y yo me perdería en el vacío-
-¿Te asustan los cambios de estado, pues?- inquirió el Protón.
-No, solo recelo de aquellos en los que salgo perdiendo-.
-Pero ¡imagina cuantas aventuras podrías vivir en el vacío!, ¿acaso quieres perdértelas?-, preguntó asombrado el Protón.
El Electrón puso cara de incredulidad al tiempo que sentenciaba:
-Acabo de darme cuenta de por qué a pesar de nuestra atracción mutua, nunca hemos chocado,
¡tu quark es tan dura que supera con creces a la fuerza electrostática!-

Lo siento, se me acaba de ocurrir. Dedicado a los que tengan que soportar optimistas iluminados y vendedores de humo diariamente y a los que creen que los pesimistas son un pequeño contratiempo que hace mas interesante el camino. Si amigos, somos un sistema en equilibrio, por eso nunca nos libraremos los unos de los otros.

Como se puede ver, estoy algo menos que poco activo últimamente, pero como esto no es una página para contar mi vida, pues no lo haré .

Para otra de esas ideas que se me ocurren de vez en cuando, cuyo potencial comercial tiende a cero a gran velocidad, he tenido que instalarme y juguetear un poco con el Google Earth (si, ya lo se, tarde de nuevo, soy tan parecido a un early adopter como un núcleo de ferrita a una xD card).
Mi intención era la de conseguir los mapas de altura de zonas determinadas del mundo a partir de los datos que manejan los servidores de Google Earth (a partir de ahora GE para abreviar). La tarea parece sencilla a priori, ya que la propia aplicación te muestra una vista en perspectiva que te permite distinguir en relieve elevaciones del terreno, montañas, valles, ríos, etc y además te presenta el dato de altitud cuando pasas el ratón por encima del terreno. Para hacer eso se necesita la altitud o elevación de cada punto del terreno (o al menos de cada cuadrante, cara, polígono o como queramos denominarlo) por lo que esa información existe, el problema es que al parecer no se quiere que esa información salga mas allá de la aplicación de Google… pero de algún sitio la habrán sacado ellos.
Cuando exportas un fichero .kml o .kmz desde el GE con un punto de interés o una ruta (track) se guardan valores de elevación que en realidad son simplemente la posición en la que has ubicado en el GE cada punto con respecto al suelo, pero nunca se te ofrece la información de la altitud con respecto al nivel del mar a la que está ese punto que es lo que a mi me hace falta.
He buscado un poco y he dado con algún servicio web que te proporciona esa información, aunque con bastantes restricciones. Para un punto dado de latitud y longitud EarthTools te responde con un XML conteniendo la altitud en metros y pies.
Por ejemplo podemos pedir la altitud del pico de Peñalara mediante esta URL http://www.earthtools.org/height/40.850751/-3.955792 y nos devolverá algo como esto:

El servicio está muy bien, como se ve la precisión no es demasiado buena pero tampoco preocupante (Peñalara mide 2430m.) pero tiene un problema: este servidor solo te permite una consulta por segundo, para evitar colapsar su ancho de banda, por lo que sacar mapas de alturas se hace un poco tedioso.

Sin embargo, un poco mas de investigación me ha llevado hasta Geonames, que también da un servicio similar solo que sin formatear, tu le pasas las coordenadas geográficas y te devuelve simplemente la altura en metros. Por ejemplo:
http://ws.geonames.org/srtm3?lat=40.850751&lng=-3.955792 devuelve simplemente 2413m.
En este caso la precisión es mayor y por lo que veo no hay restricciones de uso, quizas sería un buen lugar para hacer consultas automatizadas.
Lo interesante es que los datos de este servicio se recogieron mediante técnicas de RADAR en una misión de una lanzadera de la NASA que se denominó Shuttle Radar Topography Mission (SRTM). Me da la impresión de que estos son los datos que usa GE.
También poseen otro modelo digital de elevaciones llamado GTOPO30. La URL de acceso es similar aunque los datos son algo peores para mi ejemplo de referencia.
http://ws.geonames.org/gtopo30?lat=40.850751&lng=-3.955792 ofrece un resultado de 2125 m.
En Geonames ofrecen también muchos otros servicios web referentes a geolocalización. Ofrecen incluso una completa base de datos de puntos geográficos por países, incluyendo embalses, montes, municipios y muchos mas que podemos descargar.

Retomando un poco el tema del SRTM, existe una página de este proyecto en la que te permiten descargar un .kml (y un ASC con los datos en el formato de Arcview) que contiene todos los datos de elevación que se capturaron, con una resolución de unos 90mts (o más correctamente, en arcos de 3 segundos de grado, que en el ecuador son 90 mts.). Como es tanta información, los datos se han dividido en cuadrantes de 5×5 grados en coordenadas geográficas WGS84 datum. Por ejemplo, los datos referidos a España se encuentran en las zonas o cuadrantes 35_4, 35_5, 36_4, 36_5, 37_4 y 37_5.
Es esta web por cierto explican porque puede haber errores en las altitudes de picos montañosos. Es debido a que normalmente estas regiones suelen estar cubiertas de nubes o nieve que interfiere negativamente con el sistema de medición por radar que se usó para obtener estos valores. Esas medidas que no pudieron tomarse conforman “agujeros” que hay que rellenar mediante interpolación. La interpolación tiende a suavizar las lineas con lo que los valores de altura en los picos se suavizan y suelen ser menores que el valor real.

En una partida de cartas, la tarea de calcular el valor de una mano para saber si gana a otra se llama evaluación de manos (hand evaluation). Para un ser humano que ha aprendido las reglas de un juego de cartas cualquiera, la evaluación de manos es una tarea trivial, nada mas ver las cartas sabe que un poker es mas que una pareja, o que dos reyes caballo ganan a dos reyes sota.
Pero para un ordenador la tarea no es tan sencilla si se quiere hacer de manera eficiente y la gente se estruja el cerebro para conseguir dar con algoritmos que realicen esta tarea rápidamente y sin errores.
Yo ya me vi una vez en esta tesitura cuando hice el juego de mus multijugador de Teknoland, el mus de Commm, y la verdad es que inventé un sistema bastante bueno que con las cartas ordenadas asignaba a cada una un valor que dependía de la fase que se jugaba y lo multiplicaba por una potencia de su posición en la mano. De este modo conseguía un número entero que me permitía comparar manos de distintos jugadores, la del entero mayor era la que ganaba (salvo en la chica, claro).

Ahora me veo en la misma tesitura pero para otro juego mucho mas popular que el Mus… el Poker.
(más…)

Aprovechando que mi ansia de desmontar cosas se ha juntado con una batería del portátil que no funciona y con un cartelito que reza “DO NOT disassemble”, me he propuesto aprender un poco mas acerca de estas caras muestras de la hijoputez de las multinacionales.

Como decía hace no mucho Dan Knight, de Low End Mac, en su artículo Inside Your Notebook’s Battery: Ordinary AA Li-Ion Cells, la batería de un portátil no deja de ser mas que una mera caja de plástico carísima que contiene pilas recargables de Iones de Litio de a 5 Euros la pieza acompañadas de un pequeño circuito integrado.
Ya intuía que estas baterías debían llevar dentro algo más. Al parecer todos esos integrados sirven para regular el régimen de carga y descarga y controlar el nivel de la batería y su temperatura, lo que debe implicar cierto nivel de comunicación entre baterías y portátiles. Investigando un poco he concluido que de los 5 contactos que posee la mía, 1 lleva la alimentación (14.8V), 1 es la masa, 2 se usan para las comunicaciones (clock y data) y el último para la medición de temperatura, pero es imposible saber con certeza cual es cual porque no hay forma de encontrar una hoja de especificaciones de una batería de estas, aunque si que he leído que algún manitas que se ha hecho un programa para comunicarse con la batería vía I2C (muy usado en la programación con microcontroladores) mediante el protocolo SMBus que es el estándar que se usa.

Mirando cuidadosamente el circuito que lleva la batería se descubren sus componentes básicos:

• Un integrado encargado de monitorizar las pilas, en mi batería es uno marcado como bq2040 que resulta ser un medidor de carga con interface SMBus de transmisión serie implementando el estandar Smart Battery System. Es un circuito capaz de recalibrarse fijandose en lo que dura un ciclo completo de carga/descarga usando un timer y un sensor de temperatura internos. Parece ser que este chip se programa mediante una eprom externa para inicializarlo, lo que explicaría en cierta medida por qué mi batería, a pesar de dar casi 16V. a la salida, no funciona. Este maldito chip ha decidido que la edad de la batería, o el número de ciclos de carga, es suficiente para darla por desahuciada y a pesar de que se recarga, informa al portátil de que la batería está agotada. Hay otros integrados con la misma función aunque mucho mas complejos y completos, como el MAX1780.
• Un fusible térmico que corta la corriente si hay un exceso de temperatura no controlado por el integrado anterior. No es recuperable ni reemplazable. Al mio, también fácilmente ubicable, le he medido la continuidad y da infinito… osea que está frito. Puede que el bq2040 no sea el culpable de todo al fin y al cabo.
• Un grupo de TPC8103, transistores FET que al parecer actúan como interruptores de control que cortan el ciclo de carga o descarga bajo las señales de control del integrado .
• Un regulador de corriente de 3A LM350
• Una memoria EEPROM de 2 hilos S-240C0

Dan Knight apunta muy acertadamente que si los fabricantes de portátiles incluyesen esa poca circuitería para el control de la batería dentro del propio portatil, el resto de los mortales podríamos comprar cualquier pila recargable y usarla para dar autonomía al mismo. Pero claro, eso le restaría unos suculentos ingresos a las citadas compañías. La batería de portátil mas barata debe andar por los 100Euros, que es probablemente la mitad de lo que cuesta todo el portátil en el momento que este necesite dicha batería.

Esto no soy yo ni el segundo ni el tercero en pensarlo, y para muestra un enlace, una página donde enseñan paso a paso como cambiar las pilas de una batería recargable modelo FPCBP25 de un Fujitsu – Siemens Lifebook S-Series además de dar unas cuantas lecciones acerca de esta parte del hardware tan desconocida.

Lo que se les olvida mencionar en este fantástico artículo es la reprogramación del integrado de control de la batería. Resulta que para eso también hay software disponible. El AccPlus es una utilidad para comunicarse con una Smart Battery (se denominan así a las que implementan el SMInterface) y permite reprogramarla y leer sus EEPROMs a través de un adaptador del puerto paralelo del PC que lleva un integrado de Philips implementando el estandar de comunicación I2C. Algo de esto cuentan en el apartado de “How to service laptop batteries” de la página de la universidad de las baterías.

De todos modos tengo que advertir, aunque no lo he vivido en carne propia, que las baterías de Iones de Litio son tan caras y vienen siempre montadas en packs por la sencilla razón de que son MUY PELIGROSAS si están dañadas o se manipulan de forma erronea… y tiene su lógica. 4400mAh que es la capacidad de mi batería, por ejemplo, significa que es capaz de descargar 4,4Amp a lo largo de una hora. Si por cualquier razon, cortocircuito, temperatura excesiva, rotura en el envoltorio, se produjese una descarga inmediata, 4,4 Amperios son muchos Amperios y sueltos en un ambiente lleno de sustancias químicas como son las pilas, puede producir una explosión bastante seria.
Además los iones de Litio se pueden llegar a convertir en Litio si hay escapes, y el litio combustiona al contacto con el H₂0, incluso si solo es el de la humedad del aire.
Por eso os digo amiguitos, NO JUGUEIS CON LAS BATERÍAS EN CASA… hacedlo por lo menos al aire libre y con algo de protección, eso si, como siempre, bajo vuestra propia responsabilidad, si es que la tenéis. Y si no la tenéis, compraros una.

Para saber casi todo lo que se puede saber sobre baterías, y aclarar muchos de los mitos que las rodean, mirad en la Battery University y en Batteries in a portable world.

Yo tenía un portátil HP Omnibook XE2 que un día decidió irse de viaje a Irlanda sin mi, había elegido mejor compañía. Lo cierto es que conmigo se aburría mucho porque no soy un tio muy viajero así que se piró, y yo no esperaba volver a verle. Sin embargo el destino y un vaso de agua derramado por encima de el, hicieron que el pobre portátil entrase en coma y volviese al hogar.
Por supuesto nadie repara un portátil al que le ha caído un vaso de agua por encima, mucho menos si es un PIII y tiene 5 o 6 años de antigüedad, así que me decidí a desarmarlo como todo lo que cae en mis manos.
Le saqué todas las entrañas, vi las marcas que había dejado el agua por todas partes y llegué hasta el punto donde realmente se había jodido la placa base, cerca de la toma de alimentación había un par de integrados totalmente chamuscados. Olvídate de que tenga arreglo.
Un buen día navegando por Ebay se me ocurrió buscar “Omnibook XE2″. Impresionante, un tio vendía SOLO la base del portátil, sin disco duro, sin pantalla, sin memoria, sin disquetera ni cd ni na… solo la placa base con su procesador y caja de plástico. Me decidí a pujar y me lo llevé. Cuando lo recogí me di cuenta de la cruda realidad. Hay 12 modelos de Omnibook XE2, empezando por PII a 333 y terminando por PIII a 500, pasando incluso por AMDs… y claro, como no pregunté, este era un PII a 333 cuya placa base no se parece en nada a la mía. Ahí se quedo en mi montón de chatarra informática.

Pero unos meses después, con una búsqueda automática en Ebay, me llegó otro anuncio. Un tipo que vendía despieces de 4 portátiles XE2, igual que anteriormente, no venían pantallas, solo los marcos, no llevaban disco duro ni memoria, aunque había un par de CDs y de disqueteras. ¡Uno de los portátiles era un PIII! Loco de contento pujé por el lote y lo volví a ganar.
Con el en casa comencé de nuevo las cirugías. Le metí la memoria, un CD, el disco duro y ¡arrancó conectado al monitor externo! Yujuuuuu

Luego le puse la pantalla LCD. Se veían cosas, pero no tenía retroiluminación. Parecía que el inversor estaba petado. Aunque en el lote de Ebay no venían pantallas si que venían los marcos… ¡con los inversores dentro! vamos, una potra total. Cambie el inversor y ale, ya funcionaba la pantalla.

Yo ya me las prometía muy felices, había recuperado el PIII y la pantalla, tenia el portátil como nuevo otra vez, así que me dispuse a entrar en windows para hacer backup de lo que hubiese en el disco y de repente… el portátil va y se apaga. ¿Que ocurre? Lo vuelvo a encender y al rato, se apaga de nuevo.

Le cambie todas las piezas posibles por las que tenía pero nada, siempre lo mismo, al cabo de un rato, unas veces duraba mas, otras menos, se apagaba solo. Daba igual que tuviese todo conectado o la placa base desnuda sin nada. Daba igual que arrancase WindowsXP o Knoppix. Al cabo de un periodo aleatorio de tiempo, plof, apagado.

Primero sospeche de la temperatura, pero no podía ser, porque a veces se tiraba media hora encendido, haciendo los diagnósticos internos, poniendo la CPU a tope y la memoria y no se apagaba.
Incluso encontré un manual de servicio del portátil, pero que servía de bien poco, ya que cualquiera de los problemas que se solucionaban en dicho manual eran bastante obvios.
No había un patrón identificable en el problema y no desaparecía ni cambiándole el procesador, así que he deducido que es de la placa base, pero como no tengo mas placas base de PIII pues a fastidiarse.
Al final acabe montando uno de los PII con todos los componentes que funcionaban bien del resto de portátiles y reinstalando Windows XP porque el PII no arrancaba con el disco duro tal como estaba (no se la razón).

Es decir, que tengo una especie de frankestein portátil, pero que funciona. Eso si, la batería está agotada, así que la denominación de “portátil” la cambiaremos por la de “facilmente trasladable” .

Llevo bastante tiempo descolgado del Macromedia Flash ya que me dedico principalmente a la parte servidor de los juegos que se producen en Zinkia, pero ahora me ha dado por renovar un poco las librerias de conexión y comunicación, que hice en 2002 en Flash 5, para adaptarlas a los nuevos tiempos, sobre todo para aprovechar que el ActionScript2 ya se parece a un lenguaje de verdad, concretamente se parece mucho a Java, y me he encontrado con que esto está evolucionando de un modo vertiginoso y que me he quedado bastante atrás, como siempre.

La primera versión de nuestras librerias se hicieron en ActionScript 1.0. Esta versión del lenguaje no soportaba directamente la programación orientada a objetos mas que de manera parcial. Algunas cosas eran objetos y tenian propiedades, como los MovieClips, pero no habia una manera ortodoxa de crear clases, habia que hacerlo mediante prototipaje y con artimañas y gracias a un extenso y muy bien ilustrado tutorial sobre ello, el de Debreuill, fui capaz de montar una serie de clases que han sido la base de las comunicaciones de todos los juegos para Flash que hemos hecho desde entonces.

Así era antes:

¿Por qué era tan complicado programar orientado a objetos en Action Script 1.0? Pues por que le faltaban todas las caracteristicas que un lenguaje debe tener para ser orientado a objetos. No existian los tipos de datos explicitos, es decir, las variables podian contener un numero y al momento siguiente un texto, dependiendo de lo que les asignase el programador, lo que daba lugar a multitud de errores indetectables por despistes e impedia hacer las variables privadas, con lo que perdemos la capacidad de ocultación o encapsulamiento de la infomacion inherente a los lenguajes OO.

La herencia entre clases, aunque no era imposible, si que era complicada de implementar, al igual que lo era el polimorfismo, ya que eran necesarios trucos para sobrecargar metodos de clases padres.

Todo esto cambió con la llegada de AS 2.0 en el que las variables se han vuelto “fuertemente tipeadas” (no me gusta nada esta expresión), pueden ser publicas o privadas, las clases pueden declararse abstractas, existe la herencia con “extends” e incluso los interfaces y los namespaces, vamos, casi como Java salvo por la sintaxis que difiere mínimamente.

Así es ahora:

Mi siguiente paso ha sido buscar un plugin para el Eclipse que me permita tener proyectos en ActionScript. Cualquier programador que se precie coincidirá conmigo en que el entorno de desarrollo de Flash esta pensado para todo menos para los programadores (es lógico, por otra parte) por eso me llevo el desarrollo a un lugar (Eclipse) mas amigable. Mientras buscaba encontré 2 que tenían buena pinta, el ASDT y el FDT. El inconveniente de este último es que es de pago, aunque tienes una versión de prueba de 30 dias. Es una lástima porque es manifiestamente mejor y aprovecha mas las ventajas del Eclipse, integrandose perfectamente. En cualquier caso, he estado probando el ASDT y como siempre, me ha costado mas de la cuenta que funcionase correctamente, no tanto por dificultad de instalación, que no tiene ninguna, sino por falta de información, ya que no lleva documentación alguna.

Ambos plugins necesitan tener acceso a las Core Libraries de Flash para saber los tipos de datos, o mas correctamente, las Clases nativas y así poder hacer code highlighting y corrección del código sobre la marcha. Para tener esas librerías es necesario tener instalado FlashMX 2004, Flash8 o en su defecto, el MTASC.

No tenia ni idea de que existiese un compilador de ActionScript Open Source. Eso es precisamente el MTASC, que ha sido producido por MotionTwin Technologies. No me entretengo en comentar sus ventajas, solo dire que gracias a el podemos compilar todo el ActionScript que hagamos en el Eclipse sin necesidad siquiera de tener instalado Flash, ya que MTASC trae su propio paquete de core libraries.

Se hace bastante raro el programar en Flash sin gráficos , por eso aunque se puede tener Action Script compilado sin necesidad de tener Flash instalado, es mejor tener el Flash para poder hacer cosas interesantes y vistosas.
El principal problema que presentan estos dos plugins para Eclipse es que llevan mas de año y medio sin actualizarse y sus creadores parece ser que han abandonado el desarrollo. Por su parte, el MTASC también parece tener sus dias contados ya que sus desarrolladores estan centrados en la creación de un nuevo lenguaje, el HaXe ,que permite producir Javascript y Flash para la producción de aplicaciones web (que mania con crear lenguajes nuevos).

Me empeñé en buscar plugins mas recientes sin resultado, hasta que encontré una razón poderosa para ello. Gracias a la web de Carlos Rovira (si, ya se que se parece demasiado a cierto político XD), empecé a leer cosas sobre Flex2 y a darme cuenta de por donde van los tiros.
No me extraña que los creadores de esos plugins abandonasen, porque ha entrado en escena la todopoderosa Adobe, que hace no demasiado compró Macromedia, y que ha sacado su propio IDE y mega plugin gigante para Eclipse para desarrollar lo que ahora se llaman RIAs (Rich Internet Application) y que no es otra cosa que aplicaciones basadas en el reproductor de Flash9 (si, yo también me sorprendí de lo poco que ha durado el reproductor de Flash8, que segun parece tenía mas problemas que caracteristicas nuevas), con todo el efectismo que eso conlleva (de ahí lo de “Rich”). Han tirado para alante, han sacado el ActionScript3 y a todo el conjunto lo han llamado Flex 2.
Este IDE y plugin para producir en Flex2 se llama Flex Builder 2 y voy a probarlo una temporada para poder emitir algun juicio. Es posible que ya no tenga que pelearme con los “viejos” plugins de ActionScript2 o puede que sea demasiado grande para lo que yo quiero hacer. Ya veremos.

(NOTA: No confundir Flex 2 con el Flex (Fast LEXical analyzer generator), la herramienta heredera de LEX y que acompaña fielmente a BISON el generador de parseadores de lenguajes, igual que LEX acompañaba a YACC, mas sobre Lex/Yacc)

Eso es lo que se podia oir entre los bytes del /dev/hda del servidor Linux que sirve estas páginas. He tenido que hacer un trasvase que ríete tu del Tajo-Segura.

El tema es que mi servidor tenía 2 discos, el hda y el hdb. El bueno y gordo es el hdb asi que decidí usar el hda para poner la particion de swap y contener el directorio /boot que no ocupan demasiado. Todo lo demás, el raíz /, iría en el otro disco, asi tendría separadas las operaciones de swapping, que en un equipo con tan poca memoria suelen ser frecuentes, de los accesos al resto de los datos del servidor.

Pero yo no contaba con la mala leche de los discos duros, y resulta que este hda maldito, que ya habia pasado por algun que otro equipo windows (y quizas como venganza por ello), ha empezado a fallar y a hacer ruidos raros, sobre todo en dias de mucho calor como han sido estas últimas semanas. Un característico CLACK-CLACK que precedia a su parada eran las únicas señales. Cuando este disco se para, me quedo sin swap, por lo que el servidor se cuelga.

Tras unas consultillas a uno de los gurús de Linux que tenemos en SoyGeek hemos dado con la solución menos mala. Tengo que trasvasar el directorio /boot y el swap al otro disco y eliminar o al menos poner como secundario al disco travieso. Y esto que parece tan fácil, pues no lo es, pero con la ayuda de Futur3 y su guía para catetos de Linux, lo voy a intentar.

Lo primero es copiar el directorio /boot de un disco a otro. Como no hay una orden que haga eso lo que hago es copiar /boot, que está montado en hda1, a /boot2, lo que automaticamente hace la copia en hdb1, ya que el / está montado allí. A continuación desmonto /boot (umount /boot) y renombro /boot2 a /boot (mv boot2 boot).

Ahora voy por el swap. Como no puedo reparticionar el hdb, porque me cargaría todo lo que tengo alli, lo que hago siguiendo los consejos y detalladas instrucciones de Futur3, es crear un fichero de swap en lugar de una particion de swap.

Después modifico mi /etc/fstab para borrar la entrada de /boot y sustituir la partición de swap por el fichero de swap:

A continuación, para trasladar el gestor de arranque, ejecuto el comando “grub” y le digo lo siguiente:

con lo que consigo instalar el grub en el MBR de hdb.

Ahora viene lo bueno, apagar el servidor, quitar el disco defectuoso, configurar el otro como master y/o cambiarlo de bus IDE si es necesario, para que quede como hd0.

Luego rearrancamos…

Si ha habido suerte, este post estará publicado, si no, no podreis ver Makinolo durante una temporada X-D

Pues bueno, no ha habido suerte y he tardado cerca de 1 hora y media en recomponer el servidor. Resulta que al hacer el setup en el grub este se configura para coger el kernel del Linux del directorio raiz y mi kernel esta en el directorio /boot, asi que el muy capullo no lo encontraba y no arrancaba.

Para mas inri la pantalla tenia algun problema raro y estaba llena de rayas verticales y el teclado configurado en inglés, con lo que he tardado mas de la cuenta en saber que pasaba y en arreglarlo.

Entrando en la linea de comandos del GRUB le he especificado

y ha vuelto a arrancar, despues he editado /boot/grub/menu.lst y he escrito correctamente la ubicacion de ambos ficheros ademas de eliminar el splashscreen. Ahora todo vuelve a funcionar, el servidor tiene un disco duro menos y yo una experiencia traumatica con el Linux mas.