Desarrollador Web, Gerente de la unidad de desarrollo de Maxnegocios.com.

Reflexionar no está de mas

| viernes, 26 de octubre de 2012

Existe algo que impulsa a un geek developer más que el dinero, y es la motivación, la innovación constante y medios para aprender y mejorar.

Estar en nuevos proyectos donde meter la mano, estar en constante aprendizaje sobre nuevos métodos y técnicas incluso apenas en paper es lo que realmente persigue un buen desarrollador, el dinero es importante para comprar comida y mantener a la esposa entretenida en el shopping, pero el aprender constantemente, es lo que realmente marca la diferencia entre un geek y alguien que programa para vivir.

Un developer nato, no es un ser común, no le puedes sacar una sonrisa diciéndole que le vas a aumentar el sueldo y tienes un año que no ejecutas un plan de training.

Cuando se va alguien como este tipo de ser, no te preguntes por cuanto se ha ido, pregúntate porque se aburrió en mi empresa. El geek se aburre rápidamente del mismo proyecto, éste quiere llenarse de problemas, dificultades, retos que lograr, piensa en binario y sus únicos juguetes son cosas que armar o desarmar, pero con dificultad, de esta misma forma ve la vida y sobre todo su trabajo.

El primer error que comete un "jefe" es estar pendiente del horario más que de la productividad, ejemplo: comentarios como ví a fulanito salir del edificio en horario de oficina, donde esta sutano, porque este equipo llegó tarde hoy etc etc etc; el horario de trabajo es importante, fomenta la disciplina y estimula la cooperación entre individuos, pero no es la clave del éxito.

Cabe destacar que la hora más productiva de un geek es en la noche, ese momento del día donde el cerebro convierte el alfabeto en binario es donde se nos ocurren las más grandes ideas, muchos tenemos papel y lápiz al lado de la cama.

Hablarle a un geek sobre horario es como hablarle a un niño de 3 años de política, el geek nunca va a entender porque se molestan por un horario cuando su cerebro trabaja las 24 horas del día para un proyecto. La única opción que tiene un empresario es aprender a programar o darle a libertad a que haga su trabajo, tomando el riesgo que no se aburra si pasan los meses y no le propones un nuevo y mayor reto.

Otro error y grave que cometen muchas empresas es no tener una política de training clara, no preparar al personal IT conlleva inevitablemente a los siguientes riesgos: el geek se desmotiva y se va de tu empresa a veces para formar una propia, queda un proyecto con menos personas y las que aún están comienzan a pensar en irse también, seguramente este geek lo tomó una empresa que te hace competencia, entonces, aparte de que tiene la persona con el conocimiento, las pocas que te quedan no están preparadas para obtener un producto tan sofisticado como la empresa que toma muy en cuenta la preparación técnica.

En conclusión, preparar a los ingenieros no es un lujo ni un gasto, es la única manera de mantenerlos motivados y obtener productos realmente competentes, en un mundo donde la innovación es la regla de oro.

Muchas empresas fomentan la investigación como parte de su cultura, muchos de estos desarrolladores incluyéndome, nos gusta compartir y colaborar vía RFC sobre estándares y nuevos proyectos, de estos paper es donde nace la tecnología que usaremos en los próximos años, por esta razón es vital que tus geeks estén al día y no lo veas como: ya está éste hablando con sus amigos de Europa, Japón o Estados Unidos. Recuerda que si tú colaboras en estos temas de discusión, si estos se convierten en estándares estarás un paso adelante de la competencia, recomiendo revisar los RFC de WebSockets por Google.

La norma de vestimenta es obviado en empresas avanzadas, compare a un ingeniero de Google con un cajero de banco, verá que el cajero viste de corbata mientras que otro usa sandalias.
Estamos pasando por una etapa trascendental en la humanidad, una persona apenas en la universidad escribe un código y al año tiene un imperio, un grupo de desconocidos escriben alrededor de una idea y hacen quebrar empresas y modelos de negocios establecidos por más de 50 años, alguien quiere hacer algo diferente que no puede hacer desde su trabajo y es capaz de cambiar la forma como el mundo usa la tecnología, una persona quiere hacerle pasar un susto a un amigo y crea un troyano que ataca 30% de las computadoras alrededor del mundo, entonces, quieres tener a un tipo de estos a tu lado? O quienes alguien que llegue puntualmente y vista elegante.

Esa es tu decisión, pero mientras que lo piensas, estoy seguro que empresas que han cambiado las gráficas de Gant por RFC, que han cambiado los capta huellas por laptops para sus empleados IT, que han cambiado carteleras por pizarras, que han cambiado los cursos de ética por sesiones en vivo con comunidades de tecnología, están, en este momento, quitándote todo el mercado y probablemente no te dejará ni siquiera sacar un producto decente.

Desmotivador verdad? Así es, la era del negocio ha cambiado y medir al personal IT como quien dime a un obrero que pega ladrillos es cosa primitiva.

Siguiendo una palabra en Twitter

| domingo, 14 de octubre de 2012


Hace meses terminé es un su primera versión una aplicación para automatizar ciertas tareas en Twitter, se llama Botwitter.

Algunas de las características de mi aplicación son conocidas en otras plataformas como por ejemplo:


  • Crear una lista de tweets aleatorios.
  • Agendar un tweet para que en una determinada fecha y hora se ejecute.
  • Crear una lista de canales RSS para entregar un tweets cuando exista un cambio en alguno de ellos.
  • Conocer quienes dejan de seguirte (unfollow), mediante un reporte detallado por día.
  • Un reporte que muestra por día las actividades que has realizado con la herramienta, los tweets que has planificado y se han enviado y un porte de fallos.


Hasta el momento nada innovador, mas de lo mismo. Sin embargo, algo que a mí me gustó desarrollar y que a mucha gente también, es la posibilidad de hacer seguimiento a una palabra clave y poder hacer una respuesta automática. Esta función la he llamado Keyword-Follower.

Es como tener un asistente dentro de Twitter que te genera interacciones para después personalmente atenderlas. Por ejemplo: supongamos que quieres invitar a personas a un webinar sobre Android, puedes utilizar esta función para que cuando alguien escriba en Twitter "Android" le haces llegar la invitación con los datos del webinar.

