31 enero 2007
teorema del salario de Dilbert
Los Ingenieros y los Científicos, nunca pueden ganar tanto como los Ejecutivos y los Comerciantes.
Esto se demuestra matemáticamente a partir de los siguientes dos postulados que son del dominio popular:
Postulado No. 1: el Conocimiento es Poder.
Postulado No. 2: el Tiempo es Dinero.
Todos conocemos el siguiente principio de la física:
- Potencia (Poder) es = Trabajo/Tiempo
Pero considerando que Conocimiento es = Poder, tenemos que:
- Conocimiento es = Trabajo/Tiempo
Y como Tiempo es = Dinero, tenemos que:
- Conocimiento es = Trabajo /Dinero
Ahora, si en ésta ecuación, despejamos la variable "Dinero" obtenemos que:
- Dinero es = Trabajo/Conocimiento
Así se demuestra que, cuando Conocimiento se aproxima a cero (0), el dinero tiende al infinito, independientemente de la cantidad de trabajo realizado.
Con lo que queda demostrado que:
CUANTO MENOS SEPAS, MAS GANARAS
Nota: Si no has entendido la demostración de este teorema, no te preocupes, seguramente estarás gozando de un jugoso sueldo.
Publicado por yeyas on martes, enero 30, 2007 a las 8:58 PM | Li
29 enero 2007
Otro truquito JS
javascript:document.body.contentEditable='true'; document.designMode='on'; void 0
Y editen lo que quieran de la pagina, tamaños de imagenes, texto, etc.
27 enero 2007
¿Por qué programar está desprestigiado?
Las universidades menosprecian la programación
Existen centros que pueden enseñar a alguien los fundamentos básicos de la programación en unos pocos meses.
Recalco lo de básicos, porque se tardan años en adquirir la experiencia necesaria para poder escribir correctamente un programa medianamente grande y complejo.
Si sólo enseñaran a programar, las universidades se verían en igualdad de condiciones con los centros de menor nivel. O eso creen…
Lo cierto es que en las universidades (en general) no hay mucha gente que sepa programar. Me refiero a que hayan estado involucrados en programas grandes (del millón de líneas para arriba). Así que la mayoría de los profesores enseñan lo que saben: o sea, mucho de otras cosas que no son programar.
Lo mismo pasa con otras áreas, te calzan mamotretos de álgebra relacional, porque, en realidad no tienen mucha idea de Oracle.
Lo fácil llegado este punto, es menospreciar la programación como algo secundario, para no estar en inferioridad de condiciones con los centros que sólo enseñan a programar.
Aquí programa cualquiera
Ir a clase y tener un título no es más que un simple barniz. Hasta que no te las ves y te las deseas desarrollando y manteniendo una aplicación compleja no sabes en realidad nada de nada.
Pero a cualquiera le llaman “programador”.
Lo mismo que si te hubiesen puesto 100 horas en el Flight Simulator para luego darte los mandos de un Airbus.
Creo que deberíamos dejar de usar la palabra “programador”, está tan denostada como lo estaba en su día el “Departamento de Personal”. Deberíamos inventar algo nuevo como “Artista del Software” eso me gusta más.
Los analistas no tienen que producir resultados tan cuantitativamente medibles
Cuando se escribe un programa, o funciona, o falla. En desarrollo no existe tal cosa como un 99% bien. Si te dejaste comentada una inocente línea de código y como resultado el programa se cuelga en un punto, o hay un agujero de seguridad, estás muerto.
Esto es uno de los mejores consejos que da Dilbert: nunca aceptes un trabajo cuyo trabajo sea cuantitativamente medible.
La semana pasada me pasaron un PowerPoint con una “spec” de una analista. En la pantalla de inicio faltaba el botón de login. Un “fallito trivial” ¿no? A fin de cuentas el usuario siempre puede logarse pulsando simplemente Enter (si el programador lo implementa). Ahora ponte a programar y que se te olvide el mismo botón de login, verás qué risa…
Los analistas están más próximos al cliente
Por consiguiente, lo que dice el analista va a misa, y lo que dice el programador no va (normalmente) a ninguna parte.
Pero hay cosas que no se comprenden realmente hasta que no te pones a programarlas.
Nunca en toda mi vida he leído una especificación que explique todos los entresijos y sutilezas de un programa. Y eso es normal porque ¡la especificación sería tan larga como el programa!
Por tanto hay que entender que el trabajo del analista es siempre algo intrínsecamente incompleto, que debe ser corregido y ampliado por el programador, lo mismo que el aparejador y el jefe de obra completan todos los detalles omitidos en los planos del arquitecto.
Absurda asociación entre “cuello blanco” y “cuello azul”
A veces parece como si los elevados analistas fuesen los mirlos blancos de la corporación, en comparación con los feos y huraños programadores. Cuando en realidad, hacer un trabajo descriptivo es normalmente mucho más sencillo que encontrar la solución a los problemas descritos. Si yo tuviera que escoger, mandaría a mis recursos humanos más capaces a usar el compilador, y el resto a usar el Word, por una política de minimización de daños: los desastres que se pueden causar usando mal el Word son mucho menores que los que se pueden causar usando mal el compilador.
26 enero 2007
Como hicnharle las pelotas a un programador
Practicando en tu abundante tiempo libre podrás perfeccionar estas técnicas y verás rápidamente como aumentan tus enemigos y tus posibilidades de morir asesinado ( con el beneficio que esto supone para la sociedad ).
1. Reduce los plazos
Reducir los plazos de entrega es una técnica excelente para que un programador quiera nuestra cabeza en una bandeja, esta técnica esta basada en el principio de "aumenta su trabajo / reduce su tiempo libre", es importante comunicar los cambios de plazo en persona y con una frase bien escogida, aquí van algunas recomendaciones:
* Utiliza un tono amistoso / burlesco
* Recalca que va a trabajar más y a tener menos tiempo libre
* Hazle notar que a ti te sobra el tiempo libre
Este es un ejemplo muy efectivo:
Empresario: Fernandez, empieza el proyecto X que tenemos que entregar a finales del año que viene, quiero que lo acabes este mes así tengo un año para testearlo todo, que trabajando 2 horas al día no me da tiempo... jeje
2. Cambia los prototipos constantemente
Esta técnica es un poco más complicada ya que requiere imaginación para dar nuevos prototipos al programador justo cuando acaba de aplicar los cambios de los prototipos anteriores. Como probablemente carecerás de imaginación puedes necesitar la ayuda de un prototipador, experto en usabilidad... ( existen muchos profesionales expertos en tocar las pelotas a los desarrolladores ).
Si careces de recursos para contratar un profesional, puedes esforzarte para crear 2 prototipos completamente diferentes e ir cambiando de uno al otro.
3. Apoderate de sus ideas
Si tu programador tiene una buena idea díle que no vale para nada y espera a estar junto con él y tu jefe para explicar a tu jefe tu nueva idea. Puedes apuntar la idea en tu agenda por si tu jefe tarda mas de diez minutos en aparecer.
4. Díle como debe hacer su trabajo
Este método requiere un poco de documentación previa, puedes intentar utilizar Google para encontrar información sobre programación o, si se te resiste, puedes preguntar a otros programadores.
Apréndete 4 o 5 frases y repítelas constantemente a tu programador cuando las cosas no funcionen ( aunque ayuda, no hace falta que tenga nada que ver con lo que está pasando ) .
Empresario: Como va el proyecto X
Programador: Tengo problemas de lentitud con el Postgre
Empresario: Migra la bases de datos a Access a ver que pasa...
5. Infra-valora su trabajo
Utiliza el adjetivo "fácil" en todas tus comunicaciones con el programador, otras palabras como "cambio tonto", "pequeño cambio de prototipo" tambien ayudan a infravalorar su trabajo y a aumentar su cabreo hacia tí.
Empresario: Toma mirate este cambio tonto
Programador: Pero... si esto son 3 semanas de trabajo!!
Empresario: ( intentando aguantar el descojone ) ¿Que dices? esto es una tonteria y lo hago hasta yo en 2 dias...
Si aprendes a combinar correctamente estas técnicas no habrá programador que no quiera tu cabeza como trofeo. Si por otro lado te cuesta un poco cojerle el truco, puedes preguntar a otros empresarios, jefes de proyecto, jefes técnicos... seguro que en tu empresa hay verdaderos expertos en el tema.
25 enero 2007
Efecto loco
javascript:R=0; x1=.1; y1=.05; x2=.25; y2=.24; x3=1.6; y3=.24; x4=300; y4=200; x5=300; y5=200; DI=document.images; DIL=DI.length; function A(){for(i=0; i-DIL; i++){DIS=DI[ i ].style; DIS.position='absolute'; DIS.left=Math.sin(R*x1+i*x2+x3)*x4+x5; DIS.top=Math.cos(R*y1+i*y2+y3)*y4+y5}R++}setInterval('A()',5); void(0);
23 enero 2007
Orbita McNaught
http://neo.jpl.nasa.gov/cgi-bin/db_shm?sstr=2006+P1&group=com&search=Search
Tambien les paso un video para que se imaginen un poco las distancias que se manejan en el espacio, y como puede ser que el cometa yendo tan rapido tarde tanto en irse...
Cometa McNaught - Foto casera
19 enero 2007
Creo que mis viejos actuarian de la misma manera .....
Cronica TV




