martes, 29 de mayo de 2012

¿Como Hacer un Software para Microfinancieras?.- Part V.- Herramientas

¿Como hacer un software para Financieras?.- Part V.- Las Herramientas.

Sin presupuesto, es difícil elaborar un sistema de microfinanzas, sobre todo porque requieren alta calidad en el sistema.
En el mundo Open Source existen herramientas igual de competitivas que en el lado comercial. Es por ello que es un gran apoyo para el proyecto.

Sistema Operativo para desarrollo.

Linux: La Navaja Suiza Hiper vitaminada, la plataforma friki por excelencia. Soporta multitud de Lenguajes, emuladores, compiladores, virtualización,  etc, etc. La plataforma 64 Bits de Linux es casi tan competitiva como la x86, así que Linux es un excelente candidato.
Pero entre todas las distros, solo las basadas en Ubuntu Y Gnome (por desgracia) prometen una estabilidad deseable sin tantos dolores de cabeza. único defecto de la Plataforma 64 bits es su integración con las ultimas versiones de java, esencial en el trabajo diario. Por lo que Linux Mint es la mejor opción.
En el mundo Linux disparata la cantidad de versiones que existen, por eso es preferible versiones comerciales de RedHat u OpenSUSE, afortunadamente Canonical liberó la versión LTS de Ubuntu, de la cual esta basada Linux Mint, con la garantía de que se mantendrá por cinco años... La Opción Linux Mint 13 64 Bits.

Base de datos de Desarrollo.

Aunque el sistema será independiente del motor de base de datos, solo MySQL cuenta con herramientas de desarrollo RAD y que son open source, además que el soporta varios engines. Postgresql tiene un entorno de desarrollo, pero todavía no es capaz de llegar a las herramientas que tiene MySQL. por lo que MySQL es la opción.
Usaremos la edición comunity de MySQL Workbench para diseñar la base de datos. SQLYog emulado con wine para ejecutar las consultas, MySQL Administrator para gestionar respaldos y AQUA Data Studio 4.7 para diseñar consultas complejas.
Recordemos que todas son Open Source y nuestro proyecto es Open Source.

Lenguaje de Desarrollo.

Al usar PHP, tambien abrimos la infinidad de herramientas que se pueden usar en el desarrollo del sistema, aunque existen muchos frameworks, no existen ninguno que soporte las reglas de negocios e interactividad usuario-sistema como lo necesitamos. así que no usaremos framework alguno. PHP es la mejor opción, solo tiene dos detalles importantes.

1. Existe un problema al operar con gran precisión (bueno, dicen que no es problema de PHP, si no del compilador).
2.- No existen tipos date definidos tal y como deberían ser. Y eso es critico en cálculos basados en tiempo.

Por supuesto, que para la interacción con el usuario usaremos jquery-mobile, ¿Porqué mobile?... pues porque lo corre un desktop y un dispositivo móvil.

Utilizaremos Librerías afines de utilerías, como para escribir pdf, excel, etc. Existen buenas practicas de programación para el llamado de archivos, buenas costumbres nacidas en Java, y que adaptaremos al lenguaje.

Para el IDE usaremos Eclipse PDT, con actualizaciones en español. Es lo más cercano a Zend Studio, algunos dicen que netbeans es mejor, pero a a mi me ha dado más lata trabajarlo, ni decir con el consumo de memoria
 Para el UML usaremos Argo UML, pues es el único que corre correctamente en Ubuntu 12.04, no decir único, pero comparando sus prestaciones, portabilidad, facilidad de uso, consumo de RAM, etc, etc... es la mejor opción.

Herramientas de Apoyo.

Usaremos Xmind para ordenar nuestra ideas, Gantt Poject para la Planeación del Desarrollo, Dropbox para sincronizar el código. Skype y pidgin para comunicarnos.

La próxima empezaremos por el diseño de la Base de Datos.

domingo, 27 de mayo de 2012

Los once Principios de las Microfinanzas según la CGAP.

