Feeds:
Entradas
Comentarios

Archivos de la categoría ‘Análisis y opiniones’

Fuente: Clarin

Esta entrevista se realizó hace más de diez años pero se trata de un tema de plena actualidad. El Dr. Rafael Echeverría, sociólogo y filósofo, trabaja en la mejora de las organizaciones afrontando el desafío que nos presenta la revolución tecnológica: mientras que las empresas siguen organizadas según los principios de Frederik Taylor que se desarrollaron para el trabajo manual, éste es desplazado en el mundo real por lo que Peter Drucker denominó “trabajo no manual”.

La entrevista

Cómo debe ser un gerente coach (entrevista a Rafael Echeverría en diario Clarin 13/6/2004)

Read Full Post »

El texto a continuación es una traducción parcial de la entrevista al subdirector general de la UNESCO para la Comunicación y la Información “Towards Knowledge Societies. An Interview with Abdul Waheed Khan“.

Estás introduciendo aquí el término de las ‘sociedades del conocimiento’. ¿Cómo es este nuevo concepto diferente de el del ‘sociedad de la información’?
Realmente, los dos conceptos son complementarios. La sociedad de información es el bloque sobre el que se edifican las sociedades del conocimiento. Mientras que veo el concepto de la sociedad de la información ligado a la idea de la ‘innovación tecnológica’, el concepto de las sociedades del conocimiento incluye una dimensión de la transformación social, cultural, económica, política e institucional, y de una perspectiva más pluralista y más de desarrollo. En mi opinión, el concepto de las ‘sociedades del conocimiento’ es preferible a el de la ‘sociedad de información’ porque captura mejor la complejidad y el dinamismo de de los cambios que ocurren. Como dije antes, el conocimiento en cuestión es importante no sólo para el desarrollo económico pero también para potenciar y desarrollar todos los sectores de sociedad. Así, el papel de las TICs extiende al desarrollo humano más ampliamente – y, por lo tanto, a las asuntos tales como la cooperación intelectual, el aprendizaje permamente y los valores y las derechos humanos básicos.

Read Full Post »

Un artículo para mantener siempre a mano para seleccionar software Open Source.

Fuente: la pastilla roja por Sergio Montoro

Un conocido me dijo en cierta ocasión que al informático que mantenía su sitio web le llamaban El Hechicero porque nadie excepto él sabía cómo dar unos pases mágicos al invento que hacía que su website funcionase. Todos los hechiceros tienen su libro de recetas ocultas y ello conduce al primer consejo previo antes de empezar con el análisis comparativo de plataformas:

Cualquier gurú te dirá que la plataforma que él maneja es la mejor, pero sólo porque no conoce otras plataformas.

Entonces, si otra (que no es la del gurú) es mejor ¿Cual escoger? Mi primera respuesta sería ¡no importa! Las plataformas más populares compiten ferozmente entre ellas por ofrecer mejores funcionalidades y prestaciones. Son como las participantes en un concurso de belleza, aunque votes por la menos agraciada, incluso así, acabarás eligiendo una mujer que no es después de todo para nada fea. Esto me lleva al siguiente corolario:

Si tu plan de empresa depende críticamente de las presuntas eficiencias espectaculares de una determinada plataforma, entonces es que deberías replantearte algo en tu plan de empresa.

Criterios para evaluar una plataforma de desarrollo.

Bueno, entonces ¿Todo da igual? No. Tampoco es eso, voy a comentar a continuación las 5 plataformas más populares de lado servidor: Java, PHP, Microsoft .NET, Python y Ruby On Rails. Las plataformas voy a evaluarlas en base a los siguientes criterios:

1º) Grado de madurez.
2º) Tamaño y grado de actividad de la comunidad.
3º) Disponibilidad de librerías y aplicaciones de terceros.
4º) Disponibilidad y coste salarial de los programadores.
5º) Dificultad de la curva de aprendizaje.
6º) Compatibilidad con el resto del ecosistema.
7º) Rendimiento y escalabilidad.

He dejado premeditadamente fuera de la lista la productividad, porque, como ya he expresado, opino que, si se usan bien, todas ellas ofrecen un grado de productividad equivalente, o, al menos no lo bastante diferente como para que debiera ser relevante.

¿Por qué es relevante cada uno de los siete factores anteriores?

Primero, la madurez. Hay proyectos, como por ejemplo node.js que se crearon para resolver problemas específicos. En el caso de node.js el tratamiento de peticiones AJAX desde las nuevas aplicaciones HTML5. Node.js ofrece una modalidad de procesamiento asíncrono junto con la propuesta de programar en JavaScript igualmente en el lado cliente y en el servidor (¿alguien se acuerda del SSJS de Netscape en el 94?) cosa que sus promotores denominan “el nirvana de los programadores”, aunque yo no calificaría a JavaScript como el nirvana de nada. Lo que sucede es que lo mismo que se puede hacer con node.js se puede hacer con los servlets asíncronos de Tomcat 7. Es más enrevesado de aprender y de codificar en Tomcat, ciertamente, pero a cambio se tiene una plataforma mucho más madura, eficiente y compatible que node.js. Más madura implica, por ejemplo, casi siempre mejor documentada. Las carencias de la documentación, por cierto, son un mal endémico en las librerías JavaScript cliente incluso en las más maduras como Dojo o YUI.

Segundo, el tamaño y grado de actividad de la comunidad. Es relevante porque cuanto mayor sea la comunidad más probable es que hay alguien que se haya topado con el mismo problema que nosotros y lo haya resulto. Más probable que en Stack Overflow o en cualquier otro sitio de preguntas y respuestas hallemos la solución a un problema que nos mantiene atascados.

