ENDER SOFTWARE, desarrollo de software a medida » Tecnología

Desarrollo para terminales móviles

javi — Tue, 27 Apr 2010 14:57:10 +0000

Últimamente en Ender nos estamos planteando la posibilidad de comenzar a desarrollar aplicaciones para dispositivos móviles relacionadas con nuestros sistemas. Cada vez los usuarios están más acostumbrados a migrar las funciones que tradicionalmente realizaba un ordenador hacia sus teléfonos, netbooks u otros dispositivos de menor capacidad de proceso. Y en el mundo empresarial, hacia el que nos orientamos, las extranets cada vez realizan un mayor número de funciones en sustitución del software ‘tradicional’. Es fácil ver que ambas tendencias se combinarán en el futuro, y si bien los terminales móviles de gama alta no deberían tener ningún problema en utilizar una extranet básica, siempre será mucho más eficiente utilizar una aplicación específica.

Por tanto, allá vamos, a explorar las posibles opciones. Desarrollar para dispositivos móviles no es como desarrollar para ordenadores. En los ordenadores, la opción es clara: IBM PC compatible con alguna de las distintas versiones de windows acumula el noventa y pico por ciento del mercado. Salvo que controles la infrastructura sobre la que va a correr la aplicación, no queda otra opción que programarla para windows, por pura estadística. En el mundo móvil el panorama es muy distinto… No hay, ni de lejos, un claro dominador del mercado de los sistemas operativos para móviles: Android (5% en 2009), Blackberry (21%), Windows Mobile (9%), iPhone OS (15%), Symbian (49%), Palm (>3%)… Además, los propios porcentajes son engañosos: Los mayores porcentajes los poseen sistemas operativos que llevan más (bastante más) tiempo en el mercado, y por tanto han tenido tiempo para que un mayor número de dispositivos de varias generaciones funcionen sobre ellos… lo que no significa que en el futuro sigan haciéndolo.

De hecho, tanto Symbian como Blackberry parecen sistemas destinados a morir. Cada día son menos los nuevos terminales que corren sobre estos SOs, siendo sustituidos por Android, Windows Phone (antiguo Mobile) o versiones nativas de linux. Por tanto no parecen una buena opción como elección, hoy por hoy.

Windows Phone está siendo adaptado como sistema por bastantes terminales, cuenta con la ventaja de tener una gran integración con los PC que corren sobre windows, pero no parece terminar de convencer a los usuarios. Sin duda, si hoy por hoy hay dos sistemas operativos para móviles estrella son Android y iPhone OS. Son con diferencia los más avanzados técnicamente, y ambos están “en pañales”, mostrando sólo el comienzo de su potencial, por lo que todo el mundo apuesta por uno o por otro para convertirse en el “Windows” de los teléfonos móbiles.

Android es hijo de Google. Es un sistema operativo libre y abierto, que permite que cualquier fabricante lo incluya en su dispositivo. Así, no sólo existen en el mercado teléfonos móviles que lo lleven, también hay toda una gama de otros dispositivos (tablets, netbooks, etc) que funcionan sobre él.

Iphone OS, a su vez, es propiedad de Apple y es el sistema sobre el que corren tanto los iphone como los nuevos ipods. Ningún otro fabricante puede utilizarlo, pero el golpe que apple dio al mercado de los smart phones con el iphone (acaparando un buen porcentaje del mercado en muy poco tiempo), y el hecho de que el dispositivo estrella de apple (iPod, lider indiscutible de otro mercado casi tan grande como el de los terminales móviles) también lo emplee hacen que sea una opción muy atractiva para los desarrolladores de aplicaciones.

En resumen: Se trata de elegir desarrollar para iPhone o para Android. Y no se trata sólo de elegir la opción que te lleve a un mayor número de clientes, o la que tenga mejor perspectiva de futuro. Como vamos a ver, el problema es mucho más profundo.