Les comparto un documento, que me pareció que descrbe a las Microfinanzas como Ninguno. Escrito por la CGAP y Aprobado en una Cumbre del G8.

  1.  Las personas de escasos recursos necesitan una variedad de servicios financieros, no sólo
    préstamos. Además de crédito, la gente pobre desea contar con servicios de depósito, seguros y
    servicios de transferencia de dinero.
  2. Las microfinanzas representan una herramienta poderosa en la lucha contra la pobreza.
    Los hogares pobres utilizan los servicios financieros para aumentar sus ingresos, invertir en
    bienes y reducir su vulnerabilidad a choques externos.
  3. Las microfinanzas se refieren a la creación de sistemas financieros que atiendan las
    necesidades de las personas pobres. Las microfinanzas podrán alcanzar su máximo potencial,
    solamente si son integradas al sistema financiero ya establecido de un país.
  4. Las microfinanzas pueden y deben ser sostenibles si se espera alcanzar a un gran número
    de personas pobres. A menos que los proveedores de microfinanzas cobren lo suficiente para
    cubrir sus costos, siempre estarán limitados por la escasa e incierta oferta de subsidios por parte de cooperantes y gobiernos.
  5. Las microfinanzas requieren la construcción de instituciones financieras locales y
    permanentes que puedan atraer depósitos domésticos, reciclarlos en forma de préstamos, y
    ofrecer otros servicios financieros.
  6. El microcrédito no es siempre la solución. Otros tipos de ayuda son ideales para aquellas
    personas tan pobres que no tienen ingresos ni medios de repago.
  7. Los techos a las tasas de interés pueden perjudicar el acceso de las personas pobres a
    créditos. Cuesta mucho más hacer varios préstamos pequeños que hacer pocos préstamos
    grandes. La fijación de tasas de interés máximas impide que las instituciones microfinancieras
    cubran sus costos, y por ello corten la oferta de crédito para las personas pobres.
  8. El papel del gobierno es uno de facilitador, no el de un proveedor directo de servicios
    financieros. Los gobiernos casi nunca pueden desempeñar un buen papel como prestamistas,
    sin embargo estos pueden establecer un marco político de apoyo.
  9. Los fondos de los cooperantes deben complementar en vez de competir con el capital del
    sector privado. Los subsidios que ofrecen los cooperantes deben ser una ayuda temporal de
    arranque y están diseñados a apoyar a una institución hasta que ésta pueda explotar fuentes de
    fondos privadas, tales como depósitos.
  10. La limitación crucial es la insuficiencia de instituciones sólidas y de gerentes calificados.
    Los cooperantes deberán centrar su ayuda en la construcción de capacidad institucional.
  11. Las microfinanzas funcionan mejor cuando se revela y mide su desempeño. La revelación
    de datos no sólo ayuda a los accionistas a juzgar los costos y las ganancias, sino también a
    mejorar el desempeño. Las IMFs necesitan reportar información exacta y comparable sobre su
    desempeño financiero (p. ej. repago de préstamos y recuperación de costos) al igual que sobre
    su desempeño social (p. ej. número y nivel de pobreza de los clientes).
No tengo opnión al respecto de cada uno de ellos, solo que esto casi describe en su totalidad a las Microfinanzas.

Documento y Cita Original: http://www.cgap.org/gm/document-1.9.2752/KeyPrincMicrofinance_spa.pdf

admin@opencorebanking.com

viernes, 4 de mayo de 2012

¿Como mejorar Android?.

