Mac space running out? Whatsapp backup to iCloud may be the cause

A few weeks ago I noticed my Mac was running a bit low on disk space. It didn’t surprise me, since I have loads of RAW photos that take up massive amounts of space, and it’s a 256GB box.

However, since it hit around 15GB I’ve been keeping an eye on it. Since then, I’ve seen how almost on a daily basis the free space drops and drops…

If this situation sounds familiar to you, maybe you can find the solution here.

When it hit 10GB I started looking for an explanation. After examining with Disk Inventory X, I noticed that ~/Library/Caches folder was really fat. Fat as in ~40GB. You can browse directly to that folder by pressing CMD+Shift+G on Finder and entering ~/Library/Caches.

After further investigation, I found that folder com.apple.bird was the culprit, weighing around ~35GB.

Apparently that folder stores iCloud related stuff and you can delete it safely. I deleted it, but in a matter of weeks it got fat again. I had eradicated the symptom, but not the problem.

After searching the web again, I found an article¹ that shared the same concern. The theory is that the root problem is Whatsapp backup to iCloud. It’s not 100% proven, but after I disabled Whatsapp backups, the folder hasn’t grown again. Alternatively, I think you can enable weekly or monthly backups in Whatsapp.

Let me know in the comments if this has helped you or you have any clues on this topic.

[1] – Large com.apple.bird directory – Apple Support Communities

 

Laravel Homestead: multiple projects, one VM

Vagrant is great to isolate a development environment inside a VM. However, after a while you can find you have a bunch of heavy VMs that share the same characteristics, each one for a simple PHP project.

Enter Laravel Homestead

In these cases, you can safely use Laravel Homestead. Homestead is a Vagrant box pre-configured with an Nginx web server, PHP 5.6, MySQL, Postgres, Redis, Memcached, and other stuff to make development easier and faster.

The documentation is pretty clear and in a few steps you can have a working development environment, where you can add multiple projects.

Chek it out: Laravel Homestead

Update: Also, I recently found a simple guide on how to install MailCatcher on Homestead, which is really useful: Installing MailCatcher in Laravel Homestead

Set friendly names for validation attributes in Laravel 4

I just lost half an hour on this, so I figured I’d help you save some precious time.

Every search on Google returned info on how to specify custom messages, which is nicely documented, but there’s currently nothing about friendly names on attributes on the docs.

After searching on Google, roaming through Laravel’s code and trying almost everything, I got to this comment on GitHub.

You may call setAttributeNames on a Validator instance now.

So, for example’s sake:

$rules = array(
    ‘username’ => ‘required|min:8|unique:users|integer’,
    ‘firstname’ => ‘required’,
    ‘lastname’ => ‘required’,
    ‘email’ => ‘required|email’,
    ‘password’ => ‘required|confirmed’
);

$messages = array(
    ‘required’ => ‘El campo :attribute es obligatorio.’,
    ‘email.required’ => ‘El campo de :attribute es requerido y debe ser una dirección válida.’,
    ‘validation.confirmed’ => ‘Las contraseñas no coinciden.’
);

$friendly_names = array(
    ‘firstname’ => ‘Nombre’,
    ‘lastname’ => ‘Apellido’
);

$validator = Validator::make(Input::all(), $rules, $messages);
$validator->setAttributeNames($friendly_names);

Terminal: “You have new mail.”

La otra vez abrí una terminal y lo primero que vi fue este mensaje.

Terminal: You have new mail.

Luego de chequear mis cuentas y pensar que había sido víctima de algún hackeo o algo así, busqué en Google y encontré la solución.

Basta con eliminar la carpeta /var/mail/$USER o utilizar el comando mail y borrarlos, pero esto puede llevar bastante más tiempo.

#Fuentes:
http://superuser.com/questions/25738/why-does-terminal-say-you-have-mail 

Dominios.uy

Primero que nada, quería anunciar que este humilde sitio ya es uno de los primeros dominios .uy de Uruguay.
ign.com.uy → ign.uy

Luego, quería hacer un par de aportes.

  1. Los dominios .com.uy van a seguir existiendo (!)

    Contrario a lo que muchos creen, los dominios .uy no sustituyen a los dominios .com.uy. Simplemente son una alternativa, como son .com.mx versus .mx o .com.es versus .es.
  2. Cómo redirigir tu dominio .com.uy a .uy

    En un tono un poco más nerd, simplemente les dejo unas líneas para incluír en el .htaccess y redirigir todos los links de forma permanente desde el dominio .com.uy a .uy, super-SEO-friendly-reloaded y todo eso (creo):

    RewriteEngine on 
    RewriteCond %{HTTP_HOST} ^(www\.)?sitio\.com\.uy [NC] 
    RewriteRule ^(.*)$ http://sitio.uy/$1 [R=301,L]

PHP: The Right Way

Hace pocos días Josh Lockhart, creador del micro-framework Slim, escribió un pequeño documento y levantó un sitio web, llamado PHP: The Right Way.