Mucha gente no conoce como funciona el proceso de desarrollo de una aplicación, así que vamos a explicar un par de conceptos claves. Para desarollar software existe una gran variedad de lenguajes… El “lenguaje” original de los procesadores de los ordenadores, como casi todo el mundo sabe, es un lenguaje binario. Largas cadenas de ceros y unos que hacen que el procesador haga una cosa u haga otra. Obviamente, “hablarle” directamente al procesador es casi imposible por lo extremadamente complejo, para eso existen los lenguajes de programación. Los lenguajes son abstracciones de este lenguaje binario. Es decir, si quieres que el ordenador imprima en la pantalla “hola mundo” no es necesario que te aprendas cómo ordenárselo en binario, sino que según el lenguaje que escojas escribiras algo parecido a write(‘hola mundo’) o print(‘hola mundo’). A partir de ahí, ese lenguaje se traducirá automáticamente al lenguaje del procesador para que el ordenador entienda lo que quieres que haga.

La cuestión es que hay cientos, miles de lenguajes. Muchos son similares, todos hacen más o menos lo mismo, pero sigue habiendo cientos. Algunos son más apropiados para unas tareas y otros para otras, pero al final, casi cualquier cosa se puede hacer con cualquier lenguaje y es sólo una opción personal. A su vez, cada lenguaje tiene un gran número de “librerias”. Las librerías son packs de código que te permiten realizar alguna acción complicada sin tener que programarla una y otra vez. Por ejemplo, para calcular una raiz cuadrada no haremos todos los pasos que serían necesarios cuando la resolvemos “a mano”: Le indicaremos al ordenador que vamos a usar la librería “matemáticas.lib” y con ella podremos simplemente usar la llamada “raizcuadrada(25)”. Es un concepto un poco extraño para alguien que no ha programado nunca, pero en realidad es la base de la programación profesional. Un programa normalmente usa un número bastante grande de estos componentes, conteniendo al final tanto o más código importado y ensamblado como código propio y original.

¿Por qué explicar todo este rollo? Porque sino no es fácil explicar por qué la opción de desarrollar para iPhone es tan mala. La razón: La licencia de desarrollo de Apple. Apple tiene una concepción de sus productos que intenta dejarlo todo atado y bien atado. Pretenden controlar todo, desde la fabricación de los componentes hasta el software que corre en ellos. Y lo han llevado un paso más allá con el desarrollo para iphone. En desarrollo de software no es habitual tener que pagar una licencia para desarrollar programas para una plataforma. Pagar por poder usar ciertos programas o componentes sí, pero no por “el derecho” de desarrollar software. Pero Apple, en su intento por controlar qué se desarrolla y que no para sus sistemas, la ha introducido. Cien dólares de licencia anual para ser un desarrollador certificado por Apple. Sin esta certificación, tus programas no estarán en la tienda iphone, y por tanto no podrán funcionar en ningún teléfono ni ipod (Ya que no se puede instalar software en estos dispositivos de ninguna otra manera). La licencia no es costosa, pero tiene problemas mucho más profundos que el dinero: Apple se reserva el derecho de echar por tierra todo tu trabajo. Puedes desarrollar una aplicación y que al final Apple decida no aprobarla, tirando abajo meses de trabajo. Y lo que es aún peor, se reservan el derecho de cambiar las condiciones que rigen qué es aceptable o qué no. En su última revisión de la licencia incluyeron una nueva cláusula que restringe los lenguajes en los que se puede programar a los tres o cuatro elegidos por ellos, y prohibe, directamente, el uso de librerías externas que no hayan proporcionado ellos mismos. En el mundo de la programación, esto es como decirle a un mecánico que no puede utilizar ninguna herramienta, excepto un destornillador de un modelo y tamaño específicos, para hacer cualquier cosa.

Android, por el contrario, es un sistema operativo libre. Su código fuente está disponible para cualquiera que quiera verlo. Cualquiera puede desarrollar aplicaciones sin tener que pagar nada, sin que nadie pueda decirte que no, sin que nadie tire por tierra tu trabajo. No hay prohibiciones en Android. En ese sentido, es muy parecido a lo que ocurre en el mundo del PC: Cualquiera puede hacer cualquier cosa, de la manera quiera hacerla. Las opciones son infinitas. Todo esto se ve claramente en el hecho de que el número de aplicaciones disponibles para android crece exponencialmente, y que cada vez más fabricantes de terminales lo ofrecen como base de sus dispositivos.

Durante todo el año pasado, el crecimiento del iPhone parecía imparable. Su tecnología era mucho más avanzada que la de los sistemas operativos rivales y el usuario lo notaba y elegía. El lanzamiento de Android y su generalización en los últimos meses parece enfrentarse directamente a esta tendencia. Android rivaliza (o supera) al iPhone OS en tecnología, y los teléfonos que lo incluyen suelen ser de una gama tan alta como el iphone.