Dejen contar que actualmente pruebo Android en muchas plataformas, y junto a mi hijo (un loco por los vídeo juegos), evaluamos aplicaciones Android, después de mucho "trabajar", hemos reunido alguna recomendaciones para este Sistema Operativo.
No sin antes decir que Android es un sistema operativo que no solo tiene futuro en Teléfonos y dispositivos similares,  si no también en el escritorio, con sus cambios claro.
Fragmentación:  Uno de los problemas mas criticados de Android es su seudo-fragmentación, pero el problema no está en la cantidad de versiones que existe del SO, pues las apps son compatibles entre un 70 a 80% entre versiones, donde realmente existe la fragmentación es en la variedad de dispositivos que existen con alguna versión de android corriendo, la variedad de dichas características es inmensa. Eso no pasa con iOS, un solo SO, un solo hardware... incluso para actualizar Apple solo tiene que tocar algunas cosas. Android en esto es un pandemónium : No es lo mismo un WM8650 con 192 RAM y un vetusmo ARM9Ej-s, que un Casio C771 Commando o que un Samsung Galaxy SII... si tienes de los últimos podrás correr casi cualquier app, y si tienes el primero: Lo más que puedes correr es youtube app sin HD...
Esto hace una gran diferencia en la compatibilidad de apps, incluso con buenos procesadores como el Nvidia existen fallos por esta fragmentación. Es lógico que conforme avanza la técnología aparecen nuevas ventajas para los dispositivos, y también es lógico que los dispositivos antiguos no podrán aprovechar lo nuevo.

Android tiene una base de muchos usuarios, eso es una poderosa ventaja que google debe explotar más (Y no precisamente con Admob). A Google le toca la responsabilidad de mejorar Android en todas sus versiones... bueno eso ya lo sabemos, pasemos a los práctico.

Existen cuatro características básicas de los dispositivos Android.

  • Memoria RAM
  • Procesador o CPU (Tipo API, Escalabilidad, etc).
  • DSP / GPU.
  • Pantalla.
Todo lo demás (acelerómetros, GPS, etc) solo es parte de la mejora de la experiencia del usuario.
La combinación de estos componentes generan una experiencia mala/buena de Android, y repito, esto no pasa en iOS pues todo (salvo entre versión y versión) es lo mismo.

Estos componentes son cruciales porque:


Memoria RAM: Android es un SO que se gestiona de buena forma la RAM, evitando lecturas/Escrituras innecesarias al Disco Interno, lo malo de esto es que la RAM se convierte a veces en un cuello de botella en dispositivos con poca memoria.


Procesador o CPU: Hasta hace poco no sabía que ARM a pesar de ser una plataforma abierta ( y licenciable), no es del todo estándar, y es que cada generación de ARM y cada fabricante tienen sus propias mejoras, esto hace más difícil mantener una integridad en un SO.

DSP / GPU.:  Juegos, Vídeo, Música, Interfaz de Usuario y muchas otras apps dependen de una GPU. En ausencia del GPU, el uso del CPU aumenta, haciendo más lento tu dispositivo.

Pantalla: Que es un Dispositivo sin una buena Pantalla, la experiencia inicial de un usuario empieza al tocar. uno se enamora de android al tocar ( como si de una fémina se tratara XD ), lo malo de esto es que no nos dicen si la pantalla es capacitiva o resistivas... o cuantos puntos de sensibilidad tiene, de que calidad es, etc.  Su importancia radica en que es el punto de acceso entre el usuario y el SO.

Y sigo sin decir como mejorar, creo que se volverá una clase de android...

Vayamos con las Aplicaciones...

En Android, siguen creciendo las apps como si fueran espuma de refresco de cola con  mentos, casi de forma descontrolada. es una ventaja a lo Linux, todas la apps en un solo lugar... lo malo es lo malo de Linux, no hay apps sin conexión a internet. El usuario común percibe que es un error del SO. No todas las apps aprovechan el potencial del dispositivo(como lo hacen en iOS), pues no saben si el dispositivo tiene acelerómetro (uno de verdad) o sensor de proximidad(El desarrollador le programa capacidad para usar el acelerómetro y sabe con certeza que funcionará en todos los dispositivos). Lo que el desarrollador quiere hacer es ganar dinero, y eso se hace teniendo como objetivo un mercado de clientes con un dispositivo casi abstracto.

