Etiqueta: recomendaciones

Comprar un portátil para desarrollo en 2019

Toca cambiar de portátil. 8GB de RAM ya se quedan cortos. La patilla de la pantalla está dañada y no parece que vaya a aguantar mucho más. Y la batería con una vm, el ide y el navegador no dura mucho más de 1h.

Para situarnos el anterior comprado hace cuatro años era un MSI GE60 2PC Apache:

  • Micro i7-4720HQ. 2.60GHz de frecuencia base, hasta 3.60GHz con el Turboboost. 4 cores, 8 threads, 6MB de cache y un TDP de 47W.
  • 8GB RAM SODIMM DDR3 a 1600 fabricada por Kingston. No se cual es la latencia.
  • Nvidia GeForce GTX 850M con 2MB RAM
  • Disco duro mecánico de 1TB a 7200rpm
  • Pantalla de 15.5 y resolución de 1920×1080 normalita
  • Wireless-AC 3160, b/g/n y bt 4.0
  • hdmi, vga. 2 puertos USB 2.0 y 2 puertos USB 3.0, además de jacks para salida y entrada de audio.
  • 383 x 249 x 30 y 2.6kg de peso con batería
  • Batería de 6 celdas, 49Wh

Cuando lo compré escribí una guía de compra de portátil que aunque desactualizada me sirve de base para buscar uno nuevo. En base al rendimiento actual los requisitos no han variado demasiado:

  • Todo lo importante debe funcionar al 100% con linux. Si no va la luz del teclado me da igual. Si deja de funcionar el wifi con cada actualización del kernel adios.
  • Mínimo 16GB de RAM
  • Un i7 o equivalente en AMD. Un vistazo rápido me dice que los i5-82xxu que se montan en este rango de precios no son mucho mejores que mi micro actual y no me interesa averiguar si con un i5 me llega.
  • Resolución pantalla mínima 1920 x 1080. Como la mayoría del tiempo uso una externa como principal no necesito que sea extraordinariamente buena pero no quiero quemarme los ojos así que será un plus interesante
  • Mínimo 1TB de disco
  • No tengo necesidad de gráfica dedicada pero prefiero que no me coma RAM extra
  • No lo quiero más grande ni pesado que el actual. A pesar de que el 85% del tiempo está apoyado en una mesa, el 15% restante de viajes en tren, reuniones y uno o dos viajes de trabajo al año hacen que prefiera uno más pequeño. Pero no voy a sacrificar más de 150€ o rendimiento por ello
  • Quiero un teclado «bueno» a pesar de que la mayor parte del tiempo use uno externo
  • No tengo demasiadas necesidades de conectividad y puertos, no necesito Bluetooth y me da igual que tenga salida VGA y lector de DVD. Estos detalles me ayudaran en la decisión final pero asumo que con el resto de características que busco las necesidades mínimas en este aspecto estarán cubiertas. Update: Cuando revisé las opciones disponibles esto varió un poco, más en otro post
  • La marca no me preocupa. Hay demasiadas opiniones y experiencias particulares a favor y en contra de todas las marcas. Por experiencias cercanas doy puntos positivos a MSI y Slimbook y negativos a los HP y los Dell pero sólo en la clasificación final cuando haya dudas. No a priori. Y lo mismo con otras consideraciones como el uso de minerales de zonas de conflicto
  • Mi orquilla inicial es amplia y la reduciré a medida que investigue un poco. Empezaré por portátiles entre 900 y 1300€ con IVA. Una cantidad por la que se puede comprar algo aceptable para cuatro años si estás dispuesto a sacrificar alguna característica a cambio de precio como: batería, tamaño o potencia.

