NOTICIA

Las herramientas del programador ¿Y tú cuál usas?

25 julio, 2017

Aunque el software sea una disciplina de carácter intelectual, todo programador que se precie usa multitud de herramientas en su día a día. Como si de un artesano se tratara, los programadores intentamos elegir las herramientas que mejor se adaptan a nuestras manos. Pasamos muchas horas con ellas por lo que nos gusta que la herramienta esté a nuestro gusto, que se ajuste a nuestro flujo de trabajo y que no nos obligue a cambiarlo.

Adaptamos aspectos estéticos, como colores, fuentes o posición de los menús. Pero también adaptamos las partes funcionales, como accesos rápidos de teclado o instalamos plugins que nos ahorran trabajar más de la cuenta. Al final personalizamos tanto las herramientas que utilizamos, que se podría decir que existe una para cada programador.

A la hora de elegir una herramienta para programar solemos elegir entre dos opciones: IDE o editor de texto.

IDE

Los IDE (Integrated Development Environment) o Entornos de desarrollo integrados, son aplicaciones que nos permiten desarrollar software de manera sencilla e incluyendo prácticamente todo lo que necesitamos sin tener que salir del entorno. Tenemos un editor de código fuente; herramientas para el autocompletado de código y snippets; herramientas para depuración y compilacíón; así como herramientas para construcción o build.

Con el paso de los años los IDEs existentes en el mercado han incluido cada vez más opciones. Pero añadir tantas opciones tiene un precio y la queja general sobre estos entornos es que suelen ser pesados, necesitan una máquina potente y tienden a ser lentos.

Algunos de los IDEs que podemos encontrar en el mercado son Visual Studio, Eclipse, NetBeans o muchos de la empresa Jet Brains como IntelliJ, WebStorm o PHPStorm.

Editor de texto

Los editores de texto, son más sencillos que los IDE, y por tanto tienen menos funcionalidades integradas. La cantidad de funciones básicas depende de cada editor, pero generalmente tienen algún tipo de resaltado y formateo de código. Hoy en día es muy común que se puedan ampliar con extensiones de todo tipo, aunque eso hace que sean un poco más pesados y lentos, alejándose del concepto de editor de texto y acercándose más al de IDE. La idea de un editor es ser rápido y liviano.

Algunos de los editores que podemos encontrar son: Emacs, Vim, Atom, Sublime Text, Visual Studio Code o incluso herramientas tipo navaja Suiza como Notepad++.

¿Cuál elegir?

La elección de herramienta a elegir, viene solo condicionada por el lenguaje y la plataforma que vamos a utilizar. Si queremos desarrollar aplicaciones Windows tendremos un número de opciones limitado. Si vamos a desarrollar aplicaciones para iOS o aplicaciones web con Java, tendremos otras opciones distintas. Pero más allá de esa división, estamos solo limitados por nuestros gustos (o presupuesto). Como hemos dicho antes, aunque usemos el mismo editor o IDE que otros programadores, probablemente lo tengamos personalizado a nuestro gusto, haciéndolo totalmente diferente.

Así que para tener una idea sobre las posibilidades, nos hemos decidido a preguntar a unos cuantos programadores, sobre cual es la herramienta que utilizan en su día a día, como la tienen configurada y por qué la usan.

Editores clásicos

Aunque no los hayas utilizado, seguro que has oído hablar de Vim y Emacs. Vim lanzó su primera versión en los 90, aunque siendo una versión mejorada del ya conocido Vi que integran muchos sistemas Unix desde finales de los 70. Emacs fue desarrollado entre otros por Richard Stallman, también a finales de los 70. Como veis son muchos años, pero ambos siguen siendo ampliamente utilizados por programadores de todo el mundo, dada su capacidad de personalización.

Es el caso de Mario, desarrollador backend (Ruby, Python, SQL) en Carto, que durante muchos años ha estado utilizando Vim. Como el mismo cuenta «con VIM llevo unos 4-5 años y la configuración actual ha ido adaptándose según he ido necesitándolo. Las ventajas de esa configuración es tener la gran potencia de Vim pero con plugins que permiten funcionar sin echar de menos funcionalidades de otros IDEs más modernos«.

Y es que la personalización es el gran fuerte tanto de Vim como de Emacs, ya que a lo lago de los años se han desarrollado miles de extensiones para ellos. Y si no existe una extensión de nuestro gusto, siempre podemos desarrollarla. Es lo que nos comenta Juanma que trabaja desarrollando software para comercios en IGT Microelectronics y usa Emacs para parte de sus desarrollos: «me gusta mucho la facilidad para personalizar Emacs y el buen soporte que tiene para la mayoría de lenguajes. Con Visual Studio, por ejemplo, aunque puedes crear plugins en C# (un lenguaje que conozco bien), la experiencia de hacerlo es horrible. Con Emacs, pese a tener que usar elisp (lenguaje que conozco mucho menos), es mucho más sencillo hacer pequeñas mejoras para ajustarlo a lo que quieres y es algo que hago con frecuencia«.

Juanma usa Emacs para «HTML, CSS, JavaScript, TypeScript y lenguajes variados de uso esporádico, utilizo Emacs con una configuración creada desde cero que tengo publicada aquí. Para Javascript utilizo js2-mode, para TypeScript uso tide y cuando juego con Clojure, cider«.

La ventaja de este tipo de editores, es que la configuración se puede compartir fácilmente. Normalmente la configuración suele ir incluida en un solo archivo, y basta con bajarlo de GitHub y sobreescribirlo para tener el editor configurado a nuestro gusto (o al de otro desarrollador que lo haya compartido). Es por ejemplo lo que hace Gaspar en Cbi Consulting, «Últimamente me paso el día entre scripts Bash, Python y servidores. Aunque también suelo tocar cosas de PHP y en ocasiones tengo que hacer algunos programas en C o C++. Edito con Emacs. Tengo una configuración muy personalizada y la tengo publicada en github para bajarla siempre que la necesito. Tengo configuración especial para los lenguajes que suelo usar, comprobación de código, compilación, teclas personalizadas para muchas acciones, deshacer con undo-tree (importante porque el deshacer de Emacs es muy pesado), auto-completado y algunas cosas más. No pido mucho.

«La curva de aprendizaje en Emacs es dura y fue una cuestión de cabezonería, pero ahora me resulta muy cómodo»

Aunque Emacs y Vim funcionan realmente bien, también tienen sus peros. Por ejemplo la curva de aprendizaje. Sus forma de funcionar y sus teclas de acceso rápido están pensados para ser lo más eficientes posibles, pero no para ser fácilmente memorizables. Aprender a utilizar uno de estos editores lleva mucho tiempo, y es una de las razones de que no estén más extendidos. Como dice Juanma «La curva de aprendizaje en Emacs es dura y fue una cuestión de cabezonería, pero ahora me resulta muy cómodo»

IDEs

A pesar de la potencia de muchos editores, hay que añadirles muchas extensiones obtener la capacidad que los IDEs ya traen de base. Esto hace que mucha gente prefiera esta herramienta, ya que tienen todas las funcionalidades integradas en un mismo entorno y tan solo hay que configurar algunas cosas para personalizarlas a nuestra forma de trabajar.

Por ejemplo Adolfo, que trabaja como Asesor Técnico Docente en la CAM, utiliza Eclipse (Spring Tool Suite) para su día a día con el backend: «llevo utilizando Eclipse desde sus inicios, y soy muy productivo con esa herramienta pues ya me conozco todos sus atajos de teclado y todos sus truquitos. Una temporada que estuve con Groovy me pasé a IntelliJ IDEA pues me habían hablado muy bien de él, pero al final me quedo con Eclipse, que además es Software Libre«.

Diego José, que trabaja como freelance desde hace 17 años, para desktop utiliza Delphi «No está muerto«, nos dice. «Ahora compila para Windows, OSX, iOS y Android y no ha dejado de tener versiones. No es muy conocido por su política de precios (que viene a ser una pasta gansa). El lenguaje es Object Pascal. Con Delphi llevo desde que sus primeras versiones. El IDE y su Visual Control Library aportan una productividad altísima.«. Para PHP prefiere utilizar PHPStorm «PHPStorm es un IDE completo. Y es lo que busco. Sin preocuparme de buscar más, tengo todas las utilidades que necesito. Tiene de todo y más«.

Y es que parece que PHPStorm es una de las herramientas más conocidas a la hora de programar con PHP. Lo utiliza por ejemplo Miguel, profesor de la Universidad del Táchira y desarrollador web freenlance, «trabajo en PHP utilizando Yii2 Framework y desarrollando plugins de WordPress, sin embargo, a veces me toca mejorar las vistas, por lo que tengo que usar HTML/CSS y JS a menor escala. Uso sublime-text cuando necesito editar algo rapidamente o hacer pequeños scripts. Ya cuando son proyectos mas grandes uso un IDE, en este caso PHPStorm. Desde el mismo IDE realizar todas las actividades que necesito: acceder a la Base de Datos, probar servicios REST, realizar pruebas, validar código, etc. Más que todo busco automatizar cosas«.

Trabajando en coches.com, tenemos a Jesús, que es otro fan de PHPStorm: «Soy un poco friki de los atajos de teclado y poco a poco he ido memorizando atajos de PHPStorm para casi todo: Abrir una clase/fichero, buscar en un directorio, extraer un método/constante/variable,… además si no hay un atajo para algo que quiero hacer es muy fácil crearlo en PHPStorm. La integración con docker es genial y además tiene un montón de plugins para casi todo desde autocompletar composer hasta crear el .gitignore«

Al final los usuarios de IDEs buscan tener la mayoría de funcionalidades integradas, y no complicarse la vida. Es lo que nos cuenta Lucas, que trabaja generalmente con Visual Studio (con Resharper) y C# (aunque también usa Vim o PyCharm): «Para obtener la máxima productividad se requiere un IDE, un entorno con facilidades integradas que te permitan refactorizar, depurar, desplegar en la nube y cosas por el estilo de manera rápida y simple (usar git desde línea de comando es una de las poquísimas excepciones a esta regla para mi). Cuando por falta de contexto, ausencia de metadatos, de definición de tipos (o de lo que sea) y un IDE queda reducido a un simple editor de texto, en ese caso es quizás mejor utilizar un buen editor de texto. Lo contrario a esto es el tratar de convertir un editor de texto en un IDE a base de plugins para colorear la sintaxis de un lenguaje, lograr algún grado (siempre insuficiente) de autocompletado y/o refactoring, y ni que hablar de depuración integrada y similares facilidades tan comunes en los IDEs«, aunque reconoce que «cuando ves lo que hacen algunos con Emacs te sorprendes. Por lo general se destacan en lenguajes dinámicos donde los IDEs hasta hace poco no aportaban demasiado y donde es posible evaluar expresiones de manera rápida y evitar la depuración zombie«

