What is PrettyKit?

We’ve lately been seeing an interesting change on the interfaces of many iOS apps. The glossy effects and gray striped backgrounds nowadays look boring and démodé, and the tendency points to the use of gradients and patterns.

The latest apps introduced by Apple, such as Reminders, Game Center or Find My Friends use patterned backgrounds or leather-like navigation bars, for example. What’s more, a new API to allow more appearance customization has been introduced in the iOS SDK. Although it is an interesting step, it is not big enough, as this API is only compatible with iOS 5 or higher and, in some cases, the new appearance’s properties might be not enough.

And here’s where PrettyKit comes.

PrettyKit is a library composed by a set of new widgets and UIKit subclasses that gives you more control to customize your interfaces. You will be able to easily change backgrounds, draw gradients, drop shadows and more. This library will help you to beautify your iOS apps and give them a modern look. Besides, it is fully compatible with iOS 4.0.

Besides, if you need even more control, you can subclass any Pretty class, which will give you even more possibilities. Or, if you’re feeling brave, fork the code, it’s open source ;)

Check this video to see what you can do with PrettyKit:

PrettyKit possibilities

You might say:

Until now you’ve only said that PrettyKit is cool and blah blah, but I want to see if it’s actually that cool.

Challenge accepted!

Let’s say the interface of your application has been built with Interface Builder and it looks like this:

We’ll now apply some PrettyKit customization, take a look:

1. Go to the Interface Builder file, and change the classes of the navigation bar and tab bar to PrettyNavigationBar and PrettyTabBar.

2. Let’s change now the cells’ appearance. First, #import "PrettyKit.h". In your tableView:cellForRowAtIndexPath:, change all references to UITableViewCell to PrettyTableViewCell. And for each cell you work with, add this line [cell prepareForTableView:tableView indexPath:indexPath];. And in your tableView:heightForRowAtIndexPath: add [PrettyTableViewCell tableView:tableView neededHeightForIndexPath:indexPath] to your desired height. Nice, huh?

3. The final touches. First of all, the background is still stripped, so we’ll create a new one and we’ll set it. Then, let’s make the cells even nicer, less rounded. To change the cell’s corner radius, just do this when initializing them: cell.cornerRadius = 5;.

This is the final code to generate the cells. Lines 5 and 7 have changed the UITableViewCell reference to PrettyTableViewCell. Lines 8 and 11 are new. And heightForRow now has a sum. That’s all. That simple.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath
{
    static NSString *CellIdentifier = @"Cell";

    PrettyTableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:CellIdentifier];
    if (cell == nil) {
        cell = [[[PrettyTableViewCell alloc] initWithStyle:UITableViewCellStyleDefault reuseIdentifier:CellIdentifier] autorelease];
        cell.cornerRadius = 5;
    }

    [cell prepareForTableView:tableView indexPath:indexPath];
    cell.textLabel.text = [NSString stringWithFormat:@"Text %d",indexPath.row];

    return cell;
}

1
2
3

-(CGFloat) tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath {
    return tableView.rowHeight + [PrettyTableViewCell tableView:tableView neededHeightForIndexPath:indexPath];
}

Not convinced yet?

OK. Have you seen those several-button cells in the video?

They are part of PrettyKit. And using them is really easy, look at this code:

1
2
3
4
5
6
7

gridCell.numberOfElements = 3;
[gridCell setText:@"One" atIndex:0];
[gridCell setDetailText:@"Detail Text" atIndex:0];
[gridCell setText:@"Two" atIndex:1];
[gridCell setDetailText:@"Detail Text" atIndex:1];
[gridCell setText:@"Three" atIndex:2];
[gridCell setDetailText:@"Detail Text" atIndex:2];

Or this line, if you’re using the segmented control row:

1

segmentedCell.titles = [NSArray arrayWithObjects:@"1", @"2", @"3", @"4", nil];

And they use blocks, so it’s easy to add a callback when any button is pressed:

1
2
3
4

gridCell.actionBlock = ^(NSIndexPath *indexPath, int selectedIndex) {
  // whatever you want to do
};

Performance

Take a look at this Twitter article about smooth animation. As they state, jerky scrolling ruins the user experience. PrettyKit is entirely drawn with CoreGraphics. That means it’s really fast, and the scrolling, which usually causes headaches when customizing cells, is very smooth.