Hay un par de puntos clave sobre los que tenía dudas al principio:

  • Tamaño de la pantalla. Probablemnte la decisión más eliminadora a la hora de comprar el portátil. El de ahora es de 15.6 y para mi uso es cómodo. Pero siempre dudo con coger uno más pequeño. 14» sería perfecto. A los de 13» les tengo algo de manía. Update: Al poco de empezar a buscar los de 14» quedaron prácticamente descartados porque no me interesaba tanto sacrificar rendimiento o precio a cambio de mejoras de tamaño y batería
  • Con el disco duro también tengo dudas. De comprar unicamente un único disco magnético (HDD) tengo claro que sea de 7.200rpm. Una búsqueda rápida me dice que hay algún SSD de 1TB (lo ideal) a partir de 1.100€ pero en general suben bastante el precio. La opción de dos discos SSD + HDD puede ser buena pero me da que consume bastante batería y me puede fastidiar un poco mi organización actual de particiones, donde guardo las cosas cifrado y backups. Update: Cerca de tomar la decisión final quedó claro que en ese rango de precios tengo que sacrificar mi organización actual.

Con esto en la cabeza preparo mi hoja de cálculo y la inicializo con un par de configuraciones de Slimbook que me servirán de referencia. Luego voy rellenando algunos datos principales y descartando algunos directamente a partir de la búsqueda en un par de páginas. Fundamentalmente:

  • https://www.pccomponentes.com/
  • https://slimbook.es/
  • https://www.vantpc.es/
  • Amazon

y un vistazo rápido a:

  • http://tiendas.mediamarkt.es/ordenadores-portatiles
  • https://www.worten.es/inicio/informatica/ordenadores/portatil.html
  • http://www.elcorteingles.es
  • https://www.dell.com/es-es
  • https://www.pcbox.com/
  • https://www.lenovo.com/

Si estás interesado en este tema puedes ver otros artículos parecidos o seguir esta serie en esta etiqueta.

13 mayo 2019 3 Comentarios

Libro: El corredor del laberinto

He aprovechado las vacaciones de navidad a uno de mis «placeres culpables» que es la lectura de sagas Young Adult de ciencia ficción o fantasía. En este caso toco el turno de «El corredor del laberinto» de James Dashner.

Poco que decir de este libro a parte de ser una decepción absoluta. De los que me he tragado hasta ahora Harry Potter, Los Juegos del Hambre, Divergente, … esta serie es la peor y no la recomiendo.

Clasificación: 2/5

Te gustará si: Eres un fan incodicional de este tipo de novelas y Divergente te pareció buena.

Puedes comprarlo en tu tienda habitual, aunque hay quien te lo presta gratis en epubgratis.

31 diciembre 2017 Añadir comentario

Libro: Think Python: How to Think Like a Computer Scientist

How to Think Like a Computer Scientist es un libro clásico entre los recomendados para comenzar a programar en python. La primera edición es de 2002, escrito por Jeffrey Elkner, Allen B. Downey y Chris Meyers bajo licencia GNU FDL. El ser tan «antiguo» y el estar publicado bajo licencia libre ha hecho que a lo largo del tiempo hayan aparecido diversas versiones del libro.

Tenemos dos versiones del libro para python 2

  • How to Think Like a Computer Scientist: Learning with Python 2nd edition, sería la última edición para python 2 del libro original, y está fechada en 2012. Las soluciones a algunos ejercicios se pueden encontrar en wikibooks (y seguramente valgan para otras versiones).
  • La primera edición (2002) de ese mismo libro la podemos encontrar en Green Tea Press la página personal (y «editorial») de Allen B. Downey uno de los autores originales
  • Y también en Green Tea Press podemos encontrar una reedición distinta del mismo libro para python, renombrada simplemente a Think Python. Revisando el github donde se mantiene el libro los últimos cambios serios parecen ser de 2015

También tenemos varias versiones del libro enfocadas a python 3.

  1. La que podríamos considerar primera, de 2012, es How to Think Like a Computer Scientist: Learning with Python 3, reeditada fundamentalmente por Peter Wentworth como libro de texto para un primer curso de programación.
  2. Otra versión sería una adaptación de la de Peter Wentworth, hecha por varios profesores de la Universidad de Groningen, para emplearla también como libro de texto para sus clases. En el prólogo declaran que su idea era cambiar la filosofía del libro, de «how to think like a computer scientist» to «how to think as a scientist with a computer», pero revisándolo en mi opinión, los cambios no son tan significativos como para conseguirlo. Está en readthedocs por lo que también se puede descargar
  3. En Green Tea Press también encontramos una versión (los últimos cambios serios en el github son de 2016). Esta sería algo así como la segunda edición de Think Python
  4. Por último, un experimento interesante. Un libro interactivo, que parece basado fundamentalmente la versión de Wentworth. Consiste en una aplicación web que permite ejecutar código en el propio navegador, depurar paso a paso a modo educativo y responder a cuestionarios

