Looking at the 2007 credit crunch effect on Euribor rates, I noticed a trend on 1-week euribor rate: it always goes up one the last days of every year.
But in December 1999 suddenly it was more expensive to get a loan for 7 days than for a whole year:
Is that a sign of people getting money out of the banks – just in case ?
Today we spotted (again) the stupidestoldest “backup” bug in history from a script that should backup a 300GB/day repository.
Can you spot the bug? (ps: Don’t try to do this at homework):
tar -czf ${DEST}/${TIMESTAMP}_reports.tar.gz *${TIMESTAMP}*csv
... some more commands here ...
rm -f *${TIMESTAMP}*csv
There might be a race condition between the tar command that stores the files and the rm command that removes them.
How? some might say. I have a timestamp in the csv filename that *should* guarantee that I am removing the right files. Isn’t it?
Wrong.
First, there might be a race condition between the TAR and the RM command. The set of files that you backup and remove can be different.
If you want to actually remove the same files you have in the tar file you have two options:
Morale: If your backup tool can remove files (some vendor call this “archive”) as soon as they are backed up, use that feature.
BTW: Option#1 might be done carefully to avoid another related bug. Can you see how?
There are only two types of enterprise software: Software that IT departments buy , and
In the first group you can find the “usual suspects”: Oracle, Microsoft, IBM, etc…
IT departments usually buy something that they can use for more than one project. For instance, they don’t buy an Oracle license and setup a different database server for every application.
Selling to IT is hard; but there are some opportunities as well. IT budgets shrink even in “good” years – price and/or total cost of ownership is an important selling point here. New, disruptive technology (that affects TCO) can also make you sell something; but it’s harder to justify.
Selling to the second group – Business Units – may be easier to sell to an IT department. As a rule, Business Units don’t manage their own IT (there are some exceptions, but this is he rule). Instead, they consume IT services from the central IT department and they hate it because IT is not flexible enough form them. Remember that word: FLEXIBILITY is your primary selling point.
A Business Unit will buy all hardware, software, or services they need to do the job.
I’m tired of the way if-this-then-that software manages rules.
If you’ve grown beard (and gone a bit bald, like me) administering IfTTT software like firewalls, ETL, mail filters, web crawlers, yahoo-pipes, or just IfTTT; I’m sure you have spent a lot of timecleaning old configuration rules.
When you are part of a team that administers – for example – a firewall, you may end up asking why did someone added that rule in your firewall and why. Of course, you can always disable that rule (that’s the GUI equivalent of commenting out some lines fomr a configuration file) and cross your fingers waiting until a) someone complains or b) you remove the rule after a prudential amount of time.
The problem is that most (if not all) rule-based software doesn’t tell you how much times a disabled rule matches. And that’s a problem.
Before coding the next IfTTT rule-based software consider using three states for your rules:
Disclaimer: you can mimic this behaviour in some firewalls combining the allow and log actions, and digging in your logs; but it’s not clear and needs a lot of time for analisys.
This is specially usefull in a machine-to-machine (m2m) scenario. Most rules won’t have a person behind that will complain if there’s something wrong. In M2M the robot in the other side will take some decision based on it (limited) pre-programmed actions and you need to know how many times a rule does apply and if there’s a dumb robot trying to hit a rule you are about to remove.
Me ha llamado mucho la atención éste gráfico de ITJobswatch UK en la que mide el número de ofertas de trabajo en las que se pide Java:
Me llama mucho la atención la caída en picado del año 2007. Supongo que la crisis financiera debió hacer bastante daño a los programadores en Java de la City londinense; sin embargo esa caída no se ve si buscamos “Developer”, ni otras tecnologías como .NET.
En los últimos 8 años Java ha pasado de ser demandado por un 36% de las ofertas de empleo a poco más de un 28%.
Parece que la demanda se ha ido a la plataforma .NET de Microsoft y a lenguajes entornos más sencillos como PHP o Ruby. Mientras tanto lo que tira de la demanda de Java es el mantenimiento de aplicaciones existentes y el desarrollo de Hadoop.
PD: Si la caída de demanda de Java te llama la atención, echa un vistazo a las ofertas de trabajo para UNIX (no Linux: UNIX del de toda la vida como Solaris, IRIX, HP-UX..).
A cualquier administrador de sistemas se le pondrían los pelos de punta al ver esta gráfica:
¿Qué está pasando con el consumo de memoria de ese equipo?
La respuesta buena es NADA malo. Sólo estamos mostrando datos de distinta calidad en un mismo gráfico:
En la zona que está marcada con un círculo, tenemos datos disponibles cada 5 minutos.
Fuera de esa zona, tenemos un dato cada 30 minutos… a base de hacer la media de la información que teníamos cada 5 minutos de hace uno días…
El resultado es que el comportamiento del equipo parece que ha pasado de bueno a tener mucha variación. Y todo por mostrar en el mismo gráfico información de calidad distinta.
Espero que VMWare tome nota y lo arregle un día de estos…