Lo mejor de esto es que no necesariamente la persona a quien le llegue la invitación tiene que ser uno de tus seguidores, también puedes coloca como palabra de seguimiento "Android Desarrollador Caracas" y así filtras o eres mas preciso en los resultados.

Esta característica de mi aplicación hace que genere interacciones porque seguramente las personas te preguntarán sobre el webinar o simplemente te dará las gracias por la información, la idea es estar pendiente de estas interacciones para abordarlas personalmente. Ves? es como si tuvieras a alguien trabajando para generar interacciones pero es automático.

En las próximas semanas haré ciertas mejoras, como aplicar filtros para que la experiencia sea aún, ejemplo: que la respuesta se envíe a personas de mi región, o que se le envíe a personas que tengan mas de 100 seguidores, o que tengan mas de 1 año con su cuenta de twitter, o que tenga un avatar diferente al que Twitter coloca por defecto, etc etc.

Estoy seguro que sabrás en que usarlo, esto sirve para empresas, profesionales, estudiantes, tuiteros de toda clase.

Ingresa a http://www.botwitter.comhttp://www.botwitter.com y si te gusta recomiendala, espero poder ayudarte con Botwitter

Actualmente estoy construyendo (en base al core de botwittter) una suite de aplicaciones para Negocios y tendrá otro nombre, en su momento publicaré sobre ello.

Botwitter - Herramientas para Twitter

| miércoles, 16 de mayo de 2012

creado por: @gasparbelandria

Mejorando tu experiencia en Twitter
Botwitter es una fácil y rápida herramienta que le ayudará a realizar mercadeo, publicidad en tiempo real, programar tweets mediante un calendario por mes, semana y día, obtener estadísticas sobre el avance de su gestión y analizar e interpretar los resultados para hacer más inteligente sus actividades de promoción.
Ideal para individuos, empresas de cualquier tamaño y sector industrial y una herramienta indispensable para un Community Manager.

Dispone de diversas herramientas que le ayudará a generar interacciones, por ejemplo, cuenta con una herramienta con la que puedes crear respuestas a palabras claves, automáticamente Botwitter enviará el tweet que programaste como respuesta a esta Keyword.

También puedes crear listas de tweets para que sean publicados en el lapso de tiempo que elija. A continuación una lista de las herramientas con las que en este momento cuenta Botwitter.

Herramientas
Realtime.-
Realice mercadeo en tiempo real, obtenga seguidores relacionados a una palabra clave que elija, márquelos para realizar alguna operación y luego deje que hagamos el trabajo.

Keyword Followers.-
Obtenga seguidores basados en una palabra clave, Ud. solo elige las palabras y nosotros aseguramos que personas interesadas en su objetivo le sigan.

Tweet Scheduler.-
Programe los tweets que desee publicar por día, semana, mes incluso hora.

Analytics Tracking.-
Obtenga el progreso de su cuenta y analice las estadísticas en función a sus sesiones en botwitter, palabras claves que le ha resultado más efectivas y mucho más.

Tweet Aleatory.-
Cree una lista de tweets que desee siempre publicar y cada cierto tiempo realizaremos la tarea por Ud.

Unfollow.-
A partir del momento que comienza a usar Botwitter, el sistema hace una comparación de los seguidores del día con los anteriores y la diferencia las marca como cuentas que le han dado unfollow. Suele ser útil para determinar si las cuentas que han dado unfollow tienen un grado de influencia en el sector relacionado a tu perfil.

En este momento ha sido seleccionado entre los 40 mejores proyectos web de emprendimiento en España, la votación es hasta el 01 de Junio 2012, acá:


Para votar basta con dar clic en los botones sociales del enlace anterior.

Tips para disminuir el consumo de datos y batería Samsung Galaxy Sii y aplica para otros equipos con Android

| viernes, 11 de mayo de 2012

Varias personas me han comentado en twitter @gasparbelandria porque su celular consume tanta batería y datos. Yo creo que no existe una formula precisa para el ahorro de ambos, yo he obtenido con mi galaxy s2 buenos resultados los cuales voy a mencionar a continuación.

Inicialmente comencé a bajar aplicaciones para medir y sobre todo controlar el consumo de datos y voz, entre las mejores que pude encontrar en Play Store estan: PhoneUsage, 3G Watchdog, NetCounter y Call Meter NG.

La buena noticia para los que tenemos galaxys2 y vamos a actualizar a la versión 4.0, es que Ice Cream Sandwich trae su propio panel de control para consumo de datos.

Muchas veces el consumo de datos es porque las aplicaciones (sin darnos cuenta) se actualizan y esto obviamente genera consumo de datos, porque se descarga el apk y se instalar, no hay forma de controlarlo, yo he ido probando y cuando veo que una aplicación se actualiza mucho y no la necesito la des-instalo.

Para la Galaxy Sii, en el menú de configuración -> aplicaciones -> servicios en ejecución, puedes ver todas las aplicaciones que en ese momento están abiertas, muchas de ellas no las necesitamos tener abierta y es posible que hagan solicitudes a Internet.

Cuando te estes bajando una aplicacion te dice todas las cosas que hace, por ejemplo: Uso completo de Internet, Acceso a la Agenda etc etc. Ten presente si la aplicacion que estas bajando te advierte que usa completamente el Internet, si no la necesitas analiza antes de bajarla.

Para el consumo de la batería he notado que las aplicaciones que personalizan el móvil como los Launcher en general, solicitan mucha energía en sus animaciones, al igual que los fondos de pantalla animados, otra cosa que consume energía que al desactivar noté un buen cambio es el motor del vibrador al pulsar las teclas, este motor cada vez que pulsas una tecla hace que el móvil tenga una pequeña vibración y cada vez que lo hace consume cantidades importantes de batería, yo lo he desactivado y noté el cambio enseguida.

Las aplicaciones que hacen encender el led para indicar actividades como por ejemplo el BlackBerry consume también mucho recurso.

Yo tengo todas estas opciones desactivadas, cuando quiero personalizar mi celular lo hago por ratos cortos.

Si tiene alguna pregunta o sugerencia en este tema u otro relacionado a samsung galaxy s2 por favor use mi cuenta de twitter @gasparbelandria.

Siga frecuentemente los hashtag #galaxys2 y #galaxynote allí estoy colocando diariamente tips.

Saludos

#socialcrm + minería de datos + business intelligence + redes neuronales = #crm inteligente. Que tu crm te sugiera que hacer no tiene precio.