Tercero, la disponibilidad de aplicaciones y librerías de terceros. El framework de desarrollo es sólo la herramienta base para construir una aplicación. Justo a continuación de elegir la plataforma hay que elegir las librerías. Por ejemplo, Java domina absolutamente el entorno financiero y bancario porque su middleware es el mejor. Lo hay para todos los gustos desde JBoss a TIBCO, pasando por Informatica UM. Los frameworks más modernos de todos los lenguajes han ido incorporando librerías de serie. Java apareció en 1995 y, más que un lenguaje para aplicaciones web estaba pensado con filosofía WORA (Write Once Run Anywhere) y para tener la menor cantidad de dependencias posible. Ruby On Rails apareció 10 años después e incorporaba en su arquitectura el paradigma Modelo Vista Controlador (MVC) y mecanismos como ActiveRecord que permiten que las clases tomen de la base de datos los nombres de la columnas sin necesidad de definirlas explícitamente en el código. Para conseguir con Java un framework funcionalmente similar a Ruby on Rails se necesita, al menos, una librería MVC como Struts, una capa de persistencia como Hibernate, soporte de servicios REST como Jersey, una librería de tags como JSTL y JavaMail. La cantidad de librerías Java es tal que existen empresas como Black Duck en EE.UU. Autentia en España especializadas en evaluarlas y dar formación a los clientes corporativos.

Cuarto, la disponibilidad y coste de programadores. Si sólo se van a necesitar dos o tres, entonces no hay problema. Pero si se estima que el proyecto requerirá 40 o 50 desarrolladores entonces encontrar y contratar personas puede llegar a ser muy difícil y costoso. Si se estima que el proyecto necesitará más de 50 desarrolladores, entonces es que se ha hecho mal el plan y bien hay que partir el proyecto en trozos de menos de 50, bien sería mejor cancelarlo y tirarlo todo a la basura antes de que se queme una burrada de dinero en producir un monstruo.

Quinto, la dificultad de la curva de aprendizaje. He dicho antes que todas las plataformas son igualmente buenas en cuanto a productividad. Pero no todas son igualmente fáciles de aprender. Si se tiene cuenta el tiempo que requiere un programador novato para aprender cómo funciona el invento, entonces sí que existen diferencias entre unas y otras. El orden de más fácil a más difícil es: PHP, Ruby On Rails, .NET, Python y Java.

Sexto, la compatibilidad con el resto del ecosistema. Rara vez las aplicaciones existen de forma aislada e independiente unas de otras. En general, las diferentes plataformas no son fácilmente interoperables unas con otras. Existen muchas herramientas de integración y formatos de representación de datos independientes del lenguaje como Protocol Buffers, pero lo más común, por fácil, es que las plataformas en dos lenguajes diferentes se acaben integrando vía base de datos relacional, XML o ficheros de texto delimitado.

Séptimo, el rendimiento y escalabilidad. Todos los programadores que conozco afirman que ellos desarrollan aplicaciones escalables. De ellos, he visto con mis propios ojos desarrollos ir lentísimos con tan poco como 100.000 registros. Con ello quiero decir que la escalabilidad es en primer lugar una cuestión de diseño y sólo en segundo lugar algo que dependa de la plataforma. La prueba es que existen sitios web de altísimo tráfico sobre todas las plataformas que comentamos aquí. A grosso modo, si se tiene una base de datos con tablas que no superan el millón de registros y un sitio web que no supera las cien mil visitas al día, entonces la escalabilidad no será una cuestión relevante se use lo que se use a menos que el programador sea realmente malo, pues cualquier servidor quad-core medio moderno puede atender tal volumen de trabajo sobre una base de datos relacional.

Java
Java es la plataforma más extendida en el entorno corporativo. Se trata de una tecnología muy madura y popular que cuenta con innumerables herramientas de todo tipo y es bastante sencillo encontrar programadores. Casi todo el mundo que desarrolla en Java usa Eclipse o Netbeans como IDE. Ambos son bastante pesados y a mi personalmente me gusta más JCreator, aunque en un portátil con 4Gb de RAM tanto Eclipse como Netbeans corren perfectamente. La principal pega de Java para el desarrollo de aplicaciones web es que la plataforma no se concibió originalmente para eso, sino que fueron apareciendo proyectos como Tomcat en 1999. Las extensiones a la plataforma se acuerdan mediante el Java Community Process (JCP) compuesto por más de mil miembros que trabajan sobre más de 300 Java Specification Requests (JSR) Estas especificaciones tienden a ser muy densas y a veces salen cosas realmente retorcidas como JavaMail. Algunos presuntos gurús han difundido el mito de que una startup no debería basar su tecnología en Java. Esto es radicalmente falso pues Java es perfectamente compatible con el modelo lean en boga. La curva de aprendizaje de Java no es suave. No porque el lenguaje en sí mismo sea muy complejo sino porque además del propio Java hay que conocer todos los entresijos de las decenas de librerías y herramientas de terceros hasta el punto en que es habitual que en las demandas de programadores se especifique no que sepan Java sino que dominen el uso de Spring, Struts, Hibernate, etc. Hay bastantes programadores Java en el mercado, pero los genuinamente senior escasean debido a la gran cantidad de herramientas y técnicas que hay que dominar para explotar a fondo todo el potencial de Java. Java es, a mi juicio, la plataforma más rápida y escalable de las comentadas aquí, o, al menos, es la que permite un mayor grado de manejo a bajo nivel para optimizar el rendimiento a menos que se usen librerías en C++ llamadas desde las páginas dinámicas. Una prueba de ello es que los sitios web de alto tráfico basados en Java tienden a ser puro Java, mientras que es común encontrar que tras PHP, Django o RoR hay alguna librería compilada a código máquina para hacer algo.

