Planetaki Planet backdraft

Puntos de vista

2009-07-03T09:10:18+00:00

Respeta los puntos de vista de los demás. Porque… bueno, es lo que ellos opinan, tío.

– Notaronomio, 2:5,
libro sagrado de la Iglesia del Nota del Último Día

# Enlace Permanente

25 imprescindibles para Ubuntu Jaunty Jackalope

2009-07-03T09:10:13+00:00

How to Pick the Perfect Programming Editor

2009-07-03T09:10:18+00:00

To the outside world, developers can have an unhealthy fixation with their code editor. It’s not surprising — most of us spend longer with our IDE than our families. Sean’s recently-posted list of free editors provoked a plethora of debate about what is and what’s not the best coding tool.

There are dozens of code editors to choose from and many are freeware or open source. Ultimately, the choice is yours, whether it’s Windows Notepad, VIM or VisualStudio. However, there are a number of key IDE features that I’d recommend to all web developers.

Essential Features

An editor won’t remain on my PC if it doesn’t provide the following:

Speed and stability
The editor must start quickly and remain responsive. Sorry Eclipse and Aptana.

Multiple files / MDI interface
The days of opening a single source file are long gone. Tabs are my preferred choice of interface and they absolutely must support middle-click closing!

Multiple language support
Even the most basic web projects require HTML and CSS. A simple application is likely to add JavaScript, SQL, XML, and a server-side development language such as PHP, C#, VB, Java, Perl, Ruby or Python. Your editor should be able to effortlessly handle every type of code you choose.

Line wrapping and numbering
It may be bad practice, but long lines of code are sometimes necessary. The editor should let you view code without horizontal scrolling, so a line wrapping option is essential. When the inevitable error occurs at line 4321, you need to be able to find that bug quickly — so forget any editor that does not display line numbers.

Configurable color-coding
Missing quotes or tags can cause havoc, but color-coding can dramatically reduce your error rate. Bonus points are awarded for any editor offering fully-customizable color schemes.

Auto-complete
Microsoft VisualStudio sets the gold standard with IntelliSense. Few editors reach that level, but if I’m adding a <p> tag, you can guarantee I want a closing </p>. Please don’t make me type it!

Session store and restore
When the editor is restarted, it should restore the files you were working on, open them in the correct order and preferably at the last line you were editing.

File explorer
The option to open other files in the current project can save time.

Find and replace across files
How many times have you renamed a class or function? The editor should provide facilities to change all references quickly and easily.

Desirable Features

The following options are great if they’re available:

Debugging tools
Debugging facilities range from absolutely essential (.NET or Java), to useful (PHP or Perl), to unnecessary (JavaScript — unless it’s better than Firebug!) Make sure your editor provides the debugging tools you need.

Bookmarking
Jumping between functions in the same file is easier if you can bookmark individual lines.

Multiple views
Similarly, it can be useful to ’split’ a file into multiple windows so different segments can be edited at the same time.

Code-folding
The facility to collapse or expand segments allows you to concentrate on the important code.

Code explorer
Again, VisualStudio sets the standard with class inspection windows showing details of all properties and methods. However, a simple list of method/function names in alphabetical or source order can be just as useful. Bonus points for any editor which handles the multiple types of function declaration in JavaScript!

Good font support
In general, I prefer to code using a proportional font. I may be in the minority, but please don’t force me to use monospace! SciTE offers the best solution; you can switch between monospaced and proportional fonts using Ctrl+F11.

Shortcuts, plugins, and macros
If you use particular keyboard combinations or functionality, configurable shortcuts, macros and plugins can help you migrate to another editor.

And the Bad Features…

Sometimes, editors offer dubious functionality that you really do not need.

WYSIWYG design view
Whilst WYSIWYG can be useful for novice developers, you will soon discover that hand-coding HTML and CSS is quicker than any design package. It can also be essential if your application requires DOM manipulation. If a WYSIWYG view is provided, make sure it doesn’t refactor your carefully-crafted code when you accidentally hit the ‘design’ button.