«Para obtener la máxima productividad se requiere un IDE, un entorno con facilidades integradas que te permitan refactorizar, depurar, desplegar en la nube y cosas por el estilo de manera rápida y simple»

En entornos .NET, hasta hace no mucho Visual Studio era la opción por defecto, aunque hay gente que empieza a utilizar Visual Studio Code para ello. Además JetBrains, está preparando un IDE para .NET llamado Rider, de momento en fase de desarrollo. Mientras llega, en .NET se sigue utilizando Visual Studio como bien nos comenta Ferran, «Tanto para tareas de frontend como backEnd utilizo el Visual Studio, ya que el programa está desarrollado en Visual Basic .NET con SQL Server como SGBD. Utilizo la versión 2015, ya que la versión 2017 todavía anda en pañales o por lo que leo no es mucho de fiar. También utilizo Resharper».

Y es que está claro que JetBrains tiene contentos a muchos desarrolladores de distintas plataformas y lenguajes con sus soluciones, ya que Resharper es una de las extensiones más comunes a la hora de utilizar Visual Studio.

Los nuevos editores

Hace ya un tiempo, Sublime Text, empezó a marcar el camino que seguirían otros editores posteriores como Brackets, Atom o Visual Studio Code. Y es que muchos desarrolladores están pasándose a utilizar este tipo de herramientas.

Por ejemplo Mario, que nos hablaba antes de Vim, utiliza Visual Studio Code para programar en Node: «Ahora mismo, al moverme a programar en NodeJS, estoy probando VS Code ya que posee un debugger que funciona bastante bien. Lo he utilizado para otros lenguajes como Ruby o Python y estoy muy contento con él. El plugin para modo VIM está muy bien«.

Lo mismo que Adolfo, que aunque utiliza Eclipse para la programación backend «para el front pasé por varios IDEs: primero Brackets, luego Atom y finalmente, cuando me enteré de que Microsoft lanzó Visual Studio Code con una licencia Libre me dió por probarlo, y la verdad es que fué un amor a primera vista. Tiene temas, plugins, debuguer, buena integración con Git, autocompletado de código, funciona muy bien con HTML, CSS, JS y TypeScript.«

Opciones para todos los gustos

En definitiva, a la hora de elegir herramientas para desarrollar nuestra tarea, tenemos multitud de opciones. Es curioso como programadores de la misma plataforma, utilizan configuraciones tan diferentes, haciendo su IDE o editor un poquito diferente al de los demás. ¿Y tú que herramienta utilizas?

En GenbetaDev | Paréntesis y llaves de colores en Emacs, gracias a Rainbow Delimiters | Sublime Text 2 ¿el editor de texto definitivo?

Imagen cabecera | swiatekj

También te recomendamos

Unit Test Generator para Visual Studio 2012

Truco, volver a Crear pruebas unitarias desde Visual Studio 2012

WaterWall™: cómo es la tecnología que limpia los platos de forma vertical

–
La noticia

Las herramientas del programador ¿Y tú cuál usas?

fue publicada originalmente en

Genbeta Dev

por
rubenfa

.

0

NOTICIA

Continuous Delivery en profundidad: pipelines de Jenkins

By admin on

5 julio, 2017

- NOTICIA

En esta primera entrega, explicaremos cómo usar los pipelines de Jenkins con Stratio Big Data para obtener un rastreo de ciclo de vida completo, desde el equipo de desarrollo al entorno de productivo final.

Durante el “Lunch & Learn” sobre Continuos Delivery de Stratio vimos algunos de los problemas y ahora trataremos de explicarlos para que podáis comprender sin problema la naturaleza de los principales bugs y la solución que hemos implementado (algo que explicaremos en la segunda parte).

Los pipelines son código

Cada uno de nuestros pipeline está en un grupo privado de github bajo Stratio’s organization repo, donde contamos con varios elementos:

l.groovy
libvars.groovy
libpipeline.groovy
dev-project.groovy

l.groovy es el directorio principal para los métodos compartidos y se utiliza para analizar los archivos, comprobar el código, hacer compilaciones, ejecutar pruebas y crear imágenes de docker. Más de 70 métodos, la mayoría privados. El pipeline de Jenkins nos permite cargarlo de forma automática desde un repositorio jenkins interno, pero para hacerlo más fácil, nos saltamos esa opción y dejamos el archivo en github.

libvars.groovy es el directorio para las variable compartidas. Groovy permite variables sin tipo, pero algunas son con tipo para tener un mejor mantenimiento. Algunas de esas variables son constantes, comos las urls (internal nexus, gitolite o registro de docker), canales en slack y versiones predeterminadas.

libpipeline.groovy es el método principal. Decidirá qué tipo de operaciones se van a llevar a cabo en la tarea actual. Volveremos a hablar sobre este archivo más adelante.

dev-project.groovy es el verdadero pipeline. Verdadero porque carga los tres archivos anteriores, establece los valores de las variables e invoca el método principal previo. A modo de ejemplo, podemos echarle un vistazo a uno de los proyectos en código abierto de Stratio (Stratio Crossdata) que viene con comentarios sobre su objetivo:



import groovy.transform.Field

@Field String lib

node('master') { //Common element load
    def cdpwd = pwd().split('/').reverse()[0].replaceAll('@.*', '')
    lib = load "../${cdpwd}@script/l.groovy"
    l.vars = load "../${cdpwd}@script/libvars.groovy"
    l.pipeline = load "../${cdpwd}@script/libpipeline.groovy"
}

// Some metadata for checking out, identifying and messaging abouts warnings/errors
l.v.MODULE = 'crossdata' 
l.v.MAIL = 'crossdata@stratio.com'
l.v.REPO = 'Stratio/crossdata'
l.v.ID = 'xd'
l.v.SLACKTEAM = 'stratiocrossdata'
l.v.FAILFAST = true 

// Stratio is polyglot, and so are its developments. 
// We need to know what build tool we have to use
l.v.BUILDTOOL = 'maven' 

// Should we deploy to sonatype oss repository (so maven artifacts become public)
l.v.FOSS = true 

// Each PR gets statuses, as soon as each run action passes or fails
l.v.PRStatuses = ['Compile', 'Unit Tests', 'Integration Tests', 'Code Quality'] 

l.v.MERGETIMEOUT = 70  // Timeous for each kind of operation we could perform
l.v.PRTIMEOUT = 30
l.v.RELEASETIMEOUT = 30
l.v.SQUASHTIMEOUT = 15

l.v.MERGEACTIONS = { // If our git hook sent a payload related to a PR being merged 
                  l.doBuild()

                  parallel(UT: {
                     l.doUnitTest()
                  }, IT: {
                     l.doIntegrationTest()
                  }, failFast: l.v.FAILFAST)

                  l.doPackage() //Might be a tgz, deb, jar, war
                  // java-scaladocs are published to our s3 bucket 
                  // (such as http://stratiodocs.s3-website-us-east-1.amazonaws.com/cassandra-lucene-index/3.0.6.1/)
                  l.doDoc() 

                  parallel(CQ: {
                     // Static code analysis with Sonarqube 
                     // and coveralls.io (for some FOSS projects)
                     l.doCodeQuality() 
                  }, DEPLOY: {
                     l.doDeploy()
                  }, failFast: l.v.FAILFAST)

                  // And push it to our internal docker registry
                  //, for a later usage in tests and demos
                  l.doDockerImage() 
                  // A Marathon cluster deploys the previously build image
                  l.doMarathonInstall('mc1') 
                  l.doAcceptanceTests(['basic', 'auth', cassandra', 'elasticsearch', 'mongodb', mesos', 'yarn'])
                 }

l.v.PRACTIONS = { // If our git hook sent a payload about a PR being opened or synced
               l.doBuild()

               parallel(UT: {
                  l.doUnitTest()
               }, IT: {
                  l.doIntegrationTest()
               }, failFast: l.v.FAILFAST)

               l.doCodeQuality()
               // We deploy a subset of our wannabe packages to an staging repo            
               l.doStagePackage()
               // Work as packer, building a temporal docker image, so a container can be used for testing 
               l.doPackerImage() 
               l.doAcceptanceTests(['basic', 'auth', cassandra', 'elasticsearch', 'mongodb', mesos', 'yarn'])
              }

l.v.BRANCHACTIONS = { // We could receive a hook signalling a branch to be forged
                   l.doBranch()
                  }

l.v.RELEASEACTIONS = { // So we could release a final version
                    l.doRelease()
                    l.doDoc()
                    l.prepareForNextCycle()
                    // This time the image is the real deal
                    // It will end @ Docker Hub (https://hub.docker.com/r/stratio/)
                    l.doDockerImage() 

                    // Deploying again, to a production Marathon cluster
                    l.doMarathonInstall('mc2')
                    // Let the world know a new version is released, and spread its changelog
                    l.doReleaseMail() 
                   }

l.v.SQUASHACTIONS = {
                   // Currently just checks a PR statuse, rebases it, 
                   // invokes l.v.PRACTIONS, and merges the PR
                   l.doSquash() 
                  }

l.pipeline.roll()

Volviendo al libpipeline.groovy, podemos ver cómo se utilizan algunas de las variables previamente configuradas:

Algunas de las opciones que no se mencionan son las más brillantes: Antes de realizar los tests de integración y aceptación, se seleccionan, ejecutan y configuran varias imágenes de docker. Cuando finalizan los tests se destruyen los contenedores, pudiendo disfrutar de un entorno limpio para hacer pruebas.

Como ya te podrás imaginar, se pueden consultar tanto los repositorios públicos como los privados en diferentes proveedores de gits (github, gitlab, bitbucket). Podemos trabajar con maven y hacer proyectos.

Y como la mayoría de los elementos pueden ser definidos por cada equipo de desarrollo, algunos elementos pueden leerse desde cada repositorio git:

Un entrypoint de docker para usarlo al montar cada imagen
- Un archivo que defina la mayoría de las variables del pipeline

Javier Delgado es evangelista no oficial del uso de Jenkins para tareas continuas (inspection, testing, delivery), apasionado de la automatización y orador en diferentes conferencias sobre estas materias. Ingeniero informático y fiel seguidor del aprendizaje continuo, actualmente trabaja como ingeniero DevOps en Stratio, compañía de big data española-americana pionera en ofrecer a grandes empresas una transformación digital completa en torno a sus datos a través de un único producto.

Articulo original publicado en el blog de Stratio.

También te recomendamos

SDKMAN!: Un gestor de SDKs para dominarlos a todos

WaterWall™: cómo es la tecnología que limpia los platos de forma vertical

