I have been wanting a good version of planning poker that integrates with Trello ever since I started using Trello over a year ago. Every time I would search in google for ‘planning poker trello’, I would get absolutely nothing. It’s really rare that something I want so bad is SO absent from the internets!

Well, I have had enough. Born out of great personal need, I present to you http://trelloplanningpoker.com.


Main Features:

  • App connects to Trello via OAuth
  • Create a new poker game from a Trello board and list
  • Share poker games with team members with a simple link
  • Unlimited number of team members can view card details and choose a point size (currently fibonacci starting with .5)
  • Team members can only see point sizes after he/she has chosen a size
  • Game creator can easily apply points to Trello cards

Try it for yourself!


For those out there crazy enough to be interfacing with Excel RTD servers from .net code, here’s something re-usable that might save you some time. This is to get one value out of the RTD stream at a time…

I’ve gone to church all my life and “The Golden Rule” has been pound into my head since I was a toddler: “Do to others as you would have them do to you.” That’s Jesus talking in Matthew 7:12, by the way. Now, I’m not going to preach, so don’t navigate away too quickly… Well, I’m not going to preach about the Bible anyhow. I guess I am going to preach a little about how I think software developers should change their evil ways.

It doesn’t matter if you believe in God or follow the Bible, anyone can probably admit that Jesus was teaching something pretty important. Common human decency. An expectation that, if you treat folks badly, you’ll probably get the same in return. Love people so you will be loved. Open the door for someone and smile, because that’s what you want people to do for you. This blog article is my attempt to live out “The Golden Rule” amongst my fellow developers. I am chewing you all out because I would want you to chew me out if I did this crap to you all.

Before I started writing, I did a little research about “The Golden Rule” and “programming” to see if anyone else had written on the topic. I found out quickly that someone coined “The Golden Rule of Programming” awhile back so it has stuck. But I’m here to tell you, WE are way off on this. Here’s the popular programmer’s golden rule:

“If it can be null, it will be null.”

What does that have to do with people?? Nothing. It’s a clever way to help programmers remember to avoid nulls, which is great. But we’ve missed an opportunity to answer a higher calling: doing to other developers what we would have them do to us. So I’m reclaiming the phrase for the cause of better code.

I should have called this article, “How to Make Other Programmers Hate You,” and given a bullet list of ways to piss me off when I look at another developer’s crappy code. Maybe another day. 

When you are writing code, you should consider that you will probably not be the only human being who has to maintain it. Some other poor soul is going to eventually crack open your code and try to implement some fix, requirement change, or new feature. Will it take them days or minutes? Will they be able to decipher your structure? Or will they hate you and call you incompetent? I suggest that all developers, around the world, stop coding right now and change their hearts. It’s time to start thinking of others, and putting their future needs first when it comes to our code. It’s time to start allowing this simple teaching of Jesus to form our ethics as professional programmers.

Are you ready to repent and turn from your evils ways? Here are some suggestions that I guarantee will set you on the right path:

Use Test-First Development – Don’t write production code until you have a failing unit test. Then, only write enough production code to make that unit test pass. This sequence will help you stay disciplined in your unit test coverage and will help you produce better, more modular chunks of code. This will also enable your future readers to be able to look at your tests and understand quickly how you intended things to work. Oh, one more thing. If any future developer messes up something in your code, your unit tests will alert that dev me he/she can fix it more quickly. There are actually SO many other benefits to test-first development that are out of scope for this article. Just do it and you’ll understand.

Use Documented Architecture – Don’t try to reinvent the wheel. Architecture has been done and done and done. Learn one that fits your project and stick to it. Creating your own will probably get you into trouble and will rob your future readers of the ability to understand your architectural decisions apart from a ton of documentation that you shouldn’t have to waste time writing.

Names Matter – Name your variables, classes, methods, everything with care. Who cares if names get long. If they communicate what’s going on, let it go! This will go a long way in helping your future readers understand your code. It will also cut down or eliminate the need for code comments.