El contenido del mismo es un listado de las mejores prácticas a tener en cuenta y aplicar al realizar aplicaciones en este lenguaje, orientado a desarrolladores que están iniciándose o apenas conocen el lenguaje.

¿Por qué es imporante?

Ningún lenguaje es perfecto, pero PHP es famoso por tener muchas fallas de diseño. Además de esto -causado quizá por ser el lenguaje más fácilmente configurable en cualquier hosting compartido- también ha tenido hace años un uso y abuso de parte de programadores, “programadores” y cualquier persona con acceso a un hosting compartido. Desde pequeñas aplicaciones que envían un form hasta sitios enteros fueron construídos de la misma manera. Totalmente funcionales a simple vista, pero repletos de fallas de seguridad, poco mantenibles, etcétera.

A pesar de esto, hace pocos años muchos referentes de la comunidad comenzaron a surgir para evangelizar sobre las buenas prácticas, mientras que el lenguaje a venido mejorado mucho desde la versión 5. Sumado a eso, surgieron varios frameworks y herramientas muy buenas que facilitan la vida y resuelven muchos de los errores que podríamos cometer utilizando el lenguaje puro. La aceptación que tuvo GitHub por parte de los desarrolladores sin dudas también tuvo su impacto en todo esto.

Por lo tanto, si bien PHP tiene muchos defectos, lo que sin dudas es seguro es que no hubo otro mejor momento para aprender PHP que hoy.

Por lo tanto, si estas aprendiendo o te habías decidido a aprender el lenguaje, te recomiendo pasar por ese sitio y tomarlo como guía, adoptar desde el comienzo las buenas prácticas y seguir a la gente que hace las cosas bien.

Disclaimer: El objetivo de la entrada no es convencer a nadie de usar o no el lenguaje. Simplemente, si vas a utilizarlo, aprovechá que hoy hay buena información por la vuelta, mucha gente presionando para que se hagan las cosas bien y haciendo las cosas bien y hacé las cosas bien.
Personalmente, si bien seguramente nunca deje de usar PHP para algunos proyectos, estoy hace tiempo jugando e investigando con Python/Django, por razones que quizá luego escriba por aca. Creo que es un gran lenguaje y un framework muy bueno, flexible y potente. Una de las cosas que construí a modo de prueba fue URLy.ws, un acortador de URLs.

 Enlaces

Legibilidad en los medios online

Cada vez utilizo menos el RSS para leer noticias, y en cambio recibo lo más importante y/o lo urgente vía twitter. Esto me ha hecho visitar directamente los portales de noticias locales.

Sin mucho análisis se puede ver que la mayoría de los medios de comunicación online uruguayos tienen problemas de legibilidad [1]. Algunos bastante graves, a pesar de que debería importarles mucho cómo se lee su contenido.

Ya se, “la semana que viene lanzamos un rediseño”, “una nueva versión del sitio nuevo está en desarrollo”, y muchos más. Sin embargo, pasan semanas y nunca se actualizan. O peor, las nuevas versiones siguen teniendo los mismos defectos.

La usabilidad es algo que se va mejorando de a poco, a medida que vamos evaluando y apilando pequeñas mejoras, que a la larga, hacen una experiencia agradable para el usuario. Por eso creo que la mejora en este aspecto no puede esperar al próximo rediseño, debería ser algo más dinámico, que se evalúa y se mejora en iteraciones más cortas, que se pueden implementar hoy.

Voy a detallar algunos ejemplos de algunos de los medios que más me chocan. En todos los casos, pueden corregirse con no no más de 5 líneas de código CSS.

El País

Simplemente un poco de espacio entre párrafos y más interlineado, fuente apenas más grande y serifada.

180

En este caso el problema más grave es el tamaño de fuente que es muy pequeño.

Brecha

El problema más grande es el uso innecesario del fondo a rayas, que contrasta bastante mal con el texto. Un poco más de espacio no le viene mal tampoco.

Para ser justo, hay quienes están haciendo las cosas bastante mejor. Un ejemplo digno de mención es El Observador, que sin dudas es el más agradable para leer. De todas maneras, también tiene margen para mejorar.

De hecho, todos siempre van a poder mejorar. El objetivo de usabilidad al 100% es inalcanzable, y eso está bueno porque siempre se está buscando pequeñas mejoras que faciliten el uso del producto.

Notas

  1. Me refiero en realidad a lo que se define como “Readability”. No estoy seguro si “legibilidad” es una buena traducción, ya que “legibility” también existe en inglés y no refiere exactamente a lo mismo.
  • Merecen un capítulo aparte las publicidades de algunos de los sitios, que saltan encima de todo, te siguen, algunos no te dejan leer hasta que las cerras, etc.
  • Mientras no llega la “próxima actualización del sitio”, podemos usar una hermosa aplicación web llamada Readability, que transforma cualquier artículo online, aplicandole un estilo legible y agradable. También elimina contenido secundario, publicidad, etc. Claramente estas aplicaciones no deberían existir si se estuvieran haciendo bien las cosas en este aspecto.