• Author: guille
  • Published: Oct 29th, 2007
  • Comments: None

Taza de bizcocho de chocolate

cupcackeSe dice que el desayuno es la comida más importante del día. La verdad es que cuando me levanto entre semana nunca me apetece comer, así que tengo que esperar  una o dos horas a que me entre el hambre para ir a desayunar al bar de la esquina. Sin embargo, en fines de semana, cuando se despierta uno despejado y después de haber dormido hasta la saciedad, apetece comer algo consistente.

Para esas ocasiones, un bizcocho suele ser una buena opción. Fácil de hacer, con ingredientes relativamente básicos, tiene como único inconveniente el tiempo de cocción y enfriamiento. Si se decide en el último momento, puede tardar una hora en hacerse y desayunar. Cuando se tiene hambre, es inaceptable.

Es para esos momentos de ganas de bizcocho rápido que mi chica tiene la siguiente receta. Se hace rápidamente y, si su sabor no se puede comparar al de un bizcocho de verdad, es sin embargo delicioso. 

Ingredientes (por taza):

  • 20gr de harina
  • 1/4 de cucharita de bicarbonato de sosa
  • 10gr de chocolate
  • 30gr de azúcar
  • 1 huevo

Preparación:

  • Calentar el chocolate y la mantequilla en el microondas hasta que se fundan.
  • Mezclar bien por separado el huevo, harina y azúcar.
  • Añadir el chocolate y la mantequilla a la mezcla anterior.
  • Añadir el bicarbonato mezclado previamente con un poco de agua.
  • Poner la mezcla en tazas y calentar en el microondas 2-6 minutos (según la potencia).

Comentarios:

  • Es importante añadir el chocolate, pues el bicarbonato le da color a la mezcla.
  • Author: guille
  • Published: Oct 10th, 2007
  • Comments: None

Implementing Backup for a home network

disasterBackups are one of the least beloved activities in computing. Few people like to do backups, and thus they don’t think about doing them.

My motto is, if you think you should do a backup, it’s already too late. And lately I am thinking about doing a backup, so I’m concerned.

In order to implement automatic backups several factors must be taken into account:

  • Network topology: Is it a single computer or several computers? Are they in the same network, or distributed?
  • Computer infrastructure: Are the OS homogeneous? Or has each computer a different or a different flavour of Operating System?
  • Security: Is the network secure? Is the media where the backup is done secure, or stored securely?
  • Data nature: Has all the data the same nature? Has all the data the same backup needs?

Network topology and computer infrastructure:

In my case I have a very heterogeneous network topology. My network is on the same LAN, composed by two laptops and one server. Sometimes additional laptops are connected, but those are not taken into account for backups. We have a server running under Linux, a MacOS X laptop and a dual boot Linux-WindowsXP laptop.

Security:

My network is accessible by LAN and encrypted WLAN. As there is no DMZ, my server is in the same LAN as the two laptops. This makes the security low from a network point of view. On the other hand, only the physical server can be accessed by ssh, all the services being in virtual servers only accessible from the physical server. Thus, even if a server is compromised, the physical server is safe.

Data nature:

Concerning the data nature, I decided to split it in different groups. I have found:

  • Base system:
    I don’t need /want to backup all my systems. The configuration of the
    OS of the two laptops make it too difficult to backup anything besides
    the personal data. On the other hand, I’ve decided to backup the system
    from my server, as it is made of a base system that is almost never
    modified, as all the work is done as VServers, that are treated as a
    different form of backups.
  • VServers: Each Virtual Server
    is fully backupped. This is mainly because all my critical systems are
    in those VServers and I need them back quickly if my server crashes.
    The information in the VServers can change daily, as it hosts, among
    others, a few websites.
  • Mails: This information is critical, and change greatly from day to day.
  • Photos and mp3: Just as critical as the mails, if more for personal reasons, those files change rarely but are heavy in size.
  • Personal documents: Working documents, texts, programming code,… are files that change often but that are of limited size.

We find the following table:

Asset Owner Frequency of changes Approximate size
emails user very often 2Gb/person
mp3/photos user rarely 15Gb/person
other documents user often 1Gb/person
base system server rarely 2Gb
virtual servers server often 1Gb/virtual server

Backup procedure:

At the beginning I tried to backup all the information with the same backup procedure. But I realized that all those assets do not need to follow the same backup method.

For instance, mp3 and photos did not need a daily backup procedure with history, as the changes would be few and spaced in time. Due to their high space requirements but low criticity (I can restore my music and photos one week after disaster, while I need my server running ASAP) I can afford to store my data in a storage place with slow bandwidth and low availability as long as they have a physical backup as well.

On the other hand, my base system and virtual servers will need to be in a very secure and available storage. This will be more feasible due to the low capacity those systems require.

There are several backup solutions on the wild at the moment. Each one has different advantages and drawbacks:

  • Mozy: Costs 4.95US$ per month for an unlimited amount of space. Support for MacOS X is still in beta, but lots of users seem to be satisfied with it.
  • Carbonite: Costs 49.95US$ per year for an unlimited amount of space. Constant backup in the background. No support for MacOS X. Restoration can be done online.
  • Mediamax: 100Gb costs 4.95US$ per month, but download is limited to 10Gb/month. The backup software is in beta and only for Windows.
  • RSync: Secure and flexible, but expensive. 1.60US$/month per Gb stored, without bandwidth usage limits. The server can be accessed in a variety of ways, like rsync, scp, sftp, WebDAV,… it is the solution actually used for the server.
  • Amazon S3: Cheap and reliable, but more restrictive for access. 0.15US$ per Gb per month, and 0.10US$ per Gb transferred. There are several tools developed to interact with this vault. 