Documentation

PrettyKit has a very nice documentation, that might help you more than once. It is written with appledoc syntax, so it will integrate very well with the rest of your project when generating the docs.

That’s all folks. If you’ve got any doubt or opinion to share, comment here, tweet me at @vicpenap or visit the project’s page at github.

Para utilizar Guard y guard-livereload para recargar automáticamente la ventana de nuestro navegador cuando guardamos un fichero, instala ambos, configura el plugin de LiveReload para tu navegador y listo.

Si quieres más detalles, sigue leyendo ;)

Antes de nada

Aunque todo lo que se comenta en este post es útil sea cual sea la tecnología con la que trabajas, las herramientas que vamos a utilizar son todas del ecosistema Ruby, así que va a ser necesario tener una versión de Ruby instalada y funcionando. Si tu operativo es Linux o Mac OS X ya deberías tenerlo de serie. De todos modos, puedes informarte en Google :)

Bundler

Bundler es una herramienta para gestionar las dependencias de proyectos Ruby. Su instalación es muy sencilla:

1

$ gem install bundler

Para especificar las dependencias de nuestro proyecto crearemos un fichero Gemfile en el que indicaremos las gemas a instalar:

1
2
3
4

source 'http://rubygems.org' # gems source

gem '1st_gem_name' # 1st dependency
gem '2nd_gem_name' # 2nd dependency

Para instalar las gemas listadas en el Gemfile (y todas sus dependencias) bastará con ejecutar un comando:

1

$ bundle

Este mismo comando nos permitirá actualizar las gemas cada vez que cambiemos el Gemfile.

Por último, si alguna gema proporciona ejecutables, para asegurarnos de que todas las dependencias están cargadas, tendremos que ejecutarlos a través de Bundler mediante el comando bundle exec:

1

$ bundle exec some_gem_executable

Guard

Ya sabemos cómo instalar gemas cómodamente usando Bundler. Ahora hablemos de Guard.

Guard es una herramienta Ruby que permite automatizar tareas cuando se detecta algún cambio en el sistema de ficheros. ¿Para qué lo vamos a usar? En este caso para recargar automáticamente la ventana del navegador cuando se detecte un cambio en las plantillas de la vista, las CSS o el JS.

Este sería nuestro Gemfile:

1
2
3
4

source 'http://rubygems.org'

gem 'guard'
gem 'guard-livereload'

Es decir, vamos a instalar Guard y un plugin o guard llamado guard-livereload (como puedes ver en el wiki del proyecto, la lista de guards disponibles es muy extensa). guard-livereload recarga la ventana del navegador cuando detecta cambios en ficheros (más detalles cuando hablemos de LiveReload).

Guard tiene un DSL muy sencillo para describir qué hay que hacer cuando cambia un fichero y qué ficheros hay que “viligar”. Por defecto, Guard leerá estas reglas de un fichero Guardfile. El nuestro tiene esta pinta:

1
2
3
4

guard 'livereload' do
  watch(%r{public/.*}) # matches any file under the public directory
  watch(%r{views/.*})  # matches any file under the views directory
end

Traducido: cada vez que un fichero dentro de los directorios public o views cambie (en este caso el proyecto es una aplicación Sinatra y ahí están los ficheros CSS, JS y HTML/Erb), LiveReload se encargará de refrescar nuestro navegador. Si tienes dos monitores (o uno con el suficiente espacio) puedes decir adiós a Alt+Tab-Ctrl+R o la secuencia de teclas que uses habitualmente: podrás editar tu código y ver los cambios sin moverte del editor. Fuck yeah!

LiveReload

Te estarás preguntando dónde está la magia. Pues aquí: LiveReload, una herramienta que hace precisamente esto que estamos describiendo en este post: recargar la ventana del navegador cuando detecta cambios en los ficheros del proyecto. ¿Y por qué no la usamos directamente? Pues porque como dice en su propio sitio web:

if GUI is not your thing, guard-livereload is the next best choice.

Además, guard-livereload es la única opción para Linux :)

Ya hemos instalado guard-livereload en el paso anterior, así que nos queda instalar la extensión correspondiente en nuestro navegador (aquí LiveReload para Firefox y aquí LiveReload para Chrome).

Poniéndolo todo a funcionar