Obtrusive project management
Sometimes, you just need to open a file and make a minor change — please don’t force us to create a new project!

Dumb HTML-generation tools
I do not need a toolbar icon that uses valuable screen estate and inserts a <p> tag. And I certainly don’t need icons that insist on adding deprecated <b> tags!

What are the essential features you look for in a code editor? Are there any “features” that particularly annoy you?

La comunidad de PHP responde a Google sobre Tips de Optimización

2009-07-03T09:10:18+00:00

Vía phpdeveloper me entero que Google ha publicado una guía de optimización para acelerar las páginas con PHP. Pero lo interesante no son los consejos, sino, en mayor medida, la respuesta que la comunidad de PHP ha hecho. Y es que al parecer, varios de los consejos para acelerar aplicaciones en PHP que ofrece Google ya no son viables. Veamos las respuestas más interesantes, una por una...

10 Signs of Crappy PHP Software

2009-07-03T09:10:18+00:00

Like it or not, as a professional developer, sooner or later you are going to do some customising (if you are lucky, "extending") of existing software.

If you are not familiar with the software, it is good advice to look into it before accepting the job. I had to learn that the hard way. But how do you recognize crappy applications without getting knee deep into the code? 10 pointers to identify crappy PHP software quickly...

1. The software tries to reinvent the object model, or "fix" language features.

See if you can find a class called "Object". If you find it, it's a pretty clear indication that the author is in the business of trying to reinvent the object model (most commonly because of his own lacking understanding of OO). It is safe to assume that his "fixes" won't stop there. Unplug your phone and hide under your desk.

2. The code includes user defined global variables

A search in the code for "global" or "$GLOBALS" may reveal something like this:

global $database, $my, $mainframe;

The infamous global variable. If you can tell me what those last two variables contain you are either intimate with the software I pulled it from, or you're psychic. Unlimited bonus points if you can say what code has had it's claws on it before execution flow got to this point. In short, steer well clear.

3. Scattered HTML and SQL

Search for some common SQL and HTML strings. You should be able to determine very quickly whether these are appropriate places for HTML or SQL. If you find HTML and SQL in the same file, "crappyness" is most definitely confirmed.

4. Classes do too much

Find the 3 largest class files by bit size. Take a look at the class name. Does it indicate a distinct responsibility? Look at the methods. Are the tasks they perform closely related? If not, run away screaming.

5. Lots of properties are public or lots of properties are static

If lots of properties are declared "public static", triple your quote. If I have to explain why, maybe there's an open position on the development team of the software for you.

6. Multiple levels of inheritance

