Travis: Integración Contínua con Github

En este post (tuvimos que desempolvar el dashboard de entradas de Bonus4Code debido al parón vacacional…) vamos a comentar una forma sencilla y gratuita para llevar a cabo prácticas de integración continua(CI del inglés Continuous Integration) sin necesidad de montar vuestro propio servidor (Jenkins o similares).

Travis CI

Travis es un servicio alojado de integración continua que se integra con Github. Esto permite loguearnos con nuestra cuenta de Github e importar aquellos proyectos para los que queramos ejecutar tareas de IC.

Tiene especial soporte para los siguientes lenguajes: C, C++, Clojure, Erlang, Go, Groovy, Haskell, Java, JS (Node.js), Objective-C, Perl, PHP, Python, Ruby y por último (pero no por ello menos importante…para nada,vamos :P) Scala.

Cada vez que realizamos un push a nuestro repositorio de Github, Travis detecta dicho cambio y ejecuta las tareas que tenga planificadas.

¿Cómo lo configuramos?

• Paso 1: Entramos en travis-ci.org y nos logueamos con nuestra cuenta de Github. En este caso se mostrarán los repositorios públicos de nuestra cuenta de Github. En caso de que quisiéramos realizar la misma tarea pero para nuestros repositorios privados, el proceso sería el mismo sólo que accediendo a través de travis-ci.com.
• Paso 2: Una vez nos hemos logueado y se sincronizan los repos desde Github, accedemos a la página de nuestro perfil para proyectos open-souce o privados (dependiendo del paso anterior). A partir de aquí, podremos habilitar el service hook para aquellos repositorios de los que tenemos acceso administrativo. Cambiamos de OFF a ON aquellos repositorios que queramos habilitar
• Paso 3: Añadimos fichero de configuración .travis.yml en la raíz de nuestro proyecto en Github. En este fichero de configuración indicaremos a Travis qué tareas queremos que se ejecuten en nuestro proceso de integración continua. Para un proyecto Scala tendría el siguiente aspecto:

  language: scala
  scala:
    - "2.10.3"
  jdk:
    - oraclejdk7
  script:
    - sbt $TASKS
  env:
    - TASKS='test'
  notifications:
    email:
      - myemail@somehost.com
  

  Cómo se puede ver, la lectura es bastante sencilla: Definimos el lenguaje del proyecto (Scala), la versión que utilizaremos del compilador (Scala 2.10.3), el JDK a descargar (oraclejdk7), los scripts que se ejecutarán (en este caso sólo uno, que es ejecutar SBT), las variables de entorno y el mail donde se notificará el resultado.

• Paso 4: Comprobar que se ejecuta por primera vez. Una vez añadido el fichero .travis.yml al repositorio, realizamos un push sobre el repositorio en Github. Esto debería añadir el primer build a la cola de Travis y empezará tan pronto como haya un nodo disponible para el lenguaje de programación de tu proyecto.
  Para empezar un proceso de construcción, se puede hacer un push con cambios en el proyecto, o ir a la página de Github ‘Webhooks y servicios‘ y usar el botón Test Hook para Travis (Este método solo funciona a partir del primer build).
  Una vez ejecutado el proceso, desde la página de administración de Travis deberíamos poder ver algo del siguiente estilo:
  
  
