Retomo de nuevo el tema de los discos SSD, en este caso me centrare en el soporte de este tipo de discos en Mac OS X Snow Leopard. Como vimos hace unos dias en el post Disco SSD en MacBook Pro, Mac OS X Snow Leopard no soporta TRIM.

La realidad es un poco mas compleja de lo que parece:

- Oficialmente Mac OS no soporta TRIM, lo hara en la proxima versión: Lion

- Equipos Apple con discos SSD con soporte TRIM en Mac OS X Snow Leopard

- Activar extraoficialmente soporte TRIM para todos los discos SDD

- ¿MacBook Air sin soporte TRIM?

Pasemos a ver en detalle cada uno de los puntos comentados.

Antes de nada, recordemos un poco que es eso del TRIM. TRIM es una orden que permite al sistema operativo informar a los discos SSD (Solid State Disc) que bloques de memoria ya no estan en uso, es decir, aquellos que contenían ficheros que han sido borrados.

La operacion TRIM pretende gestionar de una forma especifica, metodo de garbage collection, el borrado de los datos del disco duro. El fin es mantener el rendimiento de los discos SSD durante toda su vida util. El metodo tradicional de borrado, usado en discos magneticos, favorece la degradación de los discos SDD. Por construccion son muy diferentes.

Por un lado el problema reside en la forma que el Sistema Operativo borra los bloques de memoria, tipicamente de un tamaño de 4K, mucho menor al tamaño mínimo a borrar en las memorias NAND de una SSD.

Por otro lado los discos magneticos no diferencian entre una escritura o una sobre-escritura de un bloque marcado como eliminado por el Sistema Operativo. En cambio en un disco SSD esto no es así, ya que la sobre-escritura genera un overhead comparado con la escritura en una pagina vacia.

Finalmente hay que tener presente que las celdas de memoria NAND tienen un numero limitado de escrituras, unos 10.000 ciclos de escritura/borrado.

Es bastante conocido que Mac OS X Snow Leopard presenta algunos inconvenientes con los discos de estado solido, curiosamente Apple ha sido uno de los primero fabricantes en vender equipos con discos SSD.

Por un lado, es de dominio publico que Mac OS no soportara TRIM hasta su proxima version, Mac OS X Lion. Desde Apple se ha asegurado que los discos SSD comprados con equipos de Apple tendran soporte TRIM en Mac OS por defecto.

Por otro lado, se han reportado algunos problemas en equipos con discos SSD de terceros relacionados con la funcion de hibernar.

La guinda del pastel la encontramos con la posibilidad de activar TRIM en Mac OS para cualquier tipo de disco SSD. A continuacion ss dejo un link de como hacerlo:

Activar soporte TRIM en Mac OS para cualquier disco SDDs

Lo mas sorprendente de todo este caso es que en una reciente vista a la Apple Store del centro comercial de La Maquinista puede comprobar que los MacBook Air, tanto de 11 como de 13 pulgadas, no tenian activado el soporte TRIM en sus discos SSD.

Podeis encontrar mas información en:

Wikipedia: TRIM

Activa el TRIM en Mac OS X con cualquier disco SSD

Como activar el soporte TRIM en Mac OS X 10.6.7 y discos SSD de Apple

La gente de Hardmac han preparado una variante del driver que ofrece Apple para sus discos SSD para poder habilitar el soporte TRIM para cualquier marca/modelo de disco SSD en Mac OS. Este driver ha sido validado en Mac OS 10.6.6 y 10.6.7.

Obviamente este driver es una version no oficial, de manera que no hay ninguna garantia sobre su funcionamiento. Todo y que deberia funcionar sin inconvenientes se desconoce si a medio o largo plaza puede producir algun problema en el disco o en sus datos.

En algunos sitios se esta hablando de que podria reducir el rendiemnto del disco SSD pero esta por confirmar.

Si alguien ha tenido la ocasion de probarlo o lo ha activado, ya nos contara sus resultados.

Mas informacion en:

Activa el TRIM en Mac OS X con cualquier disco SSD

Como activar el soporte TRIM en Mac OS X 10.6.7 y discos SSD de Apple

[Updated] The universal solution to activate TRIM

TDD son las siglas de Test Driver Development un proceso de desarrollo de software que se basa en la idea de desarrollar pruebas, codificar y refactorizar el codigo construido.