More than 2 levels inheritance should be avoided like the plague. I stake my life on the resulting objects having too much unrelated behaviour (ok, maybe not my life, but if you find a proper use of more than 2 levels of inheritance, I'll buy you a beer).

7. The authors try to use Design Patterns

Whether or not the authors have a clue is easily determined by searching for some of the most common design patters. Search the code base and/or documentation for "factory", "decorator", "strategy" etc. If present, you can pretty quickly determine whether the authors know their stuff or are trying to look interesting. That is, if you know how the code should look. If not, refuse to take the project until you do.

8. The software messes with the error level

Well written applications run fine at any error level. Searching the files for /error_level$.*$/ should do the trick. In case of hits, try replacing the value with E_STRICT. That's little more than a formality though.

9. In the code base, there is a directory called "core"

This is usually used as an excuse to have the whole application dependent on whatever is in there. Despite the appeal of the term (it does make the contents sound pretty cool and important), defining a "core" is a sign of bad design.

10. The software uses it's own template language.

Be afraid. Very afraid. These guys are definitely in the business of reinventing the wheel. Ignore this warning and you will find yourself spending the better part of a day simulating a "for" loop.

Las lecciones aprendidas de Hot or Not

2009-07-03T09:10:18+00:00

Si llevas un tiempo navegando por internet es muy posible que conozcas el sitio Hot or Not. Si no es así esta es una buena oportunidad para conocerlo.

Hot or Not es un sitio de esos que se crearon y nacieron en el momento en el que muchos otros, hoy multimillonarios negocios, fueron concebidos. Sólo que Hot or Not no llegó a estar entre la lista de las adquisiciones a precios mareantes.

Captura de pantalla de www.hotornot.com

En el blog de Martín Pérez, Pensamientos ágiles, hay una entrada magnífica que habla de una entrevista hecha al fundador de Hot or Not, James Hong que le hacen en How HOTorNOT Bootstrapped To Over $5 Million In Annual Profits – With James Hong.

Entre las cosas más interesantes de las que habla Hong, y resume muy bien Martín:

Nunca quisieron dinero para crecer más. Evitaron el capital de riesgo, no porque fuese malo sino porque ellos no lo veían. Ellos simplemente querían algo que generase constantemente dinero sin buscar aspiraciones más altas.
Nunca tuvieron más de cinco empleados. James define esa como una de las claves. No tenían burocracia ni grandes infraestructuras que mantener. Todo lo que querían hacer lo sacaban rápidamente.
HOTorNOT se defendió de todos estos gigantes al principio consiguiendo que la prensa hablase de ellos.
Lo que más importa es siempre el producto.
La clave de su éxito, la facilidad de uso. HOTorNOT se usa con un click.

Posts relacionados

78 Photography Rules for Complete Idiots

2009-07-01T21:08:17+00:00

Everyblock's Code is Open-Sourced

2009-07-01T21:08:21+00:00

MAESTROS

Everyblock's Code is Open-Sourced

2009-07-03T09:10:18+00:00

The code for Adrian Holovaty's Everyblock has been released. The open-sourcing of the site's system were apart of the Knight News Challenge Program. Everyblock is a very impressive site that aggregates and geocodes local data -- news, crime, fire, restaraunt inspections and reviews - and then lets users define their interests down to the block-level.

Adrian made the announcement on 6/30. Here's the list of newly open-sourced, GPL'd goodies found on Everyblock's new Code page:

The main package (probably the thing you're looking for) is the publishing system, known as ebpub.
Second, the packages ebdata and ebgeo contain Python modules for processing data and making maps.
Third, the packages ebinternal and everyblock round out the code that powers EveryBlock.com. They're internal tools and are likely not of general use, but we're including them to be complete.
Finally, ebblog and ebwiki are our blog and wiki software, respectively. Because, dammit, the world needs another Django-powered blogging tool.

Django fans, Python geohackers and anyone who wants to build a local data aggregator are going to be thrilled. Adrian was one of the co-creators of Django and was one of the first Google Maps Mashup creators.

Everyblock has only launched in major US cities. There's plenty of room in the market for locals to create their own version. Everyblock spends a lot of time curating the incoming data feeds so I doubt that anyone will be able to roll out new sites too quickly. One thing to note: the trademark Everyblock is not available. However, the Everyblock team would not mind being acknowledged if you use their code. Personally I get a lot of value of Everyblock in my city. I get a daily email with all the crime, news and errata near my house.

Everyblock is now going to move onto the second stage of its existence. About five months Adrian blogged about the dilemna they would be facing when they open-sourced their software. As he said at the time:

But now we've reached an interesting point in our project's growth: our grant ends on June 30, and, under the terms of our grant, we're open-sourcing the EveryBlock publishing system so that anybody will be able to take the code to create similar sites. That's a Good Thing, in that EveryBlock's philosophies and tools will have the opportunity to spread around the world much faster than we could have done on our own, but it puts the six of us EveryBlockers in an odd spot. How do we sustain our project if our code is free to the world?

At the time I suggested that they try to federate with new everyblocks. After yesterday's announcement I mailed Adrian to ask him for a hint about their future plans, but for now he's keeping mum.

El primer cable de Ethernet de la história

2009-07-01T18:15:23+00:00

Corría el año 1973 cuando Bob Metcalfe mandó un memo a sus colegas de Xerox en Palo Alto, California, proponiendo un sistema local para que interactuaran las estaciones de trabajo, impresoras y archivos. Pensó que todos los dispositivos estarían conectados a través de un cable coaxial. Lo llamó Ether Network o Ethernet. Tres años más tarde ya había más de 100 dispositivos conectados a esta red local que inclusó se utilizó para probar la primera impresora láser del mundo.

vía Make Magazine

Liberar codigo o no liberar codigo en un proyecto de aplicación web SaaS

2009-07-01T18:15:23+00:00

Por Javi Olmo, fundador del blog TuTecnologo.

Que las aplicaciones web o aplicaciones SaaS están en auge y aumento es innegable. Muchas de ellas están surgiendo para dar servicios de gestión a las empresas a las que generalmente les va costando darles buena acogida (con la excepción de las dedicadas al sector de internet).

Con respecto al SaaS y el FLOSS hay en internet hay un cierto debate interesante. Pero vamos por partes, según la Wikipedia.

El SaaS

Software como Servicio (del inglés: Software as a Service, SaaS) es un modelo de distribución de software en donde la compañía de IT provee el servicio de mantenimiento, operación diaria, y soporte del software usado por el cliente. En otras palabras es tener la información, el procesamiento, los insumos y los resultados de la lógica de negocio del software. En palabras simples: El cliente tiene el sistema hospedado en la compañía de IT.

El FOSS o FLOSS

FOSS, son las siglas, en inglés, de un concepto que designa al “Free and Open Source Software”, es decir, al “Software Libre y de Código abierto“, sin hacer distinciones entre sus diferencias.

FLOSS, es la sigla que identifica, también en inglés, al concepto del “Free/Libre & Open Source Software”, pero haciendo mención a la idea filosofía del Software Libre (Free Software), donde “Free” menciona el concepto de “Libre”, y no la idea del software gratis, de ahí lo de “F/L”, ya que en inglés se tiende a confundir y hasta a trasladarse la confusión al español.

El software gratis, muy cercano al concepto del freeware, que no es software libre, y rara vez es de código abierto, sólo está libre para descargarlo, pero no posee las implicaciones y características del software libre, como tampoco los alineamientos con el movimiento filosófico del código abierto.

El debate se centra en que la mayoría de las aplicaciones de software como servicio se basan y construyen sobre programas y aplicaciones de software libre y código abierto como apache, mysql, php, ruby, etc…

Y por tanto entre algunos sectores no esta bien visto que aplicaciones basadas enteramente en programas open source no liberen su código y sean gratuitas (pero no libres) o incluso que sean de pago.

Para una empresa que desarrolla una aplicación bajo el modelo SaaS y libera su código fuente es un peligro “regalar” su desarrollo y plataforma, porque fácilmente y en poco tiempo le puede salir un competidor haciendo lo mismo o más. Habiendose ahorrado este competidor el tiempo y costes de desarrollo o solo soportando el coste de las mejoras realizadas.

Una opcion valorable es no liberar el código hasta tener un cierto tiempo de vida , de rodaje y por tanto ya una base de clientes. En todo caso si se hace desde el principio, por muy amigable y estándar que sea el código, siempre la empresa que ha desarrollado la plataforma y código es quien mas y mejor lo conoce.

En un artículo reciente Ignacio de Miguel reflexionaba sobre como le gusta que sean las aplicaciones web y otros respecto al lanzamiento (o re-lanzamiento) de dos servicios SaaS Teambox y Documany que han decidido liberar su código desde fases muy tempranas y apostar por tener dos líneas de negocio.

El servicio hosted de uso gratuito, de precio bajo o modelo freemium (gratuito y pago por servicios avanzados premium).
El servicio de instalación y personalización del software en servidores propios de las empresas interesadas.

Y la versión liberada generalmente llamada Comunity para que quien quiera se la instale para usarla o continue desarollando funcionalidades, complementos, mejoras y las aporte a la comunidad open source del proyecto.

Es una estratégia arriesgada y algo disruptiva pero que gestionada inteligentemente puede funcionar y abrir otras vías de modelo de negocio diferentes a la publicidad, etc…

En definitiva ¿A automattic con wordpress no le ha ido tan mal no?

¿Necesitas hosting? en Hostarting podrás comparar los planes de hosting de las principales empresas del país, podrás conocer la opinión y valoraciones de otros usuarios sobre los servicios de hosting que utilizan.

Promociona tu web con BetaBlocks (www.betablocks.com).

Dilbert by Scott Adams - 1 July 2009

2009-07-01T21:08:21+00:00

Reglas obvias en fotografía

2009-07-01T21:08:21+00:00

Tómese con el humor que corresponde: 78 reglas de fotografía para torpes, ilustradas por el fotógrafo Ivars Gravlejs.

Antes de hacer la foto, recuerda quitar la tapa del objetivo.

(Vía Neatorama.)

# Enlace Permanente y Comentarios

01 Jul 2009

2009-07-01T18:15:23+00:00

01 Jul 2009

EVIL

2009-07-01T18:15:24+00:00

EVIL always starts small

u musta bin teh bad twin.

Picture by: Rayn. Caption by: Serena_Sumeragi via Poster Builder

» Recaption This

» See All Captions

La historia de HOTorNOT

2009-07-03T09:10:18+00:00

Allá por el año 2000 apareció una web llamada HOTorNOT. ¿A quién no le ha llegado alguna vez algún correo con un enlace de alguien? O ¿quién no ha pasado aunque sea unos minutos puntuando chicas y chicos? Recuerdo que allá por esas fechas me llegó uno de esos correos y al ver la web pensé, "puf, vaya chorrada, que perdida de tiempo". Pues esa perdida de tiempo se convirtió sin duda en uno de los sitios webs más populares del mundo, derivando posteriormente a un sitio de citas que convirtió a sus creadores en millonarios.

En fin, visionario que es uno, eh :) En Mixergy, un sitio web sobre startups, Andrew Warmer, su fundador, entrevista a uno de los creadores de HOTorNOT, James Hong. La entrevista dura casi hora y media y en ella hablan prácticamente de todo. Si no se os da demasiado bien el inglés hablado, también está la transcripción en el sitio web.

Os dejo aquí unas notillas de lo que a mi me ha parecido más interesante:

Os decía que un sitio para perder el tiempo. Claro, de esos sitios que los programadores pensamos "vaya chorrada, esta parida la hago yo en dos horas". Bueno a ellos les llevó dos días, y consiguieron llegar hasta 7 millones de dólares en ingresos. No está nada mal para una idea chorra.

Nunca quisieron dinero para crecer más. Evitaron el capital de riesgo, no porque fuese malo sino porque ellos no lo veían. Ellos simplemente querían algo que generase constantemente dinero sin buscar aspiraciones más altas.

Nunca tuvieron más de cinco empleados. James define esa como una de las claves. No tenían burocracia ni grandes infraestructuras que mantener. Todo lo que querían hacer lo sacaban rápidamente.

Sus fundadores, vivieron tranquilamente de HOTorNOT durante varios años. Sólo trajeron empleados porque se cansaron del modo de vida, de estar siempre pendientes y pensando en el proyecto.

En 2005, 2006, las cosas cambiaron. Las redes sociales comenzaron a aparecer y el futuro en HOTorNOT parecía mucho más incierto. Los costes eran menores así que decidieron volver, hacer el sitio libre y apuntarse a la moda de las redes sociales, aunque la cosa no funcionó.

Al pasar el sitio a un modelo de negocio free, buscaron monetizar con anuncios. En esos momentos el entusiasmo decreció. James comenta en la entrevista que perdieron la alegría por el proyecto y que tampoco tenían los conocimientos necesarios para moverse en ese mundo. Además, al hacer libre la web, comenzaron a aparecer los spammers y timadores, buscando estafar a la gente con transferencias de dinero. Un problema bastante grande en este tipo de sitio web. En 2008 buscaron un vendedor y vendieron HOTorNOT.

Hablan también de cuando comían allá por el año 2000 con los creadores de YouTube y otras startups conocidas, que coincidían normalmente en la misma cafetería. Todos se conocían y hablaban. A ellos les comentaron la idea de crear un sitio web para compartir videos. Se les ocurrió crearlo pero con un modelo muy poco tradicional para la época, invirtiéndo pero dándole a ellos el 51% de la empresa, ya que no tenían mucho interés en dedicarse a ello. Pero por esa época habían contratado un CEO al que no le gustó la idea de darle ese porcentaje de una compañía a meros empleados... El resto es historia.

MySpace, Friendster, YouTube. Mirando en archive.org las primeras versiones de todos esos sitios web, todos tenían el estilo HOTorNOT. Todos intentaron hacer algo similar cuando salieron pero ninguno lo consiguió. Pero sin embargo, todos consiguieron triunfar con ideas diferentes.

HOTorNOT se defendió de todos estos gigantes al principio consiguiendo que la prensa hablase de ellos. Si la prensa habla de ti, no tiene tiempo para hablar de tus competidores. Nadie quiere hablar de los segundos, y su idea era innovadora y llamba la atención.

Al principio no intentaron ganar dinero hasta que aseguraron el tema de costes. Se buscaron la vida. Por ejemplo los servidores se los pagó RackSpace, a cambio de que ellos les hiciesen publicidad.

Lo que más importa es siempre el producto. A la hora de monetizar HOTorNOT no pensaron demasiado en planes de negocios, no hicieron análisis de precios, ni de la competencia, ni cifras a varios años. Simplemente pensaron como se conoce la gente en los bares, y lo imitaron. ¿Cuánto cuestan dos cervezas? 6 dólares. Ese es el precio de subscripción. Lo paga uno y listo. Con el tiempo, los registros mostraban que casi siempre el que pagaba la subscripción era el hombre. Como en muchos casos, las copas en la vida real.

La clave de su éxito, la facilidad de uso. HOTorNOT se usa con un click. Todo mascado y sencillo. Hacerle fácil la vida al usuario.

No está nada mal para una "chorrada"!!! Yo voy a ver si se me ocurre alguna, que ya va siendo hora :)