La diferencia, para nosotros, es que Apple, en su intento por controlarlo todo, ahoga a los desarrolladores. Las condiciones que impone son draconianas, prácticamente nunca vistas en el mundo del desarrollo del software. No tienes derechos sobre tu propio producto, te limita las herramientas que puedes utilizar para desarrollarlo, te arriesgas a que sus propias condiciones cambien unilateralmente. Y esto no son condiciones en las que queramos desarrollar.

Android, para nosotros, es el futuro.

http://es.wikipedia.org/wiki/BlackBerry

El software libre en tu empresa: qué puedes hacer y qué no

Domingo — Thu, 04 Mar 2010 16:40:30 +0000

En todas las empresas, a día de hoy, hace falta software… ya sea para escribir cartas, para llevar la contabilidad o para publicar cosas en la web, sin software a día de hoy no se hace casi nada. Así que… ¿de dónde lo sacamos? Se me ocurren tres formas de obtener software (que en realidad son cuatro):

Pagar por el software: ya sea pagar por licencias de uso de un software que ya existe, como comprar Windows o la Office, o pagando a empresas como nosotros para que os hagan el software a medida.
Tener software pirata: hace unos años esto era, de largo, lo más común… pero creo que poco a poco va disminuyendo, cada vez hay menos. Entre las campañas anti piratería y los sistemas anti copia, con la conexión ubicua a internet esto es cada vez más difícil.
Usar software libre. Es una alternativa muy atractiva, claro, por varias razones que ahora explicaré… sin embargo, hay que tener en cuenta un par de cosas, sobre todo en cuanto a las licencias a través de las cuáles se distribuye el software.

¿Software libre, o software gratis?

Puede ser una de las dos cosas, y también las dos… la confusión puede venir de la palabra free, que en inglés significa tanto ‘libre’ como ‘gratis’. Por eso, en inglés, cuando se habla de ‘free software’ se distingue entre free, as in beer (es decir, gratis, como en ‘cerveza gratis’) y free, as in speech (es decir, libre, como en ‘libre expresión’).

Yo entiendo software libre como el que está abierto a modificaciones externas… es decir, se permite el acceso libre al código fuente y a la documentación de desarrollo, de forma que cualquiera pueda obtener dicho software, y hacer el uso que necesite, siempre que se ajuste a los términos de la licencia de distribución del software que sea. Cuando alguien libera un software, lo hace bajo una licencia de uso; es decir, una serie de condiciones que hay que cumplir si usas ese software. Lo que puedes o no puedes hacer, por tanto, viene definido por los términos de dichas licencias. No me voy a extender en los términos de cada licencia, está bien explicado en la wikipedia, sino que me interesa más reflexionar sobre qué puedes y qué no puedes hacer con el software dependiendo de la licencia que tenga.

Es decir, puedes tener software libre que es gratuito (que es el caso más común, que todos conocemos), pero también hay otras alternativas: puedes tener software libre que no es gratuito (más abajo hablaré de ello), y software gratis que no es libre, como todo el software freeware de los 90.

La madre del cordero: el copyleft

La filosofía básica que envuelve a la licencia libre más restrictiva, la GPL, es lo que se llama el copyleft. Este concepto viene como oposición directa del copyright, y se basa en la idea de compartir libremente las obras producidas (no se aplica sólo a software, sino a cualquier obra de producción propia). La idea básica es la que cualquiera pueda acceder a tu software, en este caso, y hacer las modificaciones que quiera, las mejoras o los cambios, sin ninguna limitación y sin tener que pagar derechos de autor. Pero esto no significa que este modelo de licencia no tenga ninguna restricción, todo lo contrario. La idea es que, si el software que se ha liberado tiene copyleft, todas las derivaciones del mismo tienen que tener copyleft. Es decir, no se puede coger un software libre, hacer unas modificaciones, y generar un producto nuevo que no sea libre. Cuidado, esto no significa en absoluto que no se pueda cobrar por el trabajo. GPL no significa gratis, sino libre.

