Mindfood

Polyglot Programming

arturoherrero — Tue, 27 Mar 2012 10:10:00 +0200

Polyglot Programming

How many programming languages do you know?

Most programmers know several languages. We, as web developers, work on a daily basis with Groovy, SQL, Bash Scripting, HTML, CSS, JavaScript…

Learning different languages allows us to solve problems with the most appropriate language and to explore new paths of thinking about computational problems.

Neal Ford coined the term polyglot programming, to refer about this topic.

I think it’s important in this day and age of polyglot programming to understand a variety of different languages, as they are the design tools we use to craft software. Just like regular engineers must understand the physical properties of different materials, we should understand the capabilities, strengths, and weaknesses of different languages. And when to apply them.

Neal Ford

Polyglot JVM and Polyglot Grails

Java has long been known simply as a programming language. Today, when thinking in Java we refer also a robust and mature development platform. Currently, the Java Virtual Machine (JVM) supports over 200 different programming languages.

These days we have been exploring different languages on the JVM: Java, Groovy, Scala, Clojure, JRuby… and how to incorporate them into a Grails project. We shared our experiences with others developers at Spring I/O 2012 and Codemotion 2012.

Hope you enjoy the slides.

Create your own Groovy type conversion

arturoherrero — Mon, 06 Feb 2012 10:00:00 +0100

Type conversion the standard way

Type conversion or casting is a programming language method for changing an object’s data type into another.

I’m sure you are familiar with this code that converts a String to an Integer.

def number = (Integer)'1'
def number = '1'.toInteger()
def number = '1' as Integer

If I want to convert the type of my own objects, I need to create a method to achieve this goal. I copy object properties to another object in a generic way; if a property exists on target object, I copy it from the source object.

class User {
    String name
    String city
    Integer age

    def toAdminUser() {
        def adminUser = new AdminUser()
        copyProperties(this, adminUser)
        return adminUser
    }

    def copyProperties(source, target) {
        source.properties.each { key, value ->
            if (target.hasProperty(key) && !(key in ['class', 'metaClass'])) {
                target[key] = value
            }
        }
    }
}

class AdminUser {
    String name
    String city
    Integer age
}

Now I can do something like this:

adminUser = user.toAdminUser()

Type conversion the fancy way

Great, but I want to use this fancy way to coerce one type to another:

adminUser = user as AdminUser

Simple, Groovy supports operator overloading and creating your own type conversion is really easy: we can override the asType() method.

class User {
    String name
    String city
    Integer age

    Object asType(Class clazz) {
        if (clazz == AdminUser) {
            def adminUser = new AdminUser()
            copyProperties(this, adminUser)
            return adminUser
        }
        else {
            super.asType(clazz)
        }
    }

    def copyProperties(source, target) {
        source.properties.each { key, value ->
            if (target.hasProperty(key) && !(key in ['class', 'metaClass'])) {
                target[key] = value
            }
        }
    }
}

Asynchronous tests with GPars (Osoco test gallery, part 4)

mgryszko — Mon, 16 Jan 2012 22:00:06 +0100

If you wrote multithreaded code in Groovy/Grails, I’m sure you stumbled upon the GPars library. It simplifies parallel processing - sometimes it’s as easy as wrapping a code fragment with a GPars closure, changing the iteration method (in our example from each to eachParallel) and passing the closure to a GPars pool. The library implementation handles the executor pool creation and adds new methods to collections.

Whenever I deliberately add multithreading, I always separate responsibilities (processing logic and concurrency handling). I wrap the single-threaded class with a new one, handing the parallel execution (creating a pool, managing threads, handling cancellation, etc.):

class MultithreadedProcessorService {
    ProcessorService processorService
    def threadPoolSize = ConfigurationHolder.config.threadPool.size

    void processMultithreaded(batches) {
        GParsPool.withPool(threadPoolSize) {
            batches.eachParallel { batch ->
                processorService.process(batch)
            }
        }
    }
}

class ProcessorService {
    void process(batch) {
        // some processing
    }
}

To test the multithreaded class you can you use Spock interactions. As opposed to Groovy and Grails mocks, they are thread-safe and you won’t get any weird and unstable results:

class MultithreadedProcessorServiceSpec extends UnitSpec {
    private MultithreadedProcessorService multithreadedProcessorService
    // Using Spock mocks because they are thread-safe
    private ProcessorService processorService = Mock(ProcessorService)

    def setup() {
        mockConfig('threadPool.size=2')
        multithreadedProcessorService = new MultithreadedProcessorService(
            processorService: processorService
        )
    }