Discutir la nota

2009-06-30T17:07:03+00:00

Me encuentro con un buen post en minimalart que bien vale la pena compartir.

Diego: Buenas noches profesor
Profesor: Buenas noches Ramirez
Diego: Profesor, quería ver con usted mi nota…
Profesor: Ah si, hubo un error cuando la cargaron en la página.
Diego: Ah, me imaginaba. Que me saqué?
Profesor: Un 2
Diego: Cómo un 2!!??
Profesor: Y.. si. Un 2 Ramírez. Su evaluación no estaba nada bien.
Diego: Pero no puede ser! Si yo hice todo lo necesario! Mi evaluación no merece menos que un 10
Profesor: Un 10 !!! ?? Usted no sabe lo que dice..
Diego: No profesor. Y se lo puedo demostrar. Mire, ve mi tarjetita: dice “Gerente de Desarrollo”. Y al otro lado dice “psicofxp.com” Sabe lo que significa?
Profesor: No, la verdad que no. Pero eso no cambia el 2 que se sacó.
Diego: No, no, no. Usted no está teniendo en cuenta que yo trabajo en una “punto-com”. Eso cambia todo
Profesor: No veo en que puede cambiar…
Diego: Espereme un segundo. Vamos a revisarla juntos, analicemos todos los puntos, cuantifiquemos el total de las consignas sugeridas, evaluemos cuanto tiempo usted nos dio para hacer el examen, y cuanto en realidad podía hacer yo. Y ahi llegamos al primer indicador
Profesor: Qué indicador Ramírez? Usted tenía 8 ejercicios, e hizo 4. Y todos mal. El 2 en realidad se lo estoy regalando.
Diego: Bueno, ve: hice 4 ejercicios porque cuantifiqué que en este sprint no podía hacer más. La semana que viene, en el próximo sprint hago los otros 4
Profesor: Ramirez, disculpeme pero no le entiendo.. Usted sugiere que está bien que hiciera 4 puntos, cuando todo el mundo hizo 8?
Diego: Por supuesto. Miré: 8 puntos era el product backlog, pero en este sprint solamente podían entrar 4. Como soy proactivo hice mi propia estimación. Ahi ya tengo un punto.
Profesor: Usted está loco… y de todas formas, aunque aceptara que solo hiciera 4, los 4 están mal.
Diego: Porqué mal? Fijese el primer ejercicio: “Ingresar las edades de 10 personas, determinar el máximo, el mínimo y el promedio de edad. Imprimir los 3 resultados”
Profesor: Usted solamente hizo el calculo y la impresion. No hizo el ingreso de datos.
Diego: Claro, porque este calculo es invocado por un ajax que le pasa los parametros. El ejercicio está perfecto. Ahi ya van dos puntos.
Profesor: Ramirez usted me está tomando el pelo?
Diego: Para nada Profesor. Veamos el siguiente ejercicio: “Generar una matriz de 4×4 con los numeros de 1 a 16?
Profesor: Acá dejó un espacio vacio.
Diego: Pero claro: esta es la vista del HTML. Pero la tabla la dibuja el CSS
Profesor: Que!!? Y los datos?
Diego: Los escribe el JQuery!
Profesor: Ramirez, estoy a punto de perder la paciencia…
Diego: Eso por lo menos fueron dos puntos más y van 4. Que sigue? Ah, si: “Comprobar que un numero de DNI sea correcto”.
Profesor: Y usted solamente puso una direccion de pagina web
Diego: Error. Yo puse una invocación a un webservice del anses que me devuelve true o false. Un punto más.
Profesor: Ramirez, estoy a punto de expulsarlo de mi clase
Diego: Profesor, ya terminamos: Miremos el ultimo ejercicio: “Realice un programa que solicite nombre y apellido e imprima el resultado”
Profesor: Ramirez: usted dibujo tres cuadraditos.
Diego: Son los dos campos del formulario, y el botón Submit
Profesor: Y la lógica!?
Diego: Obviamente no está acá! Usted no oyó hablar del patrón MVC. Bueno, esta es la Vista. El modelo y el controlador lo hizo mi compañero, que es del otro team.
Profesor: Qué compañero? Que team? De que me habla?!!
Diego: Que yo dividi las tareas con mis compañeros para poder terminar el sprint. Encima hice su trabajo de Scrum Master. Por lo menos dos puntos más me merezco por eso.
Profesor: Ramirez, suponiendo que acceda a todas sus locuras, está llegando a un 6. Y usted sabe que se aprueba con 7
Diego: Pero usted se está olvidando que el examen valida, no vio que le puse “This exam is XHTML 1.0 valid” Ahi tengo un punto más.
Profesor: Pero…
Diego: Y además, antes de entregarlo hice una copia para llevarme, con lo cual está commiteado en el versionador. Otro punto. Si sumamos que el examen no ocupa más de media carilla, quiere decir que está minificado. Otro punto más. Y finalmente antes de irme puse en Twitter y en Facebook “Acabo de terminar un examen de Programacion. Me voy a comer una pizza y ver Lost. Hasta mañana followers!”. Eso por supuesto, me suma otro punto y llego al 10
Profesor: Ramirez, sabe qué? Me hartó. Le voy a poner el 10 solamente para que se calle y se siente. Total esto es una universidad privada, así que poco importa si usted aprende o no.
Diego: Gracias Profesor, pero no me ponga un 10. Mejor pongame un 9 y en la parte superior de mi examen pongame un circulito pintado de verde manzana que diga “Beta”. Asi todos piensan que queda algo por mejorar.