Use Patterns – Like anybody who makes things for a living, patterns and templates are essential to reproducing similar types of products or work. Same goes for software development. There are tons of great “pre-thought-out” patterns for programmers to pick up and use. And, later on, other developers, who are also aware of those patterns, can look at your use of this or that pattern and know EXACTLY what is going on. Or you can ignore the patterns out there and do everything your way, alienating and confusing your future readers, making them hate you. Your choice.

SOLID, Know it, Love it, Use it – If your haven’t heard of the “SOLID Principles of Software Engineering” by Robert Martin, you should Google it. It is five software engineering principles that, when used together, tend to guide software developers to creating better, more maintainable code. There are tons of principles like these out there, but the nice thing about these five is that most any professional software developer can follow them closely if not to the letter in their day-to-day. So, if a future reader must maintain your code, and you follow SOLID, all they have to do is familiarize themselves with those five principles and they are almost as good as the original dev because they will understand what guides and motivates your decisions. Following a popular set of principles like SOLID sets future readers and maintainers up for success months and years in advance.

Give a Flip – Would you want your dear, sweet grandmother to have to maintain your code. How about your baby daughter? How bout yourself 6 months later. Well, the reality is that someone will probably look at your code in the future. If none of these suggestions have resonated with you, an ounce of caring would be SOMETHING. Just remember that a puppy dies every time you check-in crappy code. If that doesn’t motivate you, consider that people will hate you. Just care about people and don’t leave them hanging. Code with care!

Will you follow the REAL “Golden Rule” in your day-to-day programming, taking the necessary steps to leave future developers with code that can be maintained and extended? For your clients’ sake, for your fellow developers’ sake, for your own soul’s sake, I sincerely hope so.

On the other hand, if you want to keep putting crappy, unintelligible code out there, be my guest. I’m actually making a pretty good living by cleaning up your messes. I just feel bad for your clients who have to pay for your blunders. Your call.

Part of being a software craftsman is knowing how to recognize exceptions. Really, it takes time to build up enough experience seeing and fixing exceptions so that you can simply say, “I’ve seen this before. The problem is…” Along the way, when you find an exception that’s not very helpful in its message, get in the habit of looking at the inner exceptions until you reach the first exception. That will probably be the one that tells you what the real problem it is. Then remember the exception by its type or the error message so that you don’t have to google anything next time.

Cada uno de nosotros nació innovador, inventor, imaginativo, pensante, inteligente. Como seres humanos, tenemos una increíble capacidad de invención y creación. Soñamos con ser bomberos, conduciendo el camión grandote, la extinción de incendios, salvando vidas. Soñamos con ser astronautas e ir a la Luna. De niños, nuestros sueños son llenos de diversión, locos, indomables. Nosotros creamos cosas, probamos cosas, tocamos cosas, creemos cosas sin temor de lastimarnos. Como los niños, nuestro potencial es muy abierto e inexplorado. No hay límite a lo que podemos soñar!

Pero en algún momento, alguien nos dijo que nos detengamos, guardaramos silencio y dejaramos de inventar esas ideas locas. Hemos aprendido que es mejor ver la televisión que jugar al aire libre en la tierra. Luego, en la adolescencia, se nos dijo que debíamos encontrar un trabajo y empezar a pensar en nuestro futuro. Luego nos graduamos del colegio y la universidad y creemos que tenemos todo resuelto: “Voy a conseguir un trabajo, una casa y un carro, y con suerte consigo una novia (o un novio) con un cuerpazo.”

Si notan, ahora, todas las metas están resueltas y hacen que usted se sienta cómodo. Un trabajo que le da salario y un salario que le da seguridad y comodidad. La casa es un lugar donde se puede descansar, comer y dormir con mucha comodidad. Un auto le hace sentir más seguro de ir a cualquier parte con comodidad.

Todos nuestros objetivos en la vida giran en torno a la comodidad… se escucha como que hemos renunciado a la vida. Nos estamos preparando para morir, así que estamos tratando de ponernos cómodos.

La comodidad es una droga poderosa y peligrosa. La comodidad es casi irresistible. Una vez que hemos probado comodidad, queremos más y más. Nos canta una dulce canción de cuna y caemos en la trampa. Es tan poderosa que fácilmente olvidamos todos nuestros sueños e ideas… lo único que importa ahora es permanecer aquí… comodo.