    def 'processes batches using multiple threads'() {
        given:
        def batches = [[0, 1], [2, 3, 4], [5]]
        def processedBatches = markedAsNotProcessed(batches)

        when:
        multithreadedProcessorService.processMultithreaded(batches)

        then:
        batches.size() * processorService.process({ batch ->
            processedBatches[batch] = true
            batch in batches
        })
        assertAllProcessed(processedBatches)

    }

    private markedAsNotProcessed(batches) {
        batches.inject([:]) { processed, batch ->
            processed[batch] = false
            processed
        }
    }

    private void assertAllProcessed(batches) {
        assert batches*.value == [true] * batches.size()
    }
}

This post series present the best of Osoco tests - tests that were tricky or we are just proud of. You can find a runnable source code for this test and more in the Grails Test Gallery project shared on GitHub.

Grails base persistence specification (Osoco test gallery, part 3)

mgryszko — Wed, 11 Jan 2012 22:15:06 +0100

In our projects we include at least one integration test per domain class. We want to assure us that the GORM mapping is correct and the class is persistable in the target database. The test plan is simple:

create a valid persistable sample of the domain object
save it
clear Hibernate first level cache (i.e. flush and clear current session)
retrieve the object once again and compare it with the previously saved object. They must be equal as by equals() but be different object references

We put the steps above in a base abstract specification. In concrete specifications we implement merely the factory method spawning a persistable object instance.

abstract class PersistenceSpec extends IntegrationSpec {
    SessionFactory sessionFactory

    protected abstract createPersistableDomainObject()

    def 'persistable domain object should be able to be saved and retrieved'() {
        given:
        def persistableDomainObject = createPersistableDomainObject()

        when:
        def savedDomainObject = persistableDomainObject.save()

        then:
        savedDomainObject.id != null

        when:
        clearFirstLevelCache()

        def retrievedDomainObject = persistableDomainObject.class.get(savedDomainObject.id)

        then:
        savedDomainObject == retrievedDomainObject
        !savedDomainObject.is(retrievedDomainObject)
    }

    private clearFirstLevelCache() {
        sessionFactory.currentSession.flush()
        sessionFactory.currentSession.clear()
    }
}

GNU Screen. Uso avanzado

arturoherrero — Tue, 10 Jan 2012 09:24:10 +0100

Hace unos meses, mi compañero Diego Toharia escribió sobre el uso de la herramienta Screen en máquinas remotas. Vamos a repasar algunos conceptos básicos y aprender algunas opciones más avanzadas para poder automatizar nuestro trabajo.

Uso básico

Crear una nueva sesión de screen:

$ screen -S sessionname

Reanudar una sesión detached:

$ screen -r sessionname

Listar todas las sesiones de screen:

$ screen -ls

Eliminar una sesión:

$ screen -S sessionname -X quit

Eliminar todas las sesiones de screen:

$ killall screen

Atajos de teclado útiles:

Ctrl + a, d Detach screen del terminal
Ctrl + a, c Crear una nueva ventana
Ctrl + a, space Cambiar a la ventana siguiente
Ctrl + a, backspace Cambiar a la ventana anterior
Ctrl + a, A Renombrar la ventana actual
Ctrl + a, " Listar todas ventanas para seleccionar una
Ctrl + a, k Eliminar la ventana actual
Ctrl + a, ? Mostrar los atajos de teclado

Múltiples shells abiertas en la misma terminal:

Ctrl + a, | Dividir verticalmente
Ctrl + a, S Dividir horizontalmente
Ctrl + a, tab Cambiar el foco a la siguiente región
Ctrl + a, X Eliminar la región actual
Ctrl + a, Q Eliminar todas la regiones menos la actual

Una sesión tranquila

$ ssh me@server.com
$ screen -S sessionname
$ start something really important

Desconexión del servidor (pánico en otros tiempos sin utilizar screen).

$ ssh me@server.com
$ screen -r sessionname

Todo correcto, continuamos trabajando.

Automatizar el trabajo

Después de una desconexión, podemos volver a autenticarnos en nuestra maquina remota y recuperar la sesión en un simple paso:

$ ssh me@server.com -t "screen -r sessionname"

¿Cómo podemos mejorar esto? autossh es la respuesta.

autossh, automáticamente reconecta una sesión SSH y recupera una sesión de forma transparente:

$ ssh me@server.com
$ screen -S sessionname
$ Ctrl + a, d
$ exit
$ autossh me@server.com -t "screen -r sessionname"