Mantra. Pruebas de seguridad desde el navegador.

–
La noticia

Continuous Delivery en profundidad: pipelines de Jenkins

fue publicada originalmente en

Genbeta Dev

por
Javier Delgado Garrido

.

0

NOTICIA

Continuous Delivery en profundidad: pipelines

By admin on

5 julio, 2017

- NOTICIA

Articulo original publicado en el blog de Stratio.

En esta primera entrega, explicaremos cómo usar los pipelines de Jenkins con Stratio Big Data para obtener un rastreo de ciclo de vida completo, desde el equipo de desarrollo al entorno de productivo final.

Durante el “Lunch & Learn” sobre Continuos Delivery de Stratio vimos algunos de los problemas y ahora trataremos de explicarlos para que podáis comprender sin problema la naturaleza de los principales bugs y la solución que hemos implementado (algo que explicaremos en la segunda parte).

Los pipelines son código

Cada uno de nuestros pipeline está en un grupo privado de github bajo Stratio’s organization repo, donde contamos con varios elementos:

l.groovy
libvars.groovy
libpipeline.groovy
dev-project.groovy

l.groovy es el directorio principal para los métodos compartidos y se utiliza para analizar los archivos, comprobar el código, hacer compilaciones, ejecutar pruebas y crear imágenes de docker. Más de 70 métodos, la mayoría privados. El pipeline de Jenkins nos permite cargarlo de forma automática desde un repositorio jenkins interno, pero para hacerlo más fácil, nos saltamos esa opción y dejamos el archivo en github.

libvars.groovy es el directorio para las variable compartidas. Groovy permite variables sin tipo, pero algunas son con tipo para tener un mejor mantenimiento. Algunas de esas variables son constantes, comos las urls (internal nexus, gitolite o registro de docker), canales en slack y versiones predeterminadas.

libpipeline.groovy es el método principal. Decidirá qué tipo de operaciones se van a llevar a cabo en la tarea actual. Volveremos a hablar sobre este archivo más adelante.

dev-project.groovy es el verdadero pipeline. Verdadero porque carga los tres archivos anteriores, establece los valores de las variables e invoca el método principal previo. A modo de ejemplo, podemos echarle un vistazo a uno de los proyectos en código abierto de Stratio (Stratio Crossdata) que viene con comentarios sobre su objetivo:



import groovy.transform.Field

@Field String lib

node('master') { //Common element load
    def cdpwd = pwd().split('/').reverse()[0].replaceAll('@.*', '')
    lib = load "../${cdpwd}@script/l.groovy"
    l.vars = load "../${cdpwd}@script/libvars.groovy"
    l.pipeline = load "../${cdpwd}@script/libpipeline.groovy"
}

// Some metadata for checking out, identifying and messaging abouts warnings/errors
l.v.MODULE = 'crossdata' 
l.v.MAIL = 'crossdata@stratio.com'
l.v.REPO = 'Stratio/crossdata'
l.v.ID = 'xd'
l.v.SLACKTEAM = 'stratiocrossdata'
l.v.FAILFAST = true 

// Stratio is polyglot, and so are its developments. 
// We need to know what build tool we have to use
l.v.BUILDTOOL = 'maven' 

// Should we deploy to sonatype oss repository (so maven artifacts become public)
l.v.FOSS = true 

// Each PR gets statuses, as soon as each run action passes or fails
l.v.PRStatuses = ['Compile', 'Unit Tests', 'Integration Tests', 'Code Quality'] 

l.v.MERGETIMEOUT = 70  // Timeous for each kind of operation we could perform
l.v.PRTIMEOUT = 30
l.v.RELEASETIMEOUT = 30
l.v.SQUASHTIMEOUT = 15

l.v.MERGEACTIONS = { // If our git hook sent a payload related to a PR being merged 
                  l.doBuild()

                  parallel(UT: {
                     l.doUnitTest()
                  }, IT: {
                     l.doIntegrationTest()
                  }, failFast: l.v.FAILFAST)

                  l.doPackage() //Might be a tgz, deb, jar, war
                  // java-scaladocs are published to our s3 bucket 
                  // (such as http://stratiodocs.s3-website-us-east-1.amazonaws.com/cassandra-lucene-index/3.0.6.1/)
                  l.doDoc() 

                  parallel(CQ: {
                     // Static code analysis with Sonarqube 
                     // and coveralls.io (for some FOSS projects)
                     l.doCodeQuality() 
                  }, DEPLOY: {
                     l.doDeploy()
                  }, failFast: l.v.FAILFAST)

                  // And push it to our internal docker registry
                  //, for a later usage in tests and demos
                  l.doDockerImage() 
                  // A Marathon cluster deploys the previously build image
                  l.doMarathonInstall('mc1') 
                  l.doAcceptanceTests(['basic', 'auth', cassandra', 'elasticsearch', 'mongodb', mesos', 'yarn'])
                 }

l.v.PRACTIONS = { // If our git hook sent a payload about a PR being opened or synced
               l.doBuild()

               parallel(UT: {
                  l.doUnitTest()
               }, IT: {
                  l.doIntegrationTest()
               }, failFast: l.v.FAILFAST)

               l.doCodeQuality()
               // We deploy a subset of our wannabe packages to an staging repo            
               l.doStagePackage()
               // Work as packer, building a temporal docker image, so a container can be used for testing 
               l.doPackerImage() 
               l.doAcceptanceTests(['basic', 'auth', cassandra', 'elasticsearch', 'mongodb', mesos', 'yarn'])
              }

l.v.BRANCHACTIONS = { // We could receive a hook signalling a branch to be forged
                   l.doBranch()
                  }

l.v.RELEASEACTIONS = { // So we could release a final version
                    l.doRelease()
                    l.doDoc()
                    l.prepareForNextCycle()
                    // This time the image is the real deal
                    // It will end @ Docker Hub (https://hub.docker.com/r/stratio/)
                    l.doDockerImage() 

                    // Deploying again, to a production Marathon cluster
                    l.doMarathonInstall('mc2')
                    // Let the world know a new version is released, and spread its changelog
                    l.doReleaseMail() 
                   }

l.v.SQUASHACTIONS = {
                   // Currently just checks a PR statuse, rebases it, 
                   // invokes l.v.PRACTIONS, and merges the PR
                   l.doSquash() 
                  }

l.pipeline.roll()

Volviendo al libpipeline.groovy, podemos ver cómo se utilizan algunas de las variables previamente configuradas:

Algunas de las opciones que no se mencionan son las más brillantes: Antes de realizar los tests de integración y aceptación, se seleccionan, ejecutan y configuran varias imágenes de docker. Cuando finalizan los tests se destruyen los contenedores, pudiendo disfrutar de un entorno limpio para hacer pruebas.

Como ya te podrás imaginar, se pueden consultar tanto los repositorios públicos como los privados en diferentes proveedores de gits (github, gitlab, bitbucket). Podemos trabajar con maven y hacer proyectos.

Y como la mayoría de los elementos pueden ser definidos por cada equipo de desarrollo, algunos elementos pueden leerse desde cada repositorio git:

Un entrypoint de docker para usarlo al montar cada imagen
- Un archivo que defina la mayoría de las variables del pipeline

Javier Delgado es evangelista no oficial del uso de Jenkins para tareas continuas (inspection, testing, delivery), apasionado de la automatización y orador en diferentes conferencias sobre estas materias. Ingeniero informático y fiel seguidor del aprendizaje continuo, actualmente trabaja como ingeniero DevOps en Stratio, compañía de big data española-americana pionera en ofrecer a grandes empresas una transformación digital completa en torno a sus datos a través de un único producto.

También te recomendamos

WaterWall™: cómo es la tecnología que limpia los platos de forma vertical

Diez tecnologías que los javeros amamos (o al menos hablamos bien de ellas)

Continuous Delivery en profundidad: problemas y soluciones alternativas comunes de los pipelines de Jenkins

–
La noticia

Continuous Delivery en profundidad: pipelines

fue publicada originalmente en

Genbeta Dev

por
Javier Delgado Garrido

.

0

Un primer vistazo a las co-rutinas de Kotlin en Android

By admin on

3 julio, 2017

- NOTICIA

Las co-rutinas han sido la mayor incorporación en Kotlin 1.1. Son absolutamente geniales debido a su potencia, y la comunidad aún sigue descubriendo como aprovecharlas al máximo.

Explicado de forma simple, las co-rutinas son una manera de escribir código asíncrono de forma secuencial. En lugar de llenarlo todo de callbacks, puedes escribir tus líneas de código una detrás de otra. Algunas de ellas tendrán la capacidad de suspender la ejecución y esperar hasta que el resultado esté disponible.

Si te has formado como desarrollador de C#, async/wait es el concepto más parecido. Pero las co-rutinas en Kotlin son más potentes, porque en lugar de ser una implementación especifica de la idea, son una característica del lenguaje que puede implementarse de diferentes maneras para solucionar distintos problemas.

Las co-rutinas están basadas en la idea de funciones de suspensión: funciones que pueden parar la ejecución cuando son llamadas y reanudarla una vez que han terminado de ejecutar su propia tarea

Puedes escribir tu propia implementación, o usar una de las múltiples opciones que el equipo de Kotlin y otros desarrolladores independientes han construido.

Necesitas entender que las co-rutinas son una característica experimental en Kotlin 1.1. Esto quiere decir que la implementación podría cambiar en el futuro, y aunque la antigua aún será compatible, podrías querer migrar a la nueva definición. Como veremos después, necesitas optar por esta característica, de lo contrario verás un warning cuando la utilices.

Esto quiere decir que debes tomar este artículo como un ejemplo de que puedes hacer, no como una regla general. Las cosas pueden cambiar mucho en los próximos meses.

Entendiendo como trabajan las co-rutinas

Mi meta con este artículo es que seas capaz de tomar algunos conceptos básicos y ponerlos en práctica usando las librerías que hay, no construir tus propias implementaciones. Pero creo que es importante entender algo de cómo funcionan por dentro para que no te limites a usar ciegamente lo que te proveen las librerías.

Las co-rutinas están basadas en la idea de funciones de suspensión (suspending functions): funciones que pueden parar la ejecución cuando son llamadas y reanudarla una vez que han terminado de ejecutar su propia tarea.

Las funciones de suspensión se señalan con la palabra reservada suspend, y sólo pueden ser llamadas dentro de otras funciones de suspensión o de una co-rutina.

Esto significa que no puedes llamar a una función de suspensión en cualquier lugar. Es necesario que exista una función circundante que construya la co-rutina y proporcione el contexto requerido para que se haga. Algo como esto:

fun  async(block: suspend () -> T)