| jueves, 26 de abril de 2012
Esta entrada es en respuesta a:

http://www.re-ingenia.com/blog/2012/01/vtiger-crm-inteligente/

de Jeremías Maggi el cual aprecio y leo bastante sus contenidos.




Hola Jeremías,

Te explico mi idea:

El fundamento de un sistema de inteligencia artificial no pretende más que sugerir acciones en base a un patrón de conducta estudiado, cada sistema está conformado por entradas que generan acciones y reacciones, un CRM visto como cultura organizacional y no como un software no se escapa de este patrón.

Considerando que sé lo que digo cuando hablo de Inteligencia Artificial específicamente Redes Neuronales Perceptrónicas Multicapas  puedo identificar que un sistema humano como las actividades de ventas puede ser claramente analizado mediante algoritmos y procesados para que tenga la habilidad de aprender según los perfiles, patrones y tendencias suministrados.

Por ejemplo, mediante la minería de datos (una técnica de muchas que tiene la IA) se pueden descubrir patrones ocultos en los datos que recibe un CRM, como pueden ser reglas de consumo, regresiones entre variables, segmentos de mercado, hábitos de los consumidores y otras conductas de comportamiento utilizando métodos de probabilidades, grafos, estadísticas y muchos más.

Cada conjunto de entrada genera gráficamente una curva y esta curva es un patrón analizable, por ejemplo, se puede analizar las cantidades de visitas a un cliente y otorgar prioridad a otro que en determinada hora del día, se detectó que tiene más posibilidad de atender el ejecutivo.

O también puede encontrar que un cliente tenga una frecuencia de consumo en determinadas horas del día, entonces la estrategia del mercado se puede dirigir a estos en las horas adecuadas para aumentar su experiencia con el producto y entusiasmarlo a compartir estos en sus redes sociales.

Imagínate que cuando te levantes por la mañana, tu CRM te genere la lista de visitas tomando en cuenta la ruta más optima por medio del análisis de grafos, previendo que en determinadas horas existe congestionamiento en ciertas zonas e incluso recomendándote visitas en horas de mediodía en sitios cercano donde te guste almorzar, esto es posible generando base de conocimiento.

Puedes tener en tu CRM lógica de ruteo, maximización de tareas, minimización de riesgos, inspección y control automático, imagina que un compañero indique un embotellamiento y que el CRM te genere una nueva trayectoria, grandioso no?.

Se me ocurren cientos de aplicaciones que sin duda alguna, generan beneficios para la inteligencia de negocios. Proyectos como Frito-Lay, COPAMEX, CEMEX, son pioneros en estas áreas y utilizan inteligencia artificial para apoyar su competitividad.

Mi propuesta no es obedecer un software, ni que el CRM sea un Siri (asistente personal de Iphone) que indique que hacer, para nada, mi propuesta es hacer que los avances de la tecnología mejoren la calidad de vida de los empleados y la productividad en las empresas.

Respeto mucho tu opinión, pero pienso que es posible apoyar el negocio con todas estas técnicas.

Un abrazo

P.D. sugiero leer el libro "Building Data Mining Aplications for CRM" de Alex Berson, Stephen Smith y Kurt Thearling.


Mc Graw Hill

TimeZone Array PHP

| viernes, 3 de febrero de 2012

$africa = Array('Africa/Abidjan', 'Africa/Accra', 'Africa/Addis_Ababa', 'Africa/Algiers', 'Africa/Asmara', 'Africa/Asmera', 'Africa/Bamako', 'Africa/Bangui', 'Africa/Banjul', 'Africa/Bissau', 'Africa/Blantyre', 'Africa/Brazzaville', 'Africa/Bujumbura', 'Africa/Cairo', 'Africa/Casablanca', 'Africa/Ceuta', 'Africa/Conakry', 'Africa/Dakar', 'Africa/Dar_es_Salaam', 'Africa/Djibouti', 'Africa/Douala', 'Africa/El_Aaiun', 'Africa/Freetown', 'Africa/Gaborone', 'Africa/Harare', 'Africa/Johannesburg', 'Africa/Juba', 'Africa/Kampala', 'Africa/Khartoum', 'Africa/Kigali', 'Africa/Kinshasa', 'Africa/Lagos', 'Africa/Libreville', 'Africa/Lome', 'Africa/Luanda', 'Africa/Lubumbashi', 'Africa/Lusaka', 'Africa/Malabo', 'Africa/Maputo', 'Africa/Maseru', 'Africa/Mbabane', 'Africa/Mogadishu', 'Africa/Monrovia', 'Africa/Nairobi', 'Africa/Ndjamena', 'Africa/Niamey', 'Africa/Nouakchott', 'Africa/Ouagadougou', 'Africa/Porto-Novo', 'Africa/Sao_Tome', 'Africa/Timbuktu', 'Africa/Tripoli', 'Africa/Tunis', 'Africa/Windhoek');