Me gradué de la universidad y de inmediato encontré un trabajo. Todavía tenía algo de ambición… algunas cosas que quería hacer con mi vida. Pero luego empecé a recibir salario de mi trabajo y mis prioridades cambiaron rápidamente. Ese salario me dio un nivel de confort y seguridad que nunca había tenido antes. Así cambió mi objetivo y la meta fue hacer lo que fuera necesario para mantener ese trabajo. Finalmente me compré una casa y un carro y empecé a vivir mi nuevo sueño aburrido. Iba a trabajar por la mañana, volvía a casa por la tarde, y me sentaba en mi silla para ver televisión. Entonces hacía lo mismo el día siguiente y el siguiente, año tras año. Yo estaba completamente atrapado, pero era cómodo y feliz.

Yo era un programador en una empresa de servicios financieros en el que pensaba que iba a estar el resto de mi vida. Yo estaba básicamente creando software que haría que los dueños de la empresa fueran más ricos de lo que ya eran. A pesar de que me sentía muy cómodo con mi vida, algo no iba bien. Los programadores en esta empresa no eran valorados ni respetados. Los programadores son la sangre vital de la empresa, sin embargo aun así no se les pagaba tanto como la agente de ventas. Y peor aún, los líderes de la compañía siempre presionaban más y más fuerte, como si fuéramos animales de carga que empujan una carreta pesada.

Doy gracias a Dios por esa empresa y la manera tan fea en que nos trataban. Por que? Porque eso me ayudo de saber que la comodidad no era suficiente. Un dia, dos compañeros y yo tomamos la decisión de marcharnos de la empresa, diciendo “Ya no mas. Vamos a emprender una nueva empresa y hacer lo mejor!”

Dejar una droga nunca es fácil. Dejando la comodidad tampoco lo es. Hasta el dia de hoy puedo recordar cuando llego mi último cheque de mi pasado trabajo y recuerdo haber pensado, “Que es lo que he hecho??” Yo tenia un poco de dinero ahorrado, asi que empece a comer frijoles y arroz y deje de comer como rey que me sentia. Vendi mi casa y consegui una casa rentada. Cancele mis cosas no esenciales como cable y seguro (este ultimo, no lo hagas). Hize todo lo que pude para hacer que mi poco dinero durara mas tiempo. No fue una vida muy facil. No estaba comodo.

Pocos años después, Acklen Avenue, my pequena empresa, ha crecido hasta ganarse el respeto en los Estados Unidos y en Honduras como empresa que crea productos de calidad. Tenemos empleados en ambos países y nos aferramos a dos objetivos: 1) Programadores felices, 2) Clientes felices. Ha sido un sueño hecho realidad. He dado un paso atrás a mi zona de confort, empecé algo nuevo, camine por fuego por un tiempo, y ahora tengo la oportunidad de ver los frutos de mi trabajo. Por fin puedo tener televisión por cable de nuevo.

Si nunca me hubiera salido de mi zona de comfort, nunca hubiera comenzado Acklen Avenue, y nunca me hubiera casado con mi esposa, conocer mi nuevo hijo, moverme a Honduras, y tampoco estaria aca hablando con ustedes hoy.

La comodidad hace que usted tenga que trabajar mucho cada dia para que usted se pueda comprar cosas que no tienen valor actual. La comodidad lo pone en deuda. La comodidad impide a un padre jugar con su hijo en el piso duro. La comodidad lo hace tener un trabajo que desafía su moral. La comodidad le impide a su esposo comunicarse con su esposa. La comodidad mantiene sus excelentes ideas en silencio. La comodidad lo mantiene sentado, golpeando el reloj, haciendo lo mismo dia tras dia. La comodidad no es su amigo. La comodidad es su enemigo.