PHP
También conocido popularmente como LAMP (Linux+Apache+MySQL+PHP). PHP (acrónimo recursivo de Hypertext Pre-processor) es coetáneo de Java. Apareció también en 1995, pero, a diferencia de Java, estaba pensado desde el principio como un lenguaje que se pudiera incorporar en documentos HTML. La gran ventaja de PHP es que resulta sencillo empezar con él y existe mucha documentación online. Es más fácil aprender PHP que Java, y todos los ISP proprocionan algún tipo de stack LAMP preconfigurado. Es por consiguiente sencillo encontrar programadores PHP a precios asequibles. PHP no proporciona un sistema MVC por defecto pero existen muchas opciones para ello. A mi me gusta CakePHP mas se pueden contar las alternativas por decenas siendo Zend probablemente la más popular. Hay muchas startups de éxito basadas en PHP, incluídas algunas de las de mayor tráfico como Wikipedia, Yahoo o Facebook entre ellas. El lenguage en sí mismo presenta algunas limitaciones importantes. No se pueden crear de forma natural pools de conexiones, no hay sesiones, el módulo mod_php para Apache permite mantener sesiones pero mucha gente lo considera intrínsecamente inseguro. La propia facebook acabó desarrollando su propio compilador just in time (JIT) HHVM para poder alcanzar el rendimiento que necesitaban con PHP.

.NET
Si Sun no hubiese creado Java probablemente .NET dominaría ahora mismo todo el panorama de software empresarial. El punto fuerte de plataforma de Microsoft es el grado de integración entre el escritorio y las aplicaciones web. Si yo tuviese que desarrollar una Intranet a sabiendas de que los usuarios van a tener todos Windows no lo dudaría y la desarrollaría sobre .NET. Mas para una startup yo nunca elegiría .NET no por problema alguno con la tecnología sino simplemente porque el software de Microsoft no es Open Source. .NET sólo puede correr en servidores distintos de Microsoft Internet Information Server si se usa Mono y los servidores Windows son más caros de alojar que los Linux. Además usar SQL Server (la elección natural para .NET) también es bastante más caro que elegir PostgreSQL o MySQL.

Python
Python para la web es sinónimo de Django. Django apareció en 2005 como framework para la creación de sitios web de contenidos dinámicos, y, si eso es lo que hay que hacer, puede ser una excelente elección. El tipado dinámico y los tipos de alto nivel hacen que el código Python sea más corto que Java. Como RoR, Django incluye un subsistema MVC (aunque algo ecléctico) y también mapeador objeto-relacional, un sistema extensible de plantillas basado en etiquetas, un despachador de URLs basado en expresiones regulares y middleware para cacheo, compresión de la salida, normalización de URLs, protección Cross-Site Request Forgery (CSRF) y soporte de sesiones. Lo normal es ejecutar Python con el mod_python de Apache 2. Aunque gracias al soporte WSGI se puede correr también sobre Lighttpd. En general es de esperar que el rendimiento de Python sea inferior al de Java y, por consiguiente, ello puede ser un obstáculo si se pretende llevar el tráfico hasta el límite. Algunos sitios web de alto tráfico como Instagram o Pinterest están desarrollados con Django, aunque ellos mismos han reconocido que tuvieron problemas con la escalabilidad debido a su vertiginoso crecimiento, no sólo por Python sino también en gran parte por llegar al límite de las tecnologías de almacenamiento de datos. Python es relativamente sencillo de aprender, y a la mayoría de los programadores profesionales les gusta cuando llegan a conocerlo, pero, debido a que existe menos demanda de programadores Python que de Java, .NET o PHP estos son más difíciles de encontrar.

Ruby On Rails
Ningún framework de los anteriores levanta tantas pasiones a favor y en contra que Ruby On Rails. Como Django, RoR es un framework que se pensó desde el principio para el diseño de aplicaciones web. Es un framework de pila completa, lo que significa que trata de integrarlo todo desde la base de datos hasta el código que corre en el navegador cliente. RoR incorpora de serie el paradigma MVC, el mapeo objeto-relacional, infraestructura para crear recursos REST y otras funcionalidades propias del desarrollo web como un detector de inyección de JavaScript y SQL. RoR también incorpora JQuery, y se pueden conseguir herramientas de terceros como Aptana para el desarrollo de las páginas HTML5. Los críticos de RoR argumentan que es lento y que no escala bien en webfarms. Es cierto que las sesiones sólo se pueden compartir en Ruby a través de la base de datos. Pero es que yo soy partidario de que las aplicaciones no deben mantener nada en una sesión de lado servidor sino que se deben usar cookies para mantener las credenciales del usuario y luego cachear el resto. El sitio web más grande basado en RoR probablemente es Twitter. Otra crítica común es que, debido a la integración transparente entre el lenguage y la base de datos, no se puede usar Ruby fácilmente contra un modelo de datos que ya esté creado o siga unas normas de programación del estilo de sólo poder acceder a la información vía procedimientos almacenados, o, más bien, sí se puede, pero entonces se le mata la magia de ActiveRecord al lenguaje. Ruby es relativamente fácil de aprender, más o menos como PHP sólo que la documentación de Ruby no es tan extensa ni detallada. Hay muchos menos programadores de Ruby que de Java o de PHP. Sus defensores argumentan que los programadores de Ruby son pocos porque son todos unos gurús, mas creo que leyendo este artículo ya se sabe lo que opino de los gurús.