$america = Array('America/Adak', 'America/Anchorage', 'America/Anguilla', 'America/Antigua', 'America/Araguaina', 'America/Argentina/Buenos_Aires', 'America/Argentina/Catamarca', 'America/Argentina/ComodRivadavia', 'America/Argentina/Cordoba', 'America/Argentina/Jujuy', 'America/Argentina/La_Rioja', 'America/Argentina/Mendoza', 'America/Argentina/Rio_Gallegos', 'America/Argentina/Salta', 'America/Argentina/San_Juan', 'America/Argentina/San_Luis', 'America/Argentina/Tucuman', 'America/Argentina/Ushuaia', 'America/Aruba', 'America/Asuncion', 'America/Atikokan', 'America/Atka', 'America/Bahia', 'America/Bahia_Banderas', 'America/Barbados', 'America/Belem', 'America/Belize', 'America/Blanc-Sablon', 'America/Boa_Vista', 'America/Bogota', 'America/Boise', 'America/Buenos_Aires', 'America/Cambridge_Bay', 'America/Campo_Grande', 'America/Cancun', 'America/Caracas', 'America/Catamarca', 'America/Cayenne', 'America/Cayman', 'America/Chicago', 'America/Chihuahua', 'America/Coral_Harbour', 'America/Cordoba', 'America/Costa_Rica', 'America/Cuiaba', 'America/Curacao', 'America/Danmarkshavn', 'America/Dawson', 'America/Dawson_Creek', 'America/Denver', 'America/Detroit', 'America/Dominica', 'America/Edmonton', 'America/Eirunepe', 'America/El_Salvador', 'America/Ensenada', 'America/Fort_Wayne', 'America/Fortaleza', 'America/Glace_Bay', 'America/Godthab', 'America/Goose_Bay', 'America/Grand_Turk', 'America/Grenada', 'America/Guadeloupe', 'America/Guatemala', 'America/Guayaquil', 'America/Guyana', 'America/Halifax', 'America/Havana', 'America/Hermosillo', 'America/Indiana/Indianapolis', 'America/Indiana/Knox', 'America/Indiana/Marengo', 'America/Indiana/Petersburg', 'America/Indiana/Tell_City', 'America/Indiana/Vevay', 'America/Indiana/Vincennes', 'America/Indiana/Winamac', 'America/Indianapolis', 'America/Inuvik', 'America/Iqaluit', 'America/Jamaica', 'America/Jujuy', 'America/Juneau', 'America/Kentucky/Louisville', 'America/Kentucky/Monticello', 'America/Knox_IN', 'America/Kralendijk', 'America/La_Paz', 'America/Lima', 'America/Los_Angeles', 'America/Louisville', 'America/Lower_Princes', 'America/Maceio', 'America/Managua', 'America/Manaus', 'America/Marigot', 'America/Martinique', 'America/Matamoros', 'America/Mazatlan', 'America/Mendoza', 'America/Menominee', 'America/Merida', 'America/Metlakatla', 'America/Mexico_City', 'America/Miquelon', 'America/Moncton', 'America/Monterrey', 'America/Montevideo', 'America/Montreal', 'America/Montserrat', 'America/Nassau', 'America/New_York', 'America/Nipigon', 'America/Nome', 'America/Noronha', 'America/North_Dakota/Beulah', 'America/North_Dakota/Center', 'America/North_Dakota/New_Salem', 'America/Ojinaga', 'America/Panama', 'America/Pangnirtung', 'America/Paramaribo', 'America/Phoenix', 'America/Port-au-Prince', 'America/Port_of_Spain', 'America/Porto_Acre', 'America/Porto_Velho', 'America/Puerto_Rico', 'America/Rainy_River', 'America/Rankin_Inlet', 'America/Recife', 'America/Regina', 'America/Resolute', 'America/Rio_Branco', 'America/Rosario', 'America/Santa_Isabel', 'America/Santarem', 'America/Santiago', 'America/Santo_Domingo', 'America/Sao_Paulo', 'America/Scoresbysund', 'America/Shiprock', 'America/Sitka', 'America/St_Barthelemy', 'America/St_Johns', 'America/St_Kitts', 'America/St_Lucia', 'America/St_Thomas', 'America/St_Vincent', 'America/Swift_Current', 'America/Tegucigalpa', 'America/Thule', 'America/Thunder_Bay', 'America/Tijuana', 'America/Toronto', 'America/Tortola', 'America/Vancouver', 'America/Virgin', 'America/Whitehorse', 'America/Winnipeg', 'America/Yakutat', 'America/Yellowknife');

$antarctica = Array('Antarctica/Casey', 'Antarctica/Davis', 'Antarctica/DumontDUrville', 'Antarctica/Macquarie', 'Antarctica/Mawson', 'Antarctica/McMurdo', 'Antarctica/Palmer', 'Antarctica/Rothera', 'Antarctica/South_Pole', 'Antarctica/Syowa', 'Antarctica/Vostok');

$arctic = Array('Arctic/Longyearbyen');

$asia = Array('Asia/Aden', 'Asia/Almaty', 'Asia/Amman', 'Asia/Anadyr', 'Asia/Aqtau', 'Asia/Aqtobe', 'Asia/Ashgabat', 'Asia/Ashkhabad', 'Asia/Baghdad', 'Asia/Bahrain', 'Asia/Baku', 'Asia/Bangkok', 'Asia/Beirut', 'Asia/Bishkek', 'Asia/Brunei', 'Asia/Calcutta', 'Asia/Choibalsan', 'Asia/Chongqing', 'Asia/Chungking', 'Asia/Colombo', 'Asia/Dacca', 'Asia/Damascus', 'Asia/Dhaka', 'Asia/Dili', 'Asia/Dubai', 'Asia/Dushanbe', 'Asia/Gaza', 'Asia/Harbin', 'Asia/Hebron', 'Asia/Ho_Chi_Minh', 'Asia/Hong_Kong', 'Asia/Hovd', 'Asia/Irkutsk', 'Asia/Istanbul', 'Asia/Jakarta', 'Asia/Jayapura', 'Asia/Jerusalem', 'Asia/Kabul', 'Asia/Kamchatka', 'Asia/Karachi', 'Asia/Kashgar', 'Asia/Kathmandu', 'Asia/Katmandu', 'Asia/Kolkata', 'Asia/Krasnoyarsk', 'Asia/Kuala_Lumpur', 'Asia/Kuching', 'Asia/Kuwait', 'Asia/Macao', 'Asia/Macau', 'Asia/Magadan', 'Asia/Makassar', 'Asia/Manila', 'Asia/Muscat', 'Asia/Nicosia', 'Asia/Novokuznetsk', 'Asia/Novosibirsk', 'Asia/Omsk', 'Asia/Oral', 'Asia/Phnom_Penh', 'Asia/Pontianak', 'Asia/Pyongyang', 'Asia/Qatar', 'Asia/Qyzylorda', 'Asia/Rangoon', 'Asia/Riyadh', 'Asia/Saigon', 'Asia/Sakhalin', 'Asia/Samarkand', 'Asia/Seoul', 'Asia/Shanghai', 'Asia/Singapore', 'Asia/Taipei', 'Asia/Tashkent', 'Asia/Tbilisi', 'Asia/Tehran', 'Asia/Tel_Aviv', 'Asia/Thimbu', 'Asia/Tokyo', 'Asia/Ujung_Pandang', 'Asia/Ulaanbaatar', 'Asia/Ulan_Bator', 'Asia/Urumqi', 'Asia/Vientiane', 'Asia/Vladivostok', 'Asia/Yakutsk', 'Asia/Yekaterinburg', 'Asia/Yerevan');

