Las pruebas A/B son experimentos controlados realizados online para determinar cómo cada característica de un producto o webpage afecta el tráfico o disposición a pagar de potenciales clientes..
Empresas de software
Usted puede encontrar en este blog entradas referidas al mundo empresarial de las firmas de software, sus interrelaciones y panorama actual.
Marketing
Usted puede encontrar en este blog entradas referidas a Marketing en la red así como para empresas de software.
Seach Engine Optimization
Usted puede encontrar en este blog entradas referidas a como operan los SEO para optimizar su presencia en la red.
Internet
Usted puede encontrar en este blog entradas referidas a Marketing en la red así como para empresas de software.
Mercado laboral en Software
Usted puede encontrar en este blog entradas referidas al mercado laboral de empresas de software.
Emprendedorismo
Usted puede encontrar en este blog entradas referidas al emprendedorismo digital.
Google le suma olor a sus mapas; Nokia presenta un microondas táctil
Esas son algunas de las noticias falsas que estas y otras compañías tecnológicas difundieron hoy, haciendo honor al festejo del Día de los Inocentes en el hemisferio norte
En Estados Unidos y Europa se celebra hoy el día de Inocentes (o día de los tontos de abril , tal la traducción literal de April Fool's Day), y es la norma hace años que las compañías tecnológicas publiquen este día productos falsos de todo tipo, con gacetillas que, por lo general, tienen bastante producción detrás.
Van aquí algunos de los más logrados:
GOOGLE CON OLOR
Además de una versión de Gmail que es azul (Blue, jugando además con las noticias alrededor de Windows Blue, la próxima actualización de Windows), el fin de YouTube y una edición de Maps que incluye un supuesto tesoro de hace tres siglos, Google Nose inaugura una nueva versión de Street View (su herramienta para ver las fachadas de las calles) que tiene 15 millones de olores indexados, y que pueden olerse en el teléfono.
NOKIA SE EXPANDE A LOS ELECTRODOMÉSTICOS
La compañía finlandesa prefirió jugar con su variada historia (hizo botas de goma, caucho, cables y más) para darle credibilidad a su entrada al mundo de los electrodomésticos con el 5AM-TH1N6 Constellation, un microondas con pantalla táctil y un transformador de 8 núcleos enfriado por agua, que combina 5000 watts para cocinar comidas en segundos.
TWITTER SIN VOCALES
Twitter aseguró en su cuenta que pasaría a una versión de su servicio gratis sin vocales, y que para escribir usando las mismas se deberían pagar 5 dólares mensuales, como una forma de lograr mayor densidad de información en las publicaciones. También promociona una versión que permite publicar 141 caracteres (es decir, uno más de lo usual); el costo de agregarlo depende de la popularidad del caracter deseado.
EL AVIÓN CON PISO DE VIDRIO
Ideal para quienes sufren vértigo, la aerolínea Virgin mostró su supuesta nueva nave , el primer avión con piso de vidrio, para ver el paisaje a nuestros pies durante el viaje.
UN TECLADO A LO HARLEM SHAKE
La compañía detrás del popular teclado SwiftKey (disponible para Android, y cuya tecnología está, en parte, en BlackBerry 10) le dieron una vuelta de tuerca al ingreso de texto. SwiftKey permite, como Swype, ir de letra a letra dibujando el trayecto en la pantalla... pero en este caso moviendo todo el cuerpo. Incluye, en el segundo 66 del video, un momento Harlem Shake .
Carcasa de madera para el iPhone
Otterbox, compañía conocida por sus fundas protectoras para diversos celulares, difundió un video explicando su nueva serie Maker , con planos que se pueden descargar para que cada uno se haga su funda... de madera.
Profiles on Women in Computing: Alicia Edelman Pelton, Program Manager
Learn about the many great women in computing careers at Microsoft. Meet researchers who are using computer science to solve some of the world’s most vexing problems or technologists who are creating the next wave of paradigm-shifting products. Discover what motivates these pioneering women and acquire insights into their current projects.
In this video, you’ll meet Alicia Edelman Pelton, program manager at Microsoft Research.
Un robot se inspira en los lagartos para avanzar sobre terrenos arenosos
El comportamiento de estos animales permitió que los investigadores aplicaran sus técnicas de locomoción; quieren evitar que robots como el que está en Marte queden empantanados
Los investigadores Daniel Goldman y Chen Li observan el desplazamiento de su creación. Foto: Gentileza Georgia Tech
Las dinámicas, diseños y movimientos de la naturaleza y sus seres vivos han inspirado desde hace décadas la fabricación de aparatos y sistemas más eficientes: si la evolución premió tal o cual planteamiento, debe tener algo bueno. Lo hemos visto en aviones, trajes de baño que recrean la piel del tiburón y en tejidos que imitan la tela de araña. También en la locomoción terrestre, aunque sigue habiendo muchas lagunas en este campo.
Para comenzar a cubrir estas deficiencias, un equipo de investigadores de Georgia Tech publicóun trabajo en Science en el que tratan de explicar la mecánica más propicia para que un robot pueda desplazarse por terrenos blandos, inestables, arenosos.
A través de sus cálculos, lograron informatizar la relación de fuerzas entre las partículas del suelo y las patas de un pequeño robot-lagarto. La idea es entender, para luego aplicar, el tipo de interacción que permite a los lagartos "nadar en la arena" para moverse con rapidez y sin hundirse.
Tras probar distintos formatos de patitas para el robot, resolvieron que las patas (seis) en forma de "C" son las más eficientes sobre finísima arena (o semillas de amapola), como se observa en la parte final del vídeo. El robot, de 13 centímetros y 150 gramos, alcanzó los 2,5 kilómetros por hora de velocidad. El primer robot de seis patas inspirado en los andares de los lagartos fue RHex, diseñado en 2001 por investigadores de la Universidad de Michigan.
El investigador Chen Li analizando el comportamiento del diseño de la pata para moverse en la arena. Foto: Gentileza Georgia Tech
Con el estudio de la dinámica del terreno granulado los investigadores han creado un modelo informático que calcula mucho más rápido que antes cómo se comportará determinada pata o rueda sobre la arena. "Antes, llevaba un mes simular en nuestros ordenadores un segundo de locomoción del robot sobre un lecho con cinco millones de semillas; ahora, la simulación tarda sólo 10 segundos", explican en una nota .
Entender este funcionamiento servirá para mejorar el conocimiento de la fauna, pero también para desarrollar mejores vehículos. Y para evitar que ocurra lo que le sucedió al robot de seis ruedas Spirit en Marte, que quedó atrapado en mayo de 2009 en un punto de suaves arenas de las que nunca pudo escapar..
Con 17 años vende una aplicación a Yahoo! por más de 60 millones de dólares
Nick D'Aloisio desarrolló en la habitación de su casa la "app" Summly que reduce el tamaño de las noticias para hacerlas más fáciles de utilizar en la pantalla de un celular. La Nación
No terminó ni siquiera la secundaria, pero ese no fue un obstáculo para que Nick D'Aloisio, de tan sólo 17 años, se convirtiese en un nuevo multimillonario tecnológico, tras vender una aplicación para celulares a Yahoo! por US$ 61,2 millones, según el London Evening Standard, pero fuentes como el blog de tecnología All Things Digital menciona que la operación se concretó en 30 millones de dólares, en su mayor parte en efectivo.
D'Aloisio, residente en Wimbledon, en el sur de Londres, desarrolló en la habitación de su casa familiar la aplicación Summly, que reduce el tamaño de las noticias para hacerlas más fáciles de utilizar en la pantalla de un celular.
Según contó el adolescente al diario Evening Standard la idea surgió mientras buscaba información en Internet en 2011. "La búsqueda en Google era ineficaz y hacía perder el tiempo, pese a la cantidad de información que existe en la red, ésta se encuentra desordenada y es, por lo tanto, inservible. Fue entonces cuando tuve la idea de crear una algoritmo que resumiera resultados de búsqueda automático", dijo.
Cuando D'Aloisio lanzó Summly en el año 2011 tenía tan sólo 15 años. El corazón de la pequeña empresa de D'Aloisio es la aplicación para el iPhone Summly. Se trata de una aplicación que resume noticias que se adaptan a la perfección al tamaño de la pantalla del smartphone de Apple y que tienen un máximo de 400 caracteres.
Consultado sobre qué hará con el dinero, D'Aloisio indicó que ahorrará la mayor parte del dinero. "Me gustan los zapatos: compraré un nuevo par de zapatillas Nike y probablemente una nueva computadora, pero en este momento sólo quiero ahorrar y guardar el dinero en el banco. No tengo muchos gastos en el día a día", reconoció.
Además del pago, el acuerdo con Yahoo! incluye un puesto para D'Aloisio en las oficinas de la compañía en Londres, donde trabajará a tiempo completo y estudiará por las noches para completar su formación.
Sus padres, él financiero de energía en la City y ella abogada, fueron testigos de todo el proceso creativo, que comenzó como una simple afición con Trim It, la primera versión de Summly, que ya acumula un millón de descargas.
Trim It fue lanzada en julio de 2011 y nombrada "app" de la semana, una publicidad que suscitó el interés de la multimillonaria "joint venture" china Li Ka-Shing y el posterior apoyo de reconocidas figuras como el cómico inglés Stephen Fry, Yoko Ono o el actor Ashton Kutcher.
Con su respaldo económico, D'Aloisio desarrolló la aplicación hasta llegar a Summly, que actualmente mantiene acuerdos de colaboración con 250 publicaciones "online", entre ellas el grupo mediático News Corporation, propiedad del magnate Rupert Murdoch..
En Bahía Blanca, el electrocardiograma se hace con un celular
Un grupo de investigadores de la Universidad Nacional del Sur creó un sistema que permite usar un smartphone para procesar los datos obtenidos por los sensores y analizar el estado cardíaco. La Nación
Son investigadores de la Universidad Nacional del Sur y del la Tecnológica Nacional. Hay docentes y estudiantes. Y crearon, en Bahía Blanca, el ElectroSmart ECG , un electrocardiógrafo portátil para dispositivos móviles.
El equipo tiene 12 sensores cutáneos que se conectan a un pequeño transmisor; este no procesa la información, sino que la deriva a un smartphone, usando una conexión inalámbrica Bluetooth (presente en la enorme mayoría de los teléfonos móviles de gama media y alta); la aplicación es la que se encarga del análisis y representación de los datos, además de permitir compartirlos vía Internet con otras personas.
El equipo, integrado por Guillermina Cledou, Jonathan Vainstein, José Francisco Manera, Pablo Obreque y los profesores Claudio Delrieux y Marcos Chaparro es uno de los participantes del concurso Innovar , que difunde desarrollos nacionales.
El desarrollo no es parte de una investigación universitaria, sino algo que fueron armando en sus ratos libres, y planean llevarlo al mercado. Según declaró el doctor Delrieux (investigador del Conicet) al sitio de noticias universitarias Argentina Investiga , este diseño desdoblado permite reducir costos de fabricación, ya que delega las tareas más pesadas al celular..
We all understand the value of Unit Testing, but how come so few organisations maintain unit tests for their in-house applications? We can no longer pretend that unit testing is a universal panacea for ensuring less-buggy applications. Instead, we should be prepared to actively justify the use of unit tests, and be more savvy about where in the development cycle the unit test resources should be most effectively used.
Despite the pervasive dictum within software engineering that unit tests must exist for all code, such tests are little-used for the development of enterprise applications. In over fifteen years of consulting, I can count on the fingers of my hand the number of organizations maintaining unit tests for their applications. Why is it that so many organizations ignore such a popular software practice? In order to answer this question we first need to explore the myths and real world practices of unit testing, and then go on to describe the points within development where their value is well-established.
Myths
Two of the more generally-held myths that prop up the dogma of unit testing concern the professed benefits. The first myth, and most loudly claimed, states that unit testing inevitably saves money. The second myth, and zealously professed by many developers and engineers, promises a reduction in the bug count.
The Saving Money Myth
The idea that unit testing inevitably lowers the cost of application development rests on the reasonable assumption that fixing a bug as soon as possible saves money. Graphs such as the one below typically compare two application’s costs to support this claim. Each solid black line represents an application’s total cost over time.
The application labeled “No Unit Tests” starts out with lower expenses than that labeled “Unit Tests” as shown by the red line. Not a surprising fact since someone either coded or didn’t code unit tests. Over time though the “No Unit Tests” application costs more money because of increased support, bug fixes, deployment, lost customers, etc. According to this assumption about cost-savings, organizations can even calculate the “Breakeven” point at which their unit testing pays off. And at any time past this point they can find the total savings earned from writing unit tests as shown by the green line on the far right.
There’s a problem with the underlying assumptions supporting the above cost profiles. They do not factor in the financial repercussions of a delay in the delivery of today’s enterprise applications.
The first problem stems from the increasing importance of enterprise applications to an organization’s profitability. For example, it is not unusual for a company to build some widget that’ll save identifiable staff several hours a day. Delaying the widget’s release in order to write unit tests causes not only angst but measurable, lost productivity. I have rarely seen a developer convince an end user that adding unit tests justifies delaying a much-anticipated feature just to prevent of a few potential bugs.
The second problem is the cost associated with the consequences of writing tests. Time expended coding unit tests keeps other features un-built and idling on backlog. It disrupts the development process. The process of implementing unit tests cannot be readily scaled up to prevent backlog because, for most organizations, there are only one or two folks possessing the domain knowledge to add new or enhanced features to a specific application. When these developers code unit tests they are not coding new stuff.
When we update our cost assumptions for Unit Tests with only these two omissions, our graph alters as shown below. The “Unit Tests” application’s total cost over time line shifts up with dramatic implications.
Suddenly the savings advantage of the “Unit Tests” application shrinks. To make matters worse, it also takes longer for an organization to realize these diminished savings as shown by the rightward movement of the “Breakeven” point. No wonder that any IT management that takes a financial vantage will wish to minimise unit tests. Adding them to a project may not save an organization as much money as it had previously calculated.
The Reduce Bugs Myth
The myth of the ‘reduce bug count’ originated in the early days of software engineering. It sprung from the reality of working with the tools and technologies that were available at the time.
When enterprise applications were built 20 years ago with C and C++, unit tests helped to minimize the number of bugs escaping into the wild. Even the crudest test caught defects that were attributable to undeclared variables, mixed case method names, missing header file, calling functions without parenthesis, etc.
Enter today’s improved integrated development environment (IDE) tools and managed memory runtimes, and many C/C++ lifesaving checks handled via unit testing became superfluous. The technologies of choice for enterprise applications, such as, .NET and Java, placed many golden oldie bugs on the extinction list. Unit testing was no longer required to catch all those pesky technical code flaws.
Improved technology further eroded unit testing as the premier bug management tool by promoting software construction practices which leveraged multiple components to create an enterprise application. Dynamically cobbling together different data stores, libraries, web services via dependency injection, configuration files, and plug-ins spawned an entire new breed of defects for which unit testing proved marginally effective.
The below graphic depicts a simplified scenario of how “SomeMethod” might pull from several component’s to complete its task.
In such a scenario, it is only some form of integrated, or user acceptance, testing that will guarantee “SomeMethod” behaves appropriately. Properly-constructed unit tests only ensure that a component works as coded. Service X and Service Y may pass their respective unit tests but both may not produce the desired results when end users execute “SomeMethod” within a specific context.
Practices
If the preceding discussion leaves one believing that unit tests only provide mythical benefits, real-world experience suggests otherwise. In several circumstances they play a critical role in helping to deliver enterprise applications. This section discusses a few them.
Building Libraries
Even the most powerful frameworks and runtimes omit features that are required by an organization. Because of this, organizations wisely create their own custom libraries for all their developers. As these libraries change of over time, whether via refactoring or feature updates, unit testing is essential to quickly validate the change and can save an organization a great deal of time and money.
Enhancing Technology
Sometimes the required technology cannot work its magic alone. Unaided it allows developers to write buggy code all too easily. In such situations enhancing the technology with unit testing comes to the rescue.
Developing browser-based User-interfaces is an example of this situation. Despite the existence of such powerful plug-ins for building Web-Based User-Interfaces as Flex and Silverlight, it is HTML and JavaScript that remain the tools of choice for responsive web applications. Although JavaScript is powerful, it looks more like C++ than C#. This means developers will need unit tests to avoid the classic pitfalls of type checking, improperly cased names, overwritten functions, etc.
Helping Startup Projects
When a new project with several engineers starts from scratch it will initially generate much code that will ultimately require synchronization. But until reconciling all of the project’s components each engineer usually needs a way to execute their code without the other components. Unit testing tools and products can provide such services.
As an aside, I find test driven development (TDD) demonstrates this value proposition. It too does not require developers to have all of their components’ dependencies lined up and running. TDD allows engineers and developers to productively and safely write a lot code courtesy of unit testing. Developers only require the scantiest knowledge of the project’s other components.
Implementing Smoke Tests
Regularly deploying code to any environment can be a risky proposition for even the smallest fix or feature. We repeatedly relearn this fact. (Remember that little tweak that broke the entire application and left the testing staff without work?) In order to combat this problem many organizations write a few key unit tests which are automatically executed immediately after a build and before deployment. These few “smoke tests” provide enough coverage to ensure the basic functionality of the application.
If smoke testing sounds like continuous integration (CI), there’s a reason. They share similar objectives, albeit with vastly different scope. CI typically demands organizational commitment and resources; incorporating smoke tests typically requires a few commands by the build manager.
Writing Clearer Code
By having to Craft unit tests, developers are forced to think as consumers of their code. This gives them an extra motivation to build an application programming interface (API) that is clear, and easy to implement.
The drive to write better unit tests generally motivates better design, too. By incorporating unit tests into their components, Developers are encouraged to follow many good software design tenets, such as, avoiding hidden dependencies, and coding functions with a well-defined mission.
Note: Bug Management Practices
If unit testing provides less than ideal bug management support, what options exist for software developers and engineers? After all the integrated and UAT tests are completed prevailing practices suggest two broad strategies for better managing bugs, one passive and one active.
The passive policy amounts to organizations providing a full featured help desk. In such an environment end users report bugs which get triaged until resolved. While an effective practice from a managerial perspective, it tends to frustrate end users and place developers in a reactive mode.
Actively managing bugs is an alternative strategy of growing popularity. It requires applications to self-report exceptions and such. This can happen via home grown or 3rd party tools, such as, Red Gate’s SmartAssembly. This strategy acknowledges the difficulty of preventing bugs with the belief that knowing about them as soon as possible without explicit user complaints mitigates pain.
Conclusion
Forgive me if I have left any readers thinking ill of unit testing. Nothing could be further from my intent! The goal was to challenge the premise that writing unit tests is always a wise practice in all contexts. Because the IT culture within the enterprise application space is no longer so uncritically accepting of the value of unit testing it is up to software engineers and developers to actively justify the cost of building unit tests in terms of benefits to the enterprise. I’ve noted in this article several circumstances where unit testing is vital for the timely delivery of robust applications, and I strongly suspect that many enterprise application engineers and developers who read this will think of more.
We can no longer rely on a general acceptance of the myth that unit testing is a universal panacea, but need to focus unit testing on aspects of development where it is most effective, and be prepared to actively justify its use.
El teléfono sonó tarde a la noche. Era mi amigo Eduardo Suárez, y el diálogo que se produjo no mejoró en nada nuestra fama de hablar en Klingon o algo así.
-¿Viste MATE? -me preguntó.
-¿Mate, qué mate?
-Mint.
-Ah, MATE, el Escritorio para Linux, sí, es el que uso en mi notebook. ¿Qué pasa?
-Lo escribió un argentino.
-¡En serio!
-Sí, señor. Un muchacho de Río Negro. Bariloche o Cipolletti, no estoy seguro. Te estoy pasando su mail, ¡tenés que hacerle un reportaje!
-Obvio.
***
La historia es así. Al revés que Windows y Mac OS X, cuyo aspecto visual está férreamente dictado, respectivamente, por Microsoft y Apple, el sistema operativo de software libre Linux usa un mecanismo de ventanas modular (más información aquí) que puede personalizarse, modificarse y, llegado el caso, permite crear un entorno de Escritorio enteramente nuevo. Puesto que es software libre, el código fuente (lo que escriben los programadores) está no sólo disponible, sino que puede usarse con cualquier fin, con la condición de que el producto final incluya también el nuevo código fuente.
Una captura de pantalla del escritorio MATE para Linux Mint.
Sí, lo sé, entorno de Escritorio suena bastante esotérico, pero está compuesto de elementos hoy bien conocidos: barras de herramientas, ventanas, íconos, carpetas, y así. La disposición y las funciones de estos componentes caracterizan a cada Escritorio, desde los más clásicos, como el de Windows XP, hasta los menos tradicionales, como el Unity de Ubuntu.
Durante años, uno de los Escritorios más usados en Linux fue Gnome ( gnomo , en inglés; originalmente, eran las siglas de GNU Network Object Model Environment ), cuya versión 2 exhibía dos rasgos salientes, uno bueno y uno malo. El bueno, que era claro y fácil de aprender a usar. El malo, que se fue quedando en el tiempo.
Para subsanar esto, nació Gnome 3, de aspecto más moderno y con soporte para pantallas táctiles, pero que se apartó de la interfaz tradicional en favor de un diseño menos claro y menos flexible. Por supuesto, esto causó una ruidosa polémica en el mundo Linux y creó las condiciones para que Ubuntu experimentara con su propia alternativa visual, llamada Unity, que a su vez originó más revuelo.
Pero hubo alguien que, en lugar de quejarse, decidió rescatar Gnome 2, creando un nuevo Escritorio basado en su código fuente, actualizado, con un aspecto más moderno y más atractivo. Así nació MATE, que se convertiría en mayo de 2012 en el Escritorio predeterminado de Mint , la distribución de Linux que más ha crecido en popularidad durante los últimos 2 años.
Pues bien, el fundador del proyecto MATE es Germán Perugorría, de 30 años, que nació y vive en Cipolletti, provincia de Río Negro. En el ambiente del software libre a Germán se lo conoce por su alias Perberos ; en rigor desde antes, porque a los 23 años había desarrollado una plataforma de juegos online. Lo primero que Germán me dijo cuando le propuse entrevistarlo fue que prefería no hablar de él, sino de su proyecto. Pero, como suele ocurrir, su obra dice mucho también de él, como se verá a continuación.
-Al principio pensé que MATE quería decir sin brillo. Me parecía raro, porque es un Escritorio muy vistoso. ¿Por qué le pusiste MATE?
-Por la filosofía de preparación del mate, su cultura de compartir, y por lo primitivo que es, pero a la vez muy eficiente.
-¿Cómo empezaste a programar?
-Mi vocación por la tecnología comenzó desde muy pequeño. Siempre me gustaron los videojuegos. Aprendí mucho de ellos, incluso inglés. Poco a poco me fui acercando al mundo de la programación, usando juegos con estructuras de creaciones, música, pintura. He hecho muchas cosas, leer mucho, revisar blogs, foros, experimentar, hackear, crear.
-¿Vivís de la programación?
-Lamentablemente, no, si te referís a sustento económico. Pero sí alimenta mi pasión por crear. Actualmente, mi mayor obsesión es la programación en lenguaje C, eso es lo que me ha ayudado a iniciar el proyecto MATE.
-¿Cómo nació el proyecto?
-Surgió por una necesidad mía de no perder aquel entorno de escritorio llamado Gnome (N. de la R.: se refiere a Gnome 2). Sentí mucha tristeza al ver cómo se perdía. Entonces comencé a recolectar todo lo que podía, y luego de medio año ya tenía algo sólido.
-¿Cuando fue eso?
-En 2011.
-Y lo pusieron como Escritorio predeterminado de Mint en mayo de 2012. ¿Ellos te contactaron?
-Así es, a mediados de 2011, el fundador de Linux Mint, Clem (N. de la R.: se refiere al francés Clement Lefebvre), me contactó, interesado en el proyecto. Allí fue cuando, junto a Stefano-k (N. de la R.: el italiano Stefano Karapetsas), se armó el sitio Web, la documentación y todo eso. Mucha gente ayudó, a la que no tuve oportunidad de hablarle.
-Qué emoción habrás sentido cuando te contactaron de Mint, ¿no?
-Sí, mucha, aunque no fue la primera distro en ofrecer MATE. Creo que la primera fue Salix.
***
Distro es la forma en que nos referimos, en Linux, a una distribución. ¿Qué es una distribución? De nuevo, al revés de lo que ocurre con Windows y Mac, donde solamente existen las versiones oficiales de Microsoft y Apple, cualquiera puede crear una versión de Linux. No es que sea un paseo en bote, pero se puede y, de hecho, la distribución más respetada, Debian, sobre la que se basa Ubuntu, fue creada por el alemán Ian Murdock en 1993. La palabra Debian es la combinación del nombre de la novia que tenía entonces Ian, Debra Lynn, y su propio nombre. Debra y Ian se casaron y estuvieron juntos hasta 2007, cuando pidieron el divorcio. Debian, sin embargo, perdura como una de las marcas más indelebles e influyentes del software libre.
-Contame cómo fue desarrollar MATE, qué herramientas usaste, cómo es el proceso de crear algo así.
-Debo confesar que soy hacker y me gusta el método de prueba y error. En etapas avanzadas de desarrollo siempre bromeaba diciendo que no tenía ni la menor idea de lo que estaba haciendo, llamando a soluciones como mágicas, sin dar detalles de eso. Quizá por pereza (se ríe).
-¿Qué sería una solución mágica? ¿Cuando escribís código que no sabés bien cómo funciona, pero funciona?
-Sí, o cuando cambiás de lugar código y el programa anda.
-En todo caso, MATE debe ser mucho código, ¿no?
-MATE no sería nada sin el proyecto Gnome, que fue escrito por miles de personas. Le estoy muy agradecido a toda esa gente.
-Gnome 2 en particular.
-Sí, la versión anterior a que cambiaran su diseño, orientado hacia tablets.
-¿Cual fue específicamente tu aporte? MATE es claro, lindo y consume poca memoria.
-Eso es exactamente lo que proyecté cuando imaginé MATE, y lo que realmente hice fue tomar todo el código básico para que funcione un Escritorio, actualizar ese código y adaptarlo a las nuevas versiones de las librerías. GNU-Linux es un ecosistema bastante delicado, se rompe una librería y lo sufren todos los programas enlazados a ella.
-También hiciste aplicaciones, como Engrampa (el archivador) o Pluma (el editor de texto).
-Pluma es un fork de Gedit, el editor por defecto en Gnome, y Engrampa es un fork de Fileroller.
(N de la R: se dice fork cuando un programador crea un nuevo software, no desde cero, sino a partir del código fuente de una aplicación previamente existente.)
-¿Les cambiaste algo a esas aplicaciones?
-Te mentiría si te dijera que sí o que no, porque leer tanto código hace que uno olvide ciertas cosas.
-¿Tu proyecto era entonces que no se perdiera Gnome 2?
-En parte sí, aunque uno simplemente pudiera optar por usar el modo tradicional en Gnome 3, o pasarse a Xfce4. Lo que me daba pena es que a medida que se iba presentando el nuevo Gnome se perdía la retro compatibilidad.
-¿Cuál dirías que es la diferencia entre MATE y opciones como Xfce4, KDE o el modo tradicional en Gnome 3?
-Xfce es un entorno algo extraño, que no termina de enganchar entre sí. Su modelo CDE no es muy atractivo. Gnome 3, por alguna razón, preveía salir sin modo tradicional, eliminarlo, dejar de desarrollarlo. Y KDE es muy pesado para mi gusto.
-La cosa es que te propusiste mantener vivo un entorno de Escritorio al estilo tradicional, claro y simple.
-Sí, y además quería aprender cómo era un entorno de Escritorio por dentro, cómo se compilaba, cómo se escribía, cómo se diseñaba.
-¿Dónde escribías código? ¿Usaste algún entorno de desarrollo?
-Lo curioso es que todo fue en consola. Pasé los primeros meses sin ver Xorg. (N. de la R.: Xorg es, grosso modo, la interfaz gráfica de Linux.)
-¿En serio? ¿Escribías código en un programa para terminal?
-Sí, usaba nano.
-¿Por qué no algo más amigable?
-¿Masoquismo quizá? (se ríe).
-¿Cómo se crea un entorno de Escritorio para Linux?
-Yo lo comencé a reconstruir desde abajo.
-¿Que significa desde abajo?
-A medida que iba progresando, me acercaba al entorno gráfico. Como cuando construís un edificio, ves los pilares y en base a eso vas edificando.
-¿Qué serían los pilares en este caso?
-Las herramientas GNU, el kernel de Linux y las librerías Xorg, glib, gtk, etcétera. Gnome era los ladrillos y el cemento. De hecho, MATE actualmente sigue sufriendo el deterioro que sufrió Gnome en su momento
-¿En qué sentido?
-Creo que es el ciclo de vida del software, la obsolescencia.
-¿Cuál es el futuro de MATE, entonces?
-Adaptarse. Me gustaría que también preservara la retro compatibilidad, pero es difícil saberlo.
-¿Cuánto tardaste desde que tomaste la decisión de crear MATE hasta que tuviste la primera visión del nuevo Escritorio?
-Un año.
-¿Dedicándole cuántas horas por día?
-Entre 4 y 16 horas diarias; la inspiración o la curiosidad no me dejaban dormir (se ríe).
-¿Por qué te dijo Clem que se había interesado en MATE?
- Clem me comentó que había mucho descontento con la introducción forzada de Gnome 3. Entonces usó su equipo de gente para empaquetar MATE. Los resultados se vieron unos meses después: un entorno al estilo Gnome 2, rápido y eficiente. Productivo. Pero los siguientes meses fueron de disgustos con el proyecto Ubuntu, que es la base de Mint.
-¿Por qué disgustos?
-Porque el proyecto Ubuntu modificaban las librerías para adaptarlas a sus necesidades. No es que esté mal, pero afectaba a muchos programas de terceros, incluyendo MATE. Así que me pasé días buscando bugs (errores) donde no había nada, creando condiciones especiales para detectar las librerías de Ubuntu. Mucho hacking .
***
A estas alturas, creo, vale la pena aclararlo: la palabra hacker no se usa, en el ambiente informático, como sinónimo de delincuente. Este uso, popularizado por los medios, está muy lejos de lo que Germán quiere decir. Esto es, que un hacker es alguien que modifica el código o la electrónica de un dispositivo para mejorar su funcionamiento o, incluso, sí, para detectar fallas de seguridad.
-¿Cuántas personas colaboraron en la creación de MATE? Digo, una vez que apareció en las distros. Porque al principio estabas solo, ¿no?
-Al principio sí, luego recibía correcciones de miles de personas. Después apareció Stefano-k, que me dijo que usaba MATE en su entorno de trabajo y que lo quería soportar, y ayudó muchísimo en la creación del sitio Web, el foro, la wiki, y colaboró con mucho código.
-MATE usa, en ralentí, sólo 169 MB de memoria. ¿Cómo lograste tan bajo consumo de RAM?
-He quitado algunos componentes incompletos. A mí también me gusta el consumo que tiene, sobre todo con el nuevo Windows usando más de 700 MB de RAM sin correr nada.
-¿Tenés alguna idea rectora para la próxima versión de MATE?
-Es delicado pensar en algo revolucionario, podríamos terminar como Gnome 3 (se ríe). No, hablando en serio, me gustaría hacer MATE más compatible con la librería gtk3, pero sin perder gtk2, incluso si el código se convierte en spaghetti.
-¿Spaghetti? No conozco esa jerga...
-Funciones anidadas.
-Ah, entiendo. ¿Qué ventaja le ves a gtk3?
-Tiene soporte para las últimas computadoras táctiles. Aunque MATE no estará diseñado para pantallas táctiles, se podría usar con teclado y mouse.
-El sitio de Mint sigue primero en el ranking de Distrowatch, ¿sabías?
-Hay muchos factores que hacen que Mint esté en primer lugar.
-¿Cuáles?
-Mucha controversia de Canonical, y el estilo por defecto del escritorio de una barra (Unity) y sus aplicaciones.
-¿Saben en Cipolletti que uno de sus ciudadanos ya es ilustre en el mundo del software libre?
-Eso no lo sé.
-¿Por qué aparecés con la bandera de Japón en el sitio de MATE ? Hay alguien en el foro que se queja por eso, y dice, con razón, que sos de Río Negro, no de Japón.
-Es una broma que surgió en el canal de #mate, porque yo quería aprender japonés.
17:27
Juan MC Larrosa
Entradas