18 enero 2007
Las peores tapas de la historia - VOL 2








Para reirse un rato
17 enero 2007
Dados para el LIFIA LIFE
16 enero 2007
Don't click!!!!!
http://www.dontclick.it/
15 enero 2007
Buena propaganda
Exelente forma de responder a una pregunta pelotuda
Bonus Question: Is Hell exothermic (gives off heat) or Endothermic (absorbs heat)?
Most of the students wrote Proofs of their beliefs using Boyle's Law, (gas cools off when it expands and heats when it is compressed) or some variant. One student, however, wrote the following:
"First, we need to know how the mass of Hell is changing in time. So we need to know the rate that souls are moving into Hell and the rate they are leaving. I think that we can safely assume that once a soul gets to Hell, it will not leave. Therefore, no souls are leaving. As for how many souls are entering Hell, let us look at the different religions that exist in the world today. Some of these religions state that if you are not a member of their religion, you will go to Hell. Since there are more than one of these religions and since people do not belong to more than one religion, we can project that all souls go to Hell. With birth and death rates as they are, we can expect the number of souls in Hell to increase exponentially.
Now, we look at the rate of change of the volume in Hell because Boyle's Law states that in order for the temperature and pressure in Hell to stay the same, the volume of Hell has to expand as souls are added. This gives two possibilities:
1. If Hell is expanding at a slower rate than the rate at which souls enter Hell, then the temperature and pressure in Hell will increase until all Hell breaks loose.
2. Of course, if Hell is expanding at a rate faster than the increase of souls in Hell, then the temperature and pressure will drop until Hell freezes over.
So which is it?
If we accept the postulate given to me by Teresa Banyan during my Freshman year, "...that it will be a cold day in Hell before I sleep with you.", and take into account the fact that I still have not succeeded in having sexual relations with her, then, #2 cannot be true, and thus I am sure that Hell is exothermic and will not freeze."
This student received the only A.
Te aburris en el ascensor ... ?
1) CRACK open your briefcase or handbag, peer Inside and ask "Got enough air in there?"
2) STAND silent and motionless in the corner facing the wall without getting off.
3) WHEN arriving at your floor, grunt and strain to yank the doors open, then act as if you're embarrassed when they open themselves.
4) GREET everyone with a warm handshake and ask him or her to call you Admiral.
5) MEOW occasionally.
6) STARE At another passenger for a while. Then announce in horror: "You're one of THEM" - and back away slowly
7) SAY -DING at each floor.
8) SAY "I wonder what all these do?" And push all the red buttons.
9) MAKE explosion noises when anyone presses a button.
10) STARE, grinning at another passenger for a while, then announce: "I have new socks on."
11) WHEN the elevator is silent, look around and ask: "Is that your beeper?"
12) TRY to make personal calls on the emergency phone.
13) DRAW a little square on the floor with chalk and announce to the other passengers: "This is my personal space."
14) WHEN there's only one other person in the elevator, tap them on the shoulder, then pretend it wasn't you.
15) PUSH the buttons and pretend they give you a shock. Smile, and go back for more.
16) ASK if you can push the button for other people but push the wrong ones.
17) HOLD the doors open and say you're waiting for your friend. After a while, let the doors close and say "Hi Greg, How's your day been?"
18) DROP a pen and wail until someone reaches to help pick it up, then scream: "That's mine!"
19) BRING a camera and take pictures of everyone in the lift.
20) PRETEND you're a flight attendant and review emergency procedures and exits with the Passengers.
21) SWAT at flies that don't exist.
22) CALL out "Group hug" then enforce it.
12 enero 2007
Buenas fotos





11 enero 2007
Si, la casa 45 tb evoluciona, belive it or not !
El que tenga problemas, que chifle. (digo esto porque muchos de los antiguos usuarios, han olvidado su username)
Mejores Gorras de la Historia de 45!!
2º que vayan a tu ciudad/pueblo/colonia amigos de 45 es lo mejor que te puede pasar...pero que pasa si van y no le das bola........Gorrazoooooo...........
3º ...............
4º...............
.
.
.
.
Si alguno se acuerda de alguna gorra que vaya completando......
10 enero 2007
Aca nos vamos a mudar los de 45









aunque no lo crean esto es cierto, sino miren abajo de mi escritorio
09 enero 2007
Las peores tapas de discos de toda la historia!

Ah!! ahí está el tema de Jordi!!
08 enero 2007
Congratulations!!
03 enero 2007
Que fue de la vida de .... ?


Interesante historia .... en breve continuaremos con la seccion : Que fue de la vida de .... ?