Tecnologías Front-End
¿Agotado con las opciones de los frameworks de lado servidor? Pues ¡un momento! porque aún nos queda hablar del software del lado cliente.
La compatibilidad entre navegadores web ha sido desde siempre una merienda de negros y con la llegada de HTML5 y CSS3 la situación no ha mejorado para nada. La oveja negra es Internet Explorer sobre todo las versiones anteriores a la 10. Es virtualmente imposible desarrollar una aplicación HTML5 cross-browser sin una librería de compatibilidad como Modernizr. CSS también tiene tantas sutiles diferencias que prácticamente nadie desarrolla sin un paraguas como YUI. Y para el desarrollo en JavaScript es totalmente común encontrar JQuery o Dojo. Existen decenas de otras librerías como Bootstrap, Backbone, CoffeeScript, Datejs, RequireJS, PhantomJS, etc. O frameworks como Ext.js. Incluso se puede desarrollar en Java Swing y convertirlo a JavaScript con GWT o, aún más exótico, desarrollar en Dart y compilarlo a JavaScript. Una herramienta muy útil para componer CSS es LESS aunque hay que precompilar siempre los scripts puesto que a Rhino le puede costar 2 segundos compilar un archivo .less de ~30Kb lo cual es un tiempo muy significativo en la carga de una página web.

Conclusión
Ninguna plataforma es óptima para todas las necesidades. Para concluir con algunas reglas sencillas, mi propuesta es la siguiente:

- Si tienes que desarrollar un sitio web para una multinacional, o hacer integraciones complejas con otras plataformas o realmente vas a crecer mucho tanto en tráfico como en número de desarrolladores, entonces elige Java sobre PostgreSQL.

- Si quieres tener presencia online eficaz y asequible, incluso e-commerce, pero tu website no es el factor crítico exclusivo de tu negocio, entonces elige LAMP.

- Si tienes que desarrollar una intranet o un sitio web corporativo a sabiendas de que los usuarios tendrán Internet Explorer y tecnologías Microsoft entonces elige .NET sobre SQL Server

- Si necesitas una web con contenidos dinámicos mantenida por un equipo compacto y eficiente de programadores entonces elige Django sobre PostgreSQL o RoR sobre MySQL.

Read Full Post »

Fuente: Kriptópolis

En Kriptópolis, hace SEIS AÑOS: La NSA controla servicios de correo cifrado y cortafuegos para Windows

Entonces se mencionaba como fuente un informador secreto dentro de la propia Agencia Sin Nombre, denominado “A”. Y es que “no hay mejor cuña que la de la misma madera”…

“La Agencia de Seguridad Nacional (NSA) de Estados Unidos y la sede de Comunicaciones del Gobierno (GCHQ) de Reino Unido han burlado los sistemas de seguridad en internet descifrando la información confidencial de sus usuarios, según documentos filtrados por el ex agente de la NSA Edward Snowden a los diarios ‘The New York Times’ y ‘The Guardian’ y a ProPublica. Ello habría sido posible gracias a una alianza encubierta con las grandes empresas. Aunque en los documentos de la NSA no se especifica cuáles, los del GCHQ revelan su cooperación con Hotmail, Google, Yahoo y Facebook para acceder a los correos electrónicos. También lo habría logrado gracias a su influencia encubierta sobre los estándares internacionales de sistema de cifrado de información en internet “La NSA se convirtió en su único editor”, reza uno de los documentos de Snowden. Así, la NSA habría conseguido hacer los sistemas de cifrado “más accesibles” y “dar forma” al mercado mundial para “introducirse en el flujo de datos que circula a través de los proveedores de comunicaciones”. Los documentos de Snowden revelan que la NSA todavía no ha conseguido romper todos los sistemas de cifrado y que, en particular, se le resisten los incorporados a los teléfonos móviles inteligentes de cuarta generación (4G).”

Más información:

 

Read Full Post »

Fuente: infotechnology.com

Por Hugo Passarello Luna, desde París, Francia

Phil Libin es el creador y CEO de Evernote, una de las empresas online que creció con fuerza en 2012. Evernote, con base en California, Estados Unidos, está en el particular negocio de extender la memoria de los hombres, de recordar todo, se trate tanto de un detalle pequeño como de un suceso importante. Es un sistema que permite guardar, indexar y hacer accesible en todo momento la información desde una computadora, un celular o una tableta.

De visita en París durante la conferencia LeWeb, una de las conferencias más importantes a escala mundial sobre las nuevas tecnologías, Libin (que en el pasado creó start-ups como CoreStreet y Engine 5) habló en exclusiva con Information Technology sobre el desarrollo de su empresa, sus temores, los planes para América latina y sus consejos para quienes se lanzan a emprender.

El año pasado fue crucial para Libin y su empresa. En mayo recaudaron U$S 70 millones de diferentes inversores y a finales de noviembre lograron sumar otros U$S 85 millones. Hoy Evernote cuenta con más de 50 millones de usuarios, de los cuales el 5 por ciento accede al servicio pago. El fuerte de la empresa es su modelo “freemium”: de manera gratuita, los usuarios acceden a los servicios básicos, pero con límites mensuales en cuanto a la capacidad de almacenamiento de archivos y su accesibilidad. Pero si el cliente paga por el servicio, puede ampliar esas capacidades y obtener un mejor soporte, entre otras ventajas.

Si los usuarios aumentaron, también lo hizo el personal de la empresa. En menos de un año se triplicó la dotación de Evernote y llegó a los 300 integrantes, dispersos en varias ciudades del mundo, más allá de la californiana Redwood, como Tokio, Pekín y Zurich. La firma está en plena etapa de expansión y sus ojos están puestos en América latina, particularmente en Sudamérica. Evernote ya abrió una oficina en Brasil y otras le seguirán en los países vecinos.

¿Cómo fueron los primeros años de Evernote?
Cuando comenzamos teníamos pésimas experiencias con los capitales de riesgo. Visitábamos a los inversores, les explicábamos que estábamos haciendo un software que permitía ayudar a la gente a recordar cosas, les pedíamos millones de dólares y nos cerraban la puerta. No pudimos recaudar nada durante nuestro primer año y medio. La principal fuente de capital provenía de nuestros propios bolsillos y de amigos y familiares. Los primeros inversores fuera de nuestro círculo íntimo fueron aquellos que ya usaban Evernote y sentían que la experiencia era muy buena. No podíamos convencer a ningún inversor a menos que hubiera usado antes Evernote. Los inversores institucionales llegaron después, cuando pudimos mostrar buenos resultados económicos, pero eso fue dos años después del lanzamiento, en 2008. A partir de ese momento todos nos querían dar dinero.