Wikipedia censura artículo para salvar a periodista

2009-06-30T05:58:52+00:00

Jimmy Wales, de nuevo en medio de la polémica (cc) Wikimedia

La censura en Wikipedia es un tema delicado, pues si bien varios de nosotros tomamos una postura del estilo “todo, absolutamente todo se debe conocer”, la verdad es que en muchas ocasiones la decisión no es tan directa, y este fue justamente el caso que se dió sobre el artículo de David Rohde, periodista del New York Times que trabajaba en Afghanistan cuando fue capturado el 10 de noviembre pasado por el Talibán.

El Times, sabiendo que la notoriedad pública sólo aumentaba el riesgo que Rohde fuera ejecutado, decidió contactar a todos los medios tradicionales para evitar que la noticia fuera conocida por el público, algo que no es especialmente difícil al tener que lidiar sólo con los editores en jefe de cada publicación, pero el caso de Wikipedia fue mucho más complejo, pues la enciclopedia virtual no tiene “un puñado” de editores, sino más bien miles.

Como solución a este problema, el periódico decidió trabajar en conjunto con Jimmy Wales (co-fundador de Wikipedia) y algunos de los administradores del sitio, para que un grupo del Times se dedicara a mantener el artículo de Rohde libre de la mención de su captura por meses, librando las llamadas “edit wars” (Guerras de edición) entre lo usuarios que de una u otra forma habían escuchado de la noticia de Rohde (agregando la información al artículo) y aquellos que conocían las intenciones del Times (revirtiéndolo a su estado anterior), resultando en más de una discusión y dedos apuntándose.

