lunes, 27 de julio de 2015

Como hacer un ordenador portable ( casi portátil ) por 100 euros

Hola a todos,

Hace tiempo que tengo un poco abandonado el blog , pero ahora que estoy metido en un proyecto personal que engloba algo de hardware creo que es un gran momento para hacer un post para que sepáis como os podéis montar un ordenador sencillo que podáis llevar a cualquier sitio por poco dinero.

1. Placa base: 40 euros
La base de este ordenador es, como no podía ser de otra manera una Raspberry Pi 2.  Esta plaquita tiene 4 procesadores a 900 MHz, 1 GB de RAM, 4 USB, salida HDMI ,jack de audio y usa como disco duro una microSD. Por si esto fuera poco el consumo no llega a los 5W, así que no hace falta ni disipadores ni ventiladores.

Esta plaquita vale unos 40 euros, se puede encontrar en varios sitios, yo la pillé de amazon y no tengo queja.

Esta placa se alimenta como si fuera un móvil, así que no deberías comprarte nada para la alimentación de las primeras pruebas. Para conectarlo al monitor y hacer las primeras pruebas te hará falta un cable HDMI, es de suponer que ya tienes, sino te lo tendrás que comprar ( vale pocos euros)

2. Disco Duro: 5 euros
La tarjeta micro SD te la tendrás que comprar aparte, no va incluida con la placa. Cualquier de más de 4 GB debería funcionarte, aunque he oido que algunas dan problemas ( yo personalmente no he tenido problemas con ninguna mis microSD). 

La imagen del sistema operativo la puedes descargar de aqui . Tienes infinidad de posibilidades pero la que te recomiendo es la más estándar que es la que tiene más soporte: la Raspbian Debian Wheezy.

Para grabar la imagen en la SD te hará falta un programa tipo Win32DiskImager . Es sencillo y fácil de usar.

El tamaño de la SD es el que tu quieras, piensa que va a ser tu disco duro, así que en función de para que lo necesites te hará falta más o menos capacidad. Para que te hagas una idea de precios, a mi una microSD de 8 GB me costó unos 5 euros. (y para lo que quiero tengo más que suficiente)

3. Pantalla: 30- 50 euros
Dado que llevar a cuestas un monitor de PC no es la mejor opción deberemos ponerle una minipantalla a nuestro ordenador.  Yo me decanté por una pantalla de 3.5 pulgadas con táctil incorporado.. me costó unos 30 euros.  Si el táctil no te interesa y/o quieres una pantalla más grande puedes conseguir fácilmente pantallas de 7 pulgadas ( sin táctil )  por unos 50 euros. La elección es tuya. Más de 7 pulgadas se puede conectar pero ya empieza a costar un poco a nivel técnico (hace falta circuiteria aparte y no es objetivo de este tutorial profundizar en este tema)

4. Altavoces: 10 euros
Por el mismo motivo que no es recomendable llevar el monitor a cuestas tampoco lo es llevar el equipo de sonido encima. Ya te aviso que las Raspberry tienen fama por tener una salida de audio malilla. Yo no tengo queja, pero tampoco lo estoy usando para reproducir sonido de alta fidelidad. 
Una solución barata es comprar altavoces alimentados por usb que se conecten al jack de audio. Por menos de 10 euros deberías de poder encontrarlos, así no tendrás que estar pendiente de que las pilas se le agoten. Si el audio de calidad fuera una necesidad para tu proyecto que sepas que existen un módulo de audio para la Raspberry que mejora mucho la salida, pero eso ya es otro proyecto en si mismo, así que no me meteré.

5. Baterias : 10 euros - 30 euros
Si queremos algo que sea como mínimo portátil necesitaremos que tenga batería (sino, mal negocio si siempre hemos de tirar de cable para poder funcionar). Por 15 euros deberías de poder encontrar baterías de reserva para móvil que tienen una salida de energía por microUSB perfecta para alimentar la Raspberry. Cuenta que más o menos que por cada 1000 mAh que tenga la batería tendrás una hora de funcionamiento de portátil. Por unos 10 euros deberías de poder encontrar baterías bastantes decentes. Yo compré una batería de 4400 mAh y otra batería con placa solar.  El presupuesto se me disparó un poco más ( no mucho ) pero la autonomía que tengo es virtualmente infinita.

6. Caja : 5 euros
En cualquier bazar o tienda del hogar podrás encontrar cajas de madera en las que meter todo tu "ordenador". Mide y piensa antes de comprar, pero más de 5 euros una cajita de madera no te debería costar.