La sociedad nos dice que la comodidad es el objetivo de nuestras vida y que debemos pasar cada día de nuestras vidas tratando de conseguirla. Usted y yo lo sabemos mejor. Fuimos creados para ser creadores. Estamos hechos para algo mucho más que un trabajo a tiempo completo. Nuestro potencial como seres humanos nos hace que una busqueda de un carro y casa parezca tonta. Cuando nosotros podemos hacer más, ser más y crear más.

Es tiempo de recordar cuando eramos niños, antes que nos convertimos adictos a la droga de la comodidad. Es tiempo de sonar otra vez y emprender algo nuevo! No es tiempo dejar su trabajo… o quizas si. En cualquier caso, es tiempo para un cambio y darle valor a su vida.

Emprende algo nuevo. Empieza pequena. Duerme poco. Sacrifica su tiempo y su dinero (pero nunca su familia). Cree en su potencial y liberese a si mismo para soñar de nuevo. Talvez es tiempo para convertirse en bombero y salvar vidas. Talvez ha tenido una idea en su cabeza por anos atras y es tiempo de escribirla y realizarla. Quizas esta listo para decir, “Ya no mas!” en su trabajo y exigir su respeto, empezando una nueva y mejor compañía.

Lo que sea, es tiempo de empezar, ahora… mismo. Honduras le necesita! Ready? GO!!

I work with a team of talented developers who adhere to the “Three Rules of TDD” which are:

  1. You are not allowed to write any production code unless it is to make a failing unit test pass.
  2. You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures.
  3. You are not allowed to write any more production code than is sufficient to pass the one failing unit test.

To adhere to those three rules, we use various tools and frameworks that help us write appropriately-failing tests before writing the production code that make the same tests pass. One of those excellent tools is a mocking framework. Mocking allows us to take advantage of polymorphism and abstraction, creating “pretend” implementations of our dependencies so that our unit tests stay “unit tests”… only testing one small section of code at-a-time.

One area where we constantly run into issues is when we are mocking a dependency that takes a complex argument like an “Expression”. Expressions and Funcs are really useful because they allow you to write code that gets executed later on. However, Expressions and Funcs are especially hard to mock. Not impossible… just hard.

Here’s an example of one such dependency:

Every time I find myself mentoring another developer in mocking techniques, inevitably we arrive at a “query” method like this. A query method on a repository is very useful to the code that consumes it, but it’s not very straightforward when mocking. Here’s a test I’m working on right now:

Problem with this test is the way I’m setting up my Query method. This will not work. Do some google searching to find out why… out of scope for this article. HOWEVER, the way I’m doing this is expressive and makes sense. I need something that works and reads well.

Many of the examples on the web take the “easy way out” and lift any constraints on the mock… here’s an example using Moq:

Trouble is, that breaks rule #1: “You are not allowed to write any production code unless it is to make a failing unit test pass.” Because the test doesn’t care what you pass in to your query method, your production query actually goes uncovered by the test… you just wrote production code that didn’t actually cause a unit test to pass or fail.

In order to properly constrain a mocked method like this, you need to test the expression against actual objects to see whether or not the expression returns true or false… in order words, you need to find out if the given expression “matches”. For example, here’s how I’ve mocked a query like this in the past:

This works okay for simple queries. But it is ugly and unexpressive and doesn’t really handle things that you DON’T want… only what you DO want. So, then you have to feed some objects that you don’t expect to match… at this point we’re need to capture the expression at runtime and run it against a list of objects. Here’s an example:

Messy. First off, we have an extra test obsevation JUST to test the runtime expression. But, I don’t want to TEST the expression! I simply want to constrain the mock method so that it only returns the expected objects IF the right expression is passed in. Secondly,  my test is harder to understand because of the list of unexpreissive test objects.

Time for something different. How’s this look?

Here’s the finished test:

Now, my test is looking better. I’m back to constraining my mock instead of testing a runtime argument. Also, the “fluent” flow is quite a bit more expressive. It almost reads like plain english. I think I’ll have an easier time explaining this to others using this form.

If you like it, feel free to use it! You can either copy the code from github or just install a nuget package. My code uses Moq Mocking Framework. But I’m sure you could adapt this to your favorite mocking framework with a few minor changes.

PM> Install-Package AcklenAvenue.Testing.Moq


