Unas 72 asociaciones se unieron y proponen apagar la luz hoy por cinco minutos en toda la Tierra. Qué los llevó a tomar esta decisión para concientizar sobre la importancia de cuidar la energía
El grupo Alianza por el Planeta, que reúne a 72 asociaciones ambientalistas mundiales, propuso para el próximo jueves un apagón de cinco minutos en contra del derroche de energía. Agrupaciones de todo el mundo discuten la efectividad de la medida.
La Alianza por el Planeta llamó a las personas de todo el mundo a apagar entre las 19.55 y las 20 horas la luz. La propuesta, de acuerdo a lo indicado por la prensa europea, no pretende ahorrar energía, sino concientizar sobre la necesidad de usar la cantidad que sea necesaria.
El diario español 20 Minutos brindó 10 motivos por los cuales es importante unirse a la protesta:
* Los incendios
* Aumento del deshielo y del nivel del mar
* Reducción de la capa de ozono
* Subida de las temperaturas
* Pérdida de productividad de las cosechas
* Aumento de muertes
* Extinción de especies
* Mayor virulencia de fenómenos naturales
* Reducción de la productividad de las aguas marinas, y por tanto, de la pesca
* Adelanto de la hora del fin del mundo
Fuente: INFOBAE.
2007/08/04
¿Quién sube contenidos a las redes P2P?
Interesante tema al que llego a través de la Chica de la tele, y que viene a demostrar cómo las empresas de contenidos están jugando un papel activo en la llegada de sus propias producciones a las redes P2P: un ejecutivo de Warner TV confiesa haber sido él quien filtró el episodio piloto de Pushing Daisies al hijo de su vecino, un consumado usuario de redes P2P, con la intención de que llegase a dichas redes y beneficiarse de la difusión correspondiente (vía Boing Boing y AllYourTV). Indudablemente, en el caso de un episodio piloto de una serie que se está buscando promocionar, el efecto positivo de la difusión del mismo en las redes P2P resulta evidente, pero resulta interesantísimo ver la implicación directa de los estudios en el uso de la misma herramienta que insisten en demonizar, y hacerlo, además, con toda la doble moral habitual en estos casos: una política de tipo “que alguien lo haga, pero que no se lo cuente a nadie”.
Las declaraciones del ejecutivo en cuestión no dejan lugar a dudas:
“Well….to be specific, I didn’t upload it myself. But my neighbor’s kid loves swapping files through Usenet and Bittorrent sites. Actually, we’ve had a bit of an argument about it before. But I wanted to make sure the show got out there, and I didn’t see why I couldn’t help the cause. And (name withheld) was happy to do it, because he got a lot of…some kind of uploading credit. It allowed him to download other stuff he wanted.”“Bueno… siendo preciso, no lo subí yo mismo. Pero el hijo de mi vecino adora compartir ficheros a través de Usenet y BitTorrent, algo sobre lo que hemos tenido discusiones anteriormente . Pero quería estar seguro de que el show llegaba ahí, y no vi porqué no podía ayudar a la causa. Y (nombre eliminado) estuvo encantado de hacerlo, porque así conseguía… cierto tipo de créditos por subida que le permitían bajarse otras cosas que quería. “
Y también resulta evidente la política del estudio al respecto:
My boss? Oh, God no. I mean… it’s a bit like the military’s ‘Don’t’ Ask Don’t Tell’ rule. I think a lot of people think in theory that getting a show out there ahead of time is a good idea (…) But it’s not like anyone I know would admit to that while they’re on the clock, and it’s not even something you would bring up seriously as a suggestion.”
¿Mi jefe? Oh, Dios, no. Quiero decir… es un poco como la regla de los militares, ‘no preguntes, no lo cuentes’. Creo que un montón de gente piensa en teoría que sacar un show ahí fuera antes de tiempo es una buena idea (…) Pero no es algo que nadie que conozca admitiría abiertamente, ni siquiera algo que llegarías a sugerir seriamente.”
Más claro, agua. Por un lado, se demoniza a los usuarios y a las redes P2P por ser la gran amenaza para el negocio, por otro se las utiliza como medio de promoción para sus productos. ¿Con qué cara van a ir ahora a os tribunales a denunciar a los usuarios por incurrir en un comportamiento que ellos mismos inician desde dentro?
Fuente: El Blog de Enrique Dans.Suprnova.org resucita gracias a The Pirate Bay
A finales del 2004, el sitio BitTorrent Suprnova.org, el rey de los primeros rastreadores BitTorrent, cerró sus puertas por una disputa legal con la MPAA y la creciente presión del grupo anti-piratería francés RetSpan. Casi tres años después, un acuerdo entre los operadores de The Pirate Bay y el dueño original de Suprnova.org, Andrej Preston, ha pavimentado el camino para su resurrección.
“El dominio no estaba haciendo nada, yo se que el dominio tiene algo de valor nostálgico y algunas personas estarán mas que felices de que este en línea otra vez. Yo no lo uso, y TPB es el único equipo que se que lo usará correctamente,” dijo Andrej Preston (alias Sloncek).
Bajo el acuerdo, Sloncek se mantendrá activo en el nuevo sitio a través de los foros que serán hosteado bajo un dominio aparte. Es mas, Andrej Preston acordó con The Pirate Bay que el nuevo Suprnova se mantendrá fiel a su diseño original.
Junto con el relanzamiento de Suprnova, que se limitará a la indexación de torrents más que al rastreo de estos, The Pirate Bay también anuncio SuprBay.org, una nueva comunidad que estará enlazada tanto a Suprnova como a The Pirate Bay. Suprnova estará listo y funcionando la próxima semana.
Fuente: TechSpot.
“El dominio no estaba haciendo nada, yo se que el dominio tiene algo de valor nostálgico y algunas personas estarán mas que felices de que este en línea otra vez. Yo no lo uso, y TPB es el único equipo que se que lo usará correctamente,” dijo Andrej Preston (alias Sloncek).
Bajo el acuerdo, Sloncek se mantendrá activo en el nuevo sitio a través de los foros que serán hosteado bajo un dominio aparte. Es mas, Andrej Preston acordó con The Pirate Bay que el nuevo Suprnova se mantendrá fiel a su diseño original.
Junto con el relanzamiento de Suprnova, que se limitará a la indexación de torrents más que al rastreo de estos, The Pirate Bay también anuncio SuprBay.org, una nueva comunidad que estará enlazada tanto a Suprnova como a The Pirate Bay. Suprnova estará listo y funcionando la próxima semana.
Fuente: TechSpot.
2007/08/03
Videos de Starcraft 2 en formato DivX
Es decir videos de alta resolucion, disponibles en la pagina de Starcraft 2, de la Worldwide Invitational 2007, entre estos videos puedes ver:
- Presentación de Mike Morhaime
- Retrospectiva Blizzard
- Presentación del trailer por Mike Morhaime
- Trailer cinemático
- Demonstración del juego por parte de Dustin Browder
- Presentación del trailer sobre graficos por Dustin Browder
- Vídeo con ilustraciones
Tambien se pueden ver:
- Vídeo de juego (1280 x 720) de 647 MB.
- Vídeo de juego (720 x 404) de 268 MB.
- Trailer cinemático de 69.4 MB.
- Vídeo con ilustraciones de 27.6 MB.
Pronto habran novedades de las unidades Zerg.
- Presentación de Mike Morhaime
- Retrospectiva Blizzard
- Presentación del trailer por Mike Morhaime
- Trailer cinemático
- Demonstración del juego por parte de Dustin Browder
- Presentación del trailer sobre graficos por Dustin Browder
- Vídeo con ilustraciones
Tambien se pueden ver:
- Vídeo de juego (1280 x 720) de 647 MB.
- Vídeo de juego (720 x 404) de 268 MB.
- Trailer cinemático de 69.4 MB.
- Vídeo con ilustraciones de 27.6 MB.
Pronto habran novedades de las unidades Zerg.
Demanda por sexo: Esta vez le tocó a Johanna Cardona
A raiz de la noticia de la difusion del video sexual de la presentadora Johanna Cardona le di una mirada a Technorati ( buscando johanna cardona) al respecto...
Lo escandalos sexuales (y si hay material multimedia de por medio) son los que en la actualidad tienen mas demanda Internet... Rapidamente aparecen las personas que estan buscandolo en descarga directa.
Lo escandalos sexuales (y si hay material multimedia de por medio) son los que en la actualidad tienen mas demanda Internet... Rapidamente aparecen las personas que estan buscandolo en descarga directa.
Un Ipod transformado en un portátil. Se llama Itop según su creador
¿Y qué pasa cuando se te rompe el Ipod y no hay manera de arreglarlo? ¿Lo tiras a la basura? ¿Lo usas como pelota y lo lanzas por los aires? o… ¿Eres creativo y lo conviertes en un mini portátil que funciona con linux?
Pues fue precisamente lo que hizo Owen McGarry tras romper un poco su pantalla del Ipod y con esto, no poder hacer valida la garantía del aparato de apple. Y entonces, medio frustrado e indeciso pensó: ¿Por qué no me divierto un poco antes de que se muera el Ipod completamente? Y así fue…
Fuente original: Owen McGarry
Imagen del Itop: Ipod - Itop
El tiempo libre que este chico debe de tener para hacer algo tan radical como esto (por radical quiero decir sensacional), además de imaginación y destreza, ya que no cualquiera se atrevería a sacrificar su Ipod en pro de la experimentación, aunque si Ipod estuviera agonizando…
Esperamos luego tener más noticias de los avances del ya famoso Itop…
Fuente: portafolio en mano.
Pues fue precisamente lo que hizo Owen McGarry tras romper un poco su pantalla del Ipod y con esto, no poder hacer valida la garantía del aparato de apple. Y entonces, medio frustrado e indeciso pensó: ¿Por qué no me divierto un poco antes de que se muera el Ipod completamente? Y así fue…
El osado Owen, partió un poco más la pantalla del Ipod hasta dejarla como se ve en las imágenes y además hizo varios ajustes a los cacharritos internos para que funcionara de acuerdo a sus necesidades. Le instaló Linux y, a pesar de que algunos cables eran demasiado cortos se las ingenió para alternarlos y hacerlos funcionar. En su blog nos dice que seguirá ensamblandole cosas, botones y más utensilios para hacerlo más fácil de usar…
Fuente de referencia: Ounae.comFuente original: Owen McGarry
Imagen del Itop: Ipod - Itop
El tiempo libre que este chico debe de tener para hacer algo tan radical como esto (por radical quiero decir sensacional), además de imaginación y destreza, ya que no cualquiera se atrevería a sacrificar su Ipod en pro de la experimentación, aunque si Ipod estuviera agonizando…
Esperamos luego tener más noticias de los avances del ya famoso Itop…
Fuente: portafolio en mano.
El único punto débil del soldado del futuro es que podría ser 'hackeado'
Los norteamericanos suelen ir pensando en las guerras venideras bastante antes que el resto del mundo. La revista eWeek cuenta que durante una ponencia de la conferencia anual de seguridad informática Black Hat, Richard Clarke, asesor de seguridad nacional presidencial durante 30 años, expresó su preocupación por la baja calidad de la seguridad en Internet de cara a los proyectos del Pentágono para diseñar al soldado del futuro.
Clarke describió una guerra en la que soldados enfundados en potentes exoesqueletos mecánicos repletos de cámaras que les alertarían de cualquier movimiento a su alrededor, serían capaces de mover pesos impensables gracias a servomotores integrados en su armadura. El "sistema de armas" de cada soldado se organizaría a partir de varias IPs y sería coordinado en red desde su cuartel general. Y ese sería su punto débil.
"No tengo que contaros a vosotros el caos que vivimos a diario en Internet, señaló Clarke a su auditorio de expertos informáticos y hackers de todos los pelajes. El Pentágono está preocupado por la falta de seguridad que entrañan los protocolos actuales de Internet y por su capacidad para gestionar una cantidad mayor de IPs simultáneamente. Por esta razón, los militares norteamericanos se cuentan entre los más firmes partidarios del desarrollo de la próxima generación de Internet, la IPv6, que tendría una capacidad mucho mayor para gestionar Ips.
Al igual que con el desarrollo de la propia Red, una vez más es la industria militar la impulsora de los avances científicos.
Fuente: El Pais.La televisión que te espía
Vía Chica de la tele llego a estas notas en TV Squad y en Techdirt en las que se reseña una patente de Microsoft que pretende, mediante el uso de sensores biométricos, cámaras y otras herramientas, ser capaz de determinar si estás realmente sentado delante de la televisión ejerciendo de couch potato, o si lo están cualquier otra persona identificable dentro del domicilio, con el fin de poder servirles anuncios orientados a cada caso. El razonamiento detrás de la idea es que, ante la creciente difusión de aparatos de tipo PVR que permiten ver los contenidos cuándo y cómo quieras y, además, saltándote los anuncios, resulta fundamental para los anunciantes obtener datos en tiempo real que reflejen cuantas personas se encuentran en un momento dado consumiendo un contenido, para poder determinar la audiencia exacta y plantear mecanismos de contextualización de la publicidad que proporcionen un rendimiento superior en términos de cualificación de la audiencia.
Fuente: Blog de Enrique Dans.
El texto de la patente es completamente para echarse a temblar: según Microsoft, la idea sería extender el método a teléfonos móviles y monitores de ordenador, y vincular los registros obtenidos con fuentes adicionales de datos personales. Por un lado, intereses, aficiones, sexo, edad, localidad, profesión, suscripciones, pertenencias a asociaciones o clubs, raza, estado civil, número de hijos, posesión de mascotas, peso, altura y datos similares. Por otro, combinarlo con otros datos personales extraídos de la libreta de direcciones, calendario, correo electrónico, mensajería instantánea, listas de tareas, notas, historial de compras, reacciones ante la publicidad, historial de búsquedas y consumo de medios. Con semejante perfil, siempre según el texto de la patente, se podrían ofrecer anuncios altamente dirigidos y diseñados específicamente para las preferencias de la persona que se encuentra delante del aparato. Leer completo el texto de la patente y, sobre todo, los detallados ejemplos que propone, nos lleva a un escenario completamente orwelliano, desde mi punto de vista, aterrador. Un detalle:
Another 3D object 606 is an advertisement for flowers. The advertisement was generated from advertiser data that instructs synthesis system 202 how to create a photorealistic bouquet. Tracking system 204 has generated additional data that personalizes the advertisement with the message “A beautiful bouquet for Julie’s birthday tomorrow?” and instructions that synthesis system 202 uses to animate the bouquet and the message. In this example, tracking system 204 has been triggered to present this advertisement because the weighted combination of the following tracked information monitored by tracking system 204 has been evaluated and found to exceed the relevancy threshold: (a) tomorrow is Julie’s birthday, which is noted in the calendar of the person viewing the display, (b) flowers were sent on previous birthdays according to the person’s purchase history, and (c) the tracking system 204 stores a frequent-customer virtual punch-card. Even though this advertisement is unrelated to with the media content being watched, the weighted combination of the tracked information is sufficiently high to trigger tracking system 204.
De acuerdo con los estándares de la defensa del derecho a la privacidad, un sistema de este tipo resulta directamente aberrante y absurdo. Pero claro, ¿cuántos anunciantes estarían dispuestos a utilizar un sistema como éste pagando un premium derivado de la altísima calidad de los impactos, dando lugar a ingresos que la empresa podría administrar como incentivo a la audiencia para que aceptasen tener instalado un sistema semejante? ¿Cuántas personas aceptarían vender su privacidad a cambio de una cantidad determinada al mes? A mí, particularmente, el simple hecho de que una empresa solicite una patente así, aunque por el momento sea tan solo una solicitud, me pone enormemente nervioso. Pensar en un aparato de televisión que me espía, que determina si estoy delante o no y que combina mis datos con todos los servicios de mi ordenador me parece un escenario directamente demencial. Pero claramente, a los nueve investigadores de Microsoft que han solicitado la concesión de la patente, no se lo parece. Las conclusiones, que las extraiga cada uno.
Fuente: Blog de Enrique Dans.
10 desarrolladores por el precio de uno
En el libro "The Mythical Man-Month", Fred Brooks señala una asombrosa disparidad de producción entre los buenos y los malos programadores.
Los encargados de programación han reconocido amplias variaciones de productividad entre los buenos programadores y los malos. Pero las magnitudes medidas han asombrado a todos nosotros. En uno de sus estudios, Sackman Erickson y Grant midieron el rendimiento de un grupo de programadores con experiencia. En este grupo los ratios entre los mejores y peores rendimientos fue sobre 10:1 en medidas de productividad y 5:1 en medidas de velocidad de programación y espacio requerido.
Robert Glass cita la investigación que pone esta disparidad más de manifiesto en su libro "Facts and Fallacies of Software Enineering".
Los mejores programadores son hasta 28 veces mejores que los peores programadores, de acuerdo a la investigación "diferencias individuales". Dado que su pago no es comensurado, son los mayores negocios en el campo del software.
En otras palabras, los mejores desarrolladores a menudo están mal pagados mientras que los peores son los que mejor pagados están.
Pero no abandones tu trabajo ahora. Con esto no quiero decir que deba haber una relación 1:1 entre productividad y pago. Las personas deberían ser pagadas por el valor que traen y la productividad, aunque no lo es todo, es una parte importante. Incluso podríamos esperar ver bastante correlación en el pago con una diferencia drástica de productividad. Pero en general, no lo hacemos. ¿Por qué?
Porque la mayoría de los encargados de programación no creen esta disparidad de productividad a pesar de la comprobación repetida por múltiples estudios. ¿Por qué permiten que los hechos se ajusten a sus creencias? eso sólo puede significar que los factonistas han ganado.
Bromas aparte, ¿por qué es tan difícil de creer esta diferencia de productividad? permítame poner palabras en la boca de un mal encargado de programación:
"¿Cómo un desarrollador puede escribir código 28 veces más rápido que otro desarrollador?"
Este tipo de pensamiento representa una falacia común cuando medimos la productividad de un desarrollador. La productividad no es el número de líneas de código. Una enorme pila de código que no hace bien el trabajo no es productiva. Hay muchos aspectos que influyen en la productividad de un desarrollador, pero todos están gobernados por un principio (tomemos prestado un término de la industria de finanzas): TCO.
TCO (Coste total de la propiedad)
En general siempre he tratado de contratar a los mejores programadores que puedo encontrar. Pero he cometido errores anteriormente. Si, incluso yo.
Una situación que me viene a la mente con un desarrollador que contraté (debo añadir que bajo mucha presión) para una empresa anterior. Le di trabajo a este compañero para que asumiera el control del proyecto. Al cabo de unos pocos días no se nada de esta persona, así que suopngo que las cosas están marchando bien.
Al cabo de otros pocos días me dejo caer por allí para ver como marcha el proyecto y el desarrollador me comenta que no comprende algunos requisitos y ha estado intentando comprenderlo todo este tiempo.
Los buenos desarrolladores toman la propiedad de forma que no tengas que hacerlo tú
Este es uno de los primeros aspectos en los que los buenos desarrolladores son más productivos que los desarrolladores mediocres. Ellos toman la propiedad del proyecto. En vez de gastar una semana dándole vueltas a un requisito que no comprenden, los buenos desarrolladores se comunican con el que toma las decisiones y sacan cosas en claro.
De forma similar, un buen desarrollador no requiere que lo supervises a cada momento para asegurarse de que está progresando. Si se encuentran con un problema que le trae complicaciones irá a tí o a sus compañeros de trabajo y resolverán el problema.
Un desarrollador que puede escribir código rápidamente, pero no toma la propiedad de sus proyectos no es muy productivo porque acaba desperdiciando TU tiempo.
Los buenos desarrolladores escriben código con menos bugs
Una vez trabajé con un desarrollador elogiado por mi jefe por ser extremadamente rápido escribiendo código. Seguro que era rápido! tambien lo era introduciendo errores en el código. Su código era lento y difícil de entender.
La medida clave que no fue tenida en cuenta en su productividad fue la cantidad de productividad perdida para intentar reproducir los errores que este desarrollador introdujo en su código, junto al tiempo gastado arreglando esos errores por este u otros desarrolladores.
Todo el mundo centró sus esfuerzos en terminar la tarea, pero no en el coste total de propiedad de ese código. El código no está terminado cuando un desarrollador dice que está terminado. No es ese el momento de parar el cronómetro. Lo es cuando el equipo de calidad dice que el proyecto está completado temporalmente.
Como me gusta decir, la productividad no es la velocidad. Tiene que ver con ella. Puedes ser rápido, pero si vas en la dirección equivocada no estás ayudando a nadie.
Los buenos desarrolladores escriben código fácil de mantener
De común acuerdo escribiendo menos errores es escribir código entendible y mantenible. Tan pronto como una línea de código es escrita, estás realizando el mantenimiento de ese trozo de código.
El código que es frágil y difícil de cambiar desperdicia horas y horas de ciclos de desarrollo cuando tratamos de enmendar un sistema con actualizaciones y nuevas funcionalidades. Escribiendo código mantenible, un buen desarrollador puede hacer estos cambios de forma más rápida y mejorando también la productividad de los miembros de su equipo que más tarde tienen que trabajar con ese código.
Los buenos desarrolladores hacen más con menos código
Otra característica de un buen desarrollador es que sabe cuando no hay que escribir código. Como siempre me dice un amigo:
"¿Por qué construir lo que puedes comprar? ¿Por qué comprar lo que puedes tomar prestado? ¿Por qué tomar prestado lo que puedes robar?"
Con unas pocas excepciones, el síndrome NIA (no inventado aquí) es un asesino patológico de la productividad. He visto a desarrolladores empezar a escribir su propio entorno de formularios de validación hasta que señalo que hay uno hecho actualmente en ASP.NET que hace el trabajo (no es perfecto, pero es mejor que el que vi que se estaba escribiendo).
Todo ese tiempo desperdiciado reinventando la rueda es desperdiciado porque alguna otra persona ha escribo el código para tí. Y en muchos casos, hizo un mejor trabajo ya que se centraba concretamente en ese objetivo. En una situación de este tipo, encontrar una librería que hace el trabajo puede proveernos de un gran impulso para la productividad.
La advertencia en este caso es ser cuidadoso para evitar rígidas y no extensibles librerías ajenas, especialmente para requisitos muy especializados. Puedes gastar mucho tiempo intentando meter a una mascota redonda en una caja cuadrada.
Incluso cuando debes inventar, los buenos desarrolladores tienden a escribir menos código (pero de forma legible) que hace más. Por ejemplo, en vez de construir una máquina de estados que analice texto de una cadena grande, un buen desarrollador puede usar una expresión regular (de acuerdo, algunos dirán que una expresión regular no es legible. Incluso más legible que cientos de lineas de código de análisis de texto).
Vuelta a TCO
Cada una de estas características que he listado mantienen el coste total de propiedad bajo en un buen desarrollador. Por favor, no dejes que el término propiedad te distraiga. A lo que me refiero es al coste de la empresa de tener un desarrollador así en nómina.
Escribiendo menos código que haga más, y escribiendo código mantenible que tiene menos errores, un buen desarrollador elimina presión al departamento de calidad, trabajadores y encargados, incrementando la productividad de todos. Por esto es por lo que expresiones como "28 veces más productivo" son posibles y pueden incluso parecer bajas cuando lo consideras desde un más alto nivel.
Esperamos que la visión de esta perspectiva convenza a encargados de que los buenos desarrolladores realmente son tan productivos como muestran los estudios. Negociar un incremento de pago 28 veces superior es un ejercicio que dejamos al lector.
Fuente: turbia.net.
Los encargados de programación han reconocido amplias variaciones de productividad entre los buenos programadores y los malos. Pero las magnitudes medidas han asombrado a todos nosotros. En uno de sus estudios, Sackman Erickson y Grant midieron el rendimiento de un grupo de programadores con experiencia. En este grupo los ratios entre los mejores y peores rendimientos fue sobre 10:1 en medidas de productividad y 5:1 en medidas de velocidad de programación y espacio requerido.
Robert Glass cita la investigación que pone esta disparidad más de manifiesto en su libro "Facts and Fallacies of Software Enineering".
Los mejores programadores son hasta 28 veces mejores que los peores programadores, de acuerdo a la investigación "diferencias individuales". Dado que su pago no es comensurado, son los mayores negocios en el campo del software.
En otras palabras, los mejores desarrolladores a menudo están mal pagados mientras que los peores son los que mejor pagados están.
Pero no abandones tu trabajo ahora. Con esto no quiero decir que deba haber una relación 1:1 entre productividad y pago. Las personas deberían ser pagadas por el valor que traen y la productividad, aunque no lo es todo, es una parte importante. Incluso podríamos esperar ver bastante correlación en el pago con una diferencia drástica de productividad. Pero en general, no lo hacemos. ¿Por qué?
Porque la mayoría de los encargados de programación no creen esta disparidad de productividad a pesar de la comprobación repetida por múltiples estudios. ¿Por qué permiten que los hechos se ajusten a sus creencias? eso sólo puede significar que los factonistas han ganado.
Bromas aparte, ¿por qué es tan difícil de creer esta diferencia de productividad? permítame poner palabras en la boca de un mal encargado de programación:
"¿Cómo un desarrollador puede escribir código 28 veces más rápido que otro desarrollador?"
Este tipo de pensamiento representa una falacia común cuando medimos la productividad de un desarrollador. La productividad no es el número de líneas de código. Una enorme pila de código que no hace bien el trabajo no es productiva. Hay muchos aspectos que influyen en la productividad de un desarrollador, pero todos están gobernados por un principio (tomemos prestado un término de la industria de finanzas): TCO.
TCO (Coste total de la propiedad)
En general siempre he tratado de contratar a los mejores programadores que puedo encontrar. Pero he cometido errores anteriormente. Si, incluso yo.
Una situación que me viene a la mente con un desarrollador que contraté (debo añadir que bajo mucha presión) para una empresa anterior. Le di trabajo a este compañero para que asumiera el control del proyecto. Al cabo de unos pocos días no se nada de esta persona, así que suopngo que las cosas están marchando bien.
Al cabo de otros pocos días me dejo caer por allí para ver como marcha el proyecto y el desarrollador me comenta que no comprende algunos requisitos y ha estado intentando comprenderlo todo este tiempo.
Los buenos desarrolladores toman la propiedad de forma que no tengas que hacerlo tú
Este es uno de los primeros aspectos en los que los buenos desarrolladores son más productivos que los desarrolladores mediocres. Ellos toman la propiedad del proyecto. En vez de gastar una semana dándole vueltas a un requisito que no comprenden, los buenos desarrolladores se comunican con el que toma las decisiones y sacan cosas en claro.
De forma similar, un buen desarrollador no requiere que lo supervises a cada momento para asegurarse de que está progresando. Si se encuentran con un problema que le trae complicaciones irá a tí o a sus compañeros de trabajo y resolverán el problema.
Un desarrollador que puede escribir código rápidamente, pero no toma la propiedad de sus proyectos no es muy productivo porque acaba desperdiciando TU tiempo.
Los buenos desarrolladores escriben código con menos bugs
Una vez trabajé con un desarrollador elogiado por mi jefe por ser extremadamente rápido escribiendo código. Seguro que era rápido! tambien lo era introduciendo errores en el código. Su código era lento y difícil de entender.
La medida clave que no fue tenida en cuenta en su productividad fue la cantidad de productividad perdida para intentar reproducir los errores que este desarrollador introdujo en su código, junto al tiempo gastado arreglando esos errores por este u otros desarrolladores.
Todo el mundo centró sus esfuerzos en terminar la tarea, pero no en el coste total de propiedad de ese código. El código no está terminado cuando un desarrollador dice que está terminado. No es ese el momento de parar el cronómetro. Lo es cuando el equipo de calidad dice que el proyecto está completado temporalmente.
Como me gusta decir, la productividad no es la velocidad. Tiene que ver con ella. Puedes ser rápido, pero si vas en la dirección equivocada no estás ayudando a nadie.
Los buenos desarrolladores escriben código fácil de mantener
De común acuerdo escribiendo menos errores es escribir código entendible y mantenible. Tan pronto como una línea de código es escrita, estás realizando el mantenimiento de ese trozo de código.
El código que es frágil y difícil de cambiar desperdicia horas y horas de ciclos de desarrollo cuando tratamos de enmendar un sistema con actualizaciones y nuevas funcionalidades. Escribiendo código mantenible, un buen desarrollador puede hacer estos cambios de forma más rápida y mejorando también la productividad de los miembros de su equipo que más tarde tienen que trabajar con ese código.
Los buenos desarrolladores hacen más con menos código
Otra característica de un buen desarrollador es que sabe cuando no hay que escribir código. Como siempre me dice un amigo:
"¿Por qué construir lo que puedes comprar? ¿Por qué comprar lo que puedes tomar prestado? ¿Por qué tomar prestado lo que puedes robar?"
Con unas pocas excepciones, el síndrome NIA (no inventado aquí) es un asesino patológico de la productividad. He visto a desarrolladores empezar a escribir su propio entorno de formularios de validación hasta que señalo que hay uno hecho actualmente en ASP.NET que hace el trabajo (no es perfecto, pero es mejor que el que vi que se estaba escribiendo).
Todo ese tiempo desperdiciado reinventando la rueda es desperdiciado porque alguna otra persona ha escribo el código para tí. Y en muchos casos, hizo un mejor trabajo ya que se centraba concretamente en ese objetivo. En una situación de este tipo, encontrar una librería que hace el trabajo puede proveernos de un gran impulso para la productividad.
La advertencia en este caso es ser cuidadoso para evitar rígidas y no extensibles librerías ajenas, especialmente para requisitos muy especializados. Puedes gastar mucho tiempo intentando meter a una mascota redonda en una caja cuadrada.
Incluso cuando debes inventar, los buenos desarrolladores tienden a escribir menos código (pero de forma legible) que hace más. Por ejemplo, en vez de construir una máquina de estados que analice texto de una cadena grande, un buen desarrollador puede usar una expresión regular (de acuerdo, algunos dirán que una expresión regular no es legible. Incluso más legible que cientos de lineas de código de análisis de texto).
Vuelta a TCO
Cada una de estas características que he listado mantienen el coste total de propiedad bajo en un buen desarrollador. Por favor, no dejes que el término propiedad te distraiga. A lo que me refiero es al coste de la empresa de tener un desarrollador así en nómina.
Escribiendo menos código que haga más, y escribiendo código mantenible que tiene menos errores, un buen desarrollador elimina presión al departamento de calidad, trabajadores y encargados, incrementando la productividad de todos. Por esto es por lo que expresiones como "28 veces más productivo" son posibles y pueden incluso parecer bajas cuando lo consideras desde un más alto nivel.
Esperamos que la visión de esta perspectiva convenza a encargados de que los buenos desarrolladores realmente son tan productivos como muestran los estudios. Negociar un incremento de pago 28 veces superior es un ejercicio que dejamos al lector.
Fuente: turbia.net.
España: Telefónica lanzará VDSL2 de 50 megas a partir de octubre
Telefónica lanzará a partir del próximo mes de octubre los 50 megas y es que dará por finalizadas las primeras pruebas precomerciales que está realizando en Madrid.
El equipo de ADSLzone.net ha estado probando durante toda la semana una de las conexiones en “pruebas” y los resultados han sido bastante satisfactorios, ya que la distancia a la central deja de ser un problema por el despliegue que está realizando la operadora instalando varios repartidores de VDSL2 en cada central. A continuación os facilitaremos precios, detalles, fotografías de los equipos y además centrales que están ya preparadas para recibir la "super velocidad".
La operadora tiene más de 50 nodos instalados y funcionando en Madrid que disponen de DSLAMs Huawei y repartidores Siemens o Inelcom. Las centrales que están funcionando en la zona urbana y en los alrededores de Madrid son las siguientes:
Alcorcón/Cerrajeros, Fuenlabrada, Getafe Centro, Madrid/Almenara, Madrid Delicias, Madrid Fuencarral, Madrid Hortaleza, Madrid Pavones, Madrid San Blas, Móstoles/Pradillo y Tres Cantos.
Dependiendo de la cantidad de abonados de cada central, la operadora tiene un número determinado de repartidores asignados. Por ejemplo, en la central de Alcorcón/Cerrajeros, hay hasta cuatro repartidores automáticos sin embargo en Tres Cantos sólo hay uno. Con los repartidores la distancia a la central deja de ser un problema ya que están conectados a la central con fibra óptica. El VDSL2 es sensible y sólo ofrece 50 megas en hogares que se encuentren a menos de 500 metros aproximadamente, pero, a diferencia del ADSL2+, el VDSL2 no está meramente limitado a cortos bucles y puede ser utilizado con calidad en medias distancias.
[Sigue leyendo el articulo en ADSLZone]
El equipo de ADSLzone.net ha estado probando durante toda la semana una de las conexiones en “pruebas” y los resultados han sido bastante satisfactorios, ya que la distancia a la central deja de ser un problema por el despliegue que está realizando la operadora instalando varios repartidores de VDSL2 en cada central. A continuación os facilitaremos precios, detalles, fotografías de los equipos y además centrales que están ya preparadas para recibir la "super velocidad".
La operadora tiene más de 50 nodos instalados y funcionando en Madrid que disponen de DSLAMs Huawei y repartidores Siemens o Inelcom. Las centrales que están funcionando en la zona urbana y en los alrededores de Madrid son las siguientes:
Alcorcón/Cerrajeros, Fuenlabrada, Getafe Centro, Madrid/Almenara, Madrid Delicias, Madrid Fuencarral, Madrid Hortaleza, Madrid Pavones, Madrid San Blas, Móstoles/Pradillo y Tres Cantos.
Dependiendo de la cantidad de abonados de cada central, la operadora tiene un número determinado de repartidores asignados. Por ejemplo, en la central de Alcorcón/Cerrajeros, hay hasta cuatro repartidores automáticos sin embargo en Tres Cantos sólo hay uno. Con los repartidores la distancia a la central deja de ser un problema ya que están conectados a la central con fibra óptica. El VDSL2 es sensible y sólo ofrece 50 megas en hogares que se encuentren a menos de 500 metros aproximadamente, pero, a diferencia del ADSL2+, el VDSL2 no está meramente limitado a cortos bucles y puede ser utilizado con calidad en medias distancias.
[Sigue leyendo el articulo en ADSLZone]
Suscribirse a:
Entradas (Atom)