Buscar

2016/07/15

Usando FiraCode en Atom en Ubuntu


FiraCode es un font que soporta ligaduras para algunos símbolos que se suelen usar en programación, haciéndolos más fáciles de leer.

https://github.com/tonsky/FiraCode

Para usarlo en Atom (en Ubuntu 14.04):

atom-text-editor {
  ...
  text-rendering: optimizeLegibility;
}

Y para prevenir que se hagan ligaduras dentro de cadenas o expresiones regulares:

atom-text-editor::shadow .string.quoted,
atom-text-editor::shadow .string.regexp {
  -webkit-font-feature-settings: "liga" off, "calt" off;
}

Referencias:

2016/07/09

Vistas esquemáticas

En el diseño gráfico, la vista de alambre ayuda a abstraerse de los detalles y concentrarse en la estructura. Sería demasiado complicado e incómodo tener que trabajar todo el tiempo con la vista final. Además de innecesariamente costoso.

Sin embargo, muchas veces desarrollamos software trabajando todo el tiempo con la vista final.

Sería util poder contar con una especie de vista de alambre, además de a vista final. Esa vista esquemática pueda ayudar a abstraernos de los detalles estéticos de la interfaz y permitir apreciar mejor la estructura de la aplicación, o el flujo de solicitudes y respuestas.

El desarrollo de una vista de alambre podría ayudar también a construir un mejor software.


2016/05/24

Copiar un DVD en Linux Ubuntu




Usando Brasero en Ubuntu Linux 14.04

Una forma práctica:
  • Crear un iso del dvd origen
    1. Insertar el dvd en la lectora
    2. Abrir Brasero (incluido con Ubuntu)
    3. Click en Disc Copy
    4. Select disc to copy: el dvd de origen
    5. Select a disc to write to: Image File
    6. Click en Create Image
  • Quemar el iso en el dvd de destino
    1. Insertar el dvd en la grabadora
    2. Abrir Brasero (otra vez, para que reconozca el disco insertado)
    3. Click en Burn image
    4. Select a disc image to write: la imagen iso
    5. Select a disc to write to: el dvd de destino
    6. Click en Burn

2016/04/27

Reutilizar código

Hay programadores que parecen tomar la reutilización de código como un mandamiento que hay que cumplir mecánicamente para ser un buen programador.

Pero, como aprendimos con los diez mandamientos, la bondad de algo no está tanto en obedecer mecánicamente sino en comprender el por qué.

[Leer más]

2016/04/16

Sobre frameworks

Algunos desarrolladores dicen que prefieren no usar frameworks.

Empiezan desde cero y van completando el sistema con ayuda de los patrones y librerías que les parecen más adecuados.

Felicidades, eso es un framework. Cualquier desarrollador que quiera corregir o agregar algo al sistema tendrá que familiarizarse con las peculiaridades de ese nuevo esquema.

Seamos claros. Siempre se usa un framework. Si no es el de los demás, es el tuyo. Si no lo tienes hecho, irá surgiendo en el proceso.

¿Cuál es la ventaja de un framework propio? Que si el desarrollo es reciente probablemente estés muy familiarizado con él y puedas hacer cualquier cosa más rápido y mejor que alguien que no lo conoce (todos los demás).

En cierto modo, usar un framework propio, alimenta la ilusión de falsa competencia, porque eres el mejor en el juego (que nadie ha practicado tanto como tú).

Por supuesto que hay proyectos que requieren una solución a la medida, particular y específica. ¿Pero pertenece tu proyecto a ese grupo exclusivo de clientes que necesita un sastre? ¿O es como el 90% de los proyectos usuales? Quizás seas un buen costurero, quizás seas un buen sastre, pero, ¿que es lo que realmente necesita el cliente? ¿se sentirá cómodo en la playa con sus shorts de diseño? (el cual no puede forzar mucho porque no ha sido tan probado como los más baratos shorts que pudo haber elegido).

Muéstrame alguien que reniegue de usar un framework conocido y posiblemente encontremos que, aunque sea buen programador, no domina ninguno. Es natural querer usar lo que mejor manejamos, pero no es justo negar la virtudes de lo que no hemos probado o aún no conocemos a profundidad.

No existe tal cosa como un proyecto hecho sin frameworks, sólo con estándares. Lo que en realidad hay es un nuevo framework surgido en el transcurso del desarrollo, impregnado con las particulares opiniones del desarrollador sobre como se deben hacer las cosas correctamente, probablemente con escasa documentación y comunidad mínima (esas cosas requieren más horas hombre que las que pueda pagar cualquier cliente).

Existe la posibilidad de que el nuevo framework tenga alguna ventaja sobre los demás. Entonces, la manera más eficiente de que evolucione es que se vuelva open source. Si realmente es bueno, la comunidad llegará para usarlo, probarlo, documentarlo y difundirlo.

Encontrarás muchas razones por la que un proyecto open source es una mejor opción para hacer mejor software.

Cuando se hace software es importante reutilizar aquello que es bueno. Para reutilizar software, o para mantenerlo, con comodidad, es importante documentación y ejemplos. Para documentar y discutir casos y soluciones, una buena comunidad es grandiosa.

Pienso que un software es mejor cuanto más mantenible es. Algunos piensan que es mejor lo que corre más rápido, pero no se puede hacer muchas optimizaciones sobre código ilegible (y la optimización prematura es el camino a todo tipo de problemas). Otros piensan que es mejor software si usas menos líneas de código, pero no podrá evolucionar con facilidad si esa obsesión de menos líneas conduce a código menos legible que requiera numerosos hacks mentales tan sólo para aclarar la intención.

Además, el código lo va a correr una computadora, a la que le da lo mismo. Todas esas cosas de buenas prácticas, organización, frameworks, etc, no es por ellas, sino para la gente. Así que es más importante escribir buen código para la gente.

Pienso que un código es más mantenible si es más legible y si es más fácil de depurar. No importa que sea muy largo o parezca inocente, porque esa sencillez permitirá obtener versiones optimizadas también con facilidad.

Aprender un framework cuesta, pero usar un framework conocido puede hacer que tu proyecto sea más mantenible y una mejor opción para tu cliente. Si te gusta crear cosas nuevas, suele haber espacio para plugins (y mejor feedback para tu trabajo). Si quieres realmente ser autor de un framework, aprenderás mucho de la comunidad antes de intentar crear una. Puede que te ayude tener mejor perspectiva conocer a otros con muy alto nivel colaborando con entusiasmo en proyectos open source. Aprenderás a valorar la gran cantidad de tiempo y conocimientos que se puede condensar en un proyecto abierto, más allá de lo que puedas imaginar.

Más artículos