You can also check out the source code at Github. If you’d like to improve the code, feel free to submit a pull request! Enjoy!


“Downtown Parking”, un empresa nueva, tiene los planes de construir garajes de estacionamientos en las grandes ciudades de todo el mundo. Sin embargo, sus líderes son un poco corto de vista y se apresuran a través del proceso de construcción. Sin una verdadera comprensión de las ramificaciones, están animando a sus trabajadores de la construcción a simplificar para terminar más rápido. Mientras tanto, los líderes de la compañía están manteniendo una estrecha vigilancia sobre los libros. Ellos se aseguran de que su personal de contabilidad están siguiendo las mejores prácticas y nunca tengan errores.

Un adelanto de tres años. Los registros de contabilidad de la compañía siguen siendo perfecto después de años de atención a las mejores prácticas. Bueno, casi perfecto. Usted ve, la calidad de sus estructuras de garaje no era una prioridad y ahora son casi inutilizable. Secciones enteras de los garajes de estacionamientos ni siquiera puede ser reparado y han cerrado. Así que la compañía está gastando más de lo que se está ingresando, y los libros están al rojo vivo.

Los líderes de la empresa dan cuenta de que hay que derribar y reconstruir varios garajes de estacionamientos con el fin de mantenerse en el negocio. Por lo tanto, se iniciará la construcción de nuevo. Pero, debido a la urgencia de comenzar a generar ganancias más, tenemos la misma canción y la danza. La construcción se apresuró, los libros son impecables, y la compañía está listo para ejecutar de nuevo.

¿Por qué tanta atención a los libros y tan poco a la calidad de los estacionamientos? Es la contabilidad de alta calidad la pieza más importante de la empresa? Creo que este tipo de cosas en realidad no suceden en la vida real. Es demasiado absurdo. ¿Cómo los visionarios de una empresa de estacionamientos descuidan la calidad de la base obvia de su negocio: los de garajes de estacionamiento?

Por supuesto, si una empresa real depende de la “X” para existir y obtener beneficios, se asegurarán de que la calidad de su “X” es alta por lo que los beneficios no están dañados y su negocio no está en peligro de cierre. Esto es de sentido común básico.

Como absurdo que pueda parecer, los líderes empresariales hacen este tipo de cosas todo el tiempo con su software. Innumerables empresas dependen absolutamente de software que diseñan y construyen para ejecutar sus procesos de negocio. Pero, sin entender las ramificaciones, ellos de poca vision apresuran a sus desarrolladores haciendo que se simplifiquen los trabajos. El resultado inicial es un software que funciona. El resultado a largo plazo es un software que no se puede modificar sin incurrir en grandes gastos. Muchas veces los desarrolladores de software finalmente alzan las manos y decir a la empresa, “es hora de derribar y reconstruir”. Y empezar el proceso de nuevo.

Esta no es forma de dirigir un negocio. No es ninguna manera de crear software. No tiene que ser así. Considere el concepto de “software duradero”.

Software duradero es como garaje de alta calidad, muy bien construido. Se construye con cuidado, no se apresura. La longevidad es una prioridad, por lo que los mejores materiales se utilizan. Aunque los desarrolladores con menos experiencia trabajan en el proyecto, hay un número suficiente de maestros artesanos que trabajan junto a ellos para guiar al proyecto. Todos los que trabajan en el proyecto sigue los estándares de la industria que han demostrado producir resultados de alta calidad.

Software duradero favorece el cambio a largo plazo. No es necesario volver a escribir cada cierto tiempo, ya que da cabida a las nuevas características y los cambios en la funcionalidad existente. Aunque el software duradero es más caro para entregar inicialmente, es barata de mantener durante muchos años, lo que resulta menos costos en general. Además, la empresa es libre para beneficiarse, sin obstáculos por meses o años de despilfarro reconstrucción de software.

Mi empresa, Acklen Avenue, ha visto el problema de estacionamiento en muchas ocasiones. Con frecuencia nos llaman equipos de desarrollo existentes para ayudarles a moverse en la dirección de la durabilidad. Después de una investigación y años de experiencia, hemos encontrado que hay cuatro componentes principales del software duradero:

1) Facilidad de lectura: Escribir código que alguien pueda entender un año más tarde.
2) Arquitectura: Seguir una arquitectura documentada desde el principio hasta el final.
3) Pruebas Primero: utilizar Test-Driven Development para sacar el código de producción.
4) Principios: Adherirse a los principios SOLID de ingeniería de software.

Antes de iniciar su próximo proyecto totalmente nuevo, considere todos los costos. Recuerde que el costo del software no se detiene en la entrega. Si su negocio depende de su software para la rentabilidad, necesita un software que será capaz de cambiar con su negocio y que no hará que sus futuros desarrolladores alzen las manos. Usted necesita un software duradero.


“Downtown Parking”, an imaginary start-up, plans to build parking garages in large cities around the world. However, their leaders are a little short sighted and are hurrying through the construction process. Without truly understanding the ramifications, they are encouraging their construction workers to take shortcuts in order to finish faster. Meanwhile, the company leaders are keeping a close watch on the books. They are ensuring that their accounting staff are following best practices and never have errors.

Fast forward three years. The company’s bookkeeping records are still perfect after years of close attention to best practices. Well, almost perfect. You see, the quality of their parking garage structures was not a priority and now they are almost unusable. Entire sections of the parking garages cannot even be repaired and have closed. So the company is spending more than it is taking in, and the books are red hot.

The company leaders realize that it is necessary to tear down and rebuild various parking garages in order to stay in business. So, they start construction again. But, because of the urgency to start generating profits again, we have the same song and dance. Construction is hurried, books are immaculate, and the company is ready to roll again.

Why so much attention to the books and so little to the quality of their parking garages? Is high quality accounting the most important piece of the business? I believe this kind of thing wouldn’t actually happen in real life. It’s too preposterous. How would the visionaries of a parking garage company neglect the quality of the obvious core of their business: the parking garages?

Of course, if a real company depends on “X” in order to exist and profit, they will ensure that the quality of their “X” is high so that profits are never damaged and their business is never in danger of closing. This is basic common sense.

As preposterous as it may seem, business leaders do this kind of thing all the time with their software. Countless companies depend absolutely on software that they design and build to run their business processes. But, without understanding the ramifications, they shortsightedly rush their developers causing them to take shortcuts. The initial result is software that works. The long term result is software that cannot be modified without incurring major expense. Many times the software developers finally throw up their hands and say to the business, “it’s time to tear down and re-build.” And they start the process all over.

This is no way to run a business. It’s no way to create software. It doesn’t have to be this way. Consider the concept of “durable software”.

Durable software is like a well-built, high-quality parking garage. It is built with care, not hurried. Longevity is a priority, so the best materials are used. Although less experienced developers work on the project, there are a sufficient number of master craftsmen working alongside of them to guide the project. Everyone working on the project follows industry standards that are proven to yield high quality results.

Durable software embraces change for the long haul. It doesn’t need to be rewritten every few years because it welcomes new features and changes to existing functionality. Although durable software is more expensive to deliver initially, it is inexpensive to maintain for many years, resulting in less overall cost. In addition, the business is free to profit, unhindered by wasteful months or years of rebuilding software.

My company, Acklen Avenue, has seen the parking garage problem many times. We are frequently called in to existing development teams to help them get moving in the direction of durability. After research and years of experience, we have found that there are four major components of durable software:

1) Readability: Write code that someone can understand a year later.
2) Architecture: Follow a documented architecture like Domain-Driven Design from start to finish.
3) Tests First: Use Test-Driven Development to drive out production code.
4) Principles: Adhere to the SOLID Principles of Software Engineering.

Before starting your next green field project, consider all the costs. Remember that the cost of software doesn’t stop at delivery. If your business depends on your software for profitability, you need software that will be able to change with your business and that won’t make your future developers throw up their hands. You need durable software.

English Version