$atlantic = Array('Atlantic/Azores', 'Atlantic/Bermuda', 'Atlantic/Canary', 'Atlantic/Cape_Verde', 'Atlantic/Faeroe', 'Atlantic/Faroe', 'Atlantic/Jan_Mayen', 'Atlantic/Madeira', 'Atlantic/Reykjavik', 'Atlantic/South_Georgia', 'Atlantic/St_Helena', 'Atlantic/Stanley');

$australia = Array('Australia/ACT', 'Australia/Adelaide', 'Australia/Brisbane', 'Australia/Broken_Hill', 'Australia/Canberra', 'Australia/Currie', 'Australia/Darwin', 'Australia/Eucla', 'Australia/Hobart', 'Australia/LHI', 'Australia/Lindeman', 'Australia/Lord_Howe', 'Australia/Melbourne', 'Australia/North', 'Australia/NSW', 'Australia/Perth', 'Australia/Queensland', 'Australia/South', 'Australia/Sydney', 'Australia/Tasmania', 'Australia/Victoria', 'Australia/West', 'Australia/Yancowinna');

$europe = Array('Europe/Amsterdam', 'Europe/Andorra', 'Europe/Athens', 'Europe/Belfast', 'Europe/Belgrade', 'Europe/Berlin', 'Europe/Bratislava', 'Europe/Brussels', 'Europe/Bucharest', 'Europe/Budapest', 'Europe/Chisinau', 'Europe/Copenhagen', 'Europe/Dublin', 'Europe/Gibraltar', 'Europe/Guernsey', 'Europe/Helsinki', 'Europe/Isle_of_Man', 'Europe/Istanbul', 'Europe/Jersey', 'Europe/Kaliningrad', 'Europe/Kiev', 'Europe/Lisbon', 'Europe/Ljubljana', 'Europe/London', 'Europe/Luxembourg', 'Europe/Madrid', 'Europe/Malta', 'Europe/Mariehamn', 'Europe/Minsk', 'Europe/Monaco', 'Europe/Moscow', 'Europe/Nicosia', 'Europe/Oslo', 'Europe/Paris', 'Europe/Podgorica', 'Europe/Prague', 'Europe/Riga', 'Europe/Rome', 'Europe/Samara', 'Europe/San_Marino', 'Europe/Sarajevo', 'Europe/Simferopol', 'Europe/Skopje', 'Europe/Sofia', 'Europe/Stockholm', 'Europe/Tallinn', 'Europe/Tirane', 'Europe/Tiraspol', 'Europe/Uzhgorod', 'Europe/Vaduz', 'Europe/Vatican', 'Europe/Vienna', 'Europe/Vilnius', 'Europe/Volgograd', 'Europe/Warsaw', 'Europe/Zagreb', 'Europe/Zaporozhye', 'Europe/Zurich');

$indian = Array('Indian/Antananarivo', 'Indian/Chagos', 'Indian/Christmas', 'Indian/Cocos', 'Indian/Comoro', 'Indian/Kerguelen', 'Indian/Mahe', 'Indian/Maldives', 'Indian/Mauritius', 'Indian/Mayotte', 'Indian/Reunion');

$pacific = Array('Pacific/Apia', 'Pacific/Auckland', 'Pacific/Chatham', 'Pacific/Chuuk', 'Pacific/Easter', 'Pacific/Efate', 'Pacific/Enderbury', 'Pacific/Fakaofo', 'Pacific/Fiji', 'Pacific/Funafuti', 'Pacific/Galapagos', 'Pacific/Gambier', 'Pacific/Guadalcanal', 'Pacific/Guam', 'Pacific/Honolulu', 'Pacific/Johnston', 'Pacific/Kiritimati', 'Pacific/Kosrae', 'Pacific/Kwajalein', 'Pacific/Majuro', 'Pacific/Marquesas', 'Pacific/Midway', 'Pacific/Nauru', 'Pacific/Niue', 'Pacific/Norfolk', 'Pacific/Noumea', 'Pacific/Pago_Pago', 'Pacific/Palau', 'Pacific/Pitcairn', 'Pacific/Pohnpei', 'Pacific/Ponape', 'Pacific/Port_Moresby', 'Pacific/Rarotonga', 'Pacific/Saipan', 'Pacific/Samoa', 'Pacific/Tahiti', 'Pacific/Tarawa', 'Pacific/Tongatapu', 'Pacific/Truk', 'Pacific/Wake', 'Pacific/Wallis', 'Pacific/Yap');

Una introducción a OAuth

| viernes, 26 de agosto de 2011
Esta es una traducción del texto original escribo por Hammer-Eran Lahav.


Valet clave para la Web por Hammer-Eran Lahav

Muchos coches de lujo cuentan con una llave de valet. Es una llave especial que da el encargado del aparcamiento y, a diferencia de su clave de regular, sólo permitirá el coche para ser conducido a una corta distancia al tiempo que bloquea el acceso al maletero y el teléfono móvil a bordo. A pesar de las restricciones de la clave de valet impone, la idea es muy inteligente. Darle a alguien el acceso limitado a su coche con una llave especial, mientras con la otra llave para desbloquear todo lo demás.

A medida que la web crece, más y más sitios dependen de los servicios distribuidos y computación en la nube: un laboratorio de impresión fotográfica de su fotos de Flickr, una red social utilizando la libreta de direcciones de Google para buscar amigos, o una aplicación de terceros que utilizan las API de servicios múltiples.

El problema es, a fin de que estas aplicaciones para acceder a los datos del usuario en otros sitios, piden usuarios y contraseñas. Esto no sólo requiere la exposición de las contraseñas de usuario a otra persona - a menudo la misma contraseña utilizada para la banca en línea y otros sitios - sino que también proporciona acceso a estas aplicaciones ilimitadas para hacer lo que quieran. Pueden hacer cualquier cosa, incluyendo el cambio de las contraseñas y el bloqueo de los usuarios.

OAuth proporciona un método para que los usuarios de conceder el acceso de terceros a sus recursos sin tener que compartir sus contraseñas. También proporciona una forma de conceder el acceso limitado (en el alcance, duración, etc.)

Por ejemplo, un usuario de la web (propietarios de los recursos) puede otorgar un servicio de impresión (cliente) el acceso a sus fotos privada almacenada en un servicio para compartir fotos (servidor), sin compartir su nombre de usuario y contraseña con el servicio de impresión. En su lugar, se autentica directamente con el servicio para compartir fotos que emite el servicio de impresión de la delegación específica de credenciales.