¿Y como mejorar Android?...
Ahora si empezamos con los polémico:

Mirar al enemigo: Nadie sabe más de variedad de entornos variables, usuarios variables y noveles que un gran rival de Google: Microsoft. Microsoft ha sido exitoso en implementar la plataforma PC, con una variedad de dispositivos que van desde setbox hasta tabletas, y usuarios desde niños hasta científicos, hablando spanglish (como yo) hasta chino mandarín. Si Google quiere mejorar android debe copiar las  buenas prácticas de Microsoft (Dios sabe si no las han patentado).

Mejorar los requerimientos de las apps: hasta ahora Google solo se centra en calificar la aplicación, dejando de lado si los errores o mala experiencia del usuario fueron culpa del hardware... omite calificar el hardware.
 Mi propuesta es sencilla y fácil de implementar:

Paso 1: Crear una firma por cada dispositivo, incluyendo sus características básicas, dándole "nombre" a cada dispositivo viejo o nuevo en el mercado.



paso 2: Generando Información de errores de las aplicaciones: Al tener una base enorme de usuarios, google puede generar información de las aplicaciones instalas fácilmente, ya lo hace, pero no con el detalle ni fin aecuado.




Paso 3: Crear un tercer tag  de Instalación: Google genera una especie de mensaje cuando tu dispositivo no es compatible con la aplicación. No te da razones, limitando tu capacidad de criterio en la compra de próximo Android. Dicho aviso esta basado, por lo  general, en la versión del SO. No por el hardware. El tercer Tag debe de ser informativo, al decir que la AppX que quieres instalar ha presentado problemas con el dispositivo que tienes (buscándola por hash, por ejemplo).

Y todo esto, google lo puede hacer con pocas modificaciones.


Calidad de Hardware: Vamos a copiarle a Microsoft, Microsoft Implementó el WHQL en Windows, Androidm debería tener un sistema similar.

Seguridad.

Comprobación Checksum: Desde Windows 7, y últimos SP de Windows anteriores, Microsoft Implementó el reconocimiento de editores para Instalaciones, una especie de checksum para sus programas.... ¿Porqué no hacerlo con Android?... pero eso es solo parte del problema.

Piratería: Casi todos los programas populares para Android se pueden conseguir desde webs de warez, vulnerando la integridad de sus aplicaciones. No es que se quiera que Google monopolice las aplicaciones, pero debe implementar un sistema para que avise al usuario de una app insegura o de origen desconocido. A veces hay que cuidar al usuario de sí mismo.


Distribución de Aplicaciones: Dos opciones podrían disminuir la piratería y aumentar la ventas de Apps:


Formas de pago: El problema con las apps no está en el precio: si no en la forma de pago, Google debería acondicionar el Google Play para adquirir tu aplicaciones por SMS y por regalo... un usuario X lo paga, y el usuario Y lo descarga mediante un cupón de regalo.

Precio: En este caso, no existe un problema en Android, pues la aplicaciones son económicas... es importante mencionarlo porque el usuario no debería tener excusas si le das una forma de pago rápida y efectiva.

Adds: malditas adds, esas ventanitas que hacen de tu aplicación una porquería,si no existen SO con publicidad es por algo... como imagina Google que se ve el SO en una pantalla de 320x480 un maldito banner que ocupa un 20 -30 % del tamaño de tu aplicación, aumentando incluso cuando usas el teclado.... personalmente tengo un enfoque como programador... 1.- casi nadie se hace rico con los adds. 2.- si lo que quieres es vender tu aplicación, no les pongas adds y ofrece una versión lite, si lo que quieres es darlo gratuitamente: No les pongas adds... son demasiados molestos y hacen que la experiencia del usuario sea una mierda.

Creo, que cada una de estas ideas, no tienen que ver con el SO en sí, si no en la forma que google administra el SO. Todo esto es fácil de implementar para una empresa como Google, que siempre ha estado a  la vanguardia en tecnología.


Gracias.

@pata_de_jaguar