Finalmente la historia tuvo un final feliz, pues este mes Rohde logró escapar del Talibán, con lo que el plan de censura pudo ser desarticulado, e incluso expuesto por el propio Times, pero a algunos aún les queda un sabor algo amargo, ¿acaso esto se podría repetir con fines menos benevolentes?.

Link: Keeping News of Kidnapping Off Wikipedia (The New York Times)

En la tienda de informática

2009-06-29T18:19:20+00:00

¿Qué tipo de ordenador tienes? Y por favor, no me digas que uno blanco…

– Sheldon (The Big Bang Theory)

Tutorial de Git in RubyLit - Ruby.del.litoral!

2009-06-27T02:37:08+00:00

GENIO Y FIGURA DE MICHAEL JACKSON

2009-06-26T21:34:18+00:00

TMZ, el pequeño que se merendó a los grandes

2009-06-26T21:34:18+00:00

No fue la CNN, ni The 'New York Times', ni 'Los Angeles Times'. La noticia de la muerte de Michael Jackson, y poco antes de su ataque cardíaco, llegó primero a través de un medio digital pequeño pero consolidado en el mundo del espectáculo: TMZ.com. De ahí corrió como la pólvora por blogs y sitios como Twitter o Facebook hasta que la misma página web confirmó el fallecimiento. Los grandes medios -e incluso las agencias- que no quisieron quedarse atrás no tuvieron más remedio que citar su información. Leer