De hecho, autossh incluye un script llamado rscreen para sesiones perpetuas.

OK, funciona. Pero no parece especialmente divertido porque primero necesitamos conectarnos al servidor, crear una nueva sesión de screen, hacer detached de la misma, desconectarnos del servidor y finalmente conectarnos de nuevo con autossh.

¿Qué podemos hacer? Si usamos screen -R recuperamos la sesión o incluso la creamos primero si no existe, finalmente hemos solucionado todos los problemas.

$ autossh me@server.com -t "screen -R sessionname"

Grails equals and hashCode testing (Osoco test gallery, part 2)

mgryszko — Wed, 04 Jan 2012 22:57:38 +0100

If you work with GORM and your objects are held in collections, you should implement equals and hashCode methods. As everything, they should be thouroughly tested if they obey equals-hashCode contract. At Osoco we created a equals-hashcode-test Grails plugin that provides a base Spock specification for that. In your equals and hashCode tests you simply have to extend the EqualsHashCodeSpec and provide at least two methods:

a factory method createDomainObjectToCompare that will create a fresh object for the comparison
a map of modified properties included in equals and hashCode
optionally a map of modified properties ignored in both methods

Additionally in case of inheritance, we check whether the equals method complies with the symmetry rule. We do it in an extra feature method added to the spec:

def 'equals relation must be symmetric with inheritance'() {
    given:
    def content = new Content()

    and:
    def book = new Book()

    expect:
    (content == book) == (book == content)
}

You may say, in Grails 2.0 and Groovy 1.8 there are @Equals and @HashCode AST transformations and you don’t need to write tests of them. I agree to some point. I think you can trust Groovy developers and you don’t have to test the methods for reflexivity, symmetry, transivity, consistency, and ‘non-nullity’. Anyway, you have to test the annotation configuration if it includes the properties that actually account for the logical equality between objects.

In the future releases of the plugin we will surely simplify the base specification and remove some checks but we will surely continue testing both methods (with our plugin it’s dirt-cheap!)

Magic in Software Development

arturoherrero — Mon, 19 Dec 2011 19:36:00 +0100

My opinion about magic in software development coincides with these great posts:

Do You Believe In Magic?

Magic in software development

I extract some fragments of them that I would like to highlight.

Bad word: Magic

I often find that people talk about magic when referring to programming languages and frameworks.

The concept that some particular language features are more magical than others is insane. None of it involves fairy dust or anything particularly complicated; it’s all just programming.

There is absolutely no logic in calling language features magical. It implies that certain programming techniques are inherently fantastic and strange. That’s only the case if you don’t understand the language.

The correct response is not calling arbitrary features magic. The correct response is to keep learning how to write code and overcome your ignorance.

Magic rocks!!

Ultimately, you can continue using magic, but what’s magic? I’d define it as anything below your current level of abstraction that you don’t understand.

Any sufficiently advanced technology is indistinguishable from magic.

Arthur C. Clarke

Magic is a good idea, we don’t understand exactly how quantum physics works but we accept that it does and make good use of it.

Now, if you don’t understand some feature of your favorite framework or how it works behind the scenes, don’t worry. Do not be intimidated, just learn and enjoy without worrying about every detail.

Functional Programming with Groovy

arturoherrero — Mon, 28 Nov 2011 09:36:39 +0100

The diversity of languages and programming paradigms allow us to solve existing problems by thinking solutions from very different approaches.

But why a Groovy developer should learn functional programming?

As I learned about functional programming, I found good ideas but I also found that it brought new clarity to my thinking about the design of class and methods. It also allowed me to write more concise code and how to make it better for reuse.

A few weeks ago, I spoke about functional programming with Groovy at Greach 2011. I presented basic concepts of functional programming paradigm and then focus on how to apply them to improve the code that we write with Groovy.

JMS queue listener integration tests with Grails (Osoco test gallery, part 1)

mgryszko — Thu, 10 Nov 2011 23:13:23 +0100

In our application we have to consume JMS messages. We install Grails JMS plugin and write a listener for this task. To not violate SRP, our consumer receives a message and routes it to a MessageProcessorService for further processing.

Curious? Continue reading on Marcin’s weblog…

Grails as daemon in Jenkins

mgryszko — Wed, 09 Nov 2011 21:18:10 +0100

Sometimes you need to run Grails embedded Tomcat container in background as a part of your build in Jenkins/Hudson. Launching a grails run-app & as Execute shell build step will result in a warning from Jenkins: Process leaked file descriptors.