Más allá de cliente-servidor

En el modelo de autenticación de cliente-servidor, el cliente utiliza sus credenciales para acceder a los recursos alojados en el servidor. OAuth introduce una tercera función de este modelo: el propietario del recurso. En el modelo de OAuth, el cliente (que no es el propietario del recurso, sino que actúa en su nombre) las solicitudes de acceso a los recursos controlados por el propietario del recurso, sino alojado en el servidor.

Para que el cliente para acceder a los recursos, primero tiene que obtener el permiso del propietario del recurso. Este permiso se expresa en la forma de un token y juego secreto compartido. El propósito de la muestra es hacer innecesario que el propietario del recurso a compartir sus credenciales con el cliente. A diferencia de las credenciales de los recursos dueño, el token se pueden emitir con un alcance restringido y limitada de por vida, y revocar de forma independiente.

Tomando la inspiración de la comunidad de microformatos, la comunidad OAuth ha tomado una decisión en base a la primera versión del protocolo sobre las prácticas bien establecidas. OAuth representa la sabiduría combinada de muchos protocolos de la industria de propiedad, como Google AuthSub, Yahoo BBAuth, Twitter OAuth y Flickr API.

Cada protocolo ofrece un método distinto para el intercambio de credenciales de usuario para un token. OAuth fue creado por el estudio cuidadoso de cada uno de estos protocolos, la participación de sus autores, y extraer las mejores prácticas y comunes para apoyar a las nuevas implementaciones, así como una transición gradual de los servicios existentes para apoyar OAuth.

Un área donde OAuth es más evolucionado que algunos de los protocolos y servicios es la manipulación directa de los servicios no web. OAuth tiene soporte integrado para aplicaciones de escritorio, dispositivos móviles, set-top boxes, y de los sitios web del curso.

Historia.

OAuth Core 1.0