7. Otros:  0 euros -  X euros
- Teclado y ratón (ya sean con cable o inalambricos) no los cuento dentro del precio por que todo el mundo tiene alguno viejo en casa.  Yo usé un teclado y ratón inalambricos que tenia acumulando polvo, si te lo has de comprar, tampoco te deberías dejar mucho dinero.
- Wifi : hoy dia los adaptadores de wifi ya te vienen con las cajas de los cereales, así que ni lo cuento en el precio. Si no tienes ninguno que te sobre en casa, siempre te podrás encontrar alguno por 10 euros o menos.


Resultado:

Después de hacer un par de agujeros con el taladro, limar un poco, conectar 4 cables y pegar los componentes a la caja... tachan!!! Aquí tenéis el resultado.


Baterias internas + Raspberry Pi 2 .


Placa solar y pantalla táctil ya pegadas a la caja


Cable de alimentación de la placa solar a la batería interna.


Altavoz alimentado por USB gracias a la Raspberry Pi 2



Conclusiones:
- Es posible montarse un ordenador portable por 100 euros. (y mejorarlo bastante con un presupuesto inferior a 150 euros)
- La Raspberry Pi 2 está bien para lo que está bien, que nadie espere jugar a juegos AAA en ella ni hacer nada muy complicado.
- Comprar una placa solar es una muy buena inversión.
- Con un poco de imaginación y un presupuesto reducido se pueden conseguir cosas muy originales y prácticas, os recomiendo que busquéis inventos que se han hecho con Raspberry que dejan este proyecto al nivel del betún.

Espero que este proyecto os haya gustado y os haya picado la curiosidad para montaros vosotros mismos vuestro propio engendro.

Nos vemos

miércoles, 17 de junio de 2015

Parchear vs Refactorización Continua

Artículo perteneciente a la sección de calidad del código

Hola a todos,

En el mundo de la programación existe un mantra que se repite hasta la saciedad que reza así: "Si funciona, no lo toques que lo estropeas". Esta frase , en general, es errónea y su aplicación indiscriminada implica la duplicación de código, el aumento de complejidad de los proyectos, el incremento de tiempos de testeo y la dificultad creciente para implementar nuevas características a nuestros productos.

Esto no quiere decir que en cualquier momento tengamos que refactorizar nuestro proyecto hasta que todo el código esté como una patena, a veces, los tiempos de entrega son los que son y no disponemos del tiempo suficiente para hacer las cosas como es debido. No obstante, si nos vemos obligamos a parchear lo primero que tendremos que hacer inmediatamente después de la entrega es plantearnos la refactorización del código para eliminar el susodicho parche. Si no, estaremos contrayendo una deuda técnica que con el tiempo se hará insalvable.

Si ya has leído otros artículos míos o de otros blogs sobre calidad de código y mantenibilidad de proyectos de software estarás aburrido de todo lo que he dicho hasta ahora. Es por ello que este artículo se enfoca a explicar esta problemática entre "hacer las cosas deprisa" y "hacer las cosas bien" con un ejemplo muy sencillo.

Imaginemos que trabajamos en una empresa de software que se dedica a hacer software a medida para clientes en javascript (por decir un lenguaje). Un buen día un cliente nos pide que le hagamos una función que devuelva un string de texto con todas las combinaciones que se pueden hacer con 2 ceros binarios y 1 uno binario separada cada combinación por un retorno de carro. Dado que es la primera vez que este cliente nos hace un encargo y que lo que nos pide no es muy complicado lo programaremos sin matarnos demasiado, una cosa sencilla , a facturar y a otra cosa.

La solución más sencilla al problema que nos piden es la siguiente:

function GetBinaryString()
{
   return "001\n010\n100";
}

Un par de dias después nos aparece el cliente y nos dice que ha habido algún tipo de error. Por lo visto el encargado de tomar notas se quedó con la mitad del mensaje. El cliente quería una función que en base a un parámetro que nos pasara nos generase además de la cadena ya pedida , otra cadena que fuera de 2 unos y 1 cero.

No es muy complicado entender que dado el caso que es un cambio relativamente pequeño y el código es minúsculo ( de hecho solo tiene una linea ) se puede hacer un pequeño parche de este estilo:

function GetBinaryString(num_bits_to_1)
{
   if(num_bits_to_1 == 1)
      return "001\n010\n100";
 
   if(num_bits_to_1 == 2)
      return "011\n110\n101";
 
   return "ERROR";
}

La solución tal vez no es muy elegante, pero realmente hacerlo de otra manera, en este caso, sería perder el tiempo.

Otro trabajo bien hecho.

Entonces es cuando empieza a venir la vorágine de cambios diarios. El cliente trabaja para una subcontrata y continuamente le están cambiando las especificaciones así que va pidiendo cada día "pequeños" cambios:

- Que sean 4 bits y no 3 los que están en juego.
- Que los grupos puedan ser 1,2 y 3 unos.
- Que sean 6 bits y no 4.
- Que los grupos puedan ser de hasta 5 unos
-etc etc etc