Evernote está creciendo rápidamente y el mundo de Internet no para de cambiar. ¿Cuál es su principal miedo?
Mi miedo más grande, o mi preocupación principal, es tratar de mantener la esencia de un start-up a medida que crecemos. La meta es ser un start-up que dure 100 años. Queremos construir una empresa seria y durable pero con el espíritu de una que empieza. Triplicamos nuestro personal este año y ahora somos 300. Creo que para finales de 2013 llegaremos a 500 y para 2014 habrá 1.000 empleados. Incluso si alguna vez tenemos 20.000 empleados quiero que sigamos siendo como un start-up.

¿Y cómo se logra eso?
No lo sé. Ahí reside el mayor riesgo. No es fácil pero tampoco es imposible. No queremos volvernos una compañía estúpida, lenta, que toma decisiones tontas. Evernote es nuestra misión en la vida. No la queremos vender, ganar plata e irnos. Mi principal pesadilla es llegar a la oficina y darme cuenta que hay un empleado de Evernote que está haciendo algo y no sabe por qué lo hace. Y se dice a si mismo: “Hago esto solamente porque me dijeron que lo hiciera”. Tengo miedo de que una persona esté pensando algo así. Eso pasa cuando una persona no entiende por qué hace lo que hace y significa que ya no es un start up, sino una gran compañía. Es el principal sentimiento presente en las grandes compañías y tenemos que evitarlo. Nadie puede trabajar en Evernote sin saber o entender el impacto de su trabajo en los millones de usuarios.

¿Qué representa América latina para Evernote?
La región será una prioridad durante este año. Lo que nos atrae es la creatividad y la innovación que vemos ahí, además de la gran concentración de emprendedores. Ya hemos abierto una oficina en San Pablo, pero estaremos haciendo más cosas en Chile, Colombia y la Argentina, donde observamos que hay un gran potencial. Creo que la siguiente generación de aplicaciones y servicios que cambiarán el mundo, el próximo Facebook o Google, no vendrán del Silicon Valley sino de los grandes centros densamente urbanos. El Silicon Valley es como una granja, muy bucólico. El estilo de vida de las grandes ciudades es completamente diferente. Todo está concentrado, todo es vertical, las relaciones sociales son diferentes. Todavía no hay una aplicación perfecta para esta experiencia híper-urbana y creo que debería haberla. Nosotros queremos estar en estos centros de actividad que se encuentran principalmente en América latina y en Asia.

¿Cuál es su consejo para los emprendedores que se lanzan hoy?
Mi principal consejo es que no lo hagan, de hecho he escrito sobre eso. Antes de lanzarse deben preguntarse por qué quieren hacerlo. La mayoría de la gente que se vuelca a ser emprendedor lo hace por malas razones. El peor motivo es el dinero, porque muchos creen que pueden amasar una fortuna y no es verdad. El 99 por ciento de las empresas fallan. Si se hace por esa razón, mi mejor consejo es que se eviten las enormes dificultades de ser un emprendedor. Si alguien es inteligente, creativo, con mucha energía y quiere maximizar el dinero que ganará en su vida, no debe lanzar su propia empresa. Puede conseguir un trabajo bien pago, como banquero, ingeniero, médico o consultor, y quedarse ahí por 20 o 30 años. Las probabilidades indican que como emprendedor uno trabajará 18 horas por día durante 10 años y no necesariamente ganará dinero.

¿Y entonces? ¿Por qué emprender algo?
Para construir algo para generar un cambio, algo que te apasione, para uno mismo. Porque si se lo hace de esa forma, es la mejor manera de hacer algo relevante. Ahora es el mejor momento en la historia del mundo para realizarlo, porque vivimos en plena meritocracia. No se debe hacer algo pensando en lo que el mercado necesita, porque ésa es la sabiduría comercial, que hoy es el camino incorrecto. Era verdad hace cinco años. En el presente, si hacés algo para vos y es muy bueno, podés hacer que todo el mundo lo conozca y pague por eso, gracias a las redes sociales y las tiendas online. Pero hay que embarcarse sabiendo que tal vez no se ganará ni un centavo. Si alguien tiene éxito y logra hacer fortuna, entonces felicitaciones, pero es raro. Yo tuve mucha suerte: Evernote es mi tercera compañía, pude vender las otras dos y Evernote está haciendo dinero.

¿Qué podemos esperar de Evernote en el futuro cercano?
Queremos no sólo ser tu memoria sino hacerte aún más inteligente. Nuestra idea es que Evernote sea tu cerebro externo y ayudarte a recordar cosas y a tomar mejores decisiones. Una de las maneras es haciendo que Evernote sea menos introspectiva y que se vuelva más colaborativa, compartiendo parte de la información con tus colegas. También acabamos de lanzar un cuaderno físico, clásico, donde uno puede tomar notas como siempre lo ha hecho. Y luego, desde tu teléfono, se puede tomar una foto de las notas usando la aplicación Evernote, que las sube a tu cuenta, la convierte en texto virtual y la hace accesible desde todos tus aparatos conectados. El objetivo es acercar el mundo real al virtual.

Artículo publicado originalmente en la edición N°186 de Information Technology (Marzo 2013)

Read Full Post »

Fuente: La Pastilla Roja (Sergio Montoro)

Siempre he sido fan del “marketing introspectivo”. Una técnica de investigación de mercado de cosecha propia que consiste en lo siguiente: diseñas un producto para ti mismo y fabricas un mínimo producto viable. Ahora hay que responder a tres sencillas preguntas:

1ª) ¿Usas tu propio producto?
2ª) ¿Es realmente útil y práctico?
3ª) ¿Cuánta gente más hay ahí fuera con el mismo problema que tu tenías?

Si me dieran a elegir el software que me gustaría haber inventado probablemente elegiría PKZIP, el shareware que un chico de 23 años de Milwaukee desarrollo en la cocina de su madre y que hizo posible vivir con disquettes de 3,5 y modems de 56K.
La causa de la tremenda popularidad de PKZIP y otros compresores como ARJ es fácil de intuir: muchísima gente sufría los mismos problemas de espacio en disco que el joven Phil Katz.

El marketing introspectivo es una herramienta útil, pero los emprendedores abusan en exceso de él. Calculo que 9 de cada 10 startups que veo por primera vez pierden mi atención durante los 10 segundos por una sencilla razón: son proyectos para geeks, no para el público en general y por ello, salvo Apple, que es la excepción que confirma la regla, es difícil que lleguen a cruzar el abismo. E incluso la misma Apple basa su éxito (creo) en vender productos geek que pueden usar y desear los no-geeks.
…  seguir leyendo este artículo

Read Full Post »

Hay dos clases de vacaciones. Las olvidables y las inolvidables. Lo que nunca imaginé es que unas vacaciones pudieran ser inolvidables por lo olvidables. Pero bueno, para eso está la vida. Para enseñarte cosas.

Mi última licencia anual, en enero, comenzó en modo Unplugged. Nada de noticias, ni horarios, ni agenda, ni teléfonos, ni reloj de pulsera. Es mi manera de cargar baterías y siempre me resulta. Literatura, música y el menor número posible de compromisos.

Pero este año había algo más, algo novedoso y no del todo bienvenido. Un leve catarro.

Sin embargo, con días brillantes y calor a montones, ¿cómo darle importancia a una tosecita de nada? Le resté importancia, como corresponde a alguien que prefiere esperar lo mejor, y me propuse estar bien para cuando terminara el fin de semana.

Pero para el tercer día de mi licencia, es decir, el lunes, la tosecita se había fortificado de forma alarmante, así que, muy a mi pesar, fui a ver un médico de guardia, que me diagnosticó una bronquitis. Ah, pero qué lindo. Con todo, prefirió no tomarme una radiografía, “porque todo suma en términos de radiación”, argumentó, y no parecía ser el mío un cuadro grave.

Ahora, ¿había sido una medida razonable no hacerme la placa? En algo tenía razón, no es un procedimiento inocuo. Pero comparada con otros diagnósticos por Rayos X, la radiografía de tórax es una de las más inofensivas, equivale a sólo 10 días de la radiación que recibimos del medio ambiente. Opuestamente, una tomografía computada equivale a 6 meses. Todo esto lo averigüé en RadiologyInfo.org ( www.radiologyinfo.org/en/pdf/sfty_xray.pdf ) mientras volvía a mi casa en taxi, usando mi smartphone.

Supuse, no obstante, que su decisión había sido acertada.

Mejor no preguntes

Me dediqué a coordinar los remedios para que su ingesta no alterara demasiado mis horas de sueño al tiempo que intentaba convencerme de que todo se arreglaría en unos días. En realidad, necesitaba que se arreglara en unos días, como se verá enseguida.

Por supuesto, no ocurrió así. De hecho, empeoré bastante, y a la semana siguiente estaba sentado en el consultorio de una neumonóloga, que me cambió la medicación y me mandó a hacer un par de radiografías y un análisis de sangre. Por si acaso, también ordenó una reacción de Mantoux.

Como vacaciones, estaban cada vez mejor, ¿no?

Las placas discurrieron, como es normal, sin demasiado diálogo. Pero el técnico del laboratorio que me sacó sangre y me inyectó la tuberculina me pareció accesible, más comunicativo y hasta un poco propedéutico, así que no tuve mejor idea que preguntarle cómo leer los resultados de la Mantoux. Su actitud cambió entonces por completo y, con severidad castrense, me soltó: “Ah, no, eso lo tenemos que interpretar nosotros”.

Como prefería irme, si no curado, lo que parecía imposible, al menos con la tranquilidad de que las radiografías no revelaban nada preocupante, esperé a que estuvieran listas y que la médica pudiera revisarlas. Eso llevó unos 15 minutos, tiempo que invertí en leer en mi smartphone todo lo que encontré sobre cómo interpretar la reacción de Mantoux. No era tan difícil, debo decir.

Las radiografías dieron que estaba todo bien, lo que fue un alivio, pero me fui protestando por la ridícula actitud del técnico. Supongo que nadie entendió por qué yo repetía, al entrar en el ascensor, “es el siglo XXI, muchacho, es el siglo XXI…”

Creo que está demás aclararlo, pero lo haré. Mi intención no era hacer un diagnóstico de la reacción de Mantoux. De bien poco me habría servido, además. Como no soy médico, no tengo matrícula, y como no tengo matrícula no puedo firmar recetas. Todo lo que quería era saber y, después de todo, era mi brazo. Y mis pulmones.

Esta pulsión se llama curiosidad y su ejercicio se basa en un principio que aprendí hace mucho: no hay nada que uno no pueda entender, si le dedica un poco de tiempo. Concedido, algunos asuntos son más enmarañados que otros; la física cuántica, por ejemplo, o traducir a Catulo del latín al alemán. Pero cualquier persona puede entender cualquier cosa. La sola idea de que ciertos asuntos sólo están al alcance de algunas mentes privilegiadas me produce una fuerte reacción alérgica (que fue, precisamente, lo único que salió mal en los análisis, dicho sea de paso). Ni hablemos de la idea, todavía más espeluznante, de que algunos conocimientos pueden ser dañinos para las mentes no preparadas. Somos adultos, por favor. No niños.

Estos conceptos todavía son patrocinados por los que -en plena era de la información- hacen lo imposible por proteger, bloquear, circunscribir o de alguna forma controlar el conocimiento y el libre flujo de la información. Por ejemplo, con la frase: “Ah, no, eso lo tenemos que interpretar nosotros”. Su bloqueo le duró algo así como 3 minutos y medio.

Pronóstico reservado

Actitud opuesta me obsequió la neumonóloga, a Dios gracias. Cuando volví, a la semana siguiente, le dije que había estado mirando los resultados de los análisis de sangre y que había acertado con eso de verificar la inmunoglobulina E; estaba 4 veces más alta de lo normal. En lugar de mirarme con disgusto, como quien se encuentra a un plebeyo husmeando en escrituras secretas u oye a un profano juzgar sus decisiones, la médica se interesó por lo que había encontrado y se puso a revisar los resultados. Todo el tiempo valoró que estuviera informado, y nunca se le pasó por la cabeza que estuviera intentando usurpar su lugar. Debo decir que me sentí mucho más seguro en sus manos.

Con todo y el variado menú de drogas con el que me obsequiaron, la cosa no mejoró. Diré más: cuando el calendario sobrepasó ese difuso pero incuestionable límite en el que las vacaciones se empiezan a terminar, fui cayendo en la cuenta de que iba a pasarme toda la licencia con la dichosa bronquitis. No soy de hacerme problemas por aquello que no controlo, pero daba para amargarse un poco. Además había un pequeño problema. La semana siguiente, la tercera de mis vacaciones, tenía un viaje -tiempo ha planeado, agendado y, por supuesto, anhelado- a los glaciares.

Quiero decir, un glaciar no parece el sitio óptimo para alguien que padece bronquitis. Nunca había tenido fiebre, así que no, ni se me pasó por la cabeza cancelar la travesía. Pero quería saber si sobreviviría. Me planteé el problema y me di cuenta de que lo riesgoso no era caminar sobre hielo -los bronquios no están en los pies-, sino la temperatura del aire en el glaciar.

Como tenía proyectado hacer trekking dentro del Perito Moreno, supuse que el informe del tiempo en El Calafate no me servía; tampoco, si lo encontraba, el de la zona general del glaciar (bien detallado, lo encontré en el excepcional sitio del Instituto de Meteorología de Noruega: www.yr.no/place/Argentina/Santa_Cruz/Perito_Moreno_Glacier~6942216/ ).

Caí en la cuenta de que el único dato confiable provendría de alguien que hubiese medido la temperatura del aire en el corazón del glaciar. El dato apareció en 0,5 segundos por medio de Google. Un PDF del Instituto de Tecnología Kitami de Japón ( http://kitir.lib.kitami-it.ac.jp/dspace/bitstream/10213/1438/1/bgr24_95-.pdf ), también alojado en la Sociedad japonesa de la Nieve y el Hielo ( www.seppyo.org ) y citado en un documento del Museo del Hielo Patagónico Glaciarium ( www.glaciarium.com/mcien/Novedades%20sobre%20Glaciar%20Moreno.pdf ). Sus números me resultaron bastante tranquilizadores. Según lo que habían medido los investigadores, la temperatura del aire que iba a meter dentro de mis castigados bronquios no bajaría de 7°C durante el día en verano, y podía ser de hasta 16°C.

Asunto resuelto, sobreviviré, me dije.

Pero no contaba con que cuando las cosas vienen torcidas, toda solución viene seguida de un nuevo problema. Que fue lo que ocurrió unas 36 horas antes de subirme al avión. Parece ser que exageré con eso de toser, porque un músculo o una costilla o algo en el costado izquierdo de mi tórax hizo ¡ crac ! una noche y casi me desmayo del dolor. Me costaba creer que mis vacaciones estuvieran cayendo tan bajo. Pero así era, y la única táctica razonable, ahora que casi no podía moverme, no digamos toser, era volver al médico. Para entonces era conocido de todas las recepcionistas, los médicos y médicas, técnicos y guardias de seguridad de la clínica.

Tras una inyección intramuscular y unas pastillas que “no debía tomar durante más de cuatro días”, el padecimiento en mis costillas se volvió manejable. “Cuatro días -pensé-, justo el tiempo que necesito para caminar por el glaciar.” No obstante, el prospecto no decía cuatro días, sino diez. Pero supongo que no era un texto destinado al usuario. Por si acaso, y a pesar del sufrimiento que esto me provocó al regreso, respeté las indicaciones del médico. Ser curioso no significa automedicarse, y mucho menos con un opioide.

Ahora venía la parte complicada. El viaje en sí. Me aseguraron que lo mío no era contagioso, aunque podía llevar un barbijo, si eso me hacía sentir mejor, y cuando estaba todo más o menos listo me ubiqué mentalmente en la nave. Ups.

Normalmente no le presto mucha atención a la butaca del avión. Ese es el motivo por el que me han tocado buenas, regulares, malas y desastrosas. Esta vez mi estado no era adecuado para quedar frente a una salida de emergencia, y prefería un lugar que no se sacudiera mucho. Claro, ¿pero acaso podría encontrar en la Red un sitio con información sobre las ventajas y desventajas de los asientos de un cierto modelo de avión en una determinada línea aérea? Oh, claro que sí. Se llama SeatGuru ( www.seatguru.com ).

Prácticas fósiles

La maravilla de los glaciares me hizo olvidar por completo mis cuitas. No era quizá la forma en que me había imaginado mi primer encuentro con el Perito Moreno, pero me encantó trepar como un chico (o como un mono, depende de cómo se lo mire) por las colinas heladas gracias a los crampones de hierro; no soy de hacer mucho ejercicio, lo confieso, ni me siento gimnástico en absoluto, pero esto de trepar por el hielo me resultó como una segunda naturaleza. De no haber sido porque el efecto del analgésico empezaba a agotarse, me hubiera vuelto a subir al gigante blanco de inmediato.

Brindé con whisky al terminar la travesía (a pesar de lo que decía el prospecto del analgésico), le dije adiós y me prometí volver.

Pero volver es imposible

El vuelo de regreso fue tranquilo y, mientras leía los textos que había reunido en esos días sobre las numerosas plantas que me interesaron (el calafate, por ejemplo, un arbusto precioso que estaba repleto de frutos en esos días), reflexioné sobre el control de la información. Había tenido una suerte de revelación cuando me encontré dentro del inmenso y sonoro Perito Moreno. La censura, como los glaciares, será, dentro de 50 o 100 años, sólo un recuerdo de épocas idas.

Me imagino que es una mala noticia para algunos, pero ese mundo en el que era posible ser paternalistas con la información, negarle a la gente común (esto es, usted y yo) el acceso a ciertos datos, no va a volver.

Por supuesto, estoy al tanto de que se están haciendo enormes esfuerzos por mantener las cosas como eran, pero no pueden prosperar. Son tecnológicamente inviables. Estamos comenzando a vivir una realidad casi enteramente diferente que la que existía hasta principios de la década de 1980. Lo verán los historiadores de los siglos por venir. Por ahora, mi mejor consejo es dejar de planear métodos de censura, control y vigilancia de la información. Son una pérdida de tiempo. Y de dinero..

Read Full Post »

Fuente: barrapunto

Según se publicaba recientemente en Bussiness Insider, en el 51% de los hogares norteamericanos hay al menos un producto Apple. Esto supone que en 55 millones de hogares de EE.UU. disponen de algún aparato que comienza por ‘i’ o por ‘mac; y en esos afortunados hogares, la media de disfrute es de 1,6 dispositivos por hogar. Pero no acaban aquí las cifras sobre la ‘adicción’ al consumo de productos Apple. En 1 de cada 10 de los hogares que aún no son felices porque les falta el más ‘cool’ de los cacharros electrónicos de moda se plantean adquirirlos para el año que viene. Fundamentalmente son jóvenes varones universitarios quienes, cuanto más dinero ganan, más aparatos de la ‘manzana’ compran, aunque prácticamente son muy escasos los consumidores que escapan a la seducción de la compañía de Cuppertino. Ni el propio Marx en el mejor de sus sueños capitalistas podría haber definido mejor el concepto de ‘(mac)fetiche’. ¿Y tú, ya eres feliz con tu producto Apple? Confiesa, fiel lector de Barrapunto ¿Cuántos cacharros que empiezan con ‘i’ o con ‘mac’ posees? O por el contrario, ¿crees que el mundo está i-rremediablemente mac-ondenado al infierno consumista?

Read Full Post »

Fuente: página/12

Un teléfono funcionando desde un navegador puede revolucionar la telefonía móvil y romper con uno de los riesgos más grandes de la cultura virtual: el de la dependencia tecnológica. Cada navegador (browser) para pasear por Internet viene con una idea de mundo. No es sólo esa ventana que se abre para ingresar a la web, sino la relación que dos mil millones de usuarios tienen con lo que hay detrás. Si el objetivo de Internet Explorer era convertirse en estándar para la venta de licencias de Microsoft Windows y Google-Chrome convive de manera fascinante con el entorno de aplicaciones que ellos han creado, Firefox es una especie de aire fresco. Firefox, el programa más conocido de la Fundación Mozilla, es usado por 500 millones de personas y apuesta por el software libre como método productivo.

El concepto de web abierta, de un espacio colaborativo, pareciera ser un tanto abstracto pero tiene más sentido cuando se compara cómo funcionan los teléfonos inteligentes. En la web, cada lugar tiene una dirección, los espacios se pueden compartir y se puede participar de la construcción no sólo de contenido sino también de aplicaciones. En el mundo móvil, Apple y Google plantean pasar de ser prosumidores a apenas consumidores. Por eso la propuesta que la presidenta (o alma mater) de la Fundación Mozilla, Mitchell Baker, viene a presentar en Argentina es tan sorprendente en su funcionalidad como en la decisión de hacerlo en Argentina y Brasil. “La web debe permanecer abierta”, dice Baker en una larga conversación con Página/12, sentada y abrigada en un cómodo sillón de un complejo céntrico de Buenos Aires. Mozilla organiza un encuentro regional para su comunidad durante cuatro días aquí, de la que participa también el flamante CEO Gary Kovacs y Chris Hofmann, otro gran referente. En estos días, Mozilla anunció que pondrá a disposición dentro de unos meses –junto a Telefónica– el primer teléfono administrado íntegramente desde algo parecido a un navegador, y que su lanzamiento mundial será en Brasil y luego en Argentina.

leer más

Read Full Post »

En un breve artículo de Sergio Montoro podemos ver excelentes ilustraciones de un asunto de vital importancia: cómo enfrentar los problemas de la vida real.

  1. Desde la primera alternativa (school) se trata de categorizar el problema (determinar a qué disciplina corresponde) y derivarlo a quien corresponda. Es un enfoque centrado en el modelo académico-educativo.
  2. La segunda alternativa (life) asume que los problemas pueden no pertenecer exclusivamente a una disciplina, y que pueden requerirnos conceptos básicos de disciplinas con las que no estamos familiarizados. Es un enfoque centrado en el problema. En mi artículo La informática necesita del aporte de otras áreas del conocimiento desarrollo esta interpretación del trabajo multidisciplinario, que tiene mucho que ver con la práctica profesional informática.

Read Full Post »

Older Posts »

Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.

Únete a otros 96 seguidores