No voy a explicar cómo implementar la función de arriba. Es un proceso complejo que se sale del cometido de este artículo, y como comentaba ya hay soluciones implementadas que cubrirán la mayoría de los casos.

Si estás realmente interesado en construir la tuya, puedes leer la especificación escrita en el Github de co-rutinas. Sólo necesitas saber que la función puede tener cualquier nombre que quieras darle, y que tendrá al menos un bloque de suspensión como parámetro.

Entonces implementarías una función de suspensión y la llamarías dentro de ese bloque:

suspend fun mySuspendingFun(x: Int) : Result {
    ...
}

async { 
    val res = mySuspendingFun(20)
    print(res)
}

¿Entonces las co-rutinas son hilos? No exactamente. Funcionan de manera parecida, pero son mucho más ligeras y eficientes. Puedes tener millones de co-rutinas ejecutándose en unos pocos hilos, lo que abre un mundo de posibilidades.

Puedes usar las co-rutinas de tres maneras:

Implementación desde cero: esto implica construir tu propia manera de usar las co-rutinas. Es bastante complicado y por lo general no es necesario en absoluto.
Implementaciones de bajo nivel: Kotlin ofrece un conjunto de librerías que puedes encontrar en el repositorio kotlinx.coroutines, que resuelven algunas de las partes más difíciles y ofrecen una implementación especifica para diferentes escenarios. Hay una para Android, por ejemplo.
Implementaciones de más alto nivel: Si sólo buscas una solución que proporcione todo lo necesario para empezar a usar co-rutinas, hay muchas librerías que hacen todo el trabajo sucio por ti, y la lista no deja de crecer. Me voy a quedar con Anko, que proporciona una solución que funciona estupendamente con Android, y que probablemente te será familiar.

Usar Anko para las co-rutinas

Desde la versión 0.10, Anko ha proporcionado un par de maneras de usar co-rutinas en Android.

La primera es muy parecida a lo que hemos visto en el ejemplo de arriba, y también es similar a lo que hacen otras librerías.

Primero, necesitas crear un bloque asíncrono donde las funciones de suspensión puedan ser llamadas:

async(UI) {
    ...
}

El argumento UI es el contexto de la ejecución para el bloque async.

Entonces puedes crear bloques que sean ejecutados en un hilo en segundo plano y devolver el resultado al hilo de la UI. Estos bloques se definen usando la función bg:

async(UI) {
    val r1: Deferred = bg { fetchResult1() }
    val r2: Deferred = bg { fetchResult2() }
    updateUI(r1.await(), r2.await())
}

bg devuelve un objeto Deferred, el cual suspenderá la co-rutina cuando la función await() sea llamada, sólo hasta que el resultado sea devuelto. Usaremos esta solución en el ejemplo que hay más abajo.

Como puede que sepas, una de las características más interesantes cuando estás aprendiendo Kotlin, es que el compilador es capaz de inferir el tipo de las variables, así que esto puede hacerse más sencillo:

async(UI) {
    val r1 = bg { fetchResult1() }
    val r2 = bg { fetchResult2() }
    updateUI(r1.await(), r2.await())
}

La segunda alternativa es hacer uso de la integración con los listeners que proporcionan sub-librerias especificas, dependiendo del listener que vayas a utilizar.

Por ejemplo, en anko-sdk15-coroutines, existe un onClick listener cuya lambda es de hecho una co-rutina. Así que puedes empezar a usar funciones de suspensión inmediatamente dentro del bloque del listener.

textView.onClick {
    val r1 = bg { fetchResult1() }
    val r2 = bg { fetchResult2() }
    updateUI(r1.await(), r2.await())
}

Como puedes ver el resultado es bastante similar al anterior. Solo estás ahorrándote un poco de código.

Para usarla, necesitarás añadir algunas de estas dependencias, dependiendo del listener que quieras usar:

compile "org.jetbrains.anko:anko-sdk15-coroutines:$anko_version"
compile "org.jetbrains.anko:anko-appcompat-v7-coroutines:$anko_version"
compile "org.jetbrains.anko:anko-design-coroutines:$anko_version"

Usando co-rutinas en un ejemplo

En el ejemplo que desarrollo en el libro (que puedes encontrar aquí en Github), se crea una sencilla aplicación de tiempo.

Para usar las co-rutinas de Anko, primero necesitamos incluir la nueva dependencia:

compile "org.jetbrains.anko:anko-coroutines:$anko_version"

A continuación, si recuerdas, te dije que necesitabas activar esta característica, de lo contrario mostrará un warning. Para hacer esto, simplemente añade esta linea a el fichero gradle.properties en el directorio raíz (créalo si no existe aún):

kotlin.coroutines=enable

Ahora sí, ya tienes todo lo que necesitas para empezar a usar co-rutinas. Vamos primero a la actividad del detalle. Sólo llama a la base de datos (que se encarga de almacenar el pronostico semanal) utilizando un comando especifico.

Este es el código resultante:

async(UI) {
    val id = intent.getLongExtra(ID, -1)
    val result = bg { RequestDayForecastCommand(id).execute() }
    bindForecast(result.await())
}

¡Es estupendo! La previsión del tiempo se solicita en un hilo en segundo plano gracias a la función bg, que devuelve un resultado diferido. La espera de este resultado suspende la co-rutina por la llamada al await, hasta que el pronóstico esté listo para ser devuelvo.

Pero no todo es tan bonito. ¿Qué está pasando aquí? Las co-rutinas tienen un problema: están guardando una referencia a DetailActivity, provocando un leak si la petición nunca termina por ejemplo.

No te preocupes, ya que Anko tiene una solución. Puedes crear una referencia débil a tu actividad, y usarla en su lugar:

val ref = asReference()
val id = intent.getLongExtra(ID, -1)
async(UI) {
    val result = bg { RequestDayForecastCommand(id).execute() }
    ref().bindForecast(result.await())
}

Esta referencia permitirá llamar a la actividad cuando esté disponible, y cancelará la co-rutina en caso de que la actividad haya sido eliminada. Asegúrate de que todas las llamadas a métodos de la actividad o propiedades se realizan a través de este objeto ref.

Pero esto puede resultar un poco complicado si la co-rutina interactúa varias veces con la actividad. En MainActivity, por ejemplo, el uso de esta solución va a ser un poco más complicado.

Esta actividad llamará a un endpoint para solicitar un pronóstico semanal basado en un zipCode:

private fun loadForecast() {
    val ref = asReference()
    val localZipCode = zipCode
    async(UI) {
        val result = bg { RequestForecastCommand(localZipCode).execute() }
        val weekForecast = result.await()
        ref().updateUI(weekForecast)
    }
}

No puedes usar ref() dentro del bloque bg, porque el código dentro de ese bloque no es un contexto de suspensión, por lo que necesitas guardar el zipCode en otra variable local.

Personalmente creo que provocar un leak de la actividad durante 1-2 segundos no es tan malo, y probablemente no valdrá la pena el boilerplate. Por lo tanto, si puedes asegurarte de que tu proceso en segundo plano no puede durar para siempre (por ejemplo, estableciendo un tiempo máximo de espera en sus solicitudes de servidor), estarás a salvo de no usar asReference().

De esta manera, los cambios a MainActivity serían más simples:

private fun loadForecast() = async(UI) {
    val result = bg { RequestForecastCommand(zipCode).execute() }
    updateUI(result.await())
}

Así que con todo esto, ahora tienes tu código asíncrono escrito de forma síncrona fácilmente.

Este código es bastante simple, pero imagina otras situaciones complejas en las que el resultado de una operación en segundo plano es utilizado por la siguiente, o cuando necesitas iterar sobre una lista y ejecutar una solicitud por cada elemento.

Todo esto se puede escribir como código síncrono normal, que será mucho más fácil de leer y mantener.

Para simplificarlo, las co-rutinas son una manera de escribir código asíncrono secuencialmente

Aún hay mucho más que aprender para sacar el máximo provecho de las co-rutinas. Así que si tienes algo más de experiencia sobre esto, utiliza los comentarios para contarnos más sobre ello.

En Genbeta Dev | Kotlin es oficial para Android ¿Qué implicaciones tiene para los desarrolladores?
Libro | Kotlin for Android Developers

También te recomendamos

WaterWall™: cómo es la tecnología que limpia los platos de forma vertical

Kotlin 1.1 también es para desarrolladores Android

¿Será 2017 el año de Kotlin? Repasamos su evolución y por qué deberías darle una oportunidad

–
La noticia

Un primer vistazo a las co-rutinas de Kotlin en Android

fue publicada originalmente en

Genbeta Dev

por
Antonio Leiva

.

0

NOTICIA

El resurgir de la programación funcional

By admin on

2 julio, 2017

- NOTICIA

Aunque nunca hayas trabajado con ella, seguro que has oído hablar de la programación funcional. Y cada día más, ya que parece que hay un hype con ella. Este paradigma de programación, que parecía haber sido olvidado por la gran masa de desarrolladores, lleva unos cuantos años resurgiendo.

Es cierto que han sido otros lenguajes imperativos, en especial los imperativos y orientados objetos, los que se han llevado la fama de ser más productivos y eficaces para un mayor número de tareas. Pero no todo el mundo piensa igual. Últimamente ha aparecido una corriente crítica, argumentando que la mayoría de las ventajas que este tipo de lenguajes proponen, quizá no sean tan definitivas. Si bien la POO siempre ha prometido modelar el mundo real y proporcionar código reutilizable, cuando adquirimos algo de experiencia nos damos cuenta que eso no es nada sencillo.

Así que no ha tardado en aparecer gente que piensa que es más fácil programar con un enfoque funcional, afirmando incluso, que se es mucho más productivo y que se reduce el número de bugs y errores.

Si los lenguajes funcionales son la solución a todos nuestros problemas (seguramente no), es algo que el tiempo dirá, pero mientras tanto podemos analizar qué opciones tenemos.

¿Por qué el resurgimiento de la programación funcional?

La programación funcional lleva muchos años entre nosotros, pero siempre se asociaba más a entornos académicos que a empresariales y productivos. Es algo que parece que empieza a cambiar y muchas empresas, algunas muy importantes, están apostando fuerte por este paradigma. ¿Por qué?

Una de las razones puede ser que las aplicaciones son cada vez más difíciles de ejecutar en una sola máquina. Cada vez es más necesario poder soportar grandes dosis de concurrencia y paralelismo. No obstante el hardware actual, nos proporciona unas capacidades de paralelismo nunca vistas, y la nube hace cada vez más sencillo (y barato) construir sistemas distribuidos en distintos servidores. Y claro, para tareas como estas, un lenguaje funcional puede desenvolverse como pez en el agua.

La programación funcional tiene conceptos muy interesantes, tanto que que muchos lenguajes no funcionales están poco a poco adoptándolos

