como en mi ciudad son las 1:00PM aqui le dejo a todos!!!!

Hola a todos.

Esta vez Makingdevs estuvo presente en el evento #ChelaJS. Es un evento donde un grupo developers se reúnen para hablar de los frameworks de javascript con el pretexto de tomar algunas chelas. Durante el mismo se compone de una serie de platicas de temas variados desde como usar javascript en producción, como hacer aplicaciones desktop y nuevas librerías que van surgiendo en para este gran leguaje.

En esta ocasión Felipe Juárez - @sohjiro experimentado desarrollador de software nos platica sobre EmberJS framework de javascript para crear aplicaciones web del lado del cliente (código abierto).
Esta basado en la arquitectura modelo-vista-controlador (MVC). Esta catalogado como unos de los principales framework a en el mundo de JavaScript ya que permite a los desarrolladores crear aplicaciones de una sola pagina (single-page) escalables.

¡Espero lo disfruten! y apreciamos mucho cualquier comentario que nos puedan dejar.

Hace tiempo apareció este vídeo para motivar a las "personas comunes" a que aprendieran a programar.

A mi parecer fue una buena idea, lo que muchos nos hace falta es tener iniciativa, aprender de la prueba y el error.

No esperar a que (auto mágicamente) alguien nos enseñe y nos resuelvan los problemas. Se vale preguntar, todos alguna vez necesitaremos ayuda, pero no delegar nuestra responsabilidad a otros.

OpenXava es un marco de trabajo AJAX para desarrollo rápido de aplicaciones web empresariales.

Con OpenXava sólo has de escribir las clases del dominio con Java para obtener una aplicación web lista para producción.

OpenXava 4.9 tiene algunas funcionalidades nuevas muy interesantes como:

Bienvenidos sean a esta nueva emisión del podcast el episodio numero 6 de la temporada numero 1.
En esta ocasión tenemos el honor de entrevistar Laurent Sansonetti – @lrz quien nos hablo de RubyMotion – @RubyMotion.
Laurent Sansonetti, es fundador de HipByte y desarrollador principal de RubyMotion. Trabajó en Apple durante 7 años como ingeniero senior de software, tanto en iLife y OS X. A trabajado con Ruby mucho tiempo, creó y mantiene el proyecto MacRuby. Tiempo atrás, trabajó en IDA Pro y fue un activo colaborador RubyCocoa y GNOME.
Un entrevista sin duda muy interesante que no se pueden perder.
¡Espero lo disfruten! y apreciamos mucho cualquier comentario que nos puedan dejar, pronto mas capítulos de la temporada 01.

Lenguaje de Señas, asistencia a discapacitados

Este es un pequeño proyecto donde podremos escribir una palabra o frase y se nos mostrara unas imagenes indicando la señal de cada letra en lenguaje de señas.

Imagen

Pueden descargar el proyecto directamente desde aquí.

Primeramente, pensé que el truco tenía que encontrarse en el concepto de economía de escala, los tostadores, refrigeradores, etc, son menos costosos por que se producen en grandes cantidades. Claro, eso explica por qué es más barato comprar un tostador que construir uno por mí mismo, pero ¿Qué pasa con el software que construyen las consultoras? ¿Aplica ahí el mismo principio? ¿Y con el software de procesador de textos que podría estar usando para escribir esto?

Hace ya unos meses, me encontré por casualidad con que @Domix había twiteado la dirección hacia un “rant” (¿una perorata?) de Zed Shaw (el creador de Mongrel) en la que despotrica sobre todo lo que le molesta de la comunidad alrededor de Ruby on Rails. En lo personal, yo no soy desarrollador de Ruby, ni de Rails, y aunque la perorata de Shaw me pareció, como a muchos de los que la leímos ese día, interesante, no fue por sus quejas sobre esa comunidad si no por algo que comenta más adelante:

Where I work the company is willing to blow huge amounts of money on a consulting firm or hardware, but ends up firing people when times get tight. It’s a universal mass hysteria that paying $100 – $200 per hour for a group of consultants is preferable to simply hiring good employees. At the rates companies pay these consultants they could hire 4 full time employees.

Acabo de toparme con un problema en Groovy. Tristemente la solución que todo mundo da en foros es simplemente "no lo hagas, es mejor si haces [cualquier otra solución]"; pero, qué tal si lo que necesitaba era esto?

Bueno y ¿cuál es el problema? Es simple: el soporte en clases internas tiene problemas con atributos heredados en la clase externa. Tiene solución, y es sencilla, pero me parece una leaky abstraction y honestamente la encontré por pura suerte, buscando maneras de darle vuelta al asunto.

El problema se da bajo estas circunstancias:

En todo el tiempo que llevo trabajando como desarrollador he probado herramientas que me han permitido mejorar los tiempos de desarrollo y la productividad, y tengo que confesar que mi fuerte no es el diseño de la interfaz de usuario, y aunque estuve alejado de Java por algún tiempo por mi trabajo con Dynamics AX, en el reencuentro que he tenido con el lenguaje, me he encontrado con unas muy agradables sorpresas, tal vez las que más me han impactado de forma muy favorable son JavaFX y Scene Builder.

Estas dos herramientas han hecho que ese placer al programar se multiplique y que Java ahora más que antes sea mi lenguaje preferido, es cierto que le debemos mucho a swing, porque en su momento fue también un instrumento de mucha ayuda. Con la llegada de Los IDE's como Eclipse, Netbeans, IntelliJ etc, se acortaron los tiempos de programación enormemente, pero mi punto débil siempre ha sido el diseño de la interfaz, en realidad nunca logré resultados que me dejaran satisfecho, siempre hacia falta algo para que me sintiera bien con la presentación.