The problem is described in the Jenkins wiki with some possible solutions. I chose the daemonize tool. As far as I know it is not available in any Debian repository, so I had to build it myself. It takes less than 3 minutes; just follow the instructions from the daemonize website.

I wrapped the grails run-app with daemonize in a handy script: run-app-as-daemon.sh that you can download from the Osoco’s GitHub repository.

The script starts the embedded Grails server with HTTP or HTTPS connector and then checks if the server is up and running by polling a configured URL. After e.g. some functional tests, it kills the server process by its PID.

If you want to apply the script in your build, you have to customize some variables, listed (and documented) in the script header. Usage is very simple:

run-app-as-daemon.sh start|start-https|stop|force-stop

Sample Jenkins build configuration:

Build steps:

your-app-dir/run-app-as-daemon.sh force-stop
your-app-dir/run-app-as-daemon.sh start

Post build tasks:

your-app-dir/run-app-as-daemon.sh stop

Grails build event notifications with libnotify and Growl

mgryszko — Mon, 07 Nov 2011 09:01:00 +0100

If you download the _Events.groovy script from the Osoco’s GitHub repository and put in in the scripts directory of your Grails project, you’ll get a nice bubble notifications on your Linux or Mac desktop.

This script requires libnotify (Linux) or Growl with growlnotify (Mac) installed. It assumes that GRAILS_HOME environment variable is correctly pointing to a Grails distribution (in order to display the Grails goblet icon in the notification bubble).

Conferencia Agile Spain 2011

arturoherrero — Thu, 27 Oct 2011 09:55:00 +0200

Los días 20 y 21 de octubre de 2011 se celebró la Conferencia Agile Spain 2011.

He necesitado reflexionar durante algunos días para poder valorar la conferencia tal y como se merece. Después de resumir la experiencia al resto de compañeros, me he dado cuenta de que realmente he aprendido y me he llevado muchas más cosas de las que en un principio imaginaba.

La conferencia del año pasado fue mi primer contacto con las metodologías ágiles y este año he tenido el privilegio de presentar una sesión junto con Marcin Gryszko, en la que hemos explicado cómo es la evolución de uno de nuestros proyectos, que al igual que el resto, está gestionado con metodologías ágiles. El proyecto es BKOOL.

Mi experiencia personal

De entre todas las sesiones a las que asistí, me gustaría destacar las siguientes:

El último momento responsable. Xavier Quesada
From Dev to DevOps. Carlos Sánchez
Gamification. David Bonilla
Por qué Cervantes programaba mejor que tú. Javier Acero

Lo que superó todas mis expectativas:

He conocido a muchísima gente con grandes ideas y proyectos, personas con mucha ilusión y ganas de continuar mejorando.
He aprendido la forma en la que trabajan otros equipos, sus problemas, sus retos, sus soluciones.
Me han sorprendido los diferentes modelos de negocio de algunos proyectos, reflexionando desde un punto de vista económico.
He comprendido que ser ponente es algo realmente difícil, pero al mismo tiempo muy positivo y enriquecedor.
He recordado que una persona es capaz de llegar tan lejos como se proponga (aunque quizás nunca he llegado a olvidarlo).

Groovy Metakoans

mgryszko — Wed, 07 Sep 2011 22:45:48 +0200

You may have done Groovy Koans. But it’s not the end of the long way to enlightment. Groovy Metakoans will teach you how Meta Object Protocol works and how to change object behavior at runtime.

What is metaprogramming?

According to Wikipedia is

the writing of computer programs that write or manipulate other programs (or themselves) as their data, or that do part of the work at compile time that would otherwise be done at runtime

You will learn:

how dynamic method dispatch works with Groovy
how to obtain information about an object at runtime using MetaObjectProtocol interface
how to do AOP with Groovy
how to add new methods with categories and mixins
how to inject new methods and properties using MetaClass
how to synthetize behavior upon invocation (like Grails/GORM dynamic finders)

The Koans assume that you have some basic practical experience with Groovy. If not, I recommend you personally Programming Groovy by Venkat Subramaniam. Although it covers Groovy 1.5.4, you find on 300 pages everything about Groovy from first steps with the language to advanced metaprogramming.

Grab’em while they are hot!

As tar: http://github.com/osoco/groovy-metakoans/tarball/master
As zip: http://github.com/osoco/groovy-metakoans/zipball/master
Browse the source code at GitHub: https://github.com/osoco/groovy-metakoans
Clone the repository with Git: git clone git://github.com/osoco/groovy-metakoans
Read the documentation at: http://osoco.github.com/groovy-metakoans/