La comunidad OAuth, en gran medida, surgió de la comunidad OpenID. Alrededor de noviembre de 2006 Blaine Cook (http://romeda.org/) fue el encargado de añadir soporte OpenID para Twitter, donde se desempeñó como arquitecto en jefe. Blaine también estaba buscando un método de autenticación más para la API de Twitter, que no requiriera que los usuarios de Twitter pudieran compartir sus nombres de usuario y contraseñas con las aplicaciones de terceros.

Al mismo tiempo, Chris Messina (http://factoryjoe.com/) estaba trabajando junto a Larry Halff (http://larryhalff.com/) y el equipo de Ma.gnolia  en la integración de OpenID en el panel de Widgets de Ma.gnolia (el servicio Ma.gnolia se suspendió en febrero de 2009). Blaine y Chris se pusieron en contacto en diciembre de 2006 y organizaron una reunión con David Recordon (http://www.davidrecordon.com/) (OpenID co-creador) y otros en el Citizen Space OpenID para discutir las soluciones existentes.

Después de revisar la funcionalidad existente de OpenID y las limitaciones de su diseño, así como los protocolos de propietario, el grupo llegó a la conclusión de que había una necesidad de un nuevo estándar abierto para el control de acceso a la API que no requieren compartir la contraseña de inicio de sesión, lo que permite tecnologías como OpenID para su uso con llamadas a la API. Llamaron a la nueva iniciativa OpenAuth (inspirado en OpenID).

En abril de 2007, el OpenAuth Google Group (http://groups.google.com/group/openauth) fue creado con un pequeño grupo de ingenieros que trabajan en conjunto para producir una propuesta de un protocolo abierto. Resultó que este problema no es exclusivo de OpenID, con los desarrolladores de aplicaciones. El grupo original incluía Blaine Cook, Kellen Elliott-McCrea (http://laughingmeme.org/), Larry Halff, Hunt Tara (http://www.horsepigcow.com/), McKeller Ian (http://ian.mckellar.org/), Chris Messina, y unos cuantos más.

El 16 de abril de 2007, AOL presentó su protocolo OpenAuth (http://dev.aol.com/api/openauth). El protocolo de AOL se centró en el uso del sistema de acceso de AOL para autenticar a los usuarios de otras aplicaciones (por ejemplo, para entrar en el servicio AIM mediante una aplicación de terceros). Esto obligó al grupo a buscar un nuevo nombre, y el 5 de mayo de 2007, el nombre fue elegido OAuth (pronunciado oh-auth).

A principios de junio de 2007, DeWitt Clinton (http://blog.unto.net/) de Google se enteró del proyecto y expresó su interés en apoyar el esfuerzo. DeWitt llevó el esfuerzo de la atención del equipo de seguridad de Google y fueron Ben Laurie (http://www.links.org/) y Jonathan Sergent involucrados.

El 10 de junio de 2007, Blaine Cook y Kellen Elliott-McCrea, escribió el primer esbozo.

El 14 de junio, David Recordon se unió al esfuerzo de redacción. También se reunió con George Fletcher (http://practicalid.blogspot.com/) y Praveen Alavilli (http://whyidentity.blogspot.com/) de AOL para discutir la propuesta.

El grupo se reunió de nuevo a finales de junio de 2007 en FooCamp (http://wiki.oreillynet.com/foocamp07/index.cgi). En julio de 2007 después de la primera iPhoneDevCamp (http://www.iphonedevcamp.org/), que contó con la asistencia y el OAuth fué discutido por primera vez en público, se decidió que había llegado el momento de abrirlo a otros a unirse.

El público OAuth Google Group (http://groups.google.com/group/oauth) fue creado el 10 de julio y el 15 de julio David Recordon lleva a la colección de notas y lo convirtió en el proyecto las especificaciones reales (http://groups.google.com/group/openauth/web/spec?version=4).


Maquetas iniclaes del Logo OAuth por Chris Messina

A medida que el grupo se abrió durante FooCamp y iPhoneDevCamp, y se movieron a la nueva lista otros colaboradores como Mark Atwood (http://mark.atwood.name/), John Panzer (http://www.johnpanzer.com/), Sandler Eran (http://eran.sandler.co.il/), y Slesinsky Brian (http://slesinsky.org/brian/). El 26 de julio el proyecto por primera vez se publicó (http://groups.google.com/group/openauth/web/spec). El 5 de agosto de 2007, Michal Migurski (http://mike.teczno.com/) presentó la primera Implementacion Cliente de OAuth en PHP y Python, diseñado para trabajar con el entonces privado prototipo de Twitter OAuth API.

El 27 de julio de 2007, Hammer-Eran Lahav (http://hueniverse.com/) se unió al proyecto y empezó a contribuir a la especificación, con el tiempo adquirió un puesto en la comunidad como editor. El 21 de agosto y el 28, el grupo se reunió en persona en la oficina de Twitter, y trabajaron juntos para elaborar un proyecto 0.9 (http://code.google.com/p/oauth/source/browse/spec/trunk/oauth.html?spec=svn33&r=33).

Entre julio y noviembre de 2007, la comunidad publicó siete proyectos adicionales. Los proyectos recibieron un interés creciente, retroalimentación de la comunidad y las contribuciones, sobre todo la limpieza a las especificaciones iniciales de Larry Halff y Sieling Todd (http://www.toddsieling.com/Todd_Sieling.html), y la reestructuración del documento y la transición hacia el "flujo unificado" (un flujo de trabajo único para las tres clases de clientes - en la web de escritorio basado, y móvil) de Eran martillo Lahav.

El 4 de diciembre, la especificación Core OAuth 1.0 (http://oauth.net/core/1.0/) fue declarada como finalizada en el “Internet Identity Workshop” (http://www.internetidentityworkshop.com/), superando a OpenID 2.0 por un día. Ma.gnolia tuvo la primera implementación en vivo OAuth producción. El 26 de agosto de 2008, después de la ayuda de Gabe Wachob (http://blog.wachob.com/) y el equipo legal de Yahoo!, todos los colaboradores originales de la especificación de OAuth y su empleador ejecutó el OAuth y el acuerdo de licencia (http://hueniverse.com/2008/08/oauth-licensed-a-step-on-the-way-to-the-open-web/), lo que garantiza que la especificación seguirá siendo libre y disponible para todos los ejecutores.

Terminología

Cliente, Servidor y Propietario de Recurso.

OAuth define tres roles: el cliente, el servidor y el propietario del recurso (llamado el Triángulo de Amor OAuth por Leah Culver). Estos tres roles están presentes en cualquier transacción OAuth, en algunos casos, el cliente también es el propietario del recurso. La versión original de la especificación utiliza un conjunto diferente de condiciones de estos roles: consumidor (cliente), proveedor de servicios (servidor), y el usuario (propietario del recurso).

En el modelo de autenticación de cliente-servidor, el cliente utiliza sus credenciales para acceder a los recursos alojados en el servidor. A lo que el servidor concierne, el secreto compartido utilizado por el cliente pertenece al cliente. El servidor no le importa de dónde viene o si es el cliente actúa en nombre de alguna otra entidad.



Hay muchas veces cuando el cliente está actuando en nombre de otra entidad. Esa entidad puede ser otra máquina o persona. Cuando un tercer actor está involucrado, por lo general un usuario interactuar con el cliente, el cliente está actuando en nombre del usuario. En estos casos, el cliente no accede a sus recursos propios, sino los del usuario - el propietario del recurso.

En lugar de utilizar las credenciales del cliente, el cliente está utilizando las credenciales del propietario de los recursos para hacer las solicitudes - que pretende ser el propietario del recurso. Las credenciales de usuario suelen incluir un nombre de usuario o la pantalla de nombre y una contraseña, pero los propietarios de los recursos no se limitan a los usuarios, que pueden ser de cualquier entidad que controla los recursos del servidor.



El modelo se hace un poco más detallado cuando el cliente es una aplicación basada en web. En ese caso, el cliente se divide entre un componente de front-end, por lo general se ejecutan en un navegador web en el escritorio del propietario del recurso, y un componente de fondo, que se ejecutan en el servidor del cliente.

El propietario de los recursos está interactuando con una parte de la aplicación cliente mientras el servidor está recibiendo peticiones de otra parte.



Recursos Protegidos

Un recurso protegido es un recurso almacenado en (o prestados por) el servidor que requiere autenticación para acceder a él. Los recursos protegidos son propiedad o están controlados por el propietario del recurso. Cualquier persona que solicite el acceso a un recurso protegido debe estar autorizado para ello por el propietario del recurso (impuesta por el servidor).

Un recurso protegido puede ser de datos (fotos, documentos, contactos), servicios (colocar el punto del blog, la transferencia de fondos), o cualquier otro recurso que requieren restricciones de acceso. Mientras OAuth puede ser utilizado con otros protocolos, este solo está definido para recursos HTTP(S).

2 piernas, 3-piernas, n-piernas

El número de piernas se utiliza para describir una solicitud de OAuth, normalmente se refiere al número de partes involucradas. En el flujo de OAuth simple: un cliente, un servidor, y un propietario de los recursos, el flujo se describe como tres piernas. Cuando el cliente es el propietario del recurso (es decir, actuando en nombre propio), se describe como dos piernas. Piernas adicionales por lo general significan diferentes cosas para diferentes personas, pero en general significa que el acceso es compartido por el cliente con otros clientes (re-delegación).

Credenciales y Tokens

OAuth utiliza tres tipos de credenciales: las credenciales del cliente, las credenciales temporales, y las credenciales de testigo. La versión original de la especificación utiliza un conjunto diferente de los términos de estas credenciales: clave del consumidor y clave secreta (las credenciales del cliente), solicitud de token y la clave secreta (credenciales temporales), y el token de acceso y clave secreta (credenciales token). La especificación sigue utilizando un nombre de parámetro 'oauth_consumer_key "por razones de compatibilidad.

Las credenciales del cliente se utiliza para autenticar al cliente. Esto permite al servidor recopilar información sobre los clientes que utilizan sus servicios, ofrecen a algunos clientes un trato especial, tales como límite de acceso libre, o proporcionar el propietario del recurso, con más información sobre los clientes que quieran acceder a los recursos protegidos. En algunos casos, las credenciales del cliente no se puede confiar y que sólo puede ser utilizado sólo para fines informativos, como en los clientes de aplicaciones de escritorio.

Las credenciales Token se utilizan en lugar del nombre de usuario del propietario del recurso y la contraseña. En lugar de que el propietario del recurso comparta sus credenciales con el cliente, este autoriza al servidor para emitir una clase especial de credenciales para el cliente que representa la concesión de acceso proporcionada al cliente por el propietario del recurso. El cliente utiliza las credenciales de token de acceso al recurso protegido sin tener que saber la contraseña del propietario del recurso.

Las credenciales Token incluyen un identificador de señal, por lo general (pero no siempre) una cadena aleatoria de letras y números que es único, difícil de adivinar, y se combina con un Token Secret para proteger la señal de ser utilizados por personas no autorizadas. Las credenciales Token son generalmente limitados en su alcance y duración, y puede ser revocado en cualquier momento por el propietario del recurso sin afectar a otras credenciales token emitidas a otros clientes.

El proceso de autorización OAuth también utiliza un conjunto de credenciales temporales que se utilizan para identificar la solicitud de autorización. Con el fin de dar cabida a diferentes tipos de clientes (basado en la web, de escritorio, móviles, etc), las credenciales temporales ofrecen una mayor flexibilidad y seguridad.

En OAuth 1.0, el medio secreto de cada conjunto de credenciales se define como un secreto de simétrica compartida. Esto significa que tanto el cliente y el servidor debe tener acceso a la misma cadena de clave secreta. Sin embargo, OAuth es compatible con un método de autenticación basado en RSA, que utiliza un cliente secreto de asimétrica. Las credenciales diferentes se explican con más detalle más adelante.

Protocolo de flujo de trabajo

OAuth se explica mejor con ejemplos reales. La introducción de la especificación incluye un ejemplo similar pero se centra en la sintaxis de llamadas HTTP. Este recorrido muestra una sesión típica de OAuth, e incluye las perspectivas de los propietarios de los recursos, cliente y servidor. Los sitios web y personas que se mencionan son ficticios. Las referencias de Escocia son reales. Y así comienza nuestra historia ...

Jane está de vuelta de sus vacaciones en Escocia. Pasó dos semanas en la isla de "Islay sampling Scotch". Cuando llega a casa, Jane quiere compartir algunas de sus fotos de vacaciones con sus amigos. Jane utiliza Faji, un sitio para compartir fotos de viaje. Ella firma en su cuenta (se logea) en faji.com, y sube dos fotos que ella marca como privadas.



Utilizando la terminología de OAuth, Jane es el propietario del recurso y Faji el servidor. Las 2 fotos de Jane son los recursos protegidos.



“Después de compartir sus fotos con algunos de sus amigos en línea, Jane quiere también compartir con su abuela. Ella no quiere compartir su botella rara de con nadie. Pero la abuela no tiene una conexión a Internet, Jane planea encargar las impresiones y enviarlas por correo tradicional a la abuela. Siendo una persona responsable, Jane utiliza Beppa, un servicio de impresión fotográfica amigable con el medio ambiente”.

Utilizando la terminología de OAuth, Beppa es el cliente. Habiendo Jane marcado las fotos como privadas, Beppa debe utilizar OAuth para acceder a las fotos para imprimirlas.

“Jane visita beppa.com y comienza a ordenar las impresiones. Beppa permite importar imágenes desde muchos sitios para compartir fotos, incluyendo Faji. Jane selecciona las fotos y da clock a continuar”.



Cuando Beppa.com añadio soporte a la importación de fotos de Faji.com, un desarrollador de Beppa.com que conoce OAuth programó obtiene un conjunto de credenciales para habilitarlas o usadas en las APIs OAuth de Faji.

Desde de que Jane da click en continuar, algunas cosas importantes pasan entre el fondo de Beppa y Faji.

Beppa solicita a Faji el conjunto de credenciales temporales. En este punto, las credenciales temporales no son propietadad del dueño del recurso (es decir, no las conoce el usuario), y puede ser utilizado por Beppa para obtener la aprobación de Jane para acceder a sus fotos privadas.



Jane da clic en Continuar y está esperando en cambio en su pantalla. Ella bebe de su preciado Bowmore Negro a la espera de la siguiente página.

Cuando Beppa recibe las credenciales temporales, esta redirecciona a Jane a "Faji OAuth" con la credenciales temporales y pide a Faji para redirigir a Jane de regreso una vez haya sido aprobada en http://beppa.com/order.

Jane se ha dirigido a Faji y se le pedirá que firme en el sitio (se logee). OAuth requiere que los servidores primero autentiquen al propietario del recurso, y luego pide que permitan el acceso al cliente.

Jane sabe que se encuentra en una página Faji mirando la URL del navegador, y entra en su nombre de usuario y contraseña.



OAuth permite a Jane mantener su nombre de usuario y contraseña como privadas y no compartirlas con Beppa o cualquier otro sitio. En ningún momento Jane entra sus credenciales en beppa.com.

Después de iniciar sesión correctamente en Faji, Jane se le pide que conceda el acceso a Beppa, el cliente. Faji informa a Jane le estan solicitan acceso (en este caso Beppa) y el tipo de acceso. Jane puede aprobar o denegar el acceso.

Jane asegura que Beppa consiga el acceso limitado que necesita. Ella no quiere permitir que Beppa cambie sus fotos o hacer cualquier otra cosa por ella. También se señala que este acceso se hara una sola vez y durante 1 hora que debería ser tiempo suficiente para Beppa a busque sus fotos.



Una vez que Jane aprueba la solicitud, Faji marca las credenciales temporales de recursos autorizados por el propietario Jane. El navegador de Jane es redirigido a Beppa, a la dirección que ya ha proporcionado http://beppa.com/order junto con el identificador de credenciales temporales. Esto permite a Beppa saber que puede continuar para buscar las fotos de Jane.

Jane espera por Beppa para ver sus fotos que estan en su cuenta de Faji.



Mientras Jane espera, Beppa usa el token de solicitud autorizado y lo cambia por un token de acceso. El Request Token es sólo son bueno para obtener la aprobación del usuario, mientras que los Access Token para tener acceso a los recursos protegidos, en este caso las fotos de Jane. En la primera solicitud, intercambia con Beppa el token de solicitud para un token de acceso y en el segundo recibe solicitud de las fotos.



Estando Jane en Beppa, se refresca el navegador para completar el pedido.

Beppa trajo fotos de Jane exitosamente. Se presentan como imágenes en miniatura para su selección.

Jane está muy impresionada de ver cómo Beppa agarró sus fotos sin pedirle su nombre de usuario y contraseña.