La muerte de Michael Jackson en Internet

2009-06-26T21:34:18+00:00

Los números de como replicó la muerte de Michael Jackson en Internet son impresionantes; según el LA Times Twitter duplicó su nivel de tweets y Facebook triplicó su nivel de posts; y los sitios de noticias tuvieron un pico de 3 millones de usuarios por minuto. En The Guardian muestra como MJ y sus keywords robaron todo Twittscoop y 9 de 10 topic trends de Twitter!, que a su vez tuvo que cerrar el buscador que fue tan grave como Google Maps pidiendo perdon por hacer chistes y, finalmente, TechCrunch mostrando como la competencia se benefició de la caída de TMZ que fue el primero en confirmar y tenía razón :)

(CC) mariano for Denken Über, 2009. | Permalink | 10 comentarios | Sumalo a: del.icio.us
Post tags: Michael Jackson, twitter, Web 2.0

Feed enhanced by Better Feed from Ozh

5 cosas que el iPhone 3GS aún no resuelve

2009-06-26T21:34:18+00:00

Five things missing from the iPhone 3GS. Sin contar lo de la cámara, dudo que Apple (como la empresa cerrada que es) vaya a resolver los otros puntos. Odio que aún no puedan transferir archivos con tan solo conectarlo al USB ¬¬

Presentation Files: Velocity 2009 - O'Reilly Conferences, June 22 - 24, 2009, San Jose, CA

2009-06-25T20:20:00+00:00