Some of the solutions bring their own software. This allows easy deployment but can be a problem, as we create software dependency. In other solutions, backups must be done in an independent way. Besides the evident command line bash script there are other useful utilities that make the work easier:

  • Cobian Backup: Simple and easy to set up, it does differential and incremental backups that can be compressed or encrypted. Only for windows.
  • rdiff-backup and duplicity are two python command line backups that encrypt and simplify a server backup in a remote system.
  • SuperDuper! creates the image of the system, so it is immediately bootable.
  • JungleDisk is
    a software that allows direct interaction with Amazon S3 and that
    provides additional capabilities, like encryption and platform
    independence.
  • CrashPlan makes automatic backups between computers. Those can exchange backups among each other. Files are encrypted.

Now comes decision time. Taking into account my infrastructure, I think what I am going to do is to backup photos, mp3s and heavy documents I am in no hurry to get back into a cheap solution like Mozy, while storing important files I would need quickly in case of crash (base system, virtual servers, emails) in a reliable system like S3. Besides this, I will do periodical backups to a USB drive that will be stored outside home in order to complement and speed up recovery in case of disaster.

I will experiment those coming days and see what I can do with this.

  • Author: guille
  • Published: Oct 4th, 2007
  • Comments: 2

Le futur de Facebook

logoUne copine m’a fait lire un article qui donne son avis sur le commentaire de Steve Ballmer, actuel patron de Microsoft:

“I think these things [social
networks] are going to have some legs, and yet there’s a faddishness, a
faddish nature about anything that basically appeals to younger people.”

Malgré le manque d’estime que j’ai pour cet homme, je dois avouer qu’il a sûrement raison. Simplement parce que, dans un marché dans lequel il y a tellement de dynamisme, il y aura un autre produit qui prendra la même forme que Facebook mais en l’améliorant.

Des réseaux sociaux j’en ai connu plein depuis des années. J’en vois apparaître souvent, avec des succès variables. C’est, souvent, simplement une question de prestations et effet boule de neige. J’ai justement lut l’autre jour que les sites (ou sites web 2.0, une expression qui ne veut rien dire…) qui ont le plus de succès sont ceux qui ont ouvert leur API aux développeurs. Cela veut dire que n’importe qui peut intégrer (utiliser) les services du site dans leur page web, logiciel ou autre.

Dans le futur on va surtout avoir tendance à corriger les problèmes suivants, soit à travers Facebook, soit (probablement) à travers une nouvelle compagnie, l’internationalisation et l’intégration.

Internationalisation:

Jusqu’à maintenant le marché avait trop tendance à tout faire dans les sites
anglais. Ceci fermait l’accès aux communautés non-anglophones, majoritaires dans le monde, et des sites spécifiques à chaque pays étaient en train
d’apparaître (France, Espagne, Japon,…).

L’internationalisation permettra une complète participation du public non-anglophone dans ces communautés. Non seulement ils écriront dans leur langue, mais le site sera dans leur langue, ainsi que les différentes applications. Le jour où un site sera
vraiment international il verra son public cible augmenter de façon
considérable.

Intégration:

Peut être la solution au problème antérieur. On a différents
fournisseurs d’email (Hotmail, GMail, Yahoo,…), qui ont des services
différents (interfaces web, tags, accès POP,…) autour d’un même
produit, l’email. Et pourtant ils sont interopérables. La même chose
devrait apparaître pour les réseaux sociaux, la capacité de se mettre
en contact avec des personnes d’autres réseaux sociaux sans devoir
ouvrir 25 comptes différent, un dans chaque site. On commence à voir
ça. Par exemple, maintenant on peut accéder à ses contacts email de
Hotmail, GMail et autres réseaux sociaux pour les inviter
automagiquemen. Mais alors comment se différencier? Par ses services
additionnels, ces petites applications qui m’ennuient à mourir mais qui
semblent faire la joie des Facebookeurs (Vampire, Gifts,…).

La standardisation comme problème global:

Finalement, on touche un sujet bien plus vaste qui est en plein débat en ce moment, celui de la standardisation et internationalisation. Les États-Uniens se sont rendus finalement compte du fait qu’ils ne sont pas seul dans ce monde, et que ce ne sont pas les autres qui doivent apprendre *leur* langue, mais eux qui doivent adapter leur produits aux spécificités locales. Et le monde s’est rendu compte que pour avoir une vraie compétence et une vraie interopérabilité il faut des standards. Dans les communications VoIP, dans lequel le protocole propriétaire de Skype limite le développement de nouveaux produits. Dans l’informatique de bureau, avec la guerre des standards entre OFD et OOXML pour le successeur des documents .doc. Dans les mails même, où le serveur Outlook oblige à l’achat de Windows et à l’utilisation de Outlook comme client mail.

Jouer à Nostradamus:

Il ne faut quand même pas oublier que l’informatique est toujours en plein développement, et donc il est toujours difficile de jouer à Nostradamus. Bill Gates à dit dans sa jeunesse que “personne n’aura jamais besoin de plus de 640kb de RAM!!” et on en est aujourd’hui à plusieurs Gb (plus de 1000 fois plus), Thomas Watson, un des présidents d’IBM, affirmait que le marché mondial d’ordinateurs dans le monde se limitait à 5, et Ken Olson, président de DEC, se demandait qui voudrait un ordinateur à la maison.

© 2006,2007,2008,2009,2010 Guillermo Fernández Castellanos | Header images by Nick Lobeck