Está claro también, que la programación funcional tiene conceptos muy interesantes, tanto que que muchos lenguajes no funcionales están poco a poco adoptándolos. Las últimas versiones de Java ya incluyen expresiones lambda, cosa ya incluida C# hace mucho tiempo. Cada versión de C# incluye más características funcionales y de hecho en su última versión, la 7, incluye el concepto funcional del pattern matching. Ruby, Python o Go, son otros lenguajes que incorporan algunas características funcionales.

Tampoco debemos olvidar JavaScript, que tiene muchos conceptos funcionales desde hace tiempo (funciones anónimas, funciones como miembros de primera clase etc.). Al ser uno de los lenguajes más populares, es fácil que estos conceptos lleguen cada vez a más programadores, haciendo que la revolución funcional llegue un poquito más lejos.

Pero esto no acaba aquí, ya que a los viejos rockeros funcionales, se están añadiendo muchos nuevos lenguajes, con muchas otras características modernas. Es el caso de Elixir, Clojure, Scala o Elm, por citar algunos.

¿Pero esto es ruído o es una tendencia de verdad?

A los programadores nos encanta estar a la última. Antes que aprender Cobol, seguramente prefiramos aprender algo más moderno (que no tiene porque ser mejor). Tanto nos gusta aprender, que muchas veces acabamos cayendo en el hype sin pararnos a pensar en las consecuencias.

Pensando en los fríos datos, y mirando el índice Tiobe del último mes, podemos ver que los lenguajes funcionales están muy lejos de los primeros puestos. Hay más datos que nos ayudan a corroborar este punto y si nos vamos a la famosa encuesta de Stack Overflow de 2017, los datos son parecidos. Los lenguajes funcionales no están ni de lejos entre los más populares. En el mundo laboral, pasa más o menos lo mismo. Podemos ver en Indeed que el número de empleos en lenguajes funcionales, es muy bajo comparado con el de otros lenguajes más populares como Java o C#.

Esto no quiere decir que debamos dejar de lado la programación funcional, simplemente que debemos ponerla en su contexto. Si queremos encontrar un trabajo como programador, es más fácil encontrar un trabajo utilizando un lenguaje no funcional. Pero si es cierto que numerosas startups, de esas que están cambiando las reglas del juego, apuestan cada vez más por ese paradigma. Así que quizá no sea descabellado empezar a invertir tiempo en aprender alguno de estos lenguajes. Y si no, al menos habremos aprendido mucho por el camino.

¿Qué opciones tengo si quiero aprender programación funcional?

Si queremos aprender programación funcional, a día de hoy tenemos muchísimas opciones. Para todos los gustos y para todos los sabores. Vamos algunos de ellos:

Haskell

Haskell es uno de esos lenguajes funcionales conocidos como puros. Esto quiere decir que no permite mutar los datos y que las operaciones se tratan como la evaluación de funciones matemáticas.

Haskell está basado en el cálculo lambda (de ahí su logo) y debe su nombre a Haskell Brooks Curry, matemático estadounidense, que curiosamente da nombre a otro lenguaje de programación (Curry) y al concepto de currificación.

Si queréis probar Haskell, lo podéis hacer desde el mismo navegador.

Nuestro compañero Jose Juan, ya nos habló de Haskell por aquí.

Erlang/Elixir

La comunidad de Erlang está viviendo un resurgir, gracias a Elixir y es por ello que debemos tenerlo en cuenta. Erlang fue un lenguaje creado inicialmente para la gestión de centralitas telefónicas de Ericsson allá por 1986. Con esta premisa acabó siendo un lenguaje funcional, pensado para aplicaciones distribuidas y tolerantes a fallos. Erlang al igual que Elixir es un lenguaje de tipado dinámico.

Con el resurgir de la programación funcional, José Valim creó Elixir. Un lenguaje con una sintaxis basada en Ruby, que se ejecuta sobre la máquina virtual de Erlang y es totalmente compatible con él (de hecho se pueden utilizar librerías de Erlang en Elixir). De esta manera, Elixir puede aprovechar las características concurrentes de Erlang, con una sintaxis más cercana para muchos programadores. De hecho muchos programadores de Ruby están empezando a adoptar Elixir, dado su rendimiento. La llegada de programadores a Elixir, está haciendo que llegue savia nueva a Erlang, reforzando ambas comunidades.

Si queréis más información, en GenbetaDev, también hemos hablado de Elixir.

Scala

La máquina virtual de Java es una de las más avanzadas, y esto está haciendo que se generen muchos lenguajes nuevos en torno a ella. Scala es probablemente uno de los más famosos. Aunque Scala soporta todas las características típicas de la POO de Java, también posee muchas características funcionales como: funciones anónimas, funciones de orden superior, lazy evaluation, currificación, pattern matching, tuplas etc.

Obviamente Scala no se puede definir como lenguaje funcional puro (es más bien multiparadigma), pero aun siendo lenguaje orientado a objetos, se aleja de la programación imperativa.

El código de Scala es compatible con los programas ya existentes en Java, lo cual siempre es un plus.

Antonio Leiva ya entrevistó a los chicos de 47 Degrees, que nos contaron su experiencia con Scala.

Clojure

Otro lenguaje funcional que corre sobre la máquina virtual de Java es Clojure. Clojure es un dialecto de Lisp, por lo que parte de la idea de representar de igual forma código y datos. El tipado de Clojure, al igual que el de otros lenguajes funcionales como Elixir es dinámico. Y también como en otros lenguajes funcionales Clojure promueve la inmutabilidad de los datos. Clojure hace uso del concepto de identidad, que es algo así como una entidad lógica asociada a distintos valores a lo largo del tiempo.

Si queremos probar este lenguaje podemos hacerlo directamente desde el navegador

Si queremos sustituir nuestro JavaScript por un lenguaje funcional, podemos usar ClojureScript, que permite crear código de Clojure que se compila a JavaScript y es compatible con los navegadores web.

F#

F# es el lenguaje funcional de Microsoft, compatible con el stack de .NET. Por defecto los datos son inmutables, aunque podemos especificar que puedan mutar su estado. La sintaxis de F# se basa en la de OCaml, aunque con diferencias. Una de las curiosidades de F# es que es un lenguaje estático, en el que no hay que definir tipos, ya que estos son casi siempre inferidos por el compilador.

F# es multiparadigma, por lo que tiene toques de programación imperativa, como bucles while y for y también soporta programación orientada a objetos.