Suponiendo que estamos usando la configuración por defecto de LiveReload (si no es así puedes configurar el plugin del navegador y configurar las opciones disponibles de guard-livereload de manera acorde), solo nos resta:

• Activar LiveReload en el navegador, en la pestaña en la que estemos viendo nuestra aplicación en desarrollo (es decir, hacer click en el iconillo de LiveReload, uno que pone “LR”).
• Lanzar guard mediante el siguiente comando:

1

$ bundle exec guard

• Trabajar mientras miramos cómo el navegador se actualiza solo cada vez que guardamos un fichero :)

1

:mksession my_session_file.vim

Más tarde cuando quiero restaurar esa sesión, puedo hacerlo invocando Vim con la opción ‘-S’:

1

vim -S my_session_file.vim

Y listo, ya tengo el editor como lo había dejado :)

Por cierto, el fichero que describe la sesión no es más que un montón de vimscript en el que se restablece el valor de todas las variables, mappings, etc. tal y como estaban en el momento en el que guardamos la sesión (bueno, esto no exactamente así: lo que restablezca o no dependerá de nuestra configuración. Más detalles en la ayuda).

Plugins

Hay plugins para gestionar las sesiones de una manera menos pedestre. No los he probado, pero supongo que funcionan :). Una búsqueda en Google y ya salen unos cuantos. Y si usas Vundle para gestionar tus plugins (recomendación de @madtrick) aparecen más de 10 plugins relacionados con la gestión de sesiones.

Problemas

Es posible que alguno de los plugins que tengas instalados den problemas a la hora de restaurar la sesión y aparezcan algunos errores. Supongo que no es lo más común, porque yo tengo instalada una buena cantidad de plugins y no tengo problemas, pero ya sabes, si es tu caso: Google.

A part of the EOP is a WebSocket endpoint built in Erlang (with cowboy). To run some automated test on this endpoint I needed a WebSocket client in Erlang that was conformant to the last WebSocket version, wich now is the RFC6455 for WebSocket version 13. To my dispair I could only find clients (not many) that were built for old versions of the protocol.

So…I had two choices:

• Skip all the tests wich involved using a client.
• Build a client wich implements the RFC6455.

So…being me I built it.

The result is wsecli, a WebSocket client writen in Erlang wich implements the aforementioned WebSocket rfc6455. It was a nice toy-project to get a deeper understanding of:

• Erlang’s bit sintax which kicks asses when having to deal with data at a bit/byte level. Oh, fuck yeah!
• WebSocket protocol itself.

Using this project as a base I’m now working on wsock, a library to help you build WebSocket clients (like wsecli) and servers in Erlang. That’s for a future post (woo, too may posts piling up).

If you have any doubt or question comment or tweet me at @madtrick.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

$ irb -r
>> require 'net/imap'
=> true
>> session = Net::IMAP.new("mail.server.com", 993, true)
=> #<Net::IMAP:0x19fb2c0 @tagno=0, @continuation_request=nil, ...

>> session.capability
=> ["ACL", "BINARY", "CATENATE", "CHILDREN", "CONDSTORE", "ENABLE", "ESEARCH", "ID", "IDLE", 
    "IMAP4REV1", "LIST-EXTENDED", "LITERAL+", "MULTIAPPEND", "NAMESPACE", "QRESYNC", "QUOTA", 
    "RIGHTS=EKTX", "SASL-IR", "SEARCHRES", "UIDPLUS", "UNSELECT", "WITHIN", "ESORT", "I18NLEVEL=1", 
    "SORT", "THREAD=ORDEREDSUBJECT", "AUTH=PLAIN"]