En la página de Green Tea Press hay un dos artículos explicando porqué publicar «free books», y su filosofía a la hora de escribir libros de texto. Además en el prólogo del libro se puede leer algo sobre su historia para entender los autores y los cambios a lo largo del tiempo.

Todas las versiones (inluída la interactiva) están en repositorios de código en github o launchpad, por lo que es posible colaborar en su mejora. Y están escritos en reStructuredText o Markdown y convertidos a libros con sphinx u otras herramientas.

No resulta sencillo decir «cual es mejor», cada una de las veriones tiene sus puntos fuertes y débiles:

  • Los que hemos hemos numerado como dos y como tres son los que tienen para mi un orden de capítulos más lógico. Por ejemplo trata listas, tuplas y diccionarios en capítulos contiguos mientras que en las otras versiones los diccionarios están separados del resto de tipos de datos. Pero en dos han juntado varios capítulos en uno sólo por lo que su lectura se hace algo más difícil. Además los capítulos sobre numpy, matplotlib y data handling no encajan muy bien como están escritos en un libro para principiantes. Por tanto a pesar de ser el más actualizado yo en principio descartaría esta versión.

    • El uno tiene algún material adicional respecto a los otros como capítulos sobre estructuras de datos más avanzadas (pilas, colas y árboles). Si bien creo que estos capítulos son de interés, tampoco pasa nada por prescindir de ellos en un primer contacto, porque hay otros libros más avanzados o más específicos que tratan mejor este tipo de temas.

  • El número tres (Think Python) tiene para mi otros alicientes como que algunos de los problemas y soluciones están resueltos en el github del autor. Es de los que siguen un orden más lógico, capítulos cortos, y una sección «debugging» al final de cada capítulo que explica «técnicas mentales» a la hora de depurar y construír un programa que resultan útiles. Además se puede comprar a través de Amazon, descargar gratuitamente en PDF, leer en html… Así que seguramente esta es la versión más recomendable.
  • La versión interactiva también me ha sorprendido gratamente. El texto no es tan bueno como el de Think Python, pero el poder jugar con el código mientras leemos el texto, da muchas opciones a alguien que se introduce en el lenguaje y le permite aprender sin tener que liarse con el entorno. Además la opción de debug (codelens en su terminología es especialmente útil para ver lo que pasa en el programa). Esta tambień es un opción recomendable.

Entre la opción interactiva y Think Python es difícil decidirse, si quieres avanzar rápido y tener una panorámica general, el libro seguramente es mejor, y la irrupción de cajas y botones en medio del texto menos molesta. Depende del estilo de aprendizaje de cada uno. Leer un par de capítulos de cada uno y decide tu mismo.

Si está revisión te ha ahorrado tiempo y quieres agradacerme el esfuerzo planteate donar usando el botón de la derecha, o simplemente dejar un comentario en esta entrada.

15 noviembre 2017 2 Comentarios

Libro: A Byte of Python de Swaroop C H

El libro «A Byte of Python» es uno de los que se suelen recomendar en las QA de como iniciarse en el desarrollo con Python. Es un libro corto, unas 120 hojas en la versión impresa que se puede ojear en apenas un par de horas. Está distribuído bajo licencia CC-by-sa 4.0 y el desarrollo se realiza en github. Al ser libre hay distintas versiones en la red, la canónica está en la página del autor y es la que se debería leer.