Este lenguaje se puede utilizar para una gran variedad de funciones, desde generar JavaScript (con Fable, hacer aplicaciones web, o aplicaciones para móviles con Xamarin.

Si queréis probar F# podéis hacerlo desde un navegador

Vale, hay muchos lenguajes funcionales, pero ¿por qué debo usarlos?

Aunque es cierto que los programadores vivimos muchas veces de las modas, también es cierto que una mala herramienta rara vez llega a ser popular. Así que si la programación funcional está recibiendo más atención será por algo. Estas son algunas de las supuestas ventajas que podemos obtener:

El código tiende a ser más conciso y expresivo
Que el estado sea inmutable, evita muchos errores ya que no hay efectos secundarios
Que el estado sea inmutable, nos ayuda en sistemas concurrentes o paralelos
Las funciones reciben parámetros y devuelven un resultado, por lo que son siempre previsibles (si son funciones puras).
El testing tiende a ser más sencillo, ya que si escribimos funciones puras, los resultados son más previsibles.

De todas maneras, aunque esas ventajas no sean suficientes, aunque en nuestro día a día usemos otro tipo de lenguajes, es muy recomendable aprender otros paradigmas de programación. Nos abre la mente a ideas nuevas, y eso nos hace mejore programadores. Y es que a veces, enriquece mucho más aprender un lenguaje nuevo, que aprender más cosas del lenguaje que usamos todos los días.

En Genbeta Dev | Aterrizando en la programación funcional

También te recomendamos

Métodos de extensión en C#

Pliegues, una forma de encapsular las iteraciones en listas

WaterWall™: cómo es la tecnología que limpia los platos de forma vertical

–
La noticia

El resurgir de la programación funcional

fue publicada originalmente en

Genbeta Dev

por
rubenfa

.

0

Si quieres ganar más dinero ¿tienes que cambiarte de trabajo?

By admin on

29 junio, 2017

- NOTICIA

En una ocasión, escuché—si a un empleado le pagas el doble de lo que vale, querrá permanecer en tu empresa durante mucho tiempo—. En ese momento, me di cuenta que nadie te regala nada a cambio de nada; que no siempre se paga a un profesional por el valor que aporta y mucho peor; por qué todos en algún momento de nuestra vida, nos habíamos encontrado con el típico incompetente que gana más que nosotros y no se marcha de la empresa ni con agua caliente.

Seguramente, a lo largo de tu experiencia profesional, has vivido o te has contado, ciertas situaciones que te han descolocado y te han hecho pensar que, tal vez, pudieras estar haciendo algo mal porque no tienes el salario que mereces:

Un conocido te cuenta lo bien que pagan en su empresa
Otro, que a pesar de lo mal que pagan en la suya, le hicieron una increíble oferta económica
Te ha llama un recruiter, ofreciendo mejores condiciones profesionales que las tienes actualmente
E incluso, te aconsejan que si quieres ganar más dinero, digas en tu empresa que te marchas para provocar una contraoferta.

Es probable que la mayoría de nosotros, hayamos pasado por cada uno de esos escenarios y tal vez, no hemos sabido gestionarlo de la mejor manera posible. Por eso, si te estás preguntando qué puedes hacer para mejorar económicamente, recuerda que tanto si te cambias de trabajo como si recibes una contraoferta en tu empresa, tiene una responsabilidad y por supuesto, un riesgo que debes estar dispuesto a asumir.

1. Si el salario es la única razón que te desmotiva, solicita un aumento en tu empresa

Si el salario es la razón por la que no estás satisfecho, busca un aumento antes de valorar un cambio de empleo.

Partiendo de la base que todos trabajamos a cambio de dinero, hay momentos vitales, donde el salario es prioritario. Cada uno, tenemos nuestras circunstancias, y nadie es mejor ni peor persona (ni mucho menos profesional) por ganar más o menos dinero. Por tanto, querer tener un mejor salario a final del mes, es absolutamente lícito, pero no siempre es lo más importante.

Evalúa si lo que le falta (o le sobra) a tu puesto actual, se puede solucionar con dinero. Si el salario es la única razón por la que no estás satisfecho en tu trabajo, quizás deberías buscar un aumento antes de valorar un cambio de empleo.

Si la mejora salarial que te gustaría, no es viable en tu empresa y para ti, es imprescindible tener un mayor salario para sentirte motivado. Sí es recomendable que valores un cambio de trabajo.

2. Aprende a gestionar ofertas y contraofertas

Como comentaba en el punto anterior, antes de valorar un cambio de trabajo, es aconsejable hablar primero con tu empresa para ver si pueden ofrecerte lo que necesitas. Si no es así, entonces es el momento de empezar a ver otras opciones profesionales.

La mayoría de nosotros, nos hemos sentido valorados cuando no han hecho una contraoferta. Tendemos a pensar que uno no sabe lo que tiene hasta que lo pierde y en el fondo de nuestro corazón, somos unos románticos, pero para qué engañarnos más, toda esta historia es mucho más fría de lo que pensamos.

Voy a comentar distintos escenarios que pueden darse a la hora de aceptar (o no) contraofertas. Lo más importante es identificarlos y aprender a gestionarlos:

La empresa va a hacer todo lo posible porque te quedes

Los ultimátums nos hacen reaccionar a todos

Cuando tu empresa no se espera que te quieras marchar y le pilla de sorpresa, como norma general, harán todo lo posible para que te quedes. De hecho, es bastante probable que jamás de los jamases te hayas sentido más valorado que en ese momento.

Me encantaría decirte que siempre que una empresa hace una contraoferta, el único motivo que les empuja a hacerlo es tu profesionalidad, lo que te valoran y lo indispensable que eres, pero no siempre es así. A veces, hay otro motivo: buscar y contratar a tu sustituto, es más costoso.

El mundo del software, es un sector con un bajo índice de desempleo, encontrar un sustituto no es fácil y si además, aportas un valor diferencial, harán todo lo imposible para que no te marches. Los ultimátums nos hacen reaccionar a todos, por eso, es probable que te hagan promesas, solo escuches lo que quieres oír y tal vez, veas pasar el tiempo sin que se cumplan tus expectativas.

Verdad o mentira, es una realidad que ocurre con bastante frecuencia. Si llega ese momento, analiza si quedarte en tu empresa te puede suponer un paso atrás.

Si tomas la decisión de cambiar de trabajo, mira hacia delante

Una de las mayores ventajas que tenéis los desarrolladores de software es que no os faltará trabajo. A día de hoy, tenéis mucha oferta y por tanto, tenéis poder de elección. Eso sí, un gran poder conlleva una gran responsabilidad.

Si has tomado la decisión de cambiar de trabajo, significa que has invertido tiempo, ilusión e incluso has organizado tu vida buscando nuevas ofertas de empleo, investigando y conociendo a las empresas, haciendo entrevistas, pensando, analizando y valorando una nueva vida profesional con nuevos retos, aprendizajes, jefes, cultura, compañeros, horarios, tecnologías, proyectos, etc..

No es una tontería, te lo has tomado muy en serio y por eso, es importante que lo tengas en el mente y lo recuerdes cuando tu empresa te haga una contraoferta.

El sentimiento de miedo y tener dudas, es inherente en un proceso de cambio

Hasta que no veas materializada la oferta, no serás consciente que ese cambio de trabajo es una realidad

De hecho, es bastante probable que hasta que no veas materializada la oferta, no seas consciente que ese cambio de trabajo es una realidad. Además, si hablas con tu jefe para comunicarle tu baja e intenta convencerte para que no te vayas, sentirás inseguridad e incluso, tal vez, tengas una extraña sensación de culpabilidad. Esta situación es de libro de contraofertas, así que te aconsejo frialdad para que nadie decida por ti.

Todos tenemos miedo al cambio, la diferencia entre unos y otros, es cómo lo afrontamos.

Si son otros factores los que te desmotivan, el dinero no será la solución

Si realmente no estás a gusto en tu empresa, aceptar una contraoferta económica, no solucionará tu problema

Antes de aceptar una contraoferta, piensa si lo que te ofrece tu empresa, va a solucionar lo que ha hecho que quieras irte a otro sitio.

Cuando realmente no estás a gusto en tu empresa, porque lo que te afecta son otros factores que no son salariales, aceptar una contraoferta económica, no solucionará tu problema. De hecho, seguirás teniendo los mismos problemas en tu día a día, habrás perdido una buena oportunidad y es posible que tu profesionalidad, pueda verse afectada.

Si estás desmotivado, agotado e incluso quemado, tu permanencia en la empresa, no es sostenible a golpe de talonario.

Si decides cambiar de trabajo, el cambio tiene que ser a mejor

Antes de cambiar de trabajo, analiza si tu nuevo trabajo, cumple tus expectativas. Es cierto que es un riesgo, y hasta que no te incorpores en tu nueva empresa, no sabrás si el cambio es a mejor o a peor. Pero si sabes lo que quieres, has hecho un buen proceso de selección y por supuesto, has pedido referencias, tendrás información para decidir, si es el momento y la empresa para comenzar una nueva aventura profesional.

Intenta tomar una decisión objetiva, no te cambies de trabajo por impulso, pero tampoco te queden tu empresa por resignación. Si decides cambiar de trabajo, haz un análisis de pros y contras y si el resultado es positivo, adelante. Por si puede ayudarte, suelo realizar con los desarrolladores, un ejercicio muy sencillo: la comparación entre la situación profesional actual y la deseada.

Situación Actual:

Lo que te gusta	Lo que no te gusta

Situación Deseada:

Lo que te gustaría	Lo que no te gustaría

Haz una comparativa de lo que más y menos te gusta de tu situación actual, además de lo que te gustaría y no te gustaría tener en su nuevo trabajo, te ayudará a tomar decisiones.

Si vas a aceptar una contraoferta, negocia muy bien las nuevas condiciones

Si aceptas una contraoferta, negocia muy bien las nuevas condiciones y cuida la forma en la que se puede interpretar por tus compañeros

Si eres de los que has utilizado esta estrategia para que tu empresa te ofrezca mejor salario o “simplemente” cambiaste de opinión en el último momento, es aconsejable que negocies muy bien las nuevas condiciones profesionales. Si no lo haces, no solo tendrás el mismo problema a corto plazo sino que además, habrás hecho visible tus intenciones, te habrás expuesto y tanto tu permanencia en la empresa como tu lealtad, se pondrán en duda.

Si aceptas una contraoferta, negocia muy bien las nuevas condiciones y gestiona de la mejor manera posible que tus jefes y tus compañeros, no te perciban de forma distinta. Es decir, deja claro que eres un profesional firme en tu decisión y cuida que no desconfíen de ti.

La contraoferta de la contraoferta es el peor de los escenarios

Recuerda dejar siempre la puerta abierta

Ya hemos visto que se pueden dar distintos escenarios a la hora de aceptar o no una contraoferta, pero hay uno que desde mi punto de vista, no lo recomiendo: el juego a dos bandas e incluso a tres.

Recomiendo ser honestos y no utilizar a los demás. Si queréis mejorar vuestra situación actual, el fin no justifica los medios, se pueden hacer las cosas bien. Lo mejor es dejar una puerta abierta ya sea con el recruiter, la empresa interesada en contratarte o en tu propia empresa, pero como juegues mal tus cartas, perderás la confianza de todos y de cada uno.

Si lo haces, recuerda que todo acto tiene una repercusión. Valora hasta qué punto te compensa.

Conclusión

Cambiar de trabajo es una decisión importante que impactará no solo en tu vida profesional sino también en tu vida personal. Intenta tener mayor control en la toma de decisiones,sin olvidar que tendrás que asumir riesgos.

Si te cambias de empresa, puedes ganar más dinero, puedes equivocarte …pero también, si te quedas. No dejes que los demás decidan por ti. La decisión es tuya.

Foto | Flickr

También te recomendamos

Metáforas sobre el desarrollo de software

La industria que más puestos demanda es la informática

WaterWall™: cómo es la tecnología que limpia los platos de forma vertical

–
La noticia

Si quieres ganar más dinero ¿tienes que cambiarte de trabajo?

fue publicada originalmente en

Genbeta Dev

por
Emma Salamanca

.

0

NOTICIA

Kotlin es oficial en Android ¿Qué implicaciones tiene para los desarrolladores?

By admin on

25 junio, 2017

- NOTICIA

Como es posible que ya sepas, el pasado 17 de mayo, durante la keynote del Google I/O 2017, Google anunció que Kotlin sería soportado oficialmente como lenguaje para desarrollar aplicaciones Android.

Ya hemos hablado varias veces de Kotlin en Genbeta Dev, y seguramente sabrás que era perfectamente posible desarrollar Apps Android utilizando Kotlin desde hace ya bastante tiempo.

La única novedad que se anunció al respecto es que Android Studio 3.0 ya traería integrado Kotlin, en lugar de necesitar instalar un plugin para ello.

Aparentemente las novedades son pocas. Parece que nada ha cambiado, ¿o sí?

Soporte oficial para Kotlin: ahora ya tienes las espaldas cubiertas

Hasta este momento era un poco complicado justificar ante el responsable técnico de cualquier empresa la inclusión de un lenguaje no oficial.

Los riesgos con Kotlin eran mínimos, como ya han demostrado algunas empresas como Basecamp o Pinterest. Pero el miedo a lo desconocido es muy razonable, y había muchos equipos que se estaban resistiendo al cambio por esta razón.

Android Studio 3.0 incluirá soporte para Kotlin de serie

La realidad era que si algo no funcionaba como debería, Google se podía lavar las manos perfectamente. Es cierto que Jetbrains y el equipo de Kotlin siempre han sido muy rápidos para solucionar cualquier problema que ha surgido, pero la duda siempre estaba ahí.

Esto ya no es así. Un ejemplo muy claro se puede ver en movimientos como este. Al parecer Room, una librería de persistencia que también presentó Google en el I/O, estaba teniendo algún problema con el plugin de generación de código de Kotlin (KAPT).

En el pasado, esto habría supuesto confiar en la gente de Kotlin para que se solucionase. Ahora el propio personal de Google está implicado y hacen evolucionar las herramientas con ello:

Google ahora está involucrado en la evolución de Kotlin, y gracias a ello, los desarrolladores tenemos las espaldas cubiertas

Kotlin ha venido para quedarse

Otra de las dudas que surgían al respecto es que al fin y al cabo Kotlin ha sido creado por Jetbrains, quienes en un momento dado podrían llegar a olvidarse del lenguaje porque no les fuera rentable.

Siempre ha sido un lenguaje open-source, pero es evidente que no es lo mismo que una empresa tenga a 40 personas trabajando a tiempo completo a que lo tenga que mantener la comunidad.

Este problema desaparece de un plumazo también. Jetbrains y Google van a crear una fundación sin ánimo de lucro para preservar que el lenguaje siga siendo abierto y que no haya problemas de este tipo en un futuro.

Las empresas van a empezar a demandarlo aún con más fuerza

Ya había algunas ofertas de trabajo que valoraban conocimientos sobre Kotlin. Pero este lenguaje aplicado al desarrollo de Android era un futuro incierto.

En junio, Kotlin es el lenguaje #39 en Github, #60 en StackOverflow y #43 en TIOBE index

Ahora es el presente, y las compañías están como locas por buscar a personas con experiencia en este lenguaje, y por formar a sus propios empleados.

Claro lo dejan los saltos que está dando el lenguaje en tan poco tiempo en lugares como Github o StackOverflow según The RedMonk, o que haya entrado en el top 50 de los lenguajes más usados según el TIOBE index.

Así que si eres desarrollador Android, piensa en no quedarte atrás mucho tiempo. El mercado de Kotlin está explotando, y es vital moverse hacia el futuro.

¿Google abandonará Java en el futuro? Es posible

Durante el I/O, Google afirmó que seguirá evolucionando el soporte a Java, y que se podrán seguir usando ambos lenguajes para el desarrollo Android. Eso es lo que dijeron de Eclipse como entorno de desarrollo, y con el tiempo esto no fue así.

Y también es cierto que Google ha tenido bastantes problemas legales con Oracle debido a Java.

Kotlin le ha venido como anillo al dedo a Google:

Un lenguaje en el que se cubren las espaldas frente a posibles problemas legales
No tienen los problemas de verse obligados a anclarse a versiones antiguas del lenguaje
Trae al desarrollo Android todas las ventajas de un lenguaje moderno
Y además ya está maduro y se ha demostrado su validez en proyectos reales y de gran envergadura.

Imagina todo lo que supone crear un lenguaje desde cero (se podría equiparar al ejemplo de Apple con Swift). A Google le han dado el trabajo hecho.

Nada de esto quiere decir que Java vaya a dejar de ser soportado, ya que su dependencia con el lenguaje es muy grande. Para empezar todo el framework y librerías de Android están implementadas en Java.

Con esta adopción, Google ha conseguido con Kotlin lo que a Apple le está llevando años de trabajo con Swift

Pero es algo que puede llegar a ocurrir, y nunca está de más calcular las consecuencias.

Empieza desde hoy con Kotlin

Kotlin es ya una realidad en el mundo Android, así que te animo a que empieces a aprender Kotlin desde hoy. Si aún eres un poco reticente al cambio, cuando lo pruebes te darás cuenta de todas las ventajas que aporta. Y pronto no querrás volver a mirar atrás.

Si no sabes por dónde empezar, en la web de desarrolladores de Android tienes una pequeña guía por la que empezar, así como una sección de recursos, donde encontrarás recursos, vídeos y libros para empezar con ello.

En Genbeta Dev | Kotlin 1.1 también es para desarrolladores Android
En Xataka | Kotlin ya es un lenguaje oficial en Android
Libro | Kotlin for Android Developers

También te recomendamos

Kotlin llega a Gradle: Escribe tus scripts de Gradle usando Kotlin script

Kotlin: La Máquina Virtual de Java tiene un nuevo aliado

WaterWall™: cómo es la tecnología que limpia los platos de forma vertical

–
La noticia

Kotlin es oficial en Android ¿Qué implicaciones tiene para los desarrolladores?

fue publicada originalmente en

Genbeta Dev

por
Antonio Leiva

.

0

NOTICIA

By admin on

25 junio, 2017

- NOTICIA

Como es posible que ya sepas, el pasado 17 de mayo, durante la keynote del Google I/O 2017, Google anunció que Kotlin sería soportado oficialmente como lenguaje para desarrollar aplicaciones Android.

Ya hemos hablado varias veces de Kotlin en Genbeta Dev, y seguramente sabrás que era perfectamente posible desarrollar Apps Android utilizando Kotlin desde hace ya bastante tiempo.

La única novedad que se anunció al respecto es que Android Studio 3.0 ya traería integrado Kotlin, en lugar de necesitar instalar un plugin para ello.

Aparentemente las novedades son pocas. Parece que nada ha cambiado, ¿o sí?

Soporte oficial para Kotlin: ahora ya tienes las espaldas cubiertas

Hasta este momento era un poco complicado justificar ante el responsable técnico de cualquier empresa la inclusión de un lenguaje no oficial.

Los riesgos con Kotlin eran mínimos, como ya han demostrado algunas empresas como Basecamp o Pinterest. Pero el miedo a lo desconocido es muy razonable, y había muchos equipos que se estaban resistiendo al cambio por esta razón.

Android Studio 3.0 incluirá soporte para Kotlin de serie

La realidad era que si algo no funcionaba como debería, Google se podía lavar las manos perfectamente. Es cierto que Jetbrains y el equipo de Kotlin siempre han sido muy rápidos para solucionar cualquier problema que ha surgido, pero la duda siempre estaba ahí.

Esto ya no es así. Un ejemplo muy claro se puede ver en movimientos como este. Al parecer Room, una librería de persistencia que también presentó Google en el I/O, estaba teniendo algún problema con el plugin de generación de código de Kotlin (KAPT).

En el pasado, esto habría supuesto confiar en la gente de Kotlin para que se solucionase. Ahora el propio personal de Google está implicado y hacen evolucionar las herramientas con ello:

Google ahora está involucrado en la evolución de Kotlin, y gracias a ello, los desarrolladores tenemos las espaldas cubiertas

Kotlin ha venido para quedarse

Otra de las dudas que surgían al respecto es que al fin y al cabo Kotlin ha sido creado por Jetbrains, quienes en un momento dado podrían llegar a olvidarse del lenguaje porque no les fuera rentable.

Siempre ha sido un lenguaje open-source, pero es evidente que no es lo mismo que una empresa tenga a 40 personas trabajando a tiempo completo a que lo tenga que mantener la comunidad.

Este problema desaparece de un plumazo también. Jetbrains y Google van a crear una fundación sin ánimo de lucro para preservar que el lenguaje siga siendo abierto y que no haya problemas de este tipo en un futuro.

Las empresas van a empezar a demandarlo aún con más fuerza

Ya había algunas ofertas de trabajo que valoraban conocimientos sobre Kotlin. Pero este lenguaje aplicado al desarrollo de Android era un futuro incierto.

En junio, Kotlin es el lenguaje #39 en Github, #60 en StackOverflow y #43 en TIOBE index

Ahora es el presente, y las compañías están como locas por buscar a personas con experiencia en este lenguaje, y por formar a sus propios empleados.

Claro lo dejan los saltos que está dando el lenguaje en tan poco tiempo en lugares como Github o StackOverflow según The RedMonk, o que haya entrado en el top 50 de los lenguajes más usados según el TIOBE index.

Así que si eres desarrollador Android, piensa en no quedarte atrás mucho tiempo. El mercado de Kotlin está explotando, y es vital moverse hacia el futuro.

¿Google abandonará Java en el futuro? Es posible

Durante el I/O, Google afirmó que seguirá evolucionando el soporte a Java, y que se podrán seguir usando ambos lenguajes para el desarrollo Android. Eso es lo que dijeron de Eclipse como entorno de desarrollo, y con el tiempo esto no fue así.

Y también es cierto que Google ha tenido bastantes problemas legales con Oracle debido a Java.

Kotlin le ha venido como anillo al dedo a Google:

Un lenguaje en el que se cubren las espaldas frente a posibles problemas legales
No tienen los problemas de verse obligados a anclarse a versiones antiguas del lenguaje
Trae al desarrollo Android todas las ventajas de un lenguaje moderno
Y además ya está maduro y se ha demostrado su validez en proyectos reales y de gran envergadura.

Imagina todo lo que supone crear un lenguaje desde cero (se podría equiparar al ejemplo de Apple con Swift). A Google le han dado el trabajo hecho.

Nada de esto quiere decir que Java vaya a dejar de ser soportado, ya que su dependencia con el lenguaje es muy grande. Para empezar todo el framework y librerías de Android están implementadas en Java.

Con esta adopción, Google ha conseguido con Kotlin lo que a Apple le está llevando años de trabajo con Swift

Pero es algo que puede llegar a ocurrir, y nunca está de más calcular las consecuencias.

Empieza desde hoy con Kotlin

Kotlin es ya una realidad en el mundo Android, así que te animo a que empieces a aprender Kotlin desde hoy. Si aún eres un poco reticente al cambio, cuando lo pruebes te darás cuenta de todas las ventajas que aporta. Y pronto no querrás volver a mirar atrás.

Si no sabes por dónde empezar, en la web de desarrolladores de Android tienes una pequeña guía por la que empezar, así como una sección de recursos, donde encontrarás recursos, vídeos y libros para empezar con ello.

En Genbeta Dev | Kotlin 1.1 también es para desarrolladores Android
En Xataka | Kotlin ya es un lenguaje oficial en Android
Libro | Kotlin for Android Developers

También te recomendamos

Kotlin llega a Gradle: Escribe tus scripts de Gradle usando Kotlin script

El síndrome de Frankenstein y el coche autónomo: ¿por qué nos da más miedo que conduzcan solos los coches que los aviones?

Kotlin: La Máquina Virtual de Java tiene un nuevo aliado

–
La noticia

Kotlin es oficial en Android ¿Qué implicaciones tiene para los desarrolladores?

fue publicada originalmente en

Genbeta Dev

por
Antonio Leiva

.

0

NOTICIA

¿Qué red social es mejor para nuestra empresa o negocio?

By admin on

5 febrero, 2017

- NOTICIA

Saber qué red social es más conveniente para mi negocio es casi como la previsión del tiempo. Aunque tengamos todos los datos e información a la mano, hay muchos factores que pueden afectar nuestras predicciones, convirtiéndolas en unos resultados nada deseables.

¿A qué se debe esto? Muy simple, a que estamos tratando con personas y tendencias. Los seres humanos siguen modas y tendencias, las cuales cambian, a veces demasiado rápido como para permitirnos estar a la última. No sólo tenemos que subir contenido de calidad, experiencias, noticias, tutoriales… sino que también tenemos que tener en cuenta las mejores horas para subirlo, la manera de subirlo, dónde subirlo, y ahora también las tendencias para no quedarnos atrás.

Para ir a lo seguro, vamos a repasar aquellas cosas básicas que no nos afecten negativamente. También veremos cómo elegir las plataformas adecuadas a nuestro negocio, ya que no hay nada peor que una red social que no se use. Da la misma mala imagen que una web que no actualiza su contenido y aún nos están felicitando las navidades del año 2007, que las hay.

No hay nada que dé peor imagen, que una red social vinculada a nuestra empresa que no se use.

Hay miles de redes sociales, y la mayoría están muy focalizadas y responden a las necesidades de nichos de mercado muy específicos. Otras son simplemente inútiles. En este artículo vamos a considerar 6 de las principales plataformas, veremos lo que ofrecen, e intentaré ayudar en la decisión de elegir si su empresa debería tener presencia en las mismas.

PINTEREST

Pinterest es la red social “visual” por excelencia. Se trata de mostrar información, datos, contenido, estadísticas a través de imágenes, siendo la plataforma líder para este tipo de contenido. Supongo que se basan en la idea de que “una imagen vale más que 1000 palabras”.

Sus usuarios son, en un 68% mujeres, teniendo en la actualidad más de 70 millones de personas registradas y en activo. Si su negocio está muy relacionado con la decoración, moda, bodas, bebés, bricolaje, cocina, fotografía, reportajes… es indispensable su presencia en esta red social, y más teniendo en cuenta que cada vez tiene más adeptos.

Para la gente que se dedica a las redes sociales, profesionalmente hablando, o para aquellas personas que han decidido gestionar su propio marketing digital (marketing online), también es muy conveniente su presencia, ya que se pueden obtener estadísticas muy interesantes del uso o tendencias de las principales plataformas sociales.

TWITTER

A diferencia de Facebook y otras redes sociales, donde la gente puede ver nuestro perfil o “página Facebook” y responder más tarde, Twitter se basa más en la idea de “en este momento” o en “de lo que se está hablando ahora mismo”. Parte de la culpa de esto la tienen los 6.000 tuits (o tweets) que se publican cada segundo.

Con 560 millones de usuarios activos, Twitter no puede ser ignorado y su empresa podría beneficiarse enormemente de su presencia en esta plataforma “micro-blogging”, especialmente si tiene pensado dirigir su empresa hacia el mercado estadounidense. Bajo mi opinión, es una red básica que toda empresa debe tener, y según las personas que sigamos, podemos estar bastante bien informados de las tendencias del sector al que se orienta nuestros negocios.

FACEBOOK

Facebook es de las más potentes plataformas sociales que podemos encontrarnos en el mundo. Sólo por el número de personas que la utilizan, ya es interesante. Cuenta con más de 1.110 millones de usuarios activos en la actualidad, y con 2.500 millones de mensajes subidos (y material compartido), al día. Es impresionante ver la infraestructura que tienen montada para mantener viva toda esta masa de información. No podéis dejar de ver el siguiente vídeo:

Facebook no sólo está orientada al usuario final, sino también a las empresas, permitiendo crear su propia página Facebook, exponiendo aquello que venden, dónde se encuentran, información de contacto, etc. También permiten crear promociones de ciertos productos concretos, para obtener la mayor difusión posible. De algo tenían que comer, no?

Es más, hay empresas que han decidido no crear una web a la vieja usanza, y han redirigido su .com .es .net .org…….. a la página de Facebook, y usar la misma como escaparate digital de la empresa.

En mi opinión, es otra red en la que cualquier negocio debe tener presencia para darse a conocer.

INSTAGRAM

Instagram es la mejor plataforma social para llegar a los adolescentes y en general a todas las personas que aman una buena fotografía. Cualquier persona, con esta aplicación, y cierta visión fotográfica (cierto arte echando fotos), puede crear espectaculares instantáneas con un simple dispositivo tipo smartphone o tablets, darle efectos casi profesionales en cuestión de segundos y compartir el resultado final con quién le interese.

Instagram es el rey de las fotografías, al igual que Pinterest lo es con las imágenes y composiciones, y ahora también acepta vídeos cortos!!!. Tiene 150 millones de usuarios activos, y al igual que Pinterest, está más que recomendada para aquellas empresas o negocios que trabajen con fotografías para publicitar su actividad principal.

Si nuestro negocio está orientado a un público adolescente, es fundamental tener presencia en esta red social, al igual que en el Facebook español, Tuenti.

Instagram es el rey de las fotografías, al igual que Pinterest lo es con las imágenes y composiciones.

GOOGLE+

Como bien indica su nombre, es la red social de Google, y sólo por esto, y lo que puede suponer directa o indirectamente, puede ser interesante tener presencia en ella, e intentar mejorar el posicionamiento de nuestra web en el buscador de Google.

Al igual que Facebook, tiene perfiles de usuarios, y se pueden crear páginas para los negocios. Todo el material que se ponga en Google+ ayudará a nuestro negocio a obtener mayor visibilidad en el buscador de Google, que como bien sabemos, es el buscador número 1.

Aunque en la actualidad tiene 400 millones de usuarios, cifra nada despreciable, es la que más rápido está creciendo en este momento (925.000 usuarios nuevos cada día), con lo que, es indispensable empezar a tener presencia en esta plataforma, para ir cogiendo hueco y antigüedad respecto a la posible competencia. Es preferible mantener otra red social más, Google+, que el día de mañana arrepentirnos de no haber tomado esta decisión. Algún día, si no lo hace ya, el algoritmo de posicionamiento de Google puntuará mucho mejor la actividad de una empresa en Google+ que en cualquier otra red social.

LINKEDIN

LinkedIn es la red por excelencia de los negocios y profesionales. Es indispensable para cualquier negocio tener presencia en esta plataforma, si se quiere ser “alguien” en los medios sociales. No suele dar buena imagen tener otras redes sociales menos profesionales que esta, y no tener cuenta de empresa en LinkedIn.

Si quiere aumentar las conexiones comerciales de su empresa (incluso con otros países), si quiere participar en ciertos grupos de debate sobre temas específicos, si tiene dudas profesionales, ya sea de su sector o de otro, si quiere conocer gente con un perfil determinado, buscar un empleado o socio nuevo, con características muy definidas… LinkedIn es su red social!!!

El público habitual en esta red supera los 35 años de edad, aunque cada vez es más creciente la presencia de público entre 25 y 35 años, debido a que LinkedIn es también un buen medio para darse a conocer profesionalmente a muchas empresas, sobre todo como Freelance (trabajador autónomo).

Al final del artículo os dejo una imagen resumen de toda esta información, obtenida de aquí, en la que se puede ver de un vistazo todo lo comentado. Si os ha gustado el artículo, agradecería que lo compartieseis en vuestras redes sociales. Muchas Gracias!!!

0

NOTICIA, Sin categoría

ieCatastro App para facilitar los Informes de Evaluación

By admin on

24 marzo, 2014

- NOTICIA, Sin categoría

El pasado 17 de Marzo se presentó en el Colegio Oficial de Aparejadores, Arquitectos Técnicos e Ingenieros de Edificación (COAATIEMU), la nueva aplicación móvil fruto de la colaboración entre Byprox Development y el propio Colegio.

Dicha App, bautizada con el nombre de ieCatastro, estará disponible en el mes de Abril, tanto para Android como para iOS (en sus versiones smartphone y tablet), pudiendo ser descargadas de los diferentes Markets (Google Play y App Store respectivamente).

La idea base de este proyecto es facilitar a sus usuarios el poder identificar, rápida y visualmente, las construcciones que buscan, según ciertos criterios. Los usuarios podrán localizar, por ejemplo, qué unidades constructivas (cerca de su ubicación o mediante búsquedas) deben pasar el Informe de Evaluación. También se mostrará la propia información pública suministrada por la Sede Electrónica del Catastro, de una manera más práctica y funcional para el usuario, permitiendo guardarla, añadirle anotaciones, compartirla y geolocalizarla.

Indicar el gran esfuerzo del propio Colegio por ceder parte de sus recursos, humanos y técnicos, para que este proyecto esté siendo una realidad, a la vez que práctico para cualquier profesional del sector.

En breve también estará la Web (www.iecatastro.com y www.iecatastro.es), donde se verán las evoluciones de la plataforma, así como poder opinar sobre las diferentes funcionalidades, incluso se podrán indicar ciertas modificaciones que podrían ser de utilidad para todos.

Esperamos que os guste!!

0

Good Contents Are Everywhere, But Here, We Deliver The Best of The Best.Please Hold on!

NOTICIA

Las herramientas del programador ¿Y tú cuál usas?

IDE

Editor de texto

¿Cuál elegir?

Editores clásicos

IDEs

Los nuevos editores

Opciones para todos los gustos

También te recomendamos

NOTICIA

Continuous Delivery en profundidad: pipelines de Jenkins

Los pipelines son código

También te recomendamos

NOTICIA

Continuous Delivery en profundidad: pipelines

Los pipelines son código

También te recomendamos

Un primer vistazo a las co-rutinas de Kotlin en Android

Entendiendo como trabajan las co-rutinas

Usar Anko para las co-rutinas

Usando co-rutinas en un ejemplo

También te recomendamos

NOTICIA

El resurgir de la programación funcional

¿Por qué el resurgimiento de la programación funcional?

¿Pero esto es ruído o es una tendencia de verdad?

¿Qué opciones tengo si quiero aprender programación funcional?

Haskell

Erlang/Elixir

Scala

Clojure

F#

Vale, hay muchos lenguajes funcionales, pero ¿por qué debo usarlos?

También te recomendamos

Si quieres ganar más dinero ¿tienes que cambiarte de trabajo?

1. Si el salario es la única razón que te desmotiva, solicita un aumento en tu empresa

2. Aprende a gestionar ofertas y contraofertas

La empresa va a hacer todo lo posible porque te quedes

Si tomas la decisión de cambiar de trabajo, mira hacia delante

El sentimiento de miedo y tener dudas, es inherente en un proceso de cambio

Si son otros factores los que te desmotivan, el dinero no será la solución

Si decides cambiar de trabajo, el cambio tiene que ser a mejor

Si vas a aceptar una contraoferta, negocia muy bien las nuevas condiciones

La contraoferta de la contraoferta es el peor de los escenarios

Conclusión

También te recomendamos

NOTICIA

Kotlin es oficial en Android ¿Qué implicaciones tiene para los desarrolladores?

Soporte oficial para Kotlin: ahora ya tienes las espaldas cubiertas

Kotlin ha venido para quedarse

Las empresas van a empezar a demandarlo aún con más fuerza

¿Google abandonará Java en el futuro? Es posible

Empieza desde hoy con Kotlin

También te recomendamos

NOTICIA

Soporte oficial para Kotlin: ahora ya tienes las espaldas cubiertas

Kotlin ha venido para quedarse

Las empresas van a empezar a demandarlo aún con más fuerza

¿Google abandonará Java en el futuro? Es posible

Empieza desde hoy con Kotlin

También te recomendamos

NOTICIA

¿Qué red social es mejor para nuestra empresa o negocio?

PINTEREST

TWITTER

FACEBOOK

INSTAGRAM

GOOGLE+

LINKEDIN

NOTICIA, Sin categoría

ieCatastro App para facilitar los Informes de Evaluación