• Paso 5: Indicar el estado de CI en el Readme.md de tu proyecto. Para indicar el estado de integración continua basta con añadir al fichero Readme.md de tu proyecto lo siguiente:

  Title1
  ======================
  
  [![Build Status](https://travis-ci.org/your-user/your-project.svg?branch=master)](https://travis-ci.org/your-user/your-project)
  
  This is some introduction text ...
  
  

Conclusiones

Si todo el proceso de configuración ha ido correctamente, veremos el estado de CI en la página principal de nuestro proyecto de Github. Por ejemplo, en el siguiente proyecto se indica que el building es correcto (Build Passing) :

Hasta el próximo post amijos 🙂

 

Can has lolcode plz ?

Cuando surgió en Internet la moda de los Lolcat (WTF), no tardaron en surgir las primeras mentes brillantes en crear un lengaje de programación para hacer honor al fenómeno de la red de redes. LOLCODE es un lenguaje de programación esotérico creado en 2007 por Adam Lindsay, investigador del Departamento de Computación de la Universidad de Lancaster.

CAN SEE AN XAMPL ? AWSUM THX

La sintaxis del lenguaje se basa en abreviaturas de palabras utilizadas en las imagenes de los Lolcat.
Un hola mundo en LOLCODE sería algo de este estilo:

HAI
CAN HAS STDIO?
VISIBLE "HAI WORLD!"
KTHXBYE

PLZ, WAT IS A DSL ?

Un DSL, es un Domain Specific Language, y en este artículo vamos a mostrar como crear uno usando los mecanismos que nos ofrece Scala para embeber DSLs utilizando su libertad de sintaxis.

VISIBLE DSL XAMPL

Por tanto, si queremos crear una instrucción que represente el hecho de importar una librería, en LOLCODE sería

CAN HAS STDIO?

Usando notación infija podemos generar la primera parte de la instrucción usando un objecto CAN con un método HAS:

object CAN {
	def HAS(x:X):Y = ???
}

Como podeis comprobar, el método HAS tiene aún por definir un parámetro y el tipo devuelto. Y dado que de alguna forma hay que poder especificar la librería que se desea importar, el parámetro misterioso X (que intringulis) pasa a ser la librería a importar.

trait Library { val name: String }
object CAN { def HAS(library: Library): Y = ??? }

Y la librería estándar que queremos importar podría ser perfectamente un ‘case object’:

case object STDIO extends Library { val name = "stdio" }

Ahora,¿qué hay acerca del tipo devuelto? Dado que aún hay que poder añadir el signo de interrogación al final, es fácil pensar que el tipo misterioso ‘Y’ debe ser algo que tenga un método ‘?’ y que devuelva una instrucción. Para ello empleamos una clase auxiliar o helper:

class Can(l: Library) {
	def ?: Statement = ???
}

DIZ DOESNT RUN

Como ya hemos dicho antes, consideramos que cada instrucción es el elemento atómico de un programa. Además de instrucciones, un programa puede tener una o varias librería importadas, así como variables de entorno, un flag para indicar si la sintaxis es correcta y otro para indicar si se ha elevado una excepción.

Podríamos definir un programa en Scala de la siguiente forma:

case class Program (
  val env: Map[String, Any],
  val statements: Seq[Statement[_]],
  val imports: Set[Library] = Set(), 
  val isSyntaxOk: Boolean = false,
  val exceptionThrown: Boolean = false){
}

Donde una instrucción o Statement no es más que un transformador de estado y ejecutar dicha instrucción equivale a devolver un programa modificado además de un cierto output:

trait Statement[Output]{
  def execute(implicit context: Program):(Program,Output)
}

No obstante se ve más fácil con un ejemplo: Si deseamos implementar una instrucción que importa una librería al programa lo haríamos de la siguiente forma:

  case class ImportStatement(library: Library) extends Statement[String]{
    def execute(implicit context: Program):(Program,String) = (
    	context.copy(imports=context.imports + library),
    	s"LIBRARY $library WOZ SUCCSFLLY IMPORTED!")
  }

IT STILL DOESNT RUN 😡

…Y para ejecutar el código que hemos creado necesitamos un intérprete del lenguaje. Uno facilito de fabricación casera podría ser un actor Akka, que recibiera un programa y se mandara a sí mismo el programa modificado sin la última instrucción ejecutada.
Algo del estilo:

class Interpreter extends Actor {
  def receive = {
    case program: Program => 
      if (!program.isSyntaxOk) 
      	sender ! WrongSyntax(program)
      else program.statements.toList match {
      	case (nextStatement::restOfStatements) => 
      		val (updatedProgram,output) = nextStatement.execute(
      			program.copy(statements=restOfStatements))
      		println(output)
      		self ! updatedProgram
      	case _ => 
      		println("Finished!")
      }
  }
}

I WNT MOR PLZ …

Puedes ver el resto de implementación (para un conjunto muy reducido de instrucciones) en el siguiente enlace de Github:

https://github.com/JSantosP/lolcode-dsl

Y hasta aquí mi aportación.

Hasta la próxima 🙂

Scala: selftypes

Tal y como comentamos en entradas anteriores, hoy toca hablar de selftypes (¿cómo?¿lo qué?¿mande?).

Se ilustra muy bien su utilidad con el siguiente ejemplo.
Suponed que estamos definiendo nuestro objeto singleton que representa un mostrador de facturación de un aeropuerto:

object Facturacion{
  type Identificador = String
  var idMaletas: List[Identificador] = List()
}

hasta aquí sin problemas, ¿no? Ahora pongamos que queremos añadir un método para procesar un registro de facturación: Un señor que quiere volar quiere facturar sus maletas.

object Facturacion{
  type Identificador = String
  var idMaletas: List[Identificador] = List()

  def facturar(nombre: String, idMaletas: List[Idenntificador) = {
    println(s"Registrando maletas del señor $nombre")
    idMaletas ++= idMaletas //WTF
  }
}

Exacto. Ocurre que tenemos el mismo nombre para designar tanto a la variable como al parámetro de la función.
La primera lógica es cambiarle el nombre a uno de los dos.

…pero ocurre que no queremos XD Porque nos guste el nombre tal y como está, porque no tenga sentido que sea otro, porque si digo 3 veces ‘selftype’ frente al espejo aparece Odersky y me saca los ojos…Elegid vuestro motivo favorito

¿La otra opción? Hacer referencia a la enclosing class (enclosing object en este caso) de la siguiente forma:

object Facturacion{
  esteMostrador =>
  //...
}

de manera que ahora podemos efectuar la asignación que antes no podíamos:

object Facturacion{
  esteMostrador =>

  type Identificador = String
  var idMaletas: List[Identificador] = List()

  def facturar(nombre: String, idMaletas: List[Idenntificador) = {
    println(s"Registrando maletas del señor $nombre")
    esteMostrador.idMaletas ++= idMaletas //YOLO!
  }
}

Los motivos que normalmente aconsejan el uso de una anotación selftype suelen ser:

• Reforzar una cierta clase/trait base para asegurarse de que tu inner clase solo puede ser heredada o usada en mixin dentro de ese tipo.
• Referenciar una clase exterior cuando se implementa una inner class.

Este último es el caso que nos atañe y, tenéis que reconocer, que como poco os acabo de arrancar una sonrisa con esta ventaja de Scala.

Hasta la próxima 🙂

Scala: tipos estructurales

Esta semana os traemos la magia de los tipos estructurales en Scala.
Directa a vuestras casas, motherfu subscribers.

Suponed que estáis usando en vuestro proyecto Scala, una librería de un tercero que tiene la siguiente clase:

class Printer {
  type DocumentId = Int
  val documentMaxNumber: Int = 3
  val address: String = "192.168.1.10"
  def queue(document: java.io.File): DocumentId = {
    //queue document and return its identifier
    //...
    Int.MaxValue
  }
  def dequeue(document: DocumentId): Unit = {
    //do some operations...
    //...and let's supose I've dequeued it...
  }
}

Una bonita clase que representa una impresora … o algo.
Pongamos, además, que tenéis en vuestro proyecto esta clase, que sí habéis definido vosotros y que simula el comportamiento de una impresora, sin llegar a implementar su lógica.

class MyPrinterMock {
  val address: String = "127.0.0.1"
  def queue(document: java.io.File): Printer#DocumentId = 1
  def dequeue(document: Printer#DocumentId)
}

Si ahora queremos definirnos en nuestra aplicación un método que reciba como argumento o una clase u otra para encolar un documento a la impresora, estaría muy bien definir un trait común al que extendieran ambas, pero eso no es posible (recordad que la clase Printer no es nuestra). De modo que tenemos varias opciones.

Opción A: El dinero

Podemos usar un Either:

object MyApp extends App{
  def queueAtPrinter(printer: Either[Printer,MyPrinterMock],documentPath: String) {
    printer match{
      case Left(realPrinter) =>
        println(realPrinter.address)
        realPrinter.queue(new java.io.File(documentPath))
      case Right(fakePrinter) =>
        println(fakePrinter.address)
        fakePrinter.queue(new java.io.File(documentPath))
    }
  }
}

Engorroso, ¿verdad? Repetimos código.

Opción B: La caja misteriosa

La otra opción es utilizar un tipo estructural.

type PrinterLike = {
  val address: String
  def queue(document: java.io.File): Printer#DocumentId
}

Este tipo simboliza «algo» que tiene un valor de tipo String denominado address y un método queue que recibe un File y devuelve un DocumentId.
De esta forma podemos definir el método ‘queueAtPrinter’ de la forma que sigue:

def queueAtPrinter(printer: PrinterLike,documentPath: String) {
  println(printer.address)
  printer.queue(new java.io.File(documentPath))
}

o incluso parametrizarlo sin utilizar el tipo PrinterLike:

def queueAtPrinter[P <: {val address: String
  def queue(document:java.io.File):Printer#DocumentId }](printer: P,documentPath: String) {

  //...
}

¿Qué escoger? Bajo mi punto de vista, lo más elegante es un tipo estructural.

Piénsalo, Lois: Un barco es un barco, pero la caja puede ser cualquier cosa, ¡incluso un barco!

Lo único que, como todas las cosas buenas, es importante no abusar. Los tipos estructurales hacen uso de las reflectiveCalls, es decir, reflexividad, y en función de cuanto lo uséis y la forma en que lo hagáis, esto puede impactar en el rendimiento de vuestra aplicación.

Tipos estructurales e Inyección de dependencias

Si recordáis en la anterior entrada sobre Cake Pattern, podíamos indicar que un trait o clase abstracta era dependiente de otros componentes.
Ahora que hemos visto tipos estructurales, imaginad cómo quedaría expresar que tu trait depende de algo que tiene un valor entero y otros componentes:

trait MiTraitDependiente {
  dependeDe: { val unEntero: Int} with OtroComponente =>
}
trait OtroComponente

No os perdáis la próxima entrega para Scala: selftypes 🙂

Scala: Cake Pattern

Aunque este blog no sea ni remotamente parecido a las mañanas de Arguiñano, hoy vamos a aprender a cocinar tartas…con Scala para solventar una cuestión de inyección de dependencias (¿cómo?¿lo qué?)

Inyección de dependencias

Supongamos que trabajamos coordinando un equipo de diseño de coches Bercedes Menz. Hay varias áreas de trabajo.
Un grupo se encarga de diseñar el chasis, otro de diseñar las ruedas y otro de diseñar el motor.
¿Cómo especificarías la composición del coche?

Empecemos creando las clases para Coche, Rueda, Chasis y Motor. Y les añadimos un poco de funcionalidad (para que tengan algo de chicha).

class Coche {
  val ruedas : List[_] = ???
  val chasis = ???
  val motor = ???
}
trait Rueda {
  val coeficienteAdherencia: Float
}
trait Chasis {
  val numero_puertas: Int
}
trait Motor {
  val potencia: Int
}

Ahora es cuando, de alguna forma, debemos indicar que Coche depende de todos y cada uno del resto de componentes, pero imaginad que tenemos que usar métodos estáticos para poder implementar las distintas piezas.
¿Qué opciones tenemos? Por una parte podemos parametrizar el coche y agregar esos componentes como miembros de la clase:

class Coche[R<:Rueda,C<:Chasis,M<:Motor]{
  val ruedas: Lista[R] = List()
  val chasis: C = C.newInstance()
  val motor: M = C.newInstance()
}

Mmmm no compila,tío ¿Por qué?

Porque hasta mi abuela se daría cuenta de que esos métodos ‘newInstance’ se encuentan definidos en el companion de las clases C y M. Bueno, se podría decir, pues en vez de parametrizarlo como

R<:Rueda

lo cambiamos por

R<:Rueda.type

Vale, y ahora es cuando te das cuentas de que llevas muchas horas programando a base de café y de que entonces parametrizar esa clase es absurdo, ya que estás haciendo explícitos los parámetros.

¡A cocinar, Carmen de Toledo!

La opción que se propone es la de usar el Cake Pattern, considerada como la respuesta de Scala para el patrón de inyección de dependencias (DI). Este patrón de diseño orientado a objetos, anima a que se le suministren los objetos instanciados en vez de crearlos la propia clase. Si lo aplicamos a nuestro ejemplo, podríamos indicar en la expresión del selftype, que nuestra factoría de coches tiene dependencia de 3 componentes:

trait FactoriaCoches {
  estaFactoriaDependeDe: ComponenteRuedas, ComponenteChasis, ComponenteMotor =>

  case class Coche(val ruedas: List[Rueda], motor: Motor, chasis: Chasis)

  def fabricarCoche = Coche(
    List(new Rueda, new Rueda, new Rueda, new Rueda), //...colina abajo
    Motor("NumeroDeBastidorNoInventadoParaNadaAunqueIgualDeLargo",90),
    Chasis(3))
}

Nótese que se pueden definir miembros y métodos basándose en el hecho de que, en el momento de composición de la factoría, se utilizarán dichos componentes.
Y ahora los componentes se definirían como:

trait ComponenteRueda{
  class Rueda{
    val coeficienteAdherencia: Float = 0.85
  }
  def tiempoFrenada(velocidad: Float, rueda: Rueda): Float = {
    //Aquí van unos cálculos complicados del copón.
    rueda.coeficienteAdherencia * 0.1
    //El resultado es, por ejemplo:
    1
  }
}
trait ComponenteChasis{
  case class Chasis(val numeroPuertas: Int)
}
trait ComponenteMotor{
  case class Motor(val numeroBastidor: String, val potencia: Int)
  def calculaPotencia(numeroBastidor: String): Int= {
    //Un par de llamadas a tráfico y te dicen que la potencia es
    115
  }
}

Es de apreciar el uso de inner classes en los componentes.
Una vez definidos los componentes, ya podemos componer nuestro objeto factoría:

object MiFactoriaDeCoches extends FactoriaCoches 
  with ComponenteRueda 
  with ComponenteChasis
  with ComponenteMotor

val miCocheDeLosDomingos = MiFactoriaDeCoches.fabricarCoche

Si se quisiera añadir otro tipo de rueda o de motor, bastaría con extender al componente en cuestión y luego usarlo en la instanciación del objecto:

trait OtroTipoDeComponenteRueda extends ComponenteRueda{
  //...
}
object OtraFactoriaDeCoches extends FactoriaCoches
  with OtroTipoDeComponenteRueda
  with ComponenteChasis
  with ComponenteMotor

En la próxima entrada veremos tipos estructurales y cómo podemos expresar inyección de dependencias basándonos en dichos tipos.
Y hasta aquí nuestra tarta de hoy.
Rica, rica, … y con fundamento 😉

Integración con WS en Scala con Akka-Camel

Hoy vamos a hablar de la integración con servicios web usando Akka. Si bien implementar dichos servicios puede o no ser un tostón (no soy muy fan de SOAP, la verdad…), la integración, dependiendo de según como estén hechos, puede resultar un tanto complicada (abrir y mantener conexiones, definir protocolos, …). Por eso vamos a plantear el uso de una herramienta con bastante comunidad de trasfondo como es Apache Camel.

Esta herramienta da soporte a la mayoría de EIPs (Enterprise Integration Patterns) que definen en su libro Gregor Hohpe y Bobby Woolf; pudiendo definir rutas estableciendo reglas que manipulan el flujo de datos en el proceso de comunicación. Por poner un ejemplo sencillo, supongamos que queremos consumir mensajes de una cola y escribirlos a fichero. Con Camel podríamos hacerlo usando su DSL de la siguiente forma:

context.addRoutes(new RouteBuilder() {
  public void configure() {
    from("test-jms:queue:test.queue")
      .to("file://test");
  }
});

Como podréis imaginar, estas rutas pueden complicarse todo lo que se quiera. En este caso, con lo que más nos interesa quedarnos de Camel, es con los conceptos de Consumidor y Productor, considerando consumidor aquel extremo del canal que se dedica a obtener mensajes de una cierta fuente, y productor al que se dedica a escribir mensajes (¬¬ … genius!).

Sin entrar muy en detalle de todos los elementos que integran Camel (rutas, endpoints, processors, …), hemos de decir que nos apoyaremos en un componente muy concreto de Camel: camel-cxf, que emplea el framework Apache CXF (nos aporta facilidades a la hora de construir o desarrollar servicios web de tipo SOAP, XML-HTTP, RESTful-HTTP, CORBA… con soporte para distintas capas de transporte como HTTP, JMS o JBI).

Pongamos como ejemplo que queremos crear un cliente para conectarse a un servicio web. Hemos escogido para ello un web-service de carácter público, que no requiere de autenticación, como es WeatherWS, que ofrece información meteorológica del área de Estados Unidos (aquí al lado). Los pasos de la receta son los siguientes:

Generando clases JAXB

Para que la transmisión de datos, que debe ser en XML, no sea la muerte a pellizcos, vamos a utilizar CXF para generar las clases JAXB (Java Architecture for XML Binding). Esta capa de abstracción nos evita trabajar con el XML crudo, pudiendo enviar instancias de estas clases y dejando que el proceso de serialización/deserialización sea transparente al desarrollador.

Para generar estas clases, usamos la herramienta wsdl2java que viene con apache-cxf, el cual podéis descargar de la web.

1. Descargarmos el fichero WSDL (http://wsf.cdyne.com/WeatherWS/Weather.asmx?WSDL) que contiene la descripción del servicio y lo renombramos a Weather.wsdl
2. Ejecutamos la herramienta wsdl2java y decidimos el directorio donde se van a generar (en nuestro caso indicamos el directorio de nuestro proyecto donde van las clases java) :

    wsdl2java -client -p com.cdyne.ws -d src/main/java Weather.wsdl 

Creando el Productor

Dado que Akka dispone de la extensión Camel, podemos ahora crear un actor para enviar peticiones síncronas utilizando la template de productor.

En primer lugar creamos el tipo de mensaje que representa una petición y que va a recibir nuestro actor, ante el cual va a reaccionar.

case class WeatherMessage
  body: java.util.List[String],
  headers: java.util.Map[String, Object])

Y para hacer el código un poco más legible en el cuerpo del actor, creamos un objecto helpers y codificamos en su interior el extractor Response que hará que la respuesta obtenida al hacer la petición sea más fácil de diseccionar para extraer los campos que queremos:

object Response {
  def unapply(obj: Object): Option[List[Any]] =
    try {
      Some(obj.asInstanceOf[MessageContentsList].toArray.toList)
    } catch {
      case _: Throwable => None
    }
}

Posible pregunta suscitada:

Yooo, eehhhh, es que no entiendo el extractor este que te montas. Te has querido molar y…

Tranquilos, ahora se verá mejor en la definición del actor.

En primer lugar creamos la clase:

class MyProducerActor extends Actor

y generamos una instancia de CamelExtension (Atención: ¡Sólo una por instancia de sistema Akka!)

val camel = CamelExtension(context.system)

Luego definimos la URI del endpoint,

val uri = "cxf:http://wsf.cdyne.com/WeatherWS/Weather.asmx?" +
  "serviceClass=com.cdyne.ws.WeatherSoap"

y por último definimos el comportamiento del actor (atentos al extractor de antes :P):

def receive = {

  case WeatherMessage(body, headers) =>
    camel.template.requestBodyAndHeaders(uri, body, headers) match {

      case Response(List(awd: ArrayOfWeatherDescription)) =>
        awd.getWeatherDescription().toList map format foreach println

      case Response(List(wr: WeatherReturn)) =>
        println(format(wr))

      case Response(List(fr: ForecastReturn)) =>
        println(format(fr))

      case response => println(response)

    }

}

Luego si queremos probar nuestro cliente, bastará con crearnos un productor y enviarle un WeatherMessage con los parámetros adecuados:

val myProducer = system.actorOf(Props[MyProducerActor])
val operation = "GetWeatherInformation"
val params: java.util.List[String] = List()
val request = WeatherMessage(params, Map(
  "operationName" -> operation,
  "soapAction" -> s"http://ws.cdyne.com/WeatherWS/$operation"))

myProducer ! request

Conclusión

De esta manera, es sencillo integrar nuestro sistema de actores Akka con servicios web. Si juntamos la potencia de Scala, con la escalabilidad de Akka y nos apoyamos en herramientas de gran versatilidad como son Camel o CXF podemos generar clientes WS de una alta calidad y sin traumarnos (Dejad que los SOAP se acerquen a mí…).

Tenéis disponible el código que se ha utilizado como ejemplo en Github.

Y como diría Salvador Raya:

«Cenquiu veri mach. Suscribi plis»

¿Eres un buen programador?

En la actualidad, uno de los mayores retos para las empresas de recruiting a la hora de seleccionar candidatos válidos para ser endorsados a un cliente es la de probar la valía de los individuos en base a lo que saben de programación (o dicen saber). Es por eso que surge Codility, una empresa cuya andadura comenzó en China, cuando su director ejecutivo diseñó una herramienta para ayudar a su equipo a elegir el mejor candidato en entrevistas técnicas. La idea evolucionó para convertirse en una startup que desarrolla y paquetiza dicho software. ¿El producto? Un sistema de evaluación que consiste en plantear un problema al candidato que debe resolver en menos de un tiempo estipulado usando el lenguaje en cuyas habilidades que el examinador/recruiter quiere comprobar que el candidato pilota. La herramienta cuenta con compilador/intérprete para los lenguajes más populares como C, C++, C#, Java, JavaScript, Pascal, Perl, PHP, Ruby, Python, VB.NET, SQL y Scala. Además permite añadir casos de prueba específicos para probar la solución al problema. Una vez implementada la solución para el problema (ojo que en muchos casos para obtener la solución perfecta se exige que la implementación cumpla ciertas restricciones de complejidad espacio/temporales) se procede a publicar la respuesta, la cual llega directamente al recruiter que solicitó la prueba, generando un informe del siguiente estilo: Actualmente Codility es muy habitual en empresas de recruiting de UK y US; y puede probarse para testar tus habilidades mediante la demo o en la sección «Challenge yourself».

Y si el tener en cuenta el tiempo te parece mucha presión …

Para los pacientes, los que no tengan prisa y que simplemente quieran un desafío está el Proyecto Euler. Si bien no sirve para medir la calidad de tus toneladas de líneas, este proyecto sirve para ejercitar tus habilidades de programación y consta de una serie de problemas matemáticos y/o programación que suponen un reto, ya que requieren algo más que nociones matemáticas para ser resueltos. La motivación del Proyecto Euler es la de proveer de una plataforma para introducir a aquellas personas que así lo deseen en áreas poco familiares y el aprendizaje de nuevos conceptos de una manera divertida. La plataforma permite registrarse de manera gratuita e ir publicando las soluciones a los, hasta ahora publicados, 455 problemas; de manera que siguiendo un sistema de logros se busca mantener el interés del usuario en la resolución de los citados problemas matemáticos.

En resumidas cuentas …

Mientra que Codility te permite tener una visión más detallada sobre el grado cualitativo de las soluciones que aportas a determinados problemas, ProjectEuler te permite ejercitar poco a poco tus habilidades como programador, mantenerlas al día y libre de oxidación. ¡Happy coding!

Sublime Text

i bien es cierto que todo el mundo tiene un IDE preferido para programar en cualquier lenguaje, los hay que son más osados y que viven al límite. Y es por eso que deciden echarse al monte con un editor de texto y el compilador de turno (he visto rayos-C y programadores tirando de vi y javac más allá de la puerta de Tannhauser). Muchas veces es por friquismo, por minimalismo y otras es porque simplemente el IDE se queda corto cuando quieres exprimir el lenguaje sin necesidad de florituras. En este post me gustaría hablar de Sublime Text, un editor de texto en toda regla, esencial cuando aprendes a usarlo.

La criatura en cuestión ve su primera versión en enero de 2008 de la mano de su creador Jon Skinner y desde entonces viene distribuyéndose de manera gratuita, aunque para evitar un molesto aviso de que no has pagado la licencia (¡cómo se te ocurre!) es preciso aportar una pequeña cantidad que ronda actualmente los 70 dólares americanos. Con esa salvedad, la funcionalidad es completa desde el primer momento.

Características principales

En realidad enumerarlas todas sería para escribir un blog entero (mmm espera …) pero entre las más usadas  y más destacadas, se encuentran las siguientes:

• Multicursor (Ctrl + clic)  permite seleccionar múltiples cursores a lo largo del texto y poder escribir, borrar o seleccionar sobre todos ellos simultáneamente
• Multiselección (Ctrl + D) cada vez que se presiona, se selecciona la siguiente coincidencia del texto seleccionado.
• Resaltado de sintaxis configurable
• Minimapa del documento (muestra en miniatura el documento actual para desplazarse por él más rápidamente).
• Keybindings configurable
• Búsqueda de símbolos (Ctrl + P) permite buscar símbolos/ficheros dado el conjunto de proyectos disponibles
  

  Búsqueda de símbolo

• Resaltado de indentación (Ctrl + Shift + M) selecciona el contenido que se encuentra encerrado entre dos llaves, paréntesis, corchetes.
• Build systems (Da soporte nativo a la compilación de proyectos Java, Python, C++,Haskell,Ruby, …) que permite configurar la compilación de los ficheros que creemos/editemos con Sublime Text

Plugins

Ni que decir tiene, que Sublime cuenta además con una API basada en Python, que permite la implementación de plugins. A través del Package Control se pueden instalar plugins disponibles a través de repositorios Github o BitBucket.

Ejemplo de instalación de paquete desde Package Control

En resumidas cuentas …

Por todo lo antes mencionado, y dado que es multi-plataforma y que se puede combinar su uso con el de cualquier compilador (a veces sin que esto sea realmente necesario); considero esta como una de las herramientas indispensables para el desarrollo de software en la era actual. ¡El editor suizo de todo buen programador! Preparado para recibir escarnio público por parte de la gente UNIX que programa con consola. En 3 … 2 … 1 …