Jesús Navarrete
In java @deprecated word means (directly from the Java API):
A program element annotated @Deprecated is one that programmers are discouraged from using, typically because it is dangerous, or because a better alternative exists. Compilers warn when a deprecated program element is used or overridden in non-deprecated code.
a way to say that something is from the past and we’re not going to update/use anymore. No more fix, no changes, no maintenance.
It’s easy to use, because you only need to write:
/** * @deprecated any-reason-if-you-want */
or use @Deprecated annotation.
Easy to use, but not always well used. Sometimes I find uses of this keyword that it’s bad, at least in my opinion. I’m talking about refactoring. As bis as your project is, it’s very difficult to refactor, I know. But IDEs like Eclipse give you a very good tools to refactoring, in particular, change the name of your method or class.
If you use deprecation like a way to “change” the name of a method, because you found one more descriptive, you’re doing something wrong. The first, you are giving two different ways to do the same thing. The next developer could think why you don’t change this name and the most probably is that he don’t delete it. Other problem is that you have to update your Javadoc when you decide to change the new method name. Why don’t you decide to change the name only and fix the issues if they exist?
Don’t left that for the next iteration, don’t allow others to think “Why is this here?”. And don’t think that you are going to have more time in the future to delete that.
It’s different if you are using your class in serialization, the problem is more complex, not impossible, but yes more complex. If you have a public API with some version open to customers, you must to use deprecation.
Tiempo atrás queda ya la adquisición de Sun por parte Oracle. Ya desde sus inicios surgieron dudas acerca del cómo sus productos serían absorbidos. Tiempo ha pasado y ya se han visto algunos resultados: OpenOffice, Open solaris, Glassfish, MySql, Java…
Más tarde saltaría la primera demanda por el uso de Java desde Oracle a Google. Se le acusa de violación de diversas patentes en su SO Android, Google se defiende y pide que se desestime la demanda. ¿Podríamos ir considerando esto un tipo de presión? ¿Una forma de hacer caja por parte de Oracle? Algunos intentan dar alguna explicación y arrojar luz al por qué.
Llega la JavaOne, uno de los eventos más populares y famoso en el mundo java. No se revela nada importante; parece hablarse mucho de JavaFX. Aunque, de los temas candentes del momento como el futuro de Java, las demandas por patentes, etc, ni una palabra. La keynote de Larry Ellison muy orientada a los clientes de Oracle y no tanto a la comunidad Java. Un evento totalmente desvirtualizado.
En otro orden, IBM, después de contribuir durante tiempo a Harmony decide crear una nueva alianza con Oracle, posicionándose a su lado y discontinuando sus contribuciones a Harmony en favor del OpenJDK. Apache se pronuncia, aunque dice poco acerca del futuro de Harmony o suficiente, según se quiera interpretar.
De forma paralela se aprecian noticias de nuevas alianzas, hablamos de Google y VMWare. ¿Está esto manifestando algo más? ¿Son un grupo de presión? ¿Van a funcionar al margen de Oracle, en paralelo o entrarán por el aro?
Apple da su keynote, anuncia sus nuevos productos, su nueva dirección, y comunica que java está deprecated. Se cruzan correos, Steve Jobs responde, pero hay opiniones encontradas, por ejemplo de Gosling.
De forma paralela, llegan las elecciones del JCP. Oracle se saca de la chistera a una empresa (Hologic) de la que nadie ha oido hablar, un intento de sustituir a Doug Lead, que abandona el comité por voluntad propia; Henrik Ståhl, responde. Ian Skerret, director de marketing de la Fundación Eclipse, en una carta dirigida a Oracle le resalta qué es lo que está haciendo mal.
Estas son algunas de las reacciones que la comunidad ha iniciado y le seguirán más. Algunos empiezan a pedir públicamente un fork de java, otros empiezan a aunar firmas para la liberación por parte de Apple de su JDK… A lo que supongo vendrán más.
¿Es tiempo de ir mirando otros lenguajes? Mejor esperar y, ¿verlas venir? ¿Qué opináis?
Intentando configurar un entorno multistage en dreamhost para un proyecto personal y tras haber logrado el despliegue para mi configuración de staging, al comprobar la aplicación descubro que Passenger me da un error. Dado que según él no es un error de aplicación, me recomienda comprobar los logs del servidor web, para ver la traza del mismo.
Por si os sirve de ayuda, en dreamhost los logs del servidor, se encuentran en:
/home/username/logs/yourdomain.com/http.#####/access.log
/home/username/logs/yourdomain.com/http.#####/error.log
Los tenía localizados, pero no lograba ver nada en error.log, y en access.log sólo veía mis peticiones, lo normal.
Hace tiempo que no actualizo el servidor, y pensaba continuamente en los posibles errores que podría haber con respecto a versiones de gemas utilizadas, por lo que después de redesplegar varias veces intentando reajustar, seguía sin lograr ver la traza del error.
Tras comparar con mi instalación en local, decido buscar a fondo en el servidor, compruebo versiones de gemas, configuración, tenía cambios importantes con respecto a una versión anterior, a parte de estar utilizando una versión mucho más reciente de Rails, pero seguía sin funcionar y sin ver nada en las trazas. Cierto es que tenía algunas cosillas que no estaban del todo bien, y que gracias a esto he ido corrigiendo, pero nada que apuntase en la dirección del erro. Así que ejecuto un simple:
rake -T
si todo funciona bien con los plugins y las gemas, me dará el listado de tareas, simple; y he aquí que localizo la fuente del error! La versión de RubyGems es demasiado antigua para esta versión de Rails, la verdad es que las trazas inexistentes no han sido de gran ayuda para ver este error 
. Mi versión era la 1.2.0 y se requería mínimo la 1.3.
Decidido a solucionarlo, intento actualizar, un simple:
gem update –system
… no soluciona nada, dado que responde con un:
Nothing to Update
Así que probamos la siguiente opción:
gem install rubygems-update
update_rubygems
El problema es que ya de partida la instalación de rubygems-update, versión 1.3.5, arroja unos errores, aparentemente no preocupantes al terminar de instalarse, sin embargo al intentar ejecutar el segundo comando, nos da un error, siento no haber anotado la traza.
Navegando en internet, descubro que dicha versión tiene ese problema, que está anotado en los foros, pero que no ha sido resuelto, y la recomendación es: instalación manual; ante esto me han entrado las dudas y la simple pereza. Si actualizaba, ¿existirían problemas con mis gemas instaladas en mi directorio personal? Tendría que reinstalarlo todo, en principio suponía que no, pero no estaba del todo seguro, cuando sin embargo me he acordado de algo.
En las últimas versiones de RubyGems, si no antepones sudo, al comando de instalación, la copia se hace en la home del usuario que instala y todo funciona sin problemas, para él. Así que me he decidido por quitar todas las configuraciones que existían en mis ficheros acerca del mi propia instalación de RubyGems y he logrado comprobar que los chicos de dreamhost ya habían actualizado a la última versión. Así que ni corto ni perezoso he pasado de actualizar manualmente mi copia, y eso sí, continuaré utilizando mi instalación de gemas en mi cuenta de usuario, así podré controlar que gemas instalo y que versiones, dado que no siempre he encontrado las gemas que necesitaba instaladas, es por esto por lo que empezó todo (…y por no poder ejecutar sudo ).
Para todos aquellos que seguís este blog, y continuáis ahí después de la última actualización… decir que se va a realizar una migración total del sistema, esto es: servidor, sistema de blog, actualización de los feeds y un pequeño cambio en el dominio.
Los cambios:
- El sistema de gestión del blog, hasta ahora serendipity, deja de ser el alma del blog y pasamos a WordPress. Todos los datos, las imágenes, etc. han sido migrados ya.
- Los feeds. Con respecto a esto hace tiempo que empezé a utiliar feedburner, pero tras la compra por parte de google, he migrado la cuenta tal como me recomendaba el sistema y a partir de ahora hay una nueva dirección:
http://feeds2.feedburner.com/jenaiz
aunque según cuentan el sistema redireccionará automáticamente a los antiguos. Os recomendaría pasaros a la nueva dirección.
- El dominio, un pequeño cambio. La dirección del blog ahora colgará de:
así el dominio general dará cabida a otras cosillas que iréis viendo.
- Cambiamos de servidor, nos pasamos a utilizar el servicio de dreamhost a ver que tal resulta.
Golpes de tambor….
- Habrá un nuevo diseño, que espero os guste más que el actual. Un poco más moderno, y con colores que permitirán leer los post con mejor contraste.
Sólo decir que la gestión del dominio cambiará también de servidores, por lo que puede que existan algunos problemas en 24 – 48 horas.
Investigando un poco el comportamiento de acts_as_scribe, me surgió la necesidad de instanciar un clase conociendo el nombre de la misma. Algo que en java conocía como se realizaba:
Object o = Class.forName("className").newInstance()
lo curioso es que vi que no necesitaba esta solución, que mi problema era otro , sin embargo la curiosidad pudo más que la necesidad.
Esperaba utilizar para ello la misma clase: Class, sin embargo descubrí que no podía hacerlo así. En Ruby el camino es distinto. Un post en stackoverflow me llevó a encontrar una solución múltiple, aquí las distintas posibilidades:
Object::const_get('String').new()
class_name = 'String'
eval(class_name).new
Module.const_get('Array').new
Y un helper:
"String".constantize.new
Module.const_get no funciona con clases anidadas en módulos, digamos que no admite la sintaxis Admin::Folder, debido a que sólo reconoce sintaxis válidas para dar nombre a una constante.
eval, por el contrario sí permite nombres de clases con namespaces, aunque sufrimos un decrimento en el rendimiento.
Podríamos comprobar el rendimiento de todas ellas con un simple script:
#class_instanciation.rb
#!/usr/bin/env ruby
#
# Created by on 2008-11-24.
require 'benchmark'
require 'qualified_const_get'
n = 1000000
Benchmark.bmbm(10) do |rpt|
rpt.report("simple") do
n.times {Array.new}
end
rpt.report("Object::const_get") do
n.times {Object::const_get('Array').new()}
end
rpt.report("Kernel.const_get") do
n.times {Kernel.const_get('Array').new}
end
rpt.report("Kernel.qualified_const_get") do
n.times {Kernel.qualified_const_get('Array').new}
end
rpt.report("eval") do
n.times {eval('Array').new}
end
# no funciona!!
#rpt.report("eval") do
# n.times {"String".constantize.new}
#end
end
#qualified_const_get.rb
module Kernel
def qualified_const_get(str)
path = str.to_s.split('::')
from_root = path[0].empty?
if from_root
from_root = []
path = path[1..-1]
else
start_ns = ((Class === self)||(Module === self)) ? self : self.class
from_root = start_ns.to_s.split('::')
end
until from_root.empty?
begin
return (from_root+path).inject(Object) { |ns,name| ns.const_get(name) }
rescue NameError
from_root.delete_at(-1)
end
end
path.inject(Object) { |ns,name| ns.const_get(name) }
end
end
Los resultados obtenidos los podéis ver en la siguiente gráfica:
en ella podemos apreciar que si utilizamos const_get se tarda aproximadamente 2 veces más que con la creación normal; que el uso de eval nos hace emplear 5 veces más tiempo y que sin duda la implementación de qualified_const_get no es nada buena, dado que nos hace emplear unos 10sg! osea unas 15 veces más.
La recomendación sería utilizar const_get siempre que se pueda, es decir mientras nuestra clase no tenga namespaces y eval cuando no quede más remedio. El caso de qualified_const_get, me parece poco apropiado para cualquier caso.
Por otro lado, el caso de constantize, no terminó de funcionar, por lo que es imposible compararlo.
Desde el viernes pasado tenemos disponible la versión 2.2 de Rails, por lo que ya podemos disfrutar de innumerables características que llevábamos tiempo viendo en el Edge de Rails.
Algunas de las características que me han llamado más la atención por el uso inmediato que voy a hacer de ellas o por su potencial futuro:
- Internacionalización i18n. Aún existiendo numerosas opciones para internacionalización (tal como gettext, globalize, etc), sin duda es una de las características que más se le echaban en falta a Rails desde hacía tiempo. Nosotros en Tog habíamos empezado a internacionalizar utilizando esta característica que estaba disponible en el Edge.
- Compatibilidad con Ruby 1.9 y con JRuby. Mucho es el trabajo que se ha realizado para utilizar las nuevas características del lenguaje mejorando el rendimiento y adaptándose a la nueva versión de Ruby.
- Documentación. En este sentido caben destacar las guías, donde se está realizando una labor de documentación increíble. Aquí podemos apuntar un nombre de alguien que a todos os sonará por su labor: Xavier Noria. Sin duda uno de los puntitos para haber sido elegido personaje Rails 2008 .
- Mejoras en HTTP. Soporte de ETag y Last-Modified que responderán con una respuesta vacía si la página no ha cambiado.
- Thread Safety. Threads en rails; sin duda un tema complejo, para el cual os recomiendo leer una explicación realizada por Charles Nutter.
- Migraciones transaccionales. Desde ahora los errores producidos en una migración harán que la migración no se ejecute, como hasta ahora, pero también que quede registrado todo el proceso de la misma como inválido, restableciendo el estado de la base de datos a la migración anterior.
- Pool de conexiones. Podemos manejar un pool de conexiones para conectarnos con la base de datos, fácilmente configurable en nuestro database.yml.
- Resources con acciones específicas. Hasta ahora cuando creabas los resources automáticamente para un modelo se creaban las 7 acciones por defecto: index, show, create, new, edit, update y destroy. Sin embargo esto tiene un gasto de memoria extra y crea una lógica que en ocasiones no tienes porqué usar, por lo que ahora puedes seleccionar cuales te interesan:
map.resources :articles,nly => [:index, :show]
- Action Mailer: Ahora dispone de soporte para layouts; tal como el resto de nuestras vistas.
- Se incluye también soporte para cuentas de Gmail, aunque esto requiere de la versión 1.8.7 de ruby.
Existen más características e información ampliada de todo lo aquí mostrado en la nota publicada de esta release.
A finales de la semana pasada, se celebró en Madrid la Conferencia Rails 2008, tal como os comenté, estuve allí conociendo gente, intercambiando opiniones y descubriendo lo que se está haciendo con Rails.
Este año he podido disfrutar asistiendo ambos días, además he disfrutado como más me hubiese gustado hacerlo siempre. Dado que desde hace un tiempo he estado trabajando más intensamente con Rails, y este ha sido el primer evento relacionado con el tema al que he podido asistir, eso si no contamos el evento de Tog en octubre 
.
Como es habitual, aporto mi pequeña gota de feedback y como también es normal, no lo haré de todas las charlas, sino de aquellas que más me impactaron o que por una causa u otra más recuerdos han dejado en mi. Para los que se queden con ganas de más, les recuerdo que la organización grabó las charlas y que seguramente pronto estarán disponibles los vídeos como en otras ocasiones.
Apertura y keynote por fxn. Una manera de abrir la conferencia singular, con referencias a hechos que originaron cambios. Personas que fueron contra corriente, con formas de pensar y/o hacer diferentes… Somos reacios al cambio, somos animales de costumbres y nos cuesta aceptar algo nuevo, pero cuando el cambio es llevado a cabo, cuando nos dejamos embaucar por lo extraño, sin duda disfrutamos como niños. Rails sin dudarlo es una pequeña cosa que ha hecho una gran diferencia. Frameworks hay muchos, intentos de hacerlo de otra forma también, pero corrientes como la que vivimos no han habido tantas. Lo que más me maravilla de esta comunidad es que muchos hemos llegado a ella con experiencia sobre otras, con lecciones aprendidas a fuego y veo cosas que me gustan bastante.
Caso de éxito: “Tog: Open Web, Social Networks y cintas de video”. Una explicación de la visión sobre los objetos sociales y sobre lo que una red social debería crearse. Intentando mostrar el aporte que Tog podría hacer con respecto a crear una red social. No sé si fue la charla, si oir a Aitor en estado catarroso o si definitivamente Tog tiene el tirón que parece. El caso es que el último día las votaciones de mejor proyecto del año 2008 recayó sobre él XD, y eso que fue liberado a ¡finales de septiembre! La verdad es que el trabajo detrás de esta primera inflexión que supuso la liberación del código se remonta a bastantes meses atrás. Antes hubo pruebas, proyectos, afinamiento de ideas y tras todo eso la creación de lo que ahora mismo es. Todo ello entorno a la idea que nos mueve de los objetos sociales y su valor.
Rails HOT or NOT. Os recomiendo verla en video . No había utilizado todos los plugins que se comentaron, en ocasiones no podía decir nada malo por uno de ellos, pero sin duda descubrí opciones, opiniones en base a experiencias y espero pronto leer las conclusiones en la lista de ror-es; además de invertir algo de tiempo en cacharrear con alguno de ellos.
Speed dating. Un experimento que pudo hacer que nos relacionásemos gente con proyectos en busca de gente y gente en busca de proyectos, aunque tubo un mayor aporte de empresas que buscaban personal para contratar que lo yo personalmente hubiese querido encontrar. Aún así, una grata experiencia.
Caso de éxito: “b5map: Maps on Rails”. La verdad es que ya conocía la web desde hacía tiempo, conozco Aitor por sus post en jaiku, pero desconocía las tiranteces que parece haber entre los ayuntamientos. Algo que me llamó mucho la atención, fue descubrir que el proyecto se había llevado a cabo aunando a freelances y pequeñas empresas, algo loable viniendo de una administración pública.
Keynote por Obie. Una forma de ver el mundo laboral y empresarial diferente a lo que se ve en este país. Sin duda oír hablar a Obie diciendo que son buenos desarrollando, que les gusta y que eso es a lo que se dedican y es lo que le transmiten a sus clientes; lo cual despertó algún comentario en los asistentes, dada la comparación con lo que vivimos aquí en España. Aplicación de Pair Programming todo el tiempo, un ambiente laboral agradable, invitaciones a personas destacadas dentro del mundo de la programación para que interaccionen con la gente que trabaja en Hashrocket, etc etc. Fue agradable de escuchar y creo que sería increíble trabajar en esos ambientes (al lado de la playa ) y de con esas premisas. Aunque sin duda mi conclusión actual es que no estamos tan lejos de conseguirlo, y que la nueva cultura de empresas pequeñas haciendo software creada entorno a Rails, podría llevarnos a eso.
Por comentar, me queda por ver a fondo la charla de Emili Parreño sobre ActiveRecord, echarle un vistazo a Typus, probar EC2 de Amazon, hacerse con uno de los aparatos que vimos en: Hardware Hacking en Ruby y casi en Rails para iluminar los deploys y definitivamente: hacer TAFT .
Desde ayer estoy disfrutando de lo que se está viendo en la conferencia rails; por tercer año consecutivo se está celebrando en Madrid y por primera vez para mi puedo asistir.
En breve mi feedback de la misma.
Si alguno estáis por allí y aún no nos hemos visto, no dudéis soy tímido pero no muerdo .
A poco de iniciar mi actividad como freelance, comenzamos un proyecto para aprender los entresijos de rails y a la vez enfrentarnos a otro tipo de problemas que no tenían que ver tanto con programación. Como recordaréis estoy hablando de flatee.com.
Pues bien, he de anunciar que el Internship se ha dado por clausurado y el resultado no ha sido nada alentador.
La verdad es que se juntaron varias cosas, como ya apuntan en el blog de Linking. Una vez más se ha evidenciado la importancia de la dedicación total, es difícil que un proyecto propio o sideproject se convierta en una realidad cuando el tiempo empleado para ello es muy limitado.
Creo sinceramente que el momento en el tiempo no fue el mejor (verano); que se junto con el comienzo de nuestra nueva actividad; que quizás es bastante cierto que faltó algo de presión por tener un entregable; que nuestra dedicación no era completa y se juntó con otras actividades que colapsaron nuestro día a día; y quizás otros factores que no soy capaz de ver en este momento. Todo esto suena a excusas explicatorias, pero nada más lejos; lo importante es el análisis de lo ocurrido y sacar conclusiones, para aprender de la experiencia.
Para mi es un trago amargo pensar en el resultado, no se puede decir que de la experiencia no haya sacado nada, pues no estaría diciendo la verdad. Sin embargo he querido concluir totalmente con ello y en principio dado que no podía comprometerme una vez más y mentirme a mi mismo y a mis compañeros sobre el tiempo real que podría dedicar, he decicido no continuar activamente con el proyecto. No descarto volver a hacer más cosas en el proyecto, pero a día de hoy no tengo la certeza suficiente de cuánto puedo dedicarme a él.