>> session.authenticate('PLAIN', "user", "plain_password")
ArgumentError: unknown auth type - "PLAIN"
  from /home/david/.rvm/rubies/ree-1.8.7-2010.02/lib/ruby/1.8/net/imap.rb:359:in `authenticate'
  from (irb):4

¡Ups!. Consultando la documentación observamos que la librería sólo soporta los métodos de autenticación, LOGIN y CRAM-MD5. Ningún problema. net/imap permite registrar mecanismos de autenticación adicionales.

1
2
3
4
5
6
7
8
9
10
11
12

class ImapPlainAuthenticator
  def initialize(user, password)
    @user = user
    @password = password
  end

  def process(data)
    return "#{@user}\0#{@user}\0#{@password}"
  end
end

Net::IMAP::add_authenticator('PLAIN', ImapPlainAuthenticator)

1
2
3
4
5
6
7

$ irb -r
>> require 'net/imap'
>> require 'imap_plain_authenticator.rb'
>> session = Net::IMAP.new("mail.udc.es", 993, true
=> #<Net::IMAP:0x1b0edb0 @tagno=0, @continuation_request=nil, ...
>> session.authenticate('PLAIN', "user", "plain_password")
=> #<struct Net::IMAP::TaggedResponse tag="RUBY0001", name="OK", ...

Voilà, C’est fini.

¿Qué pasa con Ruby 1.9.x?

En la documentación no lo indica, pero si utilizáis Ruby 1.9.x veréis que sí incorpora soporte AUTH=PLAIN y no es necesario que registréis esta extensión.

La novedad más destacable no es el cambio de look, si no el cambio tecnológico. Abandonamos Mephisto (que llevaba con nosotros desde 2006) y adoptamos Octopress.

Octopress es un framework que utiliza Jekyll como base y que facilita la creación y gestión de blogs. Incopora una plantilla HTML5 semántica, un layout “responsive”, temificación con Compass y Sass, integración con Disqus, una pléyade de plugins y alguna cosilla más. Para nosotros, más que un cambio tecnológico implica un cambio en la manera de trabajar: en lugar de pegarnos con la administración de Mephisto nos dedicamos a abrir un editor, escribir, hacer commits y desplegar.

En cuanto al look (o al no-look), aun no estamos del todo satisfechos, pero no queríamos seguir con el blog parado. Podéis considerar que es un work in progress y aun tenemos que ajustar cosillas. Consideramos que lo más importante es tener buenos contenidos en el blog y últimamente no hemos estado muy productivos. Esperemos que este reset venga acompañado de muchos e interesantes posts.

P.D.- si nuestros amigos de Autoradio han perpetrado el mismo atentado con todos los paquetes, pegándoles una gran etiqueta sobre el lazo y la tarjeta, la mayoría no habréis visto esta última. Lo sentimos. Venía a felicitar las fiestas, nada más. Lo bueno estaba dentro :)

Lo sentimos, pero los comentarios están cerrados

.rvmrc al rescate

Los ficheros .rvmrc valen para mucho más que fijar la versión de ruby o el gemset que queremos usar en un proyecto concreto; son scripts de shell en toda regla. Podemos, por lo tanto, utilizarlos para modificar el PATH y dar prioridad a nuestro .bin, arreglando el problema.

1
2

rvm use ruby-1.9.2-p290
export PATH=./bin:$PATH

La alternativa: rbenv

Si esto os parece incómodo o sucio, siempre podéis utilizar rbenv en lugar de RVM. Yo he empezado a usarlo en casa y estoy bastante contento; en lo básico es muy parecido a RVM y es menos intrusivo con el shell.

Lo sentimos, pero los comentarios están cerrados

En Trabe hemos decidido hacer una interpretación particular de esta iniciativa, dándole la vuelta: en lugar de dejarnos crecer el bigote, hemos decidido sacrificar nuestras barbas por tan solidaria iniciativa.

Para que seáis conscientes de lo impactante del proceso, hemos preparado una miniweb que resume por lo que hemos pasado estos días: http://trabesoluciones.com/movember. Os animamos a todos a visitarla. Cuidado, es posible que no os podáis resistir a nuestro encanto bigotudo :)

También podéis visitar nuestro espacio en la web de Movember en http://mobro.co/trabe para ver más fotos y poder aportar vuestro donativo. Venga, no seáis agarrados, que es por una buena causa :)

¡Gracias a todos!

Update Nos habíamos olvidado de hacer mención especial a @bugyou y agradecerle desde aquí que cediera su bigote de forma desinteresada :)

Lo sentimos, pero los comentarios están cerrados

1. Branching

1
2
3
4

$ svn copy http://my.svn.com/myrepo/trunk \
           http://my.svn.com/myrepo/branches/featurex \
           -m "Created featurex branch from trunk"
$ svn switch http://my.svn.com/myrepo/featurex

2. Algunos commits después: Merging

1
2

$ svn switch http://my.svn.com/myrepo/trunk
$ svn up

Tomemos la revisión que nos indica el comando y llamémosla YY.

1

$ svn log --stop-on-copy http://my.svn.com/branches/featurex

Cojamos ahora, la revisión del último mensaje de log y llamémosla XX.

1
2

$ svn merge -rXX:YY http://my.svn.com/branches/featurex
$ svn ci -m "Merge branch featurex into trunk [XX:YY]"

3. Un poco de limpieza (opcional)

1
2

$ svn delete http://my.svn.com/branches/featurex \
             -m "Removed featurex branch"

Lo sentimos, pero los comentarios están cerrados

Con pry-buffers lo que queremos es juntar lo mejor de 1) y 2), permitiendo manejar buffers persistentes. Veamos cómo es una sesión pry con pry-buffers.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

pry(main)> buf
    ...  Aquí un rato con el vim (o con lo que uséis)...
This is de default buffer
pry(main)> buf -l
Available buffers: default
pry(main)> buf -s default
puts "This is the default buffer"
pry(main)> buf test
    ...  Aquí otro rato más con el vim...
This is a test 2
pry(main)> buf -s test
Buffer test contents:
puts "This is a test #{1 + 1}"
pry(main)> buf -l
Available buffers: default, test
pry(main)> buf -d test
Buffer test cleaned

En resumen, podéis usar y gestionar tantos buffers como queráis y estos serán persistentes entre comandos (y entre sesiones Pry).

Para lograrlo hemos uttilizado el mecanismo de extensión de Pry, que permite definir nuevos comandos a través del fichero de configuración de pry ($HOME/.pryrc) o mediante plugins (como pry-doc o pry-remote). Nosotros hemos optado por la segunda opción. Si os apetece probarlo instalad la gema

1

gem install pry-buffers

Y si tenéis curiosidad, el código fuente está en github.

Esta es una gema para uso interno (vamos, para que Fuco sea feliz) pero esperamos que os resulte útil a alguno.

Happy Prying!

Lo sentimos, pero los comentarios están cerrados

Como no quiero resultar pesado, este post tiene dos versiones: la corta, que va al grano y da una solución, y la extendida que explica un poquillo las cosas para el que quiera entender el problema y la solución (TL;DR).

La versión corta

Si vuestra VPN publica varios dominios de búsqueda Tunnelblick sólo se va a quedar con él último dominio (un fallo conocido y documentado: issue 144). Para solucionarlo sólo es necesario explorar los contenidos de la aplicación Tunnelblick.app (versión 3.2beta32) y modificar el contenido del fichero client.3.up.tunnelblick.sh (en Contents/Resources/) con el script que os dejo en este gist (el diff por un lado y el script completo por otro). Configurais la VPN para usar el método de establecimiento de DNS “Asignar servidores de nombre (alternativa 1)” (en inglés “Set nameserver (alternate 1)”) y listo.

La versión extendida (con explicaciones y todo eso)

En Trabe tenemos un DNS interno y varios dominios de búsqueda y los resolv.conf de nuestras máquinas se parecen a esto:

1
2

search pizza.it moussaka.gr tortilla.es
nameserver 192.168.1.10

La VPN está configurada para que envíe esta información a los clientes, utilizando directivas push en la configuración del servidor OpenVPN:

1
2
3
4

push "dhcp-option DNS 192.168.1.10"
push "dhcp-option DOMAIN pizza.it"
push "dhcp-option DOMAIN moussaka.gr"
push "dhcp-option DOMAIN tortilla.es"

Tunnelblick tiene un modo de funcionamiento que teóricamente detecta esta información y modifica el resolv.conf de la máquina cliente de manera adecuada (“Asignar servidores de nombre (alternativa 1)” en castellano y “Set nameserver (alternate 1)” en inglés). Por desgracia no funciona correctamente y sólo tiene en cuenta la última entrada, es decir, que nuestro resolv.conf una vez conectados queda así:

1
2

search tortilla.es
nameserver 192.168.1.10

El problema está en el script que detecta estas opciones y le indica al cliente que modifique su configuración. La cosa comienza a torcerse en la línea 105 del script client.3.up.tunnelblick.sh:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

while vForOptions=foreign_option_$nOptionIndex; [ -n "${!vForOptions}" ]; do
	{
	vOptions[nOptionIndex-1]=${!vForOptions}
	case ${vOptions[nOptionIndex-1]} in
		*DOMAIN* )
			domain="$(trim "${vOptions[nOptionIndex-1]//dhcp-option DOMAIN /}")"
			;;
		*DNS*    )
			vDNS[nNameServerIndex-1]="$(trim "${vOptions[nOptionIndex-1]//dhcp-option DNS /}")"
			let nNameServerIndex++
			;;
		*WINS*    )
			vWINS[nWINSServerIndex-1]="$(trim "${vOptions[nOptionIndex-1]//dhcp-option WINS /}")"
			let nWINSServerIndex++
			;;
	esac
	let nOptionIndex++
	}
done

La opción DOMAIN se trata como un campo univaluado y hay que modificar el script para tratarlo como multivaluado, al igual que se hace con el campo DNS. En este gist podéis encontrar el script modificado. Para ponerlo a funcionar os remito a la versión corta del post ;).

Ya hemos notificado todo esto a la gente que hace Tunnelblick y esperamos que lo tengan en cuenta para próximas releases y evitar tener que andar parcheando la aplicación.

Happy VPNing!

Lo sentimos, pero los comentarios están cerrados

Coincidiendo con el arranque de un par de proyectos Rails 3.1 hemos aprovechado para actualizar la gema: hemos modificado levemente el API para hacer SugarfreeConfig un poco más configurable y que se pueda usar fuera de Rails (eliminado la dependencia con ActiveSupport) y hemos cubierto todo el código con tests (utilizando specs de MiniTest para comparar su uso con RSpec, pero esa es otra historia).

Más detalles acerca de SugarfreeConfig en github: https://github.com/davidbarral/sugarfree-config.

Lo sentimos, pero los comentarios están cerrados

La nueva versión de Rails (y aquí me refiero a Rails 3.x) es un melocotonazo de miedo.

A nivel interno, las “tripas” de Rails han cambiado para mucho mejor y a nivel externo las mejoras se dejan notar en todas las partes del framework. En concreto, tras la experiencia de estos pasados meses, nosotros nos quedamos con esto:

Lo bueno

Bundler

Rails 3 y Bundler se integran tan bien que pensar en cómo desarrollábamos antes, cuando no había Gemfile, me da escalofríos. Con Bundler, la gestión de dependencias es chicle para cualquiera :).

Routing

El nuevo DSL para la definición de las rutas de la aplicación es mucho más directo y sencillo de utilizar. En concreto, la sintaxis controlador#acción, que permite decir cosas como:

1

 match 'login' => 'sessions#new'

ActiveRecord Query Interface

El API para consultas del “nuevo” ActiveRecord (básicamente, Arel) simplifica muchísimo el trabajo a la hora de escribir y utilizar los modelos de la aplicación. Cambiamos los hashes con miles de parámetros por el encadenamiento de métodos (y esto nos permite refactorizar el código de acceso a datos de una manera mucho más natural, ¡claro!).

ActiveModel

Gracias al esfuerzo de modularización llevado a cabo en Rails 3, extender el framework con nuestro propio código (y hacerlo sin recurrir a trucos oscuros) es casi trivial. En el caso de ActiveModel, proporciona mecanismos para disponer de todas las ventajas de los modelos Rails en nuestras clases: validación, internacionalización, callbacks, integración con los helpers de generación de formularios, etc.

Asset Pipeline

La joya de la corona de la versión 3.1. Como en el caso de ActiveRecord y Arel, aquí los cambios se pueden resumir en la adopción de Sprockets para la gestión de los assets de la aplicación. Además, el asset pipeline ha llegado acompañado de una decisión polémica: apostar por CoffeeScript como solución “por defecto” para escribir Javascript (sin escribirlo, claro); y de otra no tan polémica: Sass para escribir CSS.

En general, la impresión es muy positiva: CoffeeScript es mucho más compacto que Javascript y es realmente sencillo de usar (aunque creo que es muy interesante tener un background más o menos amplio en cuanto a Javascript, principalmente cuando llega el momento de depurar el código generado :P). No es un cambio que me parezca fundamental y escribir Javascript no me parece “peor”… pero el hecho es que hemos utilizado CoffeeScript :D

Sass (o LESS), por contra, no ofrece discusión. Escribir CSSs “a pelo” es tan desesperante que la mínima mejora es bienvenida. Y en el caso de este tipo de “extensiones” a las CSS, las mejoras son tantas y de tanto calado (reglas anidadas, mixin de estilos, variables, operadores, funciones, bucles, etc.) que uno lo tiene claro: jamás volveré a escribir CSSs “a pelo” si puedo evitarlo.

jQuery

Adiós Prototype, hola jQuery. Arrastrados por las anteriores versiones de Rails, siempre habíamos sido más “prototyperos”. Y ahora, arrastrados de nuevo por Rails, estamos reconvirtiéndonos y adaptándonos a jQuery. Y la verdad es que la experiencia, dejando a un lado los primeros — y tambaleantes — pasos, ha sido muy positiva. Es posible que se deba a haber adquirido un mayor y más profundo conocimiento del lenguaje (Javascript, me refiero) y no sea solo cuestión del cambio de framework, pero la sensación que me queda es que el “estilo jQuery” está más directamente ligado al Javascript que el “estilo Prototype”. Lo dicho, impresiones mías.

ActiveSupport

Hay mucho más en ActiveSupport, pero sólo voy a mencionar una cosa. Ahora se puede decir:

1
2

1.in? [1, 2, 3] #=> true
4.in? [1, 2, 3] #=> false

Y esto hacía falta :D

Lo no tan bueno

El asset pipeline, con todas sus ventajas, también trae de la mano algunos inconvenientes:

• A la hora de desplegar en producción hay que ser especialmente cuidadoso con la configuración y con las referencias interassets (por ejemplo, las imágenes en las hojas de estilos). Hay nuevos helpers para ayudar con esto, así que no es para tanto.
• En desarrollo todo funciona un poco más lento por la necesidad de compilar los coffeescripts y los scss. No es una barbaridad, pero a veces se nota.

Y poco más en este apartado :D

En resumen

Lo dicho: un melocotonazo de miedo.

Lo sentimos, pero los comentarios están cerrados

Esperemos que en el futuro nuestros caminos vuelvan a juntarse. Hasta entonces: ¡Suerte con todo!. Nos vemos.

Lo sentimos, pero los comentarios están cerrados

1 PFC, 3 años, 687 bollos, 5496 horas y 8mil risas después: hoy cierro el mejor período de mi vida en @trabe y comienza mi viaje. Ojalá se repita

Nosotros teníamos que despedirnos de él con un post que he estado posponiendo porque no encontraba las palabras adecuadas para decirle “hasta luego” a este pedazo de ser humano. Después de una épica fiesta de despedida y una resaca descomunal sigo sin encontrarlas. No voy a intentarlo. Lucas, sólo te diré que te queremos un montón, que te echaremos mucho de menos y que esta es tu casa y siempre lo será. Graciñas por todo.

Disfruta de tu nueva aventura transoceánica y envíanos muchas postales :)

Lo sentimos, pero los comentarios están cerrados

En Trabe estamos realizando algunos proyectos con Spring MVC y Thymeleaf como motor de plantilas y de momento las sensaciones son buenas. A ver si la gente que está directamente involucrada en estos proyectos se anima a hacer un post introductorio (venga, vamos, a qué estáis esperando).

Os invito a que le echéis un ojo al proyecto, a que lo probéis y que, si os interesa, colaboréis con Dani enviando parches, escribiendo tutoriales, etc. Y para terminar, y como curiosidad, deciros que Dani también es el padre de Jasypt una librería de encriptación que lleva tiempo dando guerra y que seguramente muchos de vosotros ya habréis usado.

Lo sentimos, pero los comentarios están cerrados

1
2
3
4
5
6
7
8
9
10

trustStore = self.readConf('java.trustStore')
if not trustStore == '':
  if os.path.exists(trustStore):
    print "~ using keystore \"%s\"" % trustStore
    java_args.append('-Djavax.net.ssl.trustStore=%s' % trustStore)
    trustStorePassword = self.readConf('java.trustStore.password')
    if trustStorePassword == '':
      print "~ WARNING: No java.trustStore.password key found in config. You need a password to use a keystore"
    else:
      java_args.append('-Djavax.net.ssl.trustStorePassword=%s' % trustStorePassword)

Ojo a los espacios, que esto es Python ;)

Lo sentimos, pero los comentarios están cerrados

Lo sentimos, pero los comentarios están cerrados

¡Welcome fiera!, esperamos que disfrutes de la Trabe aventura.

Lo sentimos, pero los comentarios están cerrados