El procedimiento que hay que seguir para desarrollar aplicando TDD, Test Driver Development, es muy sencillo, a continuacion veremos como usar esta metodologia, o procedimiento de desarrollo, muy comun entre los seguidores de las metodologias agiles.

TDD se basa en la idea de realizar pruebas unitarias para el codigo que debemos construir. A diferencia del procedimiento que usamos habitualmente, construir el codigo y despues realizar las pruebas unitarias, TDD establece que primero hay que realizar una prueba y a continuación desarrollar el codigo que la resuelve.

Obviamente el metodo TDD no acaba aqui, ya que ademas añade el code refactoring, re-estructuracion del codigo implementado, un factor importante que no debemos olvidar.

El metodo a seguir es sencillo. Consiste en elegir uno de los requisitos a implementar, buscar un primer ejemplo sencillo del requisito, crear una prueba unitaria, ejecutar la prueba, implementar el codigo minimo para superar la prueba y ejecutar de nuevo la prueba para ver que se supera.

Obviamente la gracia de ejecutar la prueba despues de crearla es ver que esta falla y que sera necesario hacer algo en el codigo para que esta pase.

A continuacion solo es necesario volver a aplicar el proceso descrito anteriormente hasta haber resuelto la funcionalidad o funcionalidades que se debian implementar.

A demas una vez pasada la prueba es necesario revisar el codigo, por si requiere refactoring. Si es el caso, se revisara, corregira y se ejecutaran las pruebas unitarias, de nuevo.

Es importante tener presente que solo se crea un test por iteracion y solo se implementa el codigo minimo necesario para resolver ese caso. No es bueno “emocionarse” implementando y desarrollar mas de lo necesario para resolver el caso de prueba. Si nos vamos por las ramas desarrollando mas casos perderemos una gran parte de la eficacia de este metodo.

Fuente: Dojo@SP

Elegir un requisito a desarrollar

Crear la prueba o test

Ejecutar los tests: falla (ROJO)

Crear codigo especifico para resolver el test

Ejecutar de nuevo los tests: pasa (VERDE)

Refactorizar el codigo

Ejecutar los tests: pasa (VERDE)

La pregunta habitual cuando alguien te habla sobre TDD es ¿Porque es mejor hacer las pruebas antes que el codigo?

Para responder a esta pregunta tenemos que pensar en la forma que se aplica TDD. Por un lado si se implementa y después se realizan las pruebas estas suelen estar condicionadas a lo implementado, con lo que es facil obviar pruebas o olvidar algunos casos de test.

Por otro lado al realizar primero las pruebas se realiza un ejercicio previo de analisis, en profundidad, de los requisitos y de los diversos escenarios. Eliminando la mayor parte de variabilidad y encontrado aquellos aspectos mas importantes o no contemplados en los requisitos.

El hecho que a demas solo se implemente el codigo necesario para resolver un caso de prueba concreto, pasar la prueba, hace que el codigo creado sea el minimo necesario, reduciendo redundancia y los tipicos bloques de codigo de “por si a caso” que habitualmente se convierten en codigo muerto.

Obviamente la obtención de un buen resultado aplicando TDD depende de realizar un conjunto de pruebas unitarias que cubran todos los casos descritos en los requisitos. Es cierto que habra que trabajar la tecnica para realizar buenos test, siendo aqui donde reside una de las mayores dificultades de este metodo.

No obstante hay que remarcar que TDD no solo se basa en las pruebas. Una correcta aplicación de la etapa de refactoring hace que nuestro codigo sea mas legible, optimo y facil de mantener, factores que no siempre priman en nuestros proyectos. Hay que aplicar concienzudamente el paso de refactor, que es el que aportara un valor extra a nuestro codigo.

Tambien que destacar que dado que el codigo evoluciona con el paso del tiempo el refactoring debe aplicarse, siempre que sea necesario, tanto al codigo implementado como a las pruebas unitarias, con el fin de mantenerlas actualizadas, añadiendo nuevos casos, cuando sea necesario, o completandolas al detectar fallos en el codigo.

Os espero en el proximo post sobre TDD donde veremos algunos ejemplo que nos ayudaran a entenderlo mejor.

PD: Os animo a comentar y plantear vuestras dudas en los comentarios del post.