Spock Grails extension - execute or ignore specification depending on the environment

mgryszko — Thu, 21 Jul 2011 08:24:07 +0200

Our newest Spock Grails environment extensions plugin adds two annotations to Spock:

@ExecuteForEnvironment
@IgnoreForEnvironment

You specify environment(s) as the annotation parameter, e.g. @ExecuteForEnvironment(['test_integration', 'test_performance']) or @IgnoreForEnvironment('test'). More examples can be found in the official user guide.

Grails Fixtures Plugin – Object Templates

mgryszko — Mon, 04 Jul 2011 21:35:32 +0200

Grails Fixtures plugin gives you a Grails domain object factory (or object mother if you like fancy names :)) thats lets you define your test fixture using a DSL.

Now, starting from the current snapshot (1.0.8-SNAPSHOT version) you can define domain object templates. A template defines an object with some common properties that will be replicated in all object instances based on that template.

Interested? Then continue reading Marcin’s blog…

Trabajando con diferentes versiones de Grails

deigote — Tue, 21 Jun 2011 23:15:00 +0200

En OSOCO hace tiempo que apostamos por Grails como framework para desarrollar aplicaciones web, y es la herramienta que elegimos por defecto en todos los proyectos nuevos de esta índole.

Con el tiempo, esto ha ocasionado que tengamos que trabajar con diferentes versiones de Grails a la vez, lo que por defecto puede ser algo engorroso.

Hace poco subí a mi GitHub un script que se encarga de lidiar con este problema. Sé que había cosas ya hechas para esto, pero me gusta cocinarme estas pequeñeces yo mismo :-), así que he subido el script al GitHub de OSOCO para quien lo encuentre útil:

Grails Multiple Versions

No tiene ningún misterio, pero ahorra tiempo :-D. Para hacerlo funcionar, basta con ponerlo en el path con mayor prioridad que la instalación de Grails (yo suelo tener estas cosas en $HOME/bin o $HOME/bin/scripts, que está al principio de mi path).

Se pueden configurar un par de variables (el nombre de la instalación por defecto y en qué directorios se buscarán tanto esa instalación como cualquier otra), pero con los valores por defecto debería funcionarle a la mayoría de la gente :-).

En cualquier caso, podéis ver una descripción de uso más detallada en el README.

Agile Inception

arturoherrero — Wed, 01 Jun 2011 10:07:56 +0200

Muchos proyectos mueren sin ver la luz principalmente por dos razones:

No son capaces de hacer las preguntas correctas.
No tienen el valor de hacer las preguntas difíciles.

Cuando comienza un proyecto, cada miembro del equipo se forma una idea del mismo y de cómo llevarlo a cabo con éxito. Sin embargo esta visión puede ser completamente diferente para el resto.

En el libro The Agile Samurai de Jonathan Rasmusson, se describe la herramienta Agile Project Inception.

Básicamente lo que se propone es que nos planteemos una serie de preguntas antes de comenzar cualquier proyecto. El espíritu que hay detrás de esto es llevar el proyecto a su verdadera esencia, definiendo y comunicando esa visión entre todo el equipo.

10 Preguntas

¿Por qué estamos aquí?

Esta es la primera pregunta y la más obvia. Es un recordatorio de por qué estamos aquí, quienes son nuestros clientes, y por qué decidimos hacer este proyecto.
Elevator Pitch

Si tuviéramos treinta segundos y dos frases para describir nuestros proyecto, ¿qué diríamos?
Diseña tu caja

Si hojeamos una revista y vemos un anuncio de nuestro producto o servicio, ¿qué diría? y lo más importante, ¿lo compraríamos?
Crea una NOT List

Esta claro lo que queremos hacer en este proyecto. Vamos a ser aún más claros y mostrar lo que no vamos a hacer.
Conoce a tu comunidad

La comunidad de nuestro proyecto siempre es mayor de lo que pensamos.
Visualiza la solución

Vamos a pensar en alto nivel la arquitectura y las tecnologías que vamos a utilizar para asegurarnos de que todos estamos pensando en lo mismo.
¿Qué te quita el sueño?

Algunas cosas que pueden ocurrir durante el proyecto nos pueden asustar. Pero hablando de ello, y pensando qué podemos hacer para evitarlas, puede que den menos miedo.
Calcula el tamaño

¿El proyecto es cosa de tres, seis o nueve meses de duración?
¿Cuáles son tus prioridades?