El libro hace un repaso básico a la sintaxis del lenguaje, sin entrar en demasiada profundidad en ningún tema y con ejemplos tipo «¡Hola mundo!». Tampoco se para demasiado en conceptos de teoría de la programación, como explicar que es una variable o un lenguaje interpretado pero si lo menciona. Eso sí, la terminología que emplea para hacer referencia a los conceptos es correcta.

Creo que es una buena guía si ya sabes algo de programación en otro lenguaje y quieres de una forma rápido poder empezar a hacer cosas con python, pero no es adecuado como primer contacto con el mundo del desarrollo.

11 noviembre 2017 Añadir comentario

Charlas “Programming Style” por Douglas Crockford

Otra de las series de charlas más conocidas de Crockford, son en las que habla de la importancia del estilo de código que empleamos.

A good style can help produce better programs. Style should not be about personal preferences and self-expression. Douglas Crockford

De esta serie creo que la más interesante es:

  • YUIConf 2011. 66′. Douglas Crockford. Programming Style & Your brain. En esta charla Crockford explica lo importante que es usar un estilo de código adecuado, y como hay estilos mejores que otros (según el lenguaje que estemos usando). Al programar no debemos tratar de demostrar lo listos que somos, si no escribir código para que otros puedan entenderlo, y hay estilos que favorecen esto además de reducir los bugs que podamos cometer. La charla se centra en Javascript y la herramienta JSLint, pero el porqué de usar un estilo y herramientas es importante vale para cualquier lenguaje.

Otras charlas similares serían:

Escogiendo un estilo de código

Crockford dice que al escoger un estilo, debemos priorizar (y en ese orden) que:

  1. Evite errores (aunque sea errores que raramente sucedan)
  2. Sea legible. Comuniqué claramente su intención al resto de programadores. Y se debe preferir esto sobre ahorrar memoria o velocidad.

Algunos comentarios de estilo de su charla con los que estoy de acuerdo

La llave va a la derecha

La llave va a la derecha, porqué el siguiente código en js produce un error silencioso:

[cc lang=»javascript»]
return
{
ok: false
};
[/cc]

Mientras que esto funciona correctamente:

[cc lang=»javascript»]
return {
ok: false
};
[/cc]

Usar Strict Equality Comparison

No usar nunca «==» usar siempre «===». Evita resultados indeseados al hacer casting.

No usar el slash para generar strings multilínea

No usar el slash para generar strings multilínea porqué si hay un espacio después del slash se produce un error
[cc lang=»javascript»]
«hola \
mundo»
[/cc]

Usar siempre las llaves para los bloques de código

Usar siempre las llaves aunque sea para escribir en la misma linea [cci lang=»javascript»]if (flag) { doSomething(); }[/cci]

No usar pre/post incremento

No usar pre/post incremento. En lugar de ++x o x++ usar x+=1; Los primeros casos obligan a pensar más en lo que se está haciendo de que valor va a tener x cuando se ejecute algo, e introduce más errores.

No usar asignación transitiva

No usar la asignación transitiva var a = b = 0. Porqué no está claro si lo que se quería hacer era
[cc lang=»javascript»]
var a = 0,
b = 0;

b = 0;
var a = b;
[/cc]

En los switch usar siempre break

En el switch usar siempre break después de cada caso. Es muy fácil usarlo mal, y que se presente un bug difícil de depurar.

Forma de usar las IIFE

Al usar Immediately Invocable Function Expression, preferir la tercera forma que aparece aquí
[cc lang=»javascript»]
function () {
…
}(); // Syntax error!

(function () {
…
})(); // Bien

(function () {
…
}()); // Mejor. Queda más claro lo que estamos haciendo según Crockford
[/cc]

Usar siempre el «;»

Usar siempre el ; para evitar el Automatic Semicolon Insertion que puedo provocar bugs difíciles de depurar.

Algunos con los que puedo estar de acuerdo, pero debería revisar

Declaración de variables en el top