La violencia doméstica es un problema a nivel mundial, pero es peor en países donde la cultura la apoya y no hace un buen trabajo previniéndola. Tengo hogares en Tennessee y cerca de la capital de Honduras, Tegucigalpa. Cuando camino en mi ciudad Santa Ana, ahora estoy consciente que 1 de cada 4 mujeres que veo por la calle han sufrido de violencia doméstica. Enfatizó “ahora” porque, antes del Hackathon del fin de semana pasado, yo era dichosamente ignorante.

Hablo del Hackathon contra la Violencia Doméstica que se llevó a cabo el 26 y 27 de Enero de 2013. Este Hackathon se llevó a cabo en 6 países latinoamericanos así como en Washington D.C. Fue patrocinado por El Banco Mundial y organizado por Second Muse. Todo el equipo de desarrolladores en Honduras de Acklen Avenue mas nuestro diseñador gráfico en Nashville levantaron sus manos, diciendo, “Quiero ayudar!”

El día que comenzó el Hackathon. Se nos presentó la “Definición de los problemas”, todos describieron distintos problemas que los sistemas actuales tienen a la hora de proveer ayuda a la víctima de violencia doméstica. Nosotros determinamos un área donde creímos que podíamos causar un impacto en un lapso corto de tiempo, reunimos un gran grupo de expertos en violencia doméstica y comenzamos a desarrollar.

Por dos días, programamos y programamos (Andy diseñó y diseñó) y al final obtuvimos algo de lo que todos estábamos orgullosos: “Automated Case Worker” (ACM). ACM es un prototipo de un sistema automático que conecta las víctimas de violencia doméstica con trabajadores sociales vía mensajes SMS. El sistema está hecho sobre un servidor que vigila un buzón de SMS (usamos Twilio para la demostración) y determinamos si un trabajador social humano era necesitado, basándonos en los mensajes enviados por la víctima. La seguna parte del sistema es una Single-Page Application (web-app) que provee una interface para que múltiples trabajadores sociales puedan chatear con las víctimas y tecolectar la información importante (como ubicación, sexo, edad, nombre). La tercera parte de la aplicación es una aplicación móvil que imita la funcionalidad de la web app donde el trabajador social se conecta, esto para demostrar

herramientas menos costosas como teléfonos Android y tables pueden ser utilizadas en vez de computadoras de escritorio (Gracias a Jorge García, miembro honorario del equipo de Acklen Avenue).

La idea es que todos tienen acceso a teléfonos celulares y casi cualquiera tiene el conocimiento para comunicarse via SMS (mucho mejor que por voz). Con ACM, una víctima puede enviar un mensaje gratis de texto con un código corto y chatear con un trabajador social humano que tiene acceso a toda la información necesaria, contactarse con la policía, casa de refugio locales, la habilidad de comenzar un caso en contra del atacante… La lista potencial sigue subiendo.

Con el tiempo, la información recopilada de cada interacción con ACM puede ser convertirá en datos estadísticos y geográficos de alto impacto y puede ser utilizado para promover un cambio cultural. Un buen ejemplo, durante los chats con las víctimas de violencia doméstica, los trabajadores sociales en ACM puede obtener y salvar información para cada caso.

Los datos pueden ser transformados en mapas de calor, mostrando donde la cantidad de casos son mas elevados. Con esa información nosotros podríamos saber donde enfocar las campañas educativas contra la violencia doméstica. Todo eso fue realizado en el curso de dos días. Increíble, al final de Hackathon, el Automated Case Manager de Acklen Avenue fue anunciado el ganador del Hackathon en Honduras. Un gran honor. ¡Los desarrolladores de Acklen Avenue son sorprendentes! Cada día ellos siguen dándose cuenta de su potencial impacto al mundo alrededor de ellos.

Desarrolladores Super-Héroes:

  • Camilo Aguilar – Desarrollador
  • Jorge García – Desarrollador
  • Andy Hubright – Desarrollador
  • Mario Maradiaga – Desarrollador
  • Byron Sommardahl – Desarrollador principal
  • Viktor Zavala – Desarrollador

Envíe un mensaje a +1-615-338-8533 (int) Y luego vaya a Automated Case Manager y comience a chatear con usted mismo.

Código de fuente

English Version