Delante de estos cambios hay dos opciones.
- Seguir parcheando incluyendo las nuevas especificaciones como buenamente se pueda dejando un código de este estilo
function GetBinaryString(num_bits_to_1, num_total_bits)
{
   switch(num_total_bits)
   {
     case 3: return GetBinaryStringTotal3(num_bits_to_1);
     case 4: return GetBinaryStringTotal4(num_bits_to_1);
     case 5: return GetBinaryStringTotal5(num_bits_to_1);
     case 6: return GetBinaryStringTotal6(num_bits_to_1);
   }
 
   return "ERROR";
}

function GetBinaryStringTotal3(num_bits_to_1)
{
   switch(num_bits_to_1)
   {
     case 1: return "001\n010\n100";
     case 2: return "011\n110\n101";
   }
   return "ERROR";
}

function GetBinaryStringTotal4(num_bits_to_1)
{
   switch(num_bits_to_1)
   {
     case 1: return "0001\n0010\n0100\n1000";
     case 2: return "0011\n0110\n1100\n1001\n0101\n1010";
     case 3: return "1110\n1101\n1011\n0111";
   }
   return "ERROR";
}

function GetBinaryStringTotal5(num_bits_to_1)
{
   switch(num_bits_to_1)
   {
     ..... decenas de combinaciones
   }
   return "ERROR";
}

function GetBinaryStringTotal6(num_bits_to_1)
{
   switch(num_bits_to_1)
   {
     ..... decenas de combinaciones
   }
   return "ERROR";
}

- Refactorizar código y replantearse empezar desde el principio a fin de que el nuevo código cumpla con las nuevas especificaciones con el mínimo de complejidad posible. Esto hace que el código nos quede del siguiente estilo: (no explicaré como funciona, si alguien tiene dudas, que pregunte :) )

function GetBinaryString(num_bits_to_1, num_total_bits)
{
  var pattern = 0;
  var string = "";
 
  pattern = GetPattern(pattern,num_bits_to_1, num_total_bits);
 
  do
  {
     string += DrawPattern(pattern,num_total_bits);
     pattern = GetPattern(pattern,num_bits_to_1, num_total_bits);
  } while ( pattern < (0x01<<num_total_bits) );
 
  return string;
 
}

function Count1(pattern,num_total_bits)
{
  var cont = 0;
 
  for(var i = 0 ; i < num_total_bits ; ++i)
  {
    if(patter & (0x01<<i))
    {
      cont ++;
    }
  }
 
  return cont;
}

function GetPattern(pattern,num_bits_to_1, num_total_bits)
{
     while(true)
     {
       pattern++;
             
       if(Count1(pattern,num_total_bits) == num_bits_to_1)
         return pattern;
     }
}

function DrawPattern(pattern,num_total_bits)
{
  var string = "";
 
  for(var i = 0 ; i < num_total_bits ; ++i)
  {
    if(pattern & (0x01<<i) )
      string += "1";
    else
      string += "0";
  }
  string += "\n";
  return string;
}




Evidentemente el buen camino es el camino de la refactorización dado que nuevos cambios serán absorbidos sin problemas y en algunos casos ya estarán implementados sin querer. En cambio con el parche continuado lo que no esté explicitamente implementado no estará , pero además el coste de mantenimiento será creciente.

Dicho de otra manera, con el tiempo el código parcheado se convertirá en un monstruo de miles de lineas inmantenible (y eso que al principio solo era 1 linea de código), mientras que el código refactorizado ocupará siempre menos de 30 lineas (salvo cambios muy bestias en la especificación).

Como factor adicional está que introducir casos nuevos en el sistema parcheado se tiene que hacer a mano, permitiendo que haya nueva fuentes de error, en cambio en el sistema refactorizado no haría falta ni testing del desarrollo debido a que el código es claro sobre lo que hace y lo que no hace, otorgando un plus de confianza al desarrollo.

Espero que os haya gustado y que lo pongáis en práctica en vuestros proyectos.

Recordad que para cualquier duda aquí estoy.

lunes, 2 de marzo de 2015

Nuevo blog de programación web

Hola a todos,

He recibido bastantes correos y comentarios diciendome que donde me había metido y por que el blog tiene pocas publicaciones ultimamente..

El motivo es que estoy aprendiendo nuevas tecnologías y desarrollando blogs sobre ellas.

Uno de estos blogs (el que tiene más cara y ojos ahora mismo) es el blog de Google Apps Scripts.


No es por que lo escriba yo, pero os lo recomiendo :D

Es un tema fascinante al cual llegué casi de rebote, pero cuando más aprendo más me gusta.

Echadle un ojo, aunque solo es un germen de blog, creo que os gustará.

Y recordad, que tanto para este blog, como para los nuevos que vaya haciendo las propuestas siempre son bienvenidas, espero vuestros comentarios!!

Nos vemos

Entradas populares