En los proyectos se pueden definir prioridades en cuanto a tiempo, alcance, presupuesto y calidad. ¿Qué es lo más y lo menos importante para este proyecto en este momento?
¿Cuánto me va a costar?

¿Cuánto cuesta? ¿Con qué equipo vamos a sacar esto adelante?

Seis meses en OSOCO

arturoherrero — Tue, 17 May 2011 13:15:42 +0200

La semana pasada cumplí 6 meses trabajando en OSOCO.

No suelo recordar fechas importantes o aniversarios, pero de alguna forma he tenido muy presente el día en el que comencé a trabajar aquí.

Durante este periodo de tiempo mi vida ha cambiado en muchos aspectos, tanto personal como profesionalmente. 6 meses puede parecer poco tiempo para sacar grandes conclusiones pero a mí me parece suficiente para reflexionar y poder valorar el pasado y el futuro.

Trabajo

Cuando comencé a buscar trabajo, tenía muy claro el tipo de empresa en la quería estar y desde el primer momento sentí que había llegado al lugar correcto.

Hay muchos conocimientos y tecnologías que tengo que dominar en mi trabajo diario, quizás los más destacables son el lenguaje de programación Groovy y el framework de desarrollo web Grails así como Scrum, pruebas, refactoring, patrones de diseño, HTML/CSS, etc…

Ser el peor me está permitiendo mejorar muy rápido. Cada cosa que aprendo la intento compartir con el resto de mis compañeros y alguna de mis ideas ya se ha puesto en marcha, como los breakfast speech. Estoy muy orgulloso de sentirme parte activa de este equipo.

Gracias

Si tuviera que resumir este periodo de tiempo en una palabra, esta sería gracias.

Lo primero que tengo que agradecer es que un lugar como OSOCO exista. Puede parecer extraño agradecer algo así pero para alguien tan idealista como yo, encontrar empresas donde se hacen las cosas bien y se intenta mejorar constantemente es esencial.

Lograr que todo funcione sólo es posible gracias al esfuerzo y trabajo de las personas que hay detrás, un gran equipo que me ha dado toda su confianza y libertad, ayudándome a mejorar constantemente. Gracias chicos!

Creo que cada época en la vida nos aporta algo en mayor o menor medida, para mí estos 6 meses han sumando muchísimo.

Todo lo que me ha ocurrido es demasiado evidente para llamarlo casualidad y lo suficientemente real para llamarlo destino.

Usando Screen en máquinas remotas

deigote — Wed, 11 May 2011 09:40:00 +0200

Cuando nos conectamos por SSH a servidores remotos, es habitual que la conexión muera (porque se cae la conexión a Internet, cerramos la terminal por error, etc).

Normalmente no tiene consecuencias graves, pero si estamos en mitad de una operación larga (hacer un dump de mysql o instalar un paquete usando emerge) o peor aun, de una operación delicada (una importación contra mysql, por ejemplo), puede ser un incordio, en el mejor de los casos, o tener graves consecuencias, en el peor.

Screen es una aplicación en modo texto muy útil para evitar este problema. Screen permite ejecutar sesiones de shell virtuales que no están ligadas al proceso que las arranca (ya sea éste el servidor de ssh, gnome-terminal o Terminal.app). Esto permite que aunque cualquiera de estos procesos muera, la sesión virtual de Screen no lo haga. Ideal cuando queremos hacer operaciones largas y/o delicadas.

Un ejemplo de uso (el más básico posible, ya que Screen cuenta con muchísimas más posibilidades) sería el siguiente:

$ screen -S misesion # creamos una nueva sesión $ do-some-long-and-delicate-operation ... Doing the operation

En este momento podemos pulsar la combinación de teclas ctrl+a ctrl-d (d, de detach) para dejar la sesión en segundo plano, volviendo a la shell original:

[detached] $ screen -d # lista las sesiones que existen There is a screen on: 13790.misesion.my-fancy-server-hostname (Detached) $ screen -r 13790 # recupermos la sesión 13790 (r, de reattach) $ do-some-long-and-delicate-operation ... Doing the operation ... The operation is done $

Una alternativa al algo más precario nohup, y un must-know (oh yeah :-) para cualquiera que tenga que administrar un sistema remoto.

OSOCO Breakfast Speech about LiquiBase Grails Plugin

rzamo — Mon, 14 Feb 2011 16:03:39 +0100

[Flash 10 is required to watch video.]

OSOCO Breakfast Speech about LiquiBase Grails Plugin