Como javascript no tiene (¿tenía?) block scope, si no sólo function scope, hay que declarar todas las variables en la parte de arriba y declarar todos los métodos antes de usarlos. Esto deja claro como funciona el hoisting en javascript que puede introducir errores. Esto incluye el no declarar variables dentro del for – for (var i …) {, para dejar claro que la variable i es válida para toda la función, y tiene valor antes (undefined) y después del for (el último valor que haya tomado en el bucle). Habría que ver como se conjuga esto con let, const, …

Espacio entre paréntesis y resto de elementos

Una serie de reglas sobre donde y como usar los paréntesis, del tipo:

  • No space before ( when used to invoke a function
  • No space between a function name and a parameter list
  • One space between all other names and (

Uso equivocado según crockford:

  • foo (bar);
  • function foo (b) {…}
  • function(x) {…}
  • return(a+b);
  • if (a=== 0) {…}

 

1 julio 2017 Añadir comentario

Charlas «The better Parts» por Douglas Crockford

Seguramente las charlas más conocidas de Crockford son las basadas en su libro The good parts y o algunas más modernas a las que llama de «The better parts» donde revisa alguna de sus anteriores prácticas y comenta features de ES6.

Dentro de esta serie de The Better Parts se pueden encontrar varias dadas en distintas momentos, entre ellas.

  • The Better Parts | .concat() 2015. El problema de esta charla es que no se ven las transparencias (y a pesar de ser similares) a las slides que usa en otras se hace un poco complicado seguir el hilo. Creo que una de las novedades de esta charla respecto a otra es cuando habla de los Template Literals.
  • The Better Parts. Infoq. Agosto/2014. Las transparencias de esta charla, que también valen de guía para el resto están aquí. La de la JSConfUY me pareció un poco más fluída que esta. Pero hay al menos dos secciones que en esta están mejor explicadas o ampliadas la que llama en las transaprecias New Good Parts in ES6 que empieza en el minuto 12 y acaba en el 25. Y cuando explica su constructor pattern (slide 46) a partir del minuto 34. El constructor también lo explica en la JSConfUY pero aquí se entienda mejor.
  • The Better Parts – JSConfUY Septiembre/2014. En apareciencia esta tiene un poco más de carga filosófica que la de Infoq.

Yo ví la charla de JSConfUY, ojee la de concat, y fuí a algunas partes concretas de la de InfoQ. Mi recomendación es que veas la de InfoQ. O si no que veas de la JSConfUY y las partes concretas que mencionó de la de InfoQ.

A nivel contenidos las charlas son similares.

Arranca con una cita de Saint-Exupéry, «It seems that perfection is attained not when there is nothing more to add, but when there is nothing more to subtract.» y de como los programadores deben buscar la perfección. Por ello hace incapié en uno de sus habituales, que un lenguaje nos dé un montón de características no significa que tengamos que usarlas todas si no sólo las «buenas».

Luego habla de jslint y de su libro de «The good parts». Combate algunas de las criticas que se hacen de jslint y defiende porqué el estilo de desarrollo no es simplemente un «acuerdo», si no que hay estilos mejores que otros, y que escribir de una determinada forma elimina bugs y por tanto te acerca a la perfección.

Continúa con una mini revisión de esas buenas partes de JavaScript en general mezclándolo con como debería ser el lenguaje del futuro (tiene otra charla sobre esto llamada The Post JavaScript Apocalypse), centrándose en su propuesta para un nuevo tipo de datos numérico llamado DEC64.

Y termina hablando un poco de JSON.

The better parts

Entre las prácticas que menciona como mejores están.

* No usar for. Sólo array.forEach y derivados
* No dice nada de for..of, supongo que en el momento todavía no habría una propuesta al respecto, pero si habla de evitar for..in y emplear unicamente Object.keys(object).forEach
* Y dice que tampoco usa ya while si no que usa una construcción de este tipo

function repeat(func) {
if (func() !== undefined) {
return repeat(func);
}
}

Como vemos, y como el mismo dice, estás Better Parts van en la línea de usar JavaScript como un lenguaje funcional.

Especial atención merece su nuevo patrón para la construcción de objetos. Hace tiempo que aboga por no usar new pero también ha dejado de usar Object.create, de hecho ha dejado de usar this para evitar problemas de seguridad. También defiende que la herencia basada en prototipos es una mejor idea que las jerarquías clásicas. Porqué, las jerarquías son en general erróneas, y además suelen establecerse al principio del proyecto, cuando menos información se tiene de como debe ser.

Su patrón para la construcción de objetos tendría este aspecto


function constructor(spec) {
let {member} = spec,
{other} = other_constructor(spec),
method = function () {
// member, other, method
};

return Object.freeze({
method,
other
});
}

Donde

  • spec será generalmente un object literal, que permite inicializar el objeto
  • member será un miembro privado de la clase, no accesible desde el exterior
  • Esta construcción permite que se pueden llamar tantas veces como se quiera a otros constructores (other_constructor), de ese modo se obtiene herencia múltiple, y se pueden copiar, las funciones de interés de esos otros objetos en nuestro objetos
  • También puedo crear nuevos métodos (method), que tendrán acceso a los miembros privados, a otros métodos, a lo que proporcione other. En este caso method es público porque se devuelve al llamante pero con el mismo diseño podría ser un método privado
  • Se devuelve un nuevo objeto (el literal dentro de freeze, con todos los métodos de interés)
  • Lo congela para hacerlo inmutable, con todas las implicaciones que eso trae. Seguridad, comparaciones más sencillas, …
  • Comenta que este sistema tiene un costo en memoria. Al contrario que otras estrategias que reaprovechan los métodos, en esta method sería creado cada vez. Pero a cambio es muy rápido, porque no hay que recorrer el prototype chain para encontrar las claves si no que están directamente en el propio objeto

En otro momento, me gustaría hacer un artículo con los distintos patrones de creación de objetos de Javascript, pero debo decir que este me convence mucho, porque debe ser de las pocas veces que veo algo de este tema en JS que parece tener sentido a la primera. Lo que no comprendo es porque llama «constructor» a su función de ejemplo cuando en realidad es una «factory».

28 mayo 2017 Añadir comentario

Modelado de datos booleanos en la base de datos

Cuando definimos la información que un usuario puede visualizar o modificar a través de un formulario nos encontraremos datos aparentemente booleanos. Por ejemplo: ¿Hay un pozo en esta aldea?.

La primera aproximación para implementar esta información es poner un checkbox en el formulario y definir el campo como booleano en la base de datos.

CREATE TABLE aldea (id serial, pozo boolean);

Haciéndolo de este modo existen varios posibles problemas:

  • A nivel usabilidad. Que pasa si el usuario no sabe si hay un pozo. Lógicamente dejará el checkbox sin marcar, pero cuando se revise esa información no se podrá saber si a conciencia se dejo en blanco indicando que no había pozo, o si se desconocía el dato.
  • A nivel implementación. Por defecto, a no ser que la lógica implementada en cliente lo gestione de otra forma, en la base de datos almacenaremos un valor NULL y no un valor FALSE. Al tener valores nulos las queries que hagamos se pueden complicar, por ejemplo un SELECT * FROM aldea WHERE pozo IS FALSE; no nos devolverá los valores nulos. Si empleamos la tabla para hacer un informe o exportarla a una hoja de cálculo tendremos que lidiar con los nulos, …

Por tanto cuando modelemos una información que parezca binaria, preguntémonos (y preguntemos al cliente) si es necesario distinguir entre falso, y desconocer el dato. Si estamos en la segunda situación debemos huír de usar checkboxes y emplear otro tipo de widget, como un combobox donde el usuario pueda escoger «Existe», «No existe» o dejar en blanco si no conoce el dato. A nivel implementación la información del combobox la guardaremos en general como un texto o un tipo enumerado. Y si eres un producto owner que usa algún tipo de documento para definir el modelo de datos a los desarrolladores asegurate siempre de especificar esta información.

Habrá situaciones en las que aún presentando al usuario la información mediante un combo, nos interese modelar el campo como un booleano. En este caso la lógica por encima de la base de datos sería la responsable de traducir el campo en blanco por un nulo, el ‘Existe’ por un true y el ‘No existe’ por un false.

Cuando modelemos un campo en la base de datos que sea verdaderamente binario para evitar confusiones deberíamos implementarlo de esta forma.


CREATE TABLE aldea (
id serial,
pozo boolean NOT NULL DEFAULT false
)

Addendum

Cuando trabajamos con campos booleanos que admiten el valor nulo nos podemos encontrar un problema adicional al hacer migraciones de la base de datos. Imaginemos que tenemos un campo contador de tipo boolean, y que en la base de datos tenemos valores a true, false y null. Si a posteriori decidimos cambiar contador por un sistema de medida, con opciones como Contador, Manual, Volumétrico, … hacer la migración hacia adelante será sencillo.


UPDATE myschema.mytable SET sistema_medicion = 'Contador' WHERE contador IS true;

Pero el revert no sería tan sencillo, porque habremos perdido la información de nulos y false.

9 febrero 2017 Añadir comentario

Cliente de correo para Linux

Llevo usando aplicaciones web para usar el correo desde que abrí mi primera cuenta de mail. Gmail tiene tiene una interfaz genial, funciona en cualquier dispositivo y es rápido. El único problema es que tus correos no son tuyos. Estos días he tenido que cerrar una vieja cuenta de correo en gmail y para descargar los mails a modo de copia de seguridad he estado revisando clientes de correo de escritorio:

  • Que se lleven bien con gmail/imap, respetando etiquetas, …
  • Que permitan agrupar conversaciones al modo en que lo hace gmail
  • Que tenga buenas funcionalidades de búsqueda
  • Que no use Qt

En las recomendaciones y quejas de clientes sobresalen un par de ellos:

  • Claws Mail. Que no parece tener el «modo conversación»
  • N1. Que tiene una pintaza, algo así como el Atom de los clientes de correo, el problema es que todo el correo pasa a través de sus servidores o tienes que instalar uno en local.
  • Evolution. Que parece pesado, poco documentado y con demasiada gente quejándose de bugs.
  • Thunderbird.
  • Geary.

Tanto Thunderbird (con plugins) como Geary (por diseño) cumplen todos los requisitos, pero la búsqueda de Thunderbird parece mejor, y la mayor base de usuarios y documentación hace que sea el que vaya a probar.

Siguiendo la documentación de thunderbird, la documentación sobre IMAP de Google es fácil de configurar. Si hay problemas de conexión se puede deshabilitar el acceso seguro en google o habilitar OAuth2 en thunderbird como método de autenticación.

Para configurarlo bien hay que revisar un poco la configuración pero en general funciona todo sin problemas.

15 mayo 2016 Añadir comentario

Portátiles entre 600 y 700€ para CAD y Diseño

Estos días un amigo me pidió ayuda para comprar un ordenador. Los requisitos:

  • Ofimática, CAD y Diseño sin grandes necesidades
  • Entre 600€ y 700€
  • Pantalla de 15.6»

Échando un ojo a lo que había en el mercado empecé a hacer una hoja de cálculo. Descarté todas los que tuvieran una gráfica peor que una 820M y un micro peor que un i5-4210 porque son configuraciones habituales en ese rango de precios. Luego comparando precios, características y preferencias personales llegamos a esta lista.

Están separados dos rangos de precios los que están más cerca de 600 y los que están más cerca de 700, con mis preferencias resaltadas en amarillo. Si alguién está buscando un portátil así espero que le sirva. El hecho de hacer la hoja de cálculo ya lleva un buen rato, igual hay espacio aquí para hacer un scrapper. ¿Algún programador en la sala :P?

8 agosto 2015 Añadir comentario

Buscando un portátil – Listado de candidatos entre 900 y 1150€

Decidido el tipo de procesador que queremos, podemos echar una ojeada a las páginas de distintas tiendas.

Lo mejor es entrar en varias, ver lo usables que son en función de como puedes filtrar los portátiles, y quedarse con aquellas en que la búsqueda sea más o menos rápida. Como mínimo porque nos dejan filtrar por rango de precios y tipo de procesador.

Después de ver varias yo he usado las siguientes porque me parecieron las más cómodas:

Lógicamente buscando en varias tiendas salen portátiles repetidos, pero está bien para comparar hay veces que de una tienda a otra el mismo portátil puede variar en 100€. Así que una vez escogido uno toca buscar una tienda fiable con el precio más barato.

De la búsqueda anterior me he quedado por distintos motivos con unos 25 portátiles. Esta es una tabla resumen:

Y por lo que se ve, hay varias decisiones clave que tomar (a parte del precio):

  • Resolución de la pantalla.[1] [2]Sin duda yo me iré a 1920×1080 antes que a 1366×768. Creo que la inversión merece la pena para el eclipse
  • Tarjeta gráfica. Tras leer un poco descarto las Ati RM9M265X que vienen con los Toshiba de la lista. Tienen muy buena pinta, sobre todo el P50B-11M, pero veo que podrían dar problemas con linux [1] [2] [3]. Hay que investigar un poco el resto de nvidia de la lista, por si es un factor clave para descartar más ordenadores o no. Aunque basándome en estas tres páginas las he clasificado
  • 8 o 16 de RAM. O ver si es ampliable a posteriori.
  • Si hay una diferencia real entre los discos duros de 5400 rpm y los de 7200 rpm
  • Si el VGA es fundamental o llega con HDMI. Con el uso que yo le doy al ordenador, teniendo en cuenta que cualquier pantalla moderna soporta HDMI y que cada vez más proyectores sólo tienen HDMI, la existencia de VGA no es un factor clave

Disco Duro

El rendimiento de un disco duro no viene sólo determinado por las rpm, pero averigüar el modelo concreto que monta cada ensamblador y comparar es una tarea demasiado complicada como para que la búsqueda compense. En general la gente parece notar diferencias entre los 7200 rpm y los de 5400 rpm [1] [2][3].

Los discos duros híbridos (con cache SSD) parecen dar un mejor rendimiento que los tradicionales [1] [2] [3], aunque también hay algunas opiniones a favor de los de 7200 sobre 5400 híbridos o de que depende del uso que se le de.

Así que como criterio para descartar portátiles elimino los de 5400 que no tiene cache ssd y/o no tiene 16 GB de RAM y no le doy relevancia a los hibridos sobre los de 7200 rpm.

Tarjeta gráfica

En esta página tenemos un listado de las diferentes gráficas de nvidia. Siendo las que nos interesan, ordenadas de mayor rendimiento a menor:

Tras investigar un poco no he sido capaz de determinar que tarjeta gráfica necesito o cuales son las ventajas reales de unas sobre otras si no te dedicas a jugar. Entre lo poco que he creido entender está que si vas a trabajar con resoluciones altas (como es mi caso al usar monitor extendido) debería priorizar la cantidad de RAM sobre la velocidad de la misma. Es decir mejor 4GB de RAM DDR3 que 2GB de RAM DDR5. Si te vas a dedicar a jugar es mejor priorizar al reves.

Además revisando las especificaciones de las tarjetas, la 740, la 840, la 850 y supongo que la 845 también, tienen soporte para la misma resolución, así que entre estas creo que cualquiera es suficiente para mis requisitos, por lo que puedo descartar los portátiles más caros cuya diferencia principal sea mejor gráfica.

 Conclusiones

Con el listado final de 8 ordenadores donde todos cumplen los requisitos que me había fijado quedan pocas decisiones para descartar.

  • Fundamentalmente si sacrificar rendimiento a cambio de quedarme con mountain en formato ultrabook. Lo que no me interesa en este momento teniendo en cuenta que mi portátil actual es de 2.9 kg y eso no me molesta.
  • Si 16 de RAM es un requisito. Que en principio para mi no lo es, aunque que sea ampliable a 16 sí.
  • Si alguna review de alguno de los modelos que quedan aporta algo muy negativo que lo descarte o algo muy positivo que le de puntos sobre los más económicos

Resto de artículos de esta serie

21 marzo 2015 11 Comentarios