Yo creo que los programadores pueden cambiar el mundo. Quería expresar esa idea para comenzar.

La semana pasada estaba sentado en el lobby de un hotel tomando café y revisando unas notas para una conferencia que estaba a punto de atender. Habían otras personas sentadas cerca de mi y comenzamos a conversar sobre nuestros planes individuales. Ellos trabajaban con una organización que trabaja en contra de la trata de personas. Les mencioné que era un desarrollador de software y estoy seguro que ellos pensaron que eso era “agradable”. Pero cuando les conté sobre de que era la conferencia, ellos estaban confundidos… Un concepto tan extraño y nuevo.

Piensen en el tipo de persona que tienen que ser para ser conocido en el mundo como un programador. Yo no conozco ningún programado que fuera verdaderamente estúpido.En verdad, las personas más inteligentes y trabajadoras que conozco son programadores. (Estoy dándome cuenta que me estoy auto-halagando, pero ignoremos eso). Los programadores son los que resolvian acertijos y desarmaban aparatos cuando eran niños. Hoy en dia, los programadores alrededor del mundo forman una fuerza poderosa de innovadores silenciosos y expertos en hallar soluciones a distintos problemas.

La conferencia que atendí la semana pasada era el TechCamp en Tegucigalpa, Honduras (Centro América, al sur de Louisiana, para los que no estén familiarizados con su ubicación). El TechCamp es apoyado por el Estado del Departamento de los Estados Unidos y fue diseñado para atraer a organizaciones que tratan de crear un impacto social en Honduras juntos con programadores y tecnólogos. ¿Que increible idea, verdad? Fue una gran experiencia y estoy tan feliz que conseguí una invitación a dicho evento. El punto era que los tecnólogos pudieran ayudar a las organizaciones a resolver algunos de sus problemas. Yo pude participar en algunos grupos y espero que los haya ayudado por lo menos un poco; PERO yo creo que el TechCamp creó un mayor impacto en mí, que el que yo hice en él.

Las personas que conocí en el lobby del hotel, que trabajaban en contra de la trata de personas, estaban sorprendidos cuando les dije sobre lo que el TechCamp trataba de hacer. Ellos preguntaron, “¿Cómo es que los tecnólogos pueden crear un impacto social?”. Yo creo que esa respuesta puede abarcar varios volúmenes. Las  personas no se dan cuenta sobre el potencial que los tecnólogos y los programadores tienen para cambiar el mundo. Hasta apostaría que ni los mismos tecnólogos y programadores ven su propio potencial.

Yo soy un programador y estoy muy orgulloso de eso. Yo puedo tomar una pequeña idea y transformarla en algo físico, usable e influyente Yo puedo trabajar con ideas de otros o puedo halar de un flujo infinito de ideas en mi propia mente. Yo puedo crear cosas desde cero
Los Programadores son poderosos… Una fuerza a tener en cuenta.

¿Qué pasaría si los programadores comenzaron a descubrir su potencial para crear un impacto en la sociedad alrededor de ellos? ¿Qué pasaría si los programadores serian bienvenidos en los círculos de esos que pelean en contra de cosas como el gobierno, la corrupción, la violencia doméstica, el racismo y el crimen? Yo les diré… Comenzaría un movimiento de transparencia e innovación social.

Organizaciones: Estoy aca para decirles que los programadores no son unos geeks socialmente ineptos que solo saben hablar con calculadoras. Ellos son personas normales con un poder que USTEDES NECESITAN. Ellos pueden a ayudarlos a pensar sobre soluciones a problemas de maneras que nunca se habían imaginado. Si ustedes alimentan su pasión para hacer una diferencia ellos ayudarán en la contienda y desatarán su potencial.

Desarrolladores: Una app mas de linterna no cambiará el mundo. Como programador, tu tienes un potencial único a crear cosas sorprendentes que pueden hacer un impacto social. Es tiempo para descubrir el potencial que tenemos y usar nuestros poderes para el bien del hombre. Encuentren una causa que los encienda y actúen.

¿Listos para cambiar el mundo? Miren estos enlaces:

Si conocen más, hágamenlo saber y los agregaré!