A la hora de evaluar si podemos usar un software que está distribuido sobre una licencia libre tenemos que tener en cuenta qué es lo que vamos a hacer con él. Si es para uso privado, podemos coger el software, modificarlo, cambiarlo como queramos, no tiene ningún problema… el asunto viene cuando lo que queremos hacer es distribuir las modificaciones que hemos hecho… entonces es cuando entra en juego el asunto viral que tiene la GPL: cualquier producto que incluya software GPL como alguno de sus componentes, debe ser GPL a su vez.

Hay licencias menos restrictivas, como la LGPL, que permiten el enlace de software LGPL con software de otros modelos de licencia y licenciar el software obtenido de la forma que se quiera… lo fundamental de la licencia GPL es que todo lo que contenga al menos una linea de código GPL debe ser distribuido con la misma licencia

Libre no significa gratis necesariamente – un ejemplo con WordPress

O no habría nicho de negocio para nadie… ninguna de las licencias de software libre dicen que tenga que ser gratuito. Lo que dice la GPL es que el software que tú distribuyas debe serlo utilizando la GPL… es decir, puedes cobrar por el software, o por el trabajo, pero no puedes decirle al cliente que no puede distribuir libremente ni cambiar el software que le das, porque como está protegido por la GPL, tiene derecho a hacer lo que quiera dentro de la GPL.

Un ejemplo que estamos utilizando nosotros ahora: cuando los clientes nos piden que les hagamos desarrollos web, estamos utilizando WordPress para hacerlos (de hecho, nuestra propia página está hecha utilizando wordpress). WordPress está distribuido utilizando la licencia GPL y, por tanto, los temas (que son las adaptaciones que cambian el aspecto que tiene la página), también están sujetos a la licencia GPL (como se explica muy bien en este artículo). Esto significa que, si nosotros le desarrollamos un tema especializado a un cliente, nosotros no le podemos exigir al cliente que no cambie o distribuya dicho tema a quién quiera (bueno, nosotros podemos decir lo que queramos, pero el cliente no tiene por qué hacernos caso, ya que la licencia del tema tiene por fuerza que ser GPL). Si queremos, podemos poner una tienda de temas WordPress y que la gente los compre, siempre y cuando nosotros no limitemos las acciones de nuestros clientes dentro de la GPL.

Siempre había pensado que la GPL era una licencia muy restrictiva, y creo que es uno de esos problemas de lost in translation, ya que al leer “todo software derivado de GPL debe ser GPL”, y “GPL es una licencia ‘free’”, durante años he interpretado que todo software GPL debe ser gratis, y que los derivados también, y esto no es cierto. Una extensión a esta explicación, y un análisis de las implicaciones podéis leerlo aquí.

Integración continua: proyectos Delphi en Hudson

leon.domingo — Mon, 01 Feb 2010 17:10:00 +0000

Cuando se desarrolla “en grupo” hacen faltan varias herramientas para trabajar de una forma eficiente. Una de ellas es la utilización de algún sistema de versiones (Subversion, CVS, mercurial, git, etc), y la otra es la compilación automática, lo que habréis visto muchas veces como “nightly builds”.

Estos sistemas nos permiten por un lado ahorrar tiempo (el programador no tiene que preocuparse de compilar todo el código que forma un producto/proyecto cada vez que hace algún cambio), y por otro generar una salida uniforme e integrada de todos los posibles cambios que se han producido (los cambios de varios programadores “confluyen” en único producto compilado que incluye las correcciones y mejoras de todos aquellos). Estos sistemas, lógicamente, están integrados con los sistemas de control de versiones, de modo que los cambios en uno sean detectados por el otro.

Nosotros utilizamos un sistema “free” llamado Hudson. Hudson es una aplicación web (servlet) sobre Apache o Glass fish que nos permite compilar automáticamente nuevas versiones con los cambios que hacemos en el código.

Para que Hudson genere nuevas versiones de un módulo (métodos, aplicaciones, …) tenemos que configurar un trabajo o job que le indique qué tiene que hacer para generar dicho módulo compilado.

En ender creamos (y configuramos) un job por método, por aplicación o por test, esto hace cada “pieza” independiente (hasta cierto punto) del resto. Debemos identificar cada uno de estos jobs con un nombre único. Normalmente estos nombres son iguales al nombre del módulo. Cuando hay diferentes módulos con el mismo nombre utilizamos un prefijo para el nombre. Por ejemplo,

Alu01 en la vista Turno
SQL_Alu01 en la vista SQL_Turno

Un trabajo en Hudson puede estar o no dentro de una vista (view). Una vista es como un saco dentro del que agrupar ciertos trabajos que están relacionados entre sí. En nuestro caso, esa relación siempre es porque todos ellos pertenecen a un mismo producto/proyecto. No es obligatorio que un trabajo esté dentro de una vista, pero nos permite ver rápidamente todos los trabajos relacionados con un producto/proyecto. Estas vistas son las pestañas que aparecen cuando entramos en la home de Hudson (ARGOS, AFORO, Olympo, IHMSI, etc).

Para crear un nuevo trabajo pinchamos en “New Job” en la parte superior izquierda del sitio web de Hudson. Si nos encontramos en una vista, dicho trabajo se creará bajo esa vista. Si estamos en la home se creará sin vista asociada, y posteriormente lo podremos encontrar bajo la vista general “All“.

Una vez creado (y guardado) un trabajo para acceder de nuevo a la configuración nos dirigiremos a dicho trabajo, pincharemos en él y despúes elegiremos “Configure“, en el menú de la izquierda.

Para configurar un nuevo trabajo tenemos que tener en cuenta principalmente lo siguiente:

¿Dónde está el código?
¿Cómo se compila el código?
¿Cuándo debe compilarse el código?

1. ¿Dónde está el código?

Hablábamos más arriba que los sistemas de control de versiones y los de compilación automática “deben” estar integrados. Para ello tenemos que indicar la ruta en el repositorio donde se encuentra dicho código. Esto implica indicar todo el código necesario para compilar dicho módulo, excepto los componentes comunes que ya estén instalados en el servidor donde está corriendo Hudson. Es decir, los componentes que tenemos instalados en Delphi.

Bajo el epígrafe “Source Code Management” tenemos que poner cada “pieza” del código que necesitamos para la compilación.

En el ejemplo estamos diciendo que se descargen dos “piezas” de código: AFOROFunc01 y Unidades Compartidas, cada una con su ruta correspondiente en el repositorio y un nombre de carpeta local.
svn://peter/Aforo/Trunk/Métodos/AFOROFunc01 -> Source
svn://peter/Aforo/Trunk/Métodos/Unidades compartidas -> Unidades Compartidas

svn:// indica el protocolo Subversion
/peter indica el servidor
/Aforo/Trunk/Métodos/AFOROFunc01 indica la ruta dentro del repositorio que reside en el servidor peter.

Cómo se puede ver en la imagen, Hudson permite utilizar dos sistemas de control de versiones diferentes: CVS y Subversion, o no usar ninguno cuando se trata de trabajos que no dependen de cambios en el código (test diarios, por ejemplo).

2. ¿Cómo se compila el código?

Hudson utiliza órdenes de shell para compilar cada uno de los trabajos. Por tanto, para compilar un trabajo utilizamos el ejecutable del compilador incluido en las diferentes distribuciones de Borland Developer Studio (en nuestro caso BDS 2006). Dicho compilador se encuentra en la carpeta donde esté instalado BDS, normalmente “C:\Archivos de programa\BDS\4.0\Bin\dcc32.exe”.

dcc32.exe [options] filename [options]

Todas las opciones disponibles se pueden ver ejecutando el compilador sin ningún parámetro.

Como estamos usando la versión de línea de comando ciertos datos de configuración que rellenamos en el IDE de Delphi los tenemos que rellenar a mano en el fichero “dcc32.cfg“, situado en la misma ruta que el propio compilador.

Las opciones para “Library path” se indican utilizando la opción -u. Por ejemplo,

-u”e:\archivos de programa\Borland\BDS\4.0\lib”;”e:\archivos de programa\Borland\BDS\4.0\lib\Obj”;”F:\Componentes\Package 2006″;…
-u”d:\Componentes\MiComponente”;”d:\Componentes\OtroComponente”;…

Aquí debemos poner las rutas a todos los componentes que tenemos instalados y que son necesarios para compilar nuestros proyectos.

Las opciones para “Conditional defines” se definen utilizando -D. Por ejemplo,

-DLEVEL3;LEVEL4;LEVEL5;LEVEL6;XDOM_2_3
-DDebug
-DVersionDePrueba

Se trata de opciones de compilación controladas por instrucciones como {$IFDEF}, {$IFNDEF}, etc. Es equivalente a poner {$DEFINE —–} en el código.

Las opciones para “Unit aliases” se definen utilizando -a. Por ejemplo,

-aWinTypes=Windows;WinProcs=Windows;DbiProcs=BDE;DbiTypes=BDE;DbiErrs=BDE

Ésta última ya está definida por defecto en el fichero “dcc32.cfg” y probablemente no tendremos que modificarlo.

Cada job en Hudson tiene su propia carpeta en disco y dentro de ella se descarga (desde el repositorio) el código, como hemos visto en el apartado anterior.

Bajo el epígrafe “Build” disponemos de un cuadro de texto donde escribiriemos las órdenes necesarias para compilar el módulo. Estos comandos siguen la estructura de un archivo Batch (.BAT) de Windows. De hecho, Hudson genera un archivo .bat con el contenido de “Command” y lo ejecuta cada vez que necesita compilar el job.

Partimos de la carpeta propia del trabajo, así que lo primero que tenemos que hacer es entrar en la carpeta “Source” (recuerda que es el nombre que le hemos dado a una de las piezas del código)

cd Source

y ejecutar un par de órdenes

“e:\Archivos de programa\borland\bds\4.0\bin\dcc32″ -w+ -h AFOROFunc01

La primera ejecuta el compilador de Delphi para el proyecto correspondiente (AFOROFunc01). Esto generará un fichero .DLL o un fichero .EXE, en nuestro caso AFOROFunc01.dll.

“e:\Archivos de programa\Winrar\rar.exe a AFOROFunc01.rar AFOROFunc01.dll

La segunda línea es opcional y nos permite comprimir el resultado obtenido en la compilación (AFOROFunc01.dll) en un archivo más pequeño. De esta manera cuando descargamos un módulo podemos elegir la versión comprimida y tardaremos menos.

Una vez compilado el código tenemos que indicarle a Hudson qué debe guardar de los archivos que se producen. Esto se hace bajo el epígrafe “Post-build Actions“.

Tenemos que marcar el check “Archive the artifacts”. En el cuadro de texto rotulado como “Files to archive” configuramos qué ficheros (artifacts) queremos que se almacenen. Hudson guardará un histórico (según el número de versiones disponibles que indiquemos) de dichos “artefactos”, con lo que podríamos recuperar una versión anterior.

3. ¿Cúando debe compilarse el código?
Los trabajos se pueden ejecutar tras la ejecución existosa de otro/s trabajo/s (Build after other projects are built), cada cierto tiempo (Build periodically) o cada cierto tiempo comprobando cambios en el código (Poll SCM).

Todo esto se configura bajo el epígrafe “Build Triggers“.

En la opción “Build after other projects are built” indicamos una lista con uno o varios trabajos (de Hudson) separados por comas. En las opciones “Build periodically” y “Poll SCM” se configuran utilizando el campo “Schedule“. La diferencia entre ellos es que uno se compila siempre y otro sólo si ha habido cambios en el código.

En el campo “Schedule” se trata de escribir la configuración para cinco datos separados por espacios o tabuladores. Normalmente sólo hay una línea pero podríamos tener varias. Esta configuración es similar a la de crontab en sistemas *nix.

[MINUTE] [HOUR] [DOM] [MONTH] [DOW]

MINUTE (minuto) [0, 59]
HOUR (hora) [0, 23]
DOM (day of month – día del mes) [1, 31]
MONTH (mes) [1, 12]
DOW (day of the week – día de la semana) [0, 7], donde 0 y 7 significan Domingo.

Si indicamos * (asterisco) significa “todo”. Por ejemplo, si ponemos * en la columna de los minutos, significa “cada minuto”. Si lo ponemos en el “día de la semana” significa “todos los días de la semana”, etc.

Algunos ejemplos serían:

0 20 * * *
Todos los días a las 20:00

0 20 * 1 *
Todos los días de Enero a las 20:00

30 19 1 * *
30 19 15 * *
Todos los días 1 y 15 a las 19:30

Para trabajos en los que elegimos “Poll SCM” la configuración por defecto (* * * * *) suele ser la más utilizada. Es decir, se comprueba el código “cada minuto”. Sólo en el caso de que la compilación de ciertos trabajos lleve mucho tiempo, podemos elegir que dichos trabajos más “costosos” se compilen “fuera de horario”.

Una vez hemos configurado todo pulsamos Save en la parte inferior de la página.