viernes, 29 de marzo de 2013

Mujeres: Alicia Edelman Pelton (Microsoft)

Profiles on Women in Computing: Alicia Edelman Pelton, Program Manager



Get Microsoft Silverlight

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.
©2013 Microsoft Corporation. All rights reserved.

Innovación: Robot lagarto


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


La Nación

 
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..






jueves, 28 de marzo de 2013

Emprendedorismo: Una aplicación precoz de 60 millones


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..



miércoles, 27 de marzo de 2013

Argenware: Desde Bahía Blanca de todo corazón


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..




lunes, 25 de marzo de 2013

Mitos de los tests unitarios


Unit Testing Myths and Practices
05 January 2012
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.
Finding the break even point
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.
Finding the break even point
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.
Demonstrating how SomeMethod might 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.

lunes, 18 de marzo de 2013

MATE argentino para Notebooks


Una ronda de MATE para el mundo Linux



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.
-¿Y aprendiste algo de japonés?
-Muy poco.



domingo, 17 de marzo de 2013

Cómo cobrar por Internet


Cómo cobrar por internet


Cobrar online
Una de las partes más importantes de la venta online es el cobro de tus productos. Hay muchas formas de realizarlo y aquí veremos las principales.

Pasarelas de Pago

Las pasarelas de pago (Payment Gateways en inglés) son sistemas que manejan el pago de nuestros clientes para facilitarnos a nosotros el proceso. No hace falta que tengas una cuenta de banco, simplemente teniendo una dirección de email puedes cobrar tus ventas mediante las pasarelas de pago. Dentro de las más conocidas podemos encontrar DineroMailMercadoPago y PayPal.
La pasarela se encarga de cobrarle a nuestros clientes y luego nos entrega el dinero a nosotros. En general todas cobran una comisión por cada venta que varía desde un 3% a un 7%. Esta comisión se te cobra a ti como vendedor y para tu cliente es transparente.
Mediante una pasarela de pago localizada (como por ejemplo DineroMail MercadoPago) sus clientes podrán pagar con tarjeta de crédito, con medio de pago offline como PagoFácil y RapiPago en Argentina, Oxxo en México o bien por transferencia bancaria y otros medios menos conocidos. Algo muy importante es que tus clientes podrán pagar en cuotas con su tarjeta de crédito y tu recibirás el pago completo el primer día.
Los pasos para poder utilizar una pasarela de pago son:
  1. Ingresar al sitio de la pasarela y crear una cuenta, por ejemplo a DineroMail.
  2. Integrar la cuenta con tu tienda online. Si tienes una Tienda Nube puedes hacer la integración ingresando tu número de cliente de la pasarela en tu panel de administrador.
  3. Realizar una venta ;-)
  4. Cuando un cliente pague un pedido,  la pasarela te enviará un email asegurándote que el pago fue procesado exitosamente. No envíes el pedido antes de tener esta confirmación.
  5. Envía el pedido a tu cliente.
  6. El dinero cobrado quedará en una cuenta virtual de la pasarela que hayas escogido.
  7. Puedes retirar este dinero a tu cuenta de banco desde el panel de administración de la pasarela, o bien pedirles que te emitan un cheque. En algunas, deberas esperar algunos días hasta que puedas retirar el dinero.
Las pasarelas de pago son la forma más simple y rápida de cobrar tus ventas por internet. Los costos pueden variar de una a otra y en los distintos países. Aquí les mostramos los costos de Dinero Mail para los distintos países:

Sin transacción electrónica

Puedes realizar la venta online aún si el pago se realiza de manera offline.
Una opción interesante es permitir a tu cliente que pague cuando el producto es entregado o bien que pase a retirarlo por tu local o showroom y lo pague ahí mismo. Algunas personas quieren ver el producto antes de pagarlo y tener esa opción puede ser fundamental en su decisión de compra.
Estás son las formas básicas de cobrar la venta de tus productos de tu tienda online. Esperamos que te sirvan para desarrollar tu negocio y comenzar a vender por internet.

Twitter Delicious Facebook Digg Stumbleupon Favorites More

 
Design by Free WordPress Themes | Bloggerized by Lasantha - Premium Blogger Themes | Best Hostgator Coupon Code