Conseguir un visado de trabajo para los Estados Unidos de Trump si eres desarrollador

28/04/2017
Artículo original

Melania

Las grandes empresas tecnológicas estadounidenses, las compañías totémicas de Silicon Valley (o de Seattle o de Austin o de Nueva York o de donde sea), son un caramelo muy goloso para cualquier desarrollador que se precie, provenga del lugar de donde provenga. Vamos, son el Barça o el Madrid de esta profesión nuestra, todos soñamos con jugar en esos campos de Mountain View o la 5ª Avenida.

Hasta ahora, conseguir un permiso de trabajo temporal para acceder a estos puestos era tedioso pero accesible (teniendo en cuenta que hay un importante grado de azar en el proceso, claro). ¿Ha cambiado esto con la llegada de la administración Trump y sus políticas proteccionistas? Si nuestro sueño es trabajar en los Estados Unidos, ¿lo tenemos ahora más complicado que hace tan sólo unos meses? Vamos a intentar arrojar algo de luz sobre este tema en las siguientes líneas.

Los distintos tipos de temporary visas

Visa

Vamos a empezar repasando los distintos tipos de permisos o visados con los que se puede acceder a los Estados Unidos siendo ciudadano español. Estos permisos, divididos en visados de inmigrante (la famosa green card) y visados de no inmigrante (las temporary visas), están expedidos por el Servicio de Ciudadanía e Inmigración, la USCIS.

  • B. Visitantes con propósitos de turismo, negocios o tratamientos médicos. Los españoles realmente no necesitamos este visado para estancias menores de 90 días, tan sólo rellenar adecuadamente el famoso formulario ESTA (Electronic System for Travel Authorization) y pagar la tasa. Sí, es ese formulario en el que te preguntan si tienes pensamiento de atentar contra el presidente y si no quieres que te pase como a los Medina Azahara, rellénalo con cuidado.
  • C. Tránsito a través de los Estados Unidos. Tripulación o pasaje de barcos o aviones que hagan escala en el país.
  • F / M. Estudiantes académicos, técnicos o de idiomas.
  • J. Visitantes de intercambio.
  • D. Tripulantes de barcos o aviones.
  • I. Periodistas y demás trabajadores de medios de comunicación (fotógrafos, columnistas, técnicos, colaboradores...).
  • E1 / E2. Comerciante o inversor por tratado.
  • H1-B. Profesionales especializados con estudios superiores o experiencia laboral equivalente. Este sería el visado al que deberíamos optar la mayoría de los desarrolladores. Luego hablaremos de ella en mayor profundidad.
  • H2-A. Trabajadores estacionales agrícolas.
  • H2-B. Trabajadores estacionales no agrícolas.
  • H3. Aprendices (salvo médicos y académicos).
  • L. Transferidos entre empresas filiales. Vamos, si estabas trabajando para alguna empresa estadounidense fuera de los Estados Unidos.
  • O. Personas con habilidades extraordinarias. Artistas, actores, científicos...
  • P. Deportistas de alto nivel reconocidos a nivel internacional.
  • Q. Visitantes de intercambio cultural internacional.
  • R. Trabajadores religiosos.

Pasos a seguir para conseguir una H1-B

H1b Visa

Como hemos visto en el listado anterior, el visado para trabajar en los Estados Unidos que más se ajusta a nuestra experiencia como desarrolladores es el H1-B para trabajadores especializados.

Este visado, instaurado en 1990 por la administración de Bush padre, también es al que aplican (perdón por el anglicismo) profesionales de otras ramas de la ingeniería, médicos, investigadores científicos o, en una de las excepciones a la necesidad de estudios superiores, las modelos profesionales. Sí, la Primera Dama Melania Trump entró en los Estados Unidos con una visa H1-B.

El H1-B tiene una validez de 60 meses (5 años, hablando en plata), no tiene limitación de entradas en el país ni tiene ninguna tasa extra para los ciudadanos españoles (aunque si hay que pagar los 190 dólares de tasa general del visado).

Pasos para conseguir este H1-B:

  • La empresa empleadora debe solicitar en tu nombre un certificado de trabajo al Departamento de Trabajo.
  • Una vez en poder del certificado, la empresa debe cumplimentar el formulario I-129 de la USCIS y que este sea aprobado por la misma.

Aquí es donde entra el factor suerte en el proceso: el gobierno norteamericano sólo concede 65.000 visados H1-B al año y las solicitudes aprobadas por la USCIS suelen ser mucho mayores: este 2017 han sido más de 199.000, en 2016 fueron más de 236.000 y en 2015 más de 233.000.

Es el momento de La Lotería. Un proceso aleatorio informatizado que este 2017 para los visados del año fiscal 2018 se celebró el 11 de abril después de muchos rumores sobre si este año se celebraría o la administración Trump apostaría por otros métodos... pero mejor no adelantemos acontecimientos.

  • Si has tenido suerte y te ha tocado La Lotería, ya puedes aplicar por la visa mediante la cumplimentación formulario DS-60.
  • El siguiente paso es solicitar una entrevista en la embajada de los Estados Unidos o en cualquiera de sus consulados en España. En la embajada de Madrid el tiempo de espera es de 4 días naturales.

Embajada Madrid

  • A la entrevista debes llevar: el pasaporte, la confirmación del DS-60, la confirmación del pago de las tasas, la confirmación del I-129 y una foto. Además de cualquier otra documentación que te sea requerida. En la entrevista te tomarán las huellas dactilares.
  • Después de la entrevista tu solicitud será procesada. El tiempo de espera para este proceso en la embajada madrileña es de 3 días.

Si después de estos tres días, la respuesta es afirmativa, puedes empezar a hacer el petate: tu aventura americana esta a punto de empezar.

¿Y ahora con Trump qué?

El visado H1-B es polémico en ciertos círculos prácticamente desde su implantación. Las razones que esgrimen sus detractores son básicamente dos:

1) Que, debido a la permisividad de las instituciones, las empresas lo solicitan para otro tipo de trabajos para los que hay mano de obra nacional más que de sobra como pueden ser entrenadores deportivos, trabajadores agrícolas, profesores de preescolar o las mencionadas modelos internacionales como Melania Trump.

2) Que, gracias a la poca experiencia que se necesita para conseguirlo, sirve para formar talento de economías emergentes como India o China que luego vuelve a sus países y ayudan a disminuir la ventaja competitiva estadounidense en los sectores de IT.

Por lo tanto, con la llegada de Donald Trump a la Casa Blanca y sus prometidas políticas proteccionistas (¡Compra americano! ¡Contrata americano!) había cierta expectativa por ver si iba a tocar este permiso H1-B, gracias al cual su esposa llegó legalmente al país, y en que manera.

Durante la interminable campaña electoral Trump había llegado a decir que había que suspender la concesión de estos permisos durante uno o dos años. También habló de cambiar el método de La Lotería por la confección de un ranking meritocrático (el trabajo para conseguir esto con la gran cantidad de solicitudes que hay se antoja brutal) o un ranking por salario en orden descendente (mucho más sencillo de implementar). Sin embargo, estando ya aposentado en el despacho oval, los rumores hablaban de que se podía ampliar el cupo de 65.000 hasta los 110.000 visados, algo que ya se especuló durante la segunda legislatura de Obama, como una medida para congraciarse con las belicosas grandes compañías de Silicon Valley, que tiran mucho de talento de allende los mares.

Positions H1b

De momento ni una cosa ni la otra: de las más 199.000 peticiones de visado se darán 65.000 para el año fiscal 2018 por medio de La Lotería celebrada a principios de este mes.

Sin embargo a finales de marzo saltaban las alarmas con respecto a los desarrolladores en diversos foros: circulaba un memorando gubernamental que parecía indicar que el trabajo de programador podía quedarse fuera de los trabajos cualificados con derecho a H1-B o por lo menos ser escrutado de manera mucho más estricta.

En declaraciones a Bloomberg, una portavoz de la Agencia de Inmigración, la USCIS, indicaba que "esto no es un cambio en la política de elegibilidad del H1-B in campos relacionados con la informática" si no tan sólo la actualización de unas guidelines que databan del año 2000 y que estaban obsoletas.

En 2016 más de 13.000 puestos de programador en empresas de tecnología fueron cubiertos por trabajadores con visado H1-B. Veremos a ver como evoluciona esto en los próximos años bajo el mando de Trump y si las declaraciones de la USCIS son reales o una mera cortina de humo.

Imagen Melania Trump | Wkimedia Commons
Imagen Visado | Wikimedia Commons

También te recomendamos

¿Vamos a volver a aprender a escribir a mano gracias a la tecnología?

Alta demanda de Ingenieros de Software en Irlanda

Trabajar en el extranjero como desarrollador II: la vida de un programador en Irlanda

-
La noticia Conseguir un visado de trabajo para los Estados Unidos de Trump si eres desarrollador fue publicada originalmente en Genbeta Dev por Fernando Siles .

GAMBADAS: Agricultores hackeando sus tractores con firmware ucraniano ¿qué podría salir mal?

28/04/2017
Artículo original

Es indudable que el mundo se mueve hacia los servicios de suscripción. Y ni siquiera los sectores más tradicionales se escapan de esta tendencia. Lo cual no quiere decir que siempre vaya a ser buena para todos los implicados.

Y sino que se lo pregunten a los dueños de tractores John Deere en el EEUU profundo.

Aquí quizá no es muy famosa, pero John Deere es una empresa-monstruo que factura 26.000 millones al año vendiendo máquinas para la agricultura y la construcción, y que es conocida sobre toda por sus enormes tractores. En EEUU son intrínsecos: todo el mundo los utiliza.

Desde hace una temporada los tractores vienen con un software de control instalado que entre otras cosas impide que ningún taller no autorizado pueda tocar en el tractor, incluyendo cambiar las piezas más básicas. Esto significa que si un granjero en plena temporada tiene una avería con el tractor, tiene que esperar lo que sea necesario (cualquiera remolca un bicho de estos hasta un taller autorizado a varias decenas de kilómetros) a que se presente un técnico de la marca para ver qué le pasa y repararlo. Esto puede suponer grandes pérdidas y estrés. Aunque, por ejemplo, tuviese un mecánico de confianza cerca que le pueda reparar una transmisión (¡mecánica!) y así poder estar trabajando en poco tiempo, no hay nada que puedan hacer. En cuanto tocas cualquier pieza, el tractor deja de funcionar hasta que la pieza en cuestión "se autoriza" por el software de la marca.

El problema no es solo la espera, y es que un "técnico cualificado" que llega y pincha un aparato por USB al tractor les cobra un fijo de 230$ (unos 212€) además de 130$ la hora (unos 120€) por el trabajo ?

Otra de las preocupaciones de los propietarios es: ¿qué pasa si dentro de 15 o 20 años sigo usando el tractor pero la marca no quiere prestarme el servicio porque ya no tiene las piezas disponibles? ¿Tiro con el tractor? Y no es para menos...

Ante estas enormes implicaciones económicas para los propietarios, muchos de ellos están recurriendo a "hackear" sus tractores con software ucraniano, que deben comprar en foros privados para los que también hay que pagar por entrar.

Captura de pantalla del software de hacking de John Deere

La muy recomendable publicación americana Motherboard (en inglés) nos cuenta la historia completa y nos ofrece todo tipo de detalles sobre el software, el submundo que hay a su alrededor, lo que hay que hacer para acceder a esos foros, etc... Es una muy interesante lectura que te sugiero.

El problema no es solo que los propietarios de los tractores tengan que recurrir a algo tan extremo como reventar el firmware de sus vehículos. Es que además en realidad no tienen ni idea de qué están metiendo dentro. ¿Y si ese software tiene malware, como una bomba de tiempo lógica que dentro de unos años para la producción agrícola del país de golpe? ¿o si pide un recate para recuperar el control sobre el tractor?

Desde luego no parece que la estrategia comercial del fabricante de tractores esté haciendo un favor a nadie. Probablemente ni siquiera a ellos mismos, que verán como muchos clientes se van a otras empresas y como a la larga acaban perdiendo más de lo que ganan.

El equilibrio entre el derecho a ganar dinero y la libertad del consumidor

Aunque pienses que esto te queda muy lejos, algo así está ocurriendo ya con nuestros vehículos particulares aquí en Europa también, solo que quizá no seamos tan conscientes de ello. Eso sí, cuando dentro de unos años lleves tu coche, hoy nuevo, a un taller de confianza y te digan que no pueden ponerte piezas o que debes llevarlo al concesionario oficial y pagar un pastón porque lo conecten a una máquina... entonces lo verás claro. Y es que esa es la tendencia actual en casi todas las industrias. Está pasando ya hace tiempo en algunas marcas, y pronto pasará en todas.

Y es que se necesita una legislación que proteja al consumidor de estos abusos.

Por supuesto que es lícito que un fabricante quiera hacer negocio, lo que no es adecuado es que cobre verdaderas salvajadas por un supuesto trabajo especializado que en realidad es una limitación artificial para proteger un mercado. En la actualidad las marcas tienen que ofrecer recambios para sus modelos hasta 10 años después de su fabricación. ¿Pero qué pasa si dentro de 11 años un vehículo totalmente válido y en buenas condiciones se estropea y no hay piezas oficiales? ¿Se pueden negar a que las pongas porque el software no lo permite?

El problema no es tan grave para un particular y un coche utilitario como lo es para un agricultor y la herramienta con la que se gana el sustento. Pero no deja de ser (muy) importante.

No lo sé. Como casi siempre, estas cuestiones son complicadas y hay en juego mucho más de lo que parece. Pero una cosa está clara: siempre será mucho peor que tengas que comprar un software anónimamente en un foro ucraniano o chino para poder cambiarle los frenos a tu coche.

Habría que hacer algo para que no suceda, pero nuestras instituciones y legisladores han demostrado con creces en estos años que van muy (pero que muy) por detrás de la tecnología y de las necesidades de la sociedad.

Agregar JComboBox a JTable JAVA

27/04/2017
Artículo original

Hola compañeros de programación, me ha salido una gran duda, aunque parece fácil aún no he llegado a una solución:

Quiero agregar un JComboBox a un JTable Java, pero solo quiero agregar un Combo en una fila 0 y columna 4, en los demás NO.

Alguién me puede ayudar:, este es una pequeña parte del desarrollo que hice:

public Component getTableCellRendererComponent(JTable table, Object value, boolean isSelected, boolean hasFocus, int row, int column) {
        // Obtenemos la celda que se esta renderizando
        Component c = DEFAULT_RENDERER.getTableCellRendererComponent(table, value, isSelected, hasFocus, row, column);
 
        JComboBox comboBox1 = new JComboBox(DATA1);
        comboBox1.setName("c1");
 
        if (fila.compareTo(row) == columna.compareTo(column)) {
            //System.out.println("Fila: "+fila+" - "+"Columna: "+columna);
            table.setValueAt(JComboBox.class, fila, 0);
           
        }
       else {
            c.setBackground(Color.WHITE);
            c.setForeground(Color.BLACK);
        }
        // Regresamos la celda para que se agrege a la tabla
        return c;
    }

Adjunto una imagen

Minería en tu comunidad de github con R - Analizando la popularidad de los lenguajes

27/04/2017
Artículo original

En este post vamos a explorar nuestra comunidad de Github, considerando nuestros amigos (nuestros seguidores) en esta red social. En primer lugar daremos algunas indicaciones para crear una aplicación y empezar a usar la API de github. Después extraeremos la información que necesitamos para realizar nuestro análisis, y así obtener que lenguajes de programación son más usados por nuestros amigos, y cuales los menos usados. ¡Exploremos la popularidad de los lengajes en nuestra comunidad!

1. Crear la app, instalar paquetes, autenticarse

1.1 Registrar la app

Antes de nada, ya que queremos acceder a datos públicos de github, ncesitaremos registrar una app con autenticación para ello. Esto nos permitirá no tener límite de llamadas a la API. Así que dirígete a github developer program page y clica en Register now. Luego, selecciona una cuenta (debe aparecer un listado de tus cuentas de github) y en la pestaña de Personal settings selecciona Authorized applications.

Si ya tienes una aplicación autorizada para acceder a la API de github, deberás visualizarla aquí. Sino tienes ninguna app registrada aún, vete a OAuth applications (bajo Personal settings) y selecciona Register a new application.

Ahora tienes que registrar tu nueva app, darle un nombre, una descripción… completa los campos y en Callback URL introduce: localhost:1410, que es la url a la que github devolverá cuando se autentique la app.

Ahora que tienes registrada tu app, se generarán su Client ID y Client Secret. Puedes verlos en OAuth applications -> Your App. Recuerda mantenerlos siempre en secreto y a salvo.

¡Bien! pues ya eres miembro del programa de developers. Lo siguiente que haremos es instalar los paquetes de R que vamos a usar para trabajar.

1.2 Instalación de paquetes

Usaremos la versión 3 de la API de GitHub para obtener los datos github v3 API. Ya que la API devuelve los datos en formato JSON, vamos a usar la función fromJSON, que nos permitirá usar la url de la API directamente y nos parsea los datos JSON devueltos en formato dataframe. Ésta función se encuentra en el paquete jsonlite, así que tenemos que instalar ese paquete si no lo tenemos ya instalado:

install.packages('jsonlite')

Si no tienes instalado el paquete stringr, instálalo tal como acabamos de hacer con jsonlite. Lo usaremos para hacer operaciones comunes con strings. Instala también ggplot2 si no lo tienes instalado. Lo usaremos para las gráficas.

Para conectarse a la app the github, necesitaremos instalar el paquete rgithub. Puedes hacerlo directamente desde el código fuente en github. Date cuenta que depende del paquete devtools:

require(devtools)
install_github("cscheid/rgithub")

Tras la instalación, carga las librerías:

# load libraries
library(github)
library(jsonlite)
library(stringr)
library(ggplot2)

1.3 Autentica el acceso

Necesitaremos autenticar el acceso, y lo haremos a través de la función interactive.login del paquete rgithub, pasándole nuestro ID y secreto. Mi recomendación es que pongas estas líneas en un fichero separado y no las compartas con nadie. Sólo haz un source del fichero cuando necesites autenticarte o ejecuta las líneas de nuevo.

# github app autentication
clientID<-"your_client_id_goes_here"
clientSecret<-"your_secret_goes_here"
context<-interactive.login(clientID,clientSecret)

2. Obtener la información de tus amigos

Ya estás autenticado. Lo que sigue es obtener tus seguidores de GitHub. Para obtener los usuarios que nos siguen e información sobre ellos, usaremos la función get.my.followers:

# get your followers
myFollowers<-get.my.followers(context)

Podemos comprobar fácilmente cuantos seguidores tenemos usando la función length:

# get number of my followers
numFollowing<-length(myFollowers$content)

Ahora que tenemos nuestros seguidores, vamos a crear un dataframe para guardar toda la información obtenida. Primero, extraemos cada línea de contenido de la lista de myFollowers, y la vamos añadiendo a una variable dataset usando la función rbind:

# create a dataset with your followers
dataset<-unlist(myFollowers$content[[1]])

for(i in 2:length(myFollowers$content)){
  dataset<-rbind(dataset,unlist(myFollowers$content[[i]]))
}

Ahora que tenemos el dataframe, nombra a las columnas como se llamaban originalmente en myFollowers$content y guárdalo en un csv para poder reutilizarlo:

# create a data frame and save it for later use
dataset<-unname(dataset)
dataset<-as.data.frame(dataset)
colnames(dataset)<-c(names(myFollowers$content[[1]]))
write.csv(dataset,file="CrisFollowers.csv")

Obviamente lo puedes guardar con el nombre que quieras. Pero no olvides la extensión.

3. Obtener la información de los repositorios de tus amigos y crear un nuevo conjunto de datos

Como ya te habrás percatado, en los últimos datos que extraímos había información acerca del nombre de nuestros seguidores, su id, avatar, tipo… y algunas url de interés. Sin embargo, en esa información no aparecía la información de los repositorios que necesitamos para nuestro análisis, como nombres de los repositorios, lenguaje de los repositorios, número de líneas de código…

Debemos obtener esa información. Si has explorado un poco el dataset, te habrás dado cuenta de que existe una columna, llamada repos_url que nos dice que la url para obtener los repositorios dado un usuario cualquiera, es: https://api.github.com/users/user/repos. Por ejemplo, para obtener la información de cuales son mis repositorios, etc, deberemos llamar a la API https://api.github.com/users/CritinaHG/repos , y obtendremos los datos que queremos en formato JSON.

Así que obtendremos esos datos para cada usuario leyendo el dataset que creamos anteriormente, obteniendo de él los nombres de nuestros seguidores, componiendo la correspondiente url de sus repos y parseando los datos obtenidos de la API usando la función fromJSON:

# read latest created csv
myFriends<-read.csv("CrisFollowers.csv")

# extract the names
unname<-as.character(myFriends$login)

# extract data from friends' public repositories
compdata<- NULL

for(i in 1:nrow(myFriends)){
  data<-fromJSON(paste0("https://api.github.com/users/",str_trim(unname[i],side = "both"),"/repos?clientID&clientSecret"))
  if(length(data)!=0){
    data<-data[,-4]
    compdata<-rbind(compdata,data)
  }
}

# write data for reuse
write.csv(compdata,"UsersWithRepoInfo.csv")

Debes sustituir clientID y clientSecret por el id y secreto de tu app, generados al principio del post. No es necesario especificarle estos parámetros, pero hacerlo nos permite evitar limitaciones en las peticiones. Se elimina la 4º columna porque contiene información redundante, y se usa rbind para ir agregando los datos que se van obteniendo al nuevo dataset.

4. Haciendo un poco de procesamiento

Lee (si no tienes leído) el dataset activeFriends<-read.csv("UsersWithRepoInfo.csv"). Vamos a hacerle algunas transformaciones a los datos para hacerlos más manejables con R.

En primer lugar, como la zona horaria es UTC+2 (o la de Madrid), necesitamos establecer el parámetro timezone. Construimos una función para realizar el formateo y lo aplicamos a cada columna con fechas del dataset:

# make date format supported by R
date.format<-function(datestring){
  date<-as.POSIXct(datestring,format="%Y-%m-%d %H:%M:%S",tz="Europe/Madrid", usetz=TRUE)
}

# update dates with new format
activeFriends$created_at<-date.format(activeFriends$created_at)
activeFriends$updated_at<-date.format(activeFriends$updated_at)
activeFriends$pushed_at<-date.format(activeFriends$pushed_at)

Siéntete libre de explorar el conjunto de datos. Seguro que estás pensando que en él hay columnas que nos interesan para nuestro análisis, y otras que no tanto. Lo siguiente que haremos será seleccionar las que más nos interesan para nuestro análisis:

# selecting just the interesting cols
activeFriends<-activeFriends[,c("id","name","full_name","private","description","fork","created_at","updated_at","pushed_at","homepage","size","stargazers_count","watchers_count","language",                             "has_issues","has_downloads","forks_count","open_issues_count","forks","open_issues","watchers")]

Podemos binarizar las columnas que tienen solo valores True o False:

activeFriends$private<-as.integer(activeFriends$private)
activeFriends$has_issues<-as.integer(activeFriends$has_issues)
activeFriends$fork<-as.integer(activeFriends$fork)
activeFriends$has_downloads<-as.integer(activeFriends$has_downloads)

Por último, la columna full_name contiene el nombre de usuario junto con el nombre del repositorio. Extraemos de aquí sólo el nombre de usuario, pues el nombre del repositorio ya se incluye en la columna name. Lo hacemos separando cada item por la barra que separa los nombres, y tomando el primer elemento:

# Getting the username
activeFriends$full_name<-unlist(lapply(strsplit(as.character(activeFriends$full_name),split = '/',fixed = TRUE),function(x) (x[1])))

Guárdalo si quieres, para reutilizarlo más tarde.

5. Analizando la popularidad de los lenguages de programación

Podemos hacernos una primera idea de cómo están distribuidos los datos, cual es la media, mediana, máximo, mínimo… para cada columna, usando la función summary en el dataset. Éste es sólo un ejemplo parte de la salida de esta función que se obtiene para mi comunidad de amigos, mostrando las métricas mencionadas para las primeras columnas:

summary(activeFriends)
       id                 name      full_name            private                                                                      description
Min.   : 2054512   IV      :  4   Length:524         Min.   :0   Asignatura de infraestructuras virtuales para el Grado de Informática     :  4
1st Qu.:32878832   blog    :  3   Class :character   1st Qu.:0   Repositorio para la asignatura Infraestructura Virtual de 2016-2017       :  3
Median :51252063   DAI     :  3   Mode  :character   Median :0   An example repo in Ruby for continuous integration with Travis CI         :  2
Mean   :51191269   IV16-17 :  3                      Mean   :0   Curso de LaTeX organizado por AMAT para alumnos de Trabajo de Fin de Grado:  2
3rd Qu.:70082791   swap1415:  3                      3rd Qu.:0   Diferentes scripts para representación de carreras en cifras              :  2
Max.   :88848228   TFG     :  3                      Max.   :0   (Other)                                                                   :404
                   (Other) :505                                  NA's                                                                      :107

Ahora vamos al tema que nos concierne: ver que lenguajes de programación se están usando en nuestra comunidad de amigos, y cuánto se usan. Para este cometido, podemos comenzar por crear una tabla de contingencia, para dar un primer vistazo a nuestra respuesta:

languagesAndUse<-table(activeFriends$language)
languagesAndUse

         Arduino                C               C#              C++            CLIPS              CSS             Dart
               1               13                7               55                5               19                2
      Emacs Lisp              GAP         GDScript               Go           Groovy          Haskell             HTML
               2                1                1                3                1                2               48
            Java       JavaScript Jupyter Notebook              Lex              Lua         Makefile      Mathematica
              60               67                3                1                1                6                2
             PHP       PostScript           Prolog           Python                R             Ruby            Scala
               8                2                1               56               12               24                1
           Shell              TeX       TypeScript
               7               38                1

Con nrow(languagesAndUse) podemos ver el número de lenguages diferentes que se están usando en nuestra comunidad de amigos. En la mía son 31. También podemos apreciar que hay muchos repos con código JavaScript entre mis 30 amigos, sin embargo, parece que Scala, Lua, Arduino, TypeScript, Groovy, Lex, Prolog, GDScript… sólo son usados por una persona.

Finalmente, usamos qplot del paquete ggplot2 para crear un hibstograma que represente el uso de los lenguajes de programación en nuestra comunidad de github:

languages<-na.omit(activeFriends$language)
langUssage<-qplot(languages,geom = "bar",xlab = "Language", ylab="Usage",fill=I("cornflowerblue"))
langUssage+theme(axis.text.x = element_text(angle = 90,hjust = 1)) +ggtitle("Programming languages used by my friends")+theme(plot.title = element_text(hjust = 0.5))

Donde usamos na.omit para omitir de la representación de los datos los valores NA (lenguajes que no se hayan podido extraer). El hibstograma resultante es el siguiente:

Lenguajes de programación usados en mi comunidad de github
Lenguajes usados en mi comunidad de github

Así que, como podemos ver en la representación, JavaScript es el lenguage más usado, habiendo 67 repos en total en mi comunidad de amigos que contienen código JavaScript. También Java, C++ y Python son muy populares en mi comunidad.

Encontramos código Tex en 38 repositorios, por lo que LaTeX está bastante presente en mi comunidad de amigos. También hay muchos repos con código HTML, y muchos menos con código CSS, Ruby, R and C. Tras ellos, lenguages conocidos pero no amados por muchos, como PHP, C# o CLIPS, que están presentes en menos de 10 repositorios.

Por último, se puede aprecidar que hay menos de 5 repositorios en total con código Dart, Go,Haskell, Jupyter, PostScript y Mathematica, y que sólo hay un usuario de mi comunidad usando Scala, Groovy, Lua o TypeScript. Ésto responde a mi pregunta, ya que, como mi lengugaje favorito es Scala, quería saber cuántos de mis seguidores lo usaban.

Y bueno, ¿Qué sucede en tu comunidad de amigos? ¿Se usan los mismos lenguajes que en la mía? ¿Sigue Siendo JavaScript el más usado?

Referencias:

Cómo aprender Scala con Scala Exercises. Entrevistamos a 47 Degrees

26/04/2017
Artículo original

Scala Exercises

Cuando alguien piensa en una empresa amante de la programación funcional en general, y de Scala en particular, es muy fácil que se nos cruce por la mente 47 Degrees.

Una compañía que nació a mitad de camino entre Cádiz y Seattle, y que a día de hoy se ha convertido por méritos propios en uno de los mayores exponentes del software libre y de la evangelización del paradigma funcional sobre la JVM.

47 Degrees ha participado en eventos tan importantes como el Typelevel Summit en Philadelphia pero, si algo les caracteriza, es la organización de eventos de talla mundial en la maravillosa ciudad de Cádiz.

Tras dos ediciones del Lambda World, ya están calentando motores para la de este año 2017, que podremos disfrutar el 26 y 27 de octubre.

Pero en esta ocasión les hemos pedido que nos hablen de cómo aprender Scala gracias a una herramienta de e-learning libre que han desarrollado: los Scala Exercises.

¿Por qué 47 Degrees ha apostado por Scala?

Es una serie de factores que se alinearon en un momento en concreto.

Una compañía que se ha convertido por méritos propios en uno de los mayores exponentes del software libre y del paradigma funcional

A nivel empresarial, siempre nos hemos considerado como una empresa enfocada a nichos de mercado. Empezamos a desarrollar para móvil cuando Android sólo era una beta y vimos como poco a poco el sector del desarrollo móvil se empezaba a colapsar, así que buscamos otro nicho en el que situarnos.

Scala es un lenguaje utilizado por empresas que tienen necesidades muy especificas (sobre todo orientadas a dar salida al tratamiento de grandes cantidades de datos), por lo que, nuestro nicho y target de clientes esta muy centrado.

A nivel tecnológico, llevábamos mucho tiempo desarrollando en Java y nos dimos cuenta que el mismo lenguaje (y nosotros mismos) necesitábamos una evolución. Es por eso que buscamos un cambio de paradigma, algo que se adaptara tanto a nuestra forma de pensar como a nuestro entendimiento de como deberían de ser los lenguajes de programación.

Es por eso, que apostamos por la programación funcional y con el lenguaje Scala, que te permite una transición amigable desde Java, ya que funciona en la JVM y permite cohabitar con ese lenguaje.

Img 0251

¿Qué ventajas le veis sobre el resto de lenguajes?

Trabajamos en el mundo del software desde hace tiempo y hemos aprendido lo suficiente para saber que no hay mejores lenguajes, si no, lenguajes que se adaptan mejor que otros a tus necesidades o las necesidades de tu proyecto.

Nosotros utilizamos y evangelizamos sobre Scala porque creemos que tanto la comunidad como esa tecnología esta alineada con nuestros intereses.

¿Cuál es la mejor forma de aprender Scala desde cero?

Una de las partes de la empresa en donde invertimos más tiempo y esfuerzo es en el desarrollo de Open Source y en la evangelización del lenguaje.

En nuestra página de proyectos Open Source puedes acceder a más de 100 repositorios de distinta tipología y puedes utilizar para ver cómo aplicamos ese lenguaje a distintos proyectos, librerías o plataformas.

Uno de esos proyectos, de hecho, es una plataforma de e-learning basada en ejercicios, llamada Scala Exercises, donde puedes aprender como desarrollar en Scala y sobre librerías del ecosistema.

¿Cómo surgió la idea de los Scala Exercises?

Como muchos de los proyectos Open Source, parte inicialmente de una necesidad. Debido al carácter joven del lenguaje (sobre todo en los inicios, ya que llevamos en Scala cuatro años), dentro de 47 Degrees realizamos formación y trainings a nuestro equipo.

Parte de esa formación que hacíamos en el principio, era trabajar en los Scala Koans (una recopilación de lecciones y ejercicios que empiezan en un nivel básico y poco a poco van incrementando de dificultad).

Uno de los integrantes del equipo, Rafa Paradela, se dio cuenta de que el potencial de estos ejercicios era automatizarlo, gamificarlo y darle un componente social. De esa manera, la misma comunidad podría retroalimentarse y crear un proyecto vivo y en evolución.

Img 6319

¿Cómo lo hicisteis realidad? ¿Quién participó en su desarrollo?

Nuestra política con proyectos Open Source de este tipo es que, si quieres plantear tu idea conjuntamente con 47 Degrees, nosotros apoyamos, financiamos y hacemos todo lo posible para hacerla realidad.

Vimos que lo que nos planteaba Rafa, no sólo era algo que necesitábamos, era algo con potencial que podía ayudar a mucha gente de la comunidad, por eso, decidimos invertir muchos esfuerzos en ello.

En los años de evolución del proyecto, ha participado en Scala Exercises casi la totalidad del equipo de las tres oficinas.

¿Cuál ha sido vuestra experiencia, qué habéis aprendido de todo esto?

Era algo con potencial que podía ayudar a mucha gente de la comunidad, por eso, decidimos invertir muchos esfuerzos en ello

Scala Exercises nos ha dado muchísimo más de lo que esperábamos. Por un lado, lo seguimos utilizando activamente para nuestras formaciones, pero por otro, la comunidad lo ha convertido en una pieza clave dentro del ecosistema Scala.

Es un caso práctico de cómo una idea, si la planteas Open Source y la desarrollas por y para la comunidad, puede hacerte crecer como empresa en muchos aspectos.

¿Cómo ha sido la aceptación de la comunidad?

La primera versión de Scala Exercises era una plataforma web que validaba los ejercicios basados en los Koans mediante Javascript.

En cambio, con la segunda versión, nosotros intentamos resolver uno de los muros más difíciles que se encontraban las personas que querían aprender el lenguaje por primera vez. Instalar el entorno necesario para poder compilar por primera vez (IDE, SBT, Scala, etc.).

Es un caso práctico de cómo una idea, si la planteas Open Source y la desarrollas por y para la comunidad, puede hacerte crecer como empresa en muchos aspectos.

Trabajamos duro para hacer una plataforma que permitiera embeber un compilador real dentro de Scala Exercises, de esa manera, los ejercicios que vas realizando, no sólo se validan, si no que se compilan.

La comunidad reaccionó muy bien en la primera versión, pero fue en la segunda cuando la comunidad valoró todo el trabajo invertido. Actualmente Scala Exercises forma parte de las guías oficiales de Scala, en GitHub tenemos más de 900 estrellas y 218 forks y cada vez hay más librerías que usan Scala Exercises como forma de evangelización y aprendizaje.

 Mg 8077

¿Cualquiera puede colaborar añadiendo ejercicios?

Si. La plataforma esta viva y cualquiera puede mandar un Pull Request al repositorio para añadir o modificar ejercicios de los packs actuales.

Es más, una de las posibilidades que añadimos a la V2 de Scala Exercises, es que cualquiera puede añadir un pack de ejercicios. De esa forma, si tienes una librería basada en Scala, puedes utilizar Scala Exercises para añadir una serie de ejercicios que sirvan a los desarrolladores para entender como implementarla.

¿Recomendáis la experiencia a otras personas para que hagan lo mismo con otros lenguajes?

Sin duda. Los mismos lenguajes deberían de tener como prioridad, trabajar para que la curva de aprendizaje sea lo menos compleja posible. Por eso, Scala Exercises es una gran herramienta, permite empezar desde cero y tener una valoración previa antes de lanzarte a la piscina con el desarrollo del lenguaje.

También te recomendamos

Droidcon Spain 2014: conociendo a los ponentes y sus charlas ¿Cuál es su visión sobre Android?(I)

Los distintos tipos de Yoga: así te ayuda cada uno de ellos

Festival Umbraco España 2014. Entrevista a sus organizadores

-
La noticia Cómo aprender Scala con Scala Exercises. Entrevistamos a 47 Degrees fue publicada originalmente en Genbeta Dev por Antonio Leiva .

VÍDEO: El operador Flecha en ECMAScript

26/04/2017
Artículo original

Desde siempre, en JavaScript las funciones han tenido una importancia primordial. Por un lado son el mecanismo para tener visibilidades y ámbitos, y además son "ciudadanos de primer orden". Eso significa que en JavaScript se puede, y de hecho se hace constantemente, pasar funciones como parámetros y devolver funciones como resultado.

En JavaScript podemos declarar una función anónima y colocarla en cualquier punto donde se espere un valor:

var value = function() { return 42};
value();        // 42

La variable value contiene un valor que es... una función. Es por ello que podemos usar el operador () sobre la variable y que su tipo, si lo consultamos con typeof, es function.

Observa que, una cosa es la variable value, y otra es el valor que hemos asignado a dicha variable: una función anónima. Dado que la función es anónima no hay manera de llamarla si no es a través de alguna variable que la contenga (como value).

Por supuesto también se pueden declarar en JavaScript funciones tradicionales, es decir con nombre, sin necesidad alguna de almacenarlas en una variable:

function value() { return 42;}

Al igual que antes, si ahora usas typeof para consultar el tipo de value obtendrás function, y al igual que antes puedes usar value(); para invocar a la función. Parece pues, que no hay ninguna diferencia, pero son dos cosas distintas: en el primer caso tienes una variable value cuyo valor es una función y en el segundo, value es directamente la función.

Puedes conocer las diferencias entre ambas formas de declarar las funciones en JavaScript en este artículo de nuestro tutor José Manuel Alarcón.

No deja de ser curioso que siendo JavaScript un lenguaje muy orientado a usar funciones anónimas, la sintaxis para declararlas sea un tanto "verbose", o por decirlo con palabras castellanas: tediosa, larga. Observa la sintaxis mínima necesaria para crear una función anónima que devuelva un valor:

function() {
    return 10
}

Visto así no parece tan tediosa esta sintaxis. El problema es que se usa constantemente y al final la legibilidad se ve afectada. Para solucionar esta situación en ECMAScript 2015 (también conocida como ECMAScript 6 o ES6) se introdujo el operador de "flecha" (arrow o fat arrow) que ofrece una sintaxis alternativa, mucho más clara y sencilla para declarar funciones.

En el siguiente vídeo vamos a ver su sintaxis básica y cómo utilizarlo.

[youtube:OIyd9tNMX18]

Arreglar el error de que falta un ensamblado en el GAC en una aplicación ClickOnce en una aplicación .NET

25/04/2017
Artículo original

Buff, ClickOnce: ¡menuda tecnología del año de la polca! Se nota que soy un viejuno ?

Lo cierto es que ClickOnce es una tecnología interesante que, aunque no esté tan de moda como en tiempos, se sigue utilizando y mucho. ¿No me crees? Vale, pues prueba a instalar por ejemplo Google Chrome en Windows y la verás en acción. Sí, ese pequeño ejecutable que te salta y que te pide permisos para instalar desde una ubicación remota es ClickOnce en todo su esplendor.

Nosotros en campusMVP internamente tenemos alguna aplicación de escritorio que se distribuye así y que facilita mucho la instalación y el despliegue de nuevas versiones en los equipos que la utilizan. Así que será poco "cool", pero funciona y tiene muchas ventajas.

El problema

El caso es que en ocasiones puede que te ocurra lo siguiente cuando despliegas una aplicación con esta tecnología. Compilas el proyecto, le das a "Publicar", lo despliegas a tus usuarios... y cuando van a instalarlo les salta un mensaje como el siguiente:

Unable to install or run the application. The application requires XXXXX Version X.y.zzzz.0 in the GAC

o en el idioma de Cervantes:

No se ha podido instalar o ejecutar la aplicación. La aplicación necesita XXXXX Versión X.y.zzzz.0 en el GAC

"WTF? He verificado todas las dependencias y están en la versión compilada. Es más, ni siquiera me suena que esa biblioteca que me pide la use mi aplicación para nada".

Y lo que es peor, en algunos usuarios se instala sin problemas y en otros no ?

¿A qué se debe esto?

La solución

Bueno, la causa concreta por la cual ciertos ensamblados que en teoría están en la GAC desaparecen o más bien no están, no la sé. Imagino que depende de la versión de .NET concreta que tengas, de la versión del sistema operativo, etc...

Lo bueno es que la solución es sencilla.

Los pasos son los siguientes:

  1. Pulsa con el botón secundario (normalmente el derecho) sobre el nodo de tu proyecto. Me refiero al proyecto principal, al que se compila y luego se distribuye. Vete a sus propiedades.
  2. En las propiedades busca la pestaña "Publicar" y una vez allí pulsa el botón "Prerrequisitos":

Pestaña publicar

  1. En el diálogo que aparece localiza el ensamblado que te da problemas. En mi caso era log4net.dll:

    Prerrequisitos

    Por defecto lo detecta de manera automática como un prerrequisito, es decir, algo que debe estar ya instalado en el equipo del usuario. Si esto es así y no lo tiene el instalador de ClickOnce ni siquiera dejará que siga la instalación, obteniendo el mensaje de error indicado.

  1. Cambia el valor del primer desplegable de "Prerrequisito" a "Incluir" y en el "Grupo de descarga" como "Requerido":

Prerrequisitos cambiados

Esto forzará a que el ensamblado se distribuya con la aplicación y que por lo tanto se instale si no lo está ya.

El problema desaparecerá.

¡OJO!: tienes que ver si la licencia del componente que está marcado como prerrequisito permite su distribución con la aplicación. Algunos componentes no se pueden distribuir, y los usuarios deben descargarlos por separado e instalarlos antes. En un proyecto interno no debería haber problema, pero si va a ser público o se va a vender o distribuir "en masa", puedes tener problemas legales. Asegúrate de saber esto antes de hacer lo que indico.

¡Espero que te resulte útil!

CodeNarc: Análisis estático de código Groovy

24/04/2017
Artículo original

Codenarc Logo

Cuando escribimos código es importante seguir ciertas normas, buenas prácticas, reglas de estilo, coherencia en el mismo,... pero en ocasiones esto no es tan fácil, y más cuando trabajamos en un equipo en el que, al final, cada miembro tiene ciertas manías. Una forma de mejorar todo esto es utilizando un analizador estático de código.

Para Java tenemos ciertas herramientas como FindBugs, PMD y Checkstyle que llevamos utilizando durante mucho tiempo, pero tienen el problema de que con Groovy no funcionan correctamente. Para suplir esta necesidad aparece CodeNarc.

CodeNarc es un analizador estático de código Groovy que permite detectar defectos, malas prácticas, inconsistencias, problemas con el estilo del código,... y mucho más. Se trata de un framework muy flexible que por medio de reglas fácilmente configurables analiza nuestro código para mostrarnos un detallado informe a fin de que podamos mejorarlo.

Añadiendo CodeNarc a nuestro proyecto

Ok, nos hemos decidido a mejorar nuestro código Groovy, ¿cómo añadimos CodeNarc al proyecto? Tenemos diversas formas de añadirlo según nuestras necesidades y tipo de proyecto:

  • Desde línea de comandos: Una forma muy sencilla de ejecutar CodeNarc aunque probablemente no la más útil.
  • Tarea Ant: Probablemente se trata de una de las formas más antiguas de ejecutar CodeNarc. Si tu proyecto todavía se basa en Ant y no has pensado en cambiar a Gradle 3.x, esta es tu solución.
  • Desde un test JUnit: Forma muy curiosa de ejecutar el análisis de CodeNarc aunque probablemente poco útil.
  • Plugin de Maven: Si usas Maven como herramienta de construcción de tu proyecto esta será la mejor opción puesto que el plugin se encarga de configurar todo y la integración es muy sencilla.
  • Plugin de Gradle: Al igual que en el caso anterior, si Gradle es tu herramienta de build, entonces este es el plugin a utilizar.
  • Adicionalmente también existen plugins para distintos IDEs como IntelliJ y Eclipse, frameworks como Grails y Griffon o incluso para Sonar y Jenkins.

Tipos de reglas

La última versión de CodeNarc, la 0.27.0, incluye 348 reglas agrupadas en 22 categorías:

  • Básicas: Por ejemplo para comprobar que no hay bloques else or finally vacíos.
  • "Llaves": ¿Cuántas veces habéis visto if o else de una sola línea sin las llaves? Yo personalmente los odio porque son una fuente de bugs a futuro. Podemos activar reglas en esta categoría para que realicen este tipo de comprobaciones.
  • Concurrencia: En esta categoría hay reglas que comprueban la coherencia de nuestro código concurrente cuando utilizamos synchronized o volatile principalmente.
  • Convención: Por ejemplo cuando escribimos un if invertido, un if que puede ser convertido a un operador elvis,...
  • Excepciones: Contiene reglas que fallarán si por ejemplo hacemos un throw de un NullPointerException.

Y existen muchas más como algunas que comprueban imports duplicados, variables sin utilizar, if innecesarios,...

Veamos un ejemplo

Configuración mínima

He creado un pequeño proyecto de ejemplo basado en Gradle con la configuración necesaria y unas cuantas clases con distintas infracciones para poder comprender mejor cómo funciona CodeNarc. Podeis ir revisando los commits de manera individual para comprender mejors los cambios.

Lo primero que hacemos es añadir el plugin al archivo build.gradle y configurarlo:

apply plugin: 'codenarc'
...

codenarc {
    toolVersion = '0.27.0'
    configFile = new File(projectDir, 'config/codenarc/rules.groovy')
    reportFormat = 'html'
}

Ahora añadimos el archivo de las reglas. Como veis he habilitado unas cuantas.

ruleset {
    description 'Example Project RuleSet'

    ruleset('rulesets/basic.xml')
    ruleset('rulesets/braces.xml')
    ruleset('rulesets/convention.xml')
    ruleset('rulesets/design.xml')
    ruleset('rulesets/dry.xml')
    ruleset('rulesets/exceptions.xml')
    ruleset('rulesets/formatting.xml')
    ruleset('rulesets/generic.xml')
    ruleset('rulesets/imports.xml')
    ruleset('rulesets/naming.xml')
    ruleset('rulesets/unnecessary.xml')
    ruleset('rulesets/unused.xml')
}

Con esto ya podemos empezar con el análisis del código. Sólo tenemos que ejecutar la tarea check para comprobar (en las primeras dos tareas) que se está ejecutando CodeNarc (codenarcMain) tanto para nuestro código como para los tests (codenarcTest). Eso sí, como no tenemos nada en el proyecto el informe no se ha generado.

$ ./gradlew check
:codenarcMain NO-SOURCE
:codenarcTest NO-SOURCE
:compileJava NO-SOURCE
:compileGroovy NO-SOURCE
:processResources NO-SOURCE
:classes UP-TO-DATE
:compileTestJava NO-SOURCE
:compileTestGroovy NO-SOURCE
:processTestResources NO-SOURCE
:testClasses UP-TO-DATE
:test NO-SOURCE
:check UP-TO-DATE

BUILD SUCCESSFUL

Total time: 0.67 secs

Añadiendo código de dudosa calidad

Vamos a empezar con algo muy sencillo, simplemente creamos la clase src/main/groovy/demo/Example1.groovy con lo siguiente:

package demo

class Ejemplo1 {

}

Si ahora ejecutamos de nuevo la tarea check podemos comprobar que se genera el informe con las infracciones y que además la build falla.

Codenarc Report 01

Primer encontramos un bloque con la fecha de ejecución y la versión de CodeNarc con la que se ha generado el informe. A continuación tenemos un bloque de resumen por paquete con el total de archivos con infracciones y también el total de infracciones de prioridad 1, 2 y 3. Después tendremos un bloque por cada archivo en el que vemos todas las infracciones del archivo con la línea de código en donde están y un pequeño fragmento del mismo. Además el nombre de la regla es un enlace a una descripción un poco más detallada de lo que significa.

Añadiendo más código

Creamos a continuación otro archivo en src/main/groovy/demo/Example2.groovy:

package demo

class Example2 {

    boolean isEvenNumber(Integer number) {
        if (number % 2 == 0)
            println "The number $number is even"
        else
            println "The number $number is odd"
    }

    void lorem() {
        println 'Lorem ipsum dolor sit amet, consectetur adipiscing elit. Duis volutpat fermentum enim. enean in viverra arcu.'
    }
}

Y si ejecutamos de nuevo CodeNarc vemos que tenemos nuevas infracciones: Sentencia if sin llaves, sentencia else sin llaves y longitud máxima de una línea.

Codenarc Report 02

Configurando y deshabilitando reglas

Lo primero que queremos evitar es que CodeNarc haga que falle la build cuando tenemos alguna infracción. Para ello, añadimos a la configuración en build.gradle:

codenarc {
    ...

    ignoreFailures = true
}

Ahora ejecutándolo de nuevo veremos que la build no falla. Aún así seguimos teniendo infracciones con las que puede que no estemos de acuerdo o que queramos personalizar de cierta forma.

Vamos a deshabilitar la regla ClassJavadoc porque aunque sea una buena práctica escribir el Javadoc de todas nuestras clases públicas, para este proyecto de ejemplo no nos interesa.
Para ello, primero tenemos que buscar en qué categoría está incluída la regla. Esto podemos hacerlo directamente en el índice de reglas. Después, editamos el archivo de reglas rules.groovy para deshabilitarla:

ruleset {
    ...
    ruleset('rulesets/formatting.xml') {
        'ClassJavadoc' {
            enabled = false
        }
    }
    ...
}

Si ahora generamos de nuevo el informe vemos que hemos "arreglado" esas infracciones.

Codenarc Report 03

Adicionalmente, también podemos excluir una regla en una clase concreta. Imaginad que necesitamos la clase vacía creada anteriormente pero no queremos ni desactivar la regla (porque entonces no detectaría más clases vacías) ni queremos tener de manera perpetua esa infracción en el informe. Para ello podemos hacer uso de la anotación @SuppressWarnings de Java:

package demo

@SuppressWarnings('EmptyClass')
class Example1 {

}

Y entonces, sólo para ese archivo esa regla concreta es ignorada:

Codenarc Report 04

Otra opción que tenemos disponible es configurar algunas reglas para adaptarlas a nuestras necesidades. Así, anteriormente vimos en el ejemplo 2 que teníamos una infracción de tipo LineLength porque una línea era mayor de 120 caracteres. Imaginemos que hemos decidido que queremos permitir líneas de hasta 130 caracteres:

ruleset {
    ...
    ruleset('rulesets/formatting.xml') {
        ...
        'LineLength' {
            length = 130
        }
        ...
    }
    ...
}

Haciendo esto "arreglaríamos" de nuevo esta nueva infracción.

¿Y como configuro esto para empezar?

Si no sois muy cuidadosos con el código que escribís y vuestro proyecto tiene cierto tamaño, lo más probable que ocurra nada más instalar CodeNarc es que tengais cientos o incluso miles de infracciones.
Incluso siendo muy escrupulosos es probable que haya algunas reglas que no os gusten o que su configuración por defecto no se adapte a las necesidades del equipo. Mi consejo es que vayais revisando una por una las infracciones, leyendo la documentación de las mismas y decidais si las desactivais, las configurais para que se adapten a vuestro estilo y finalmente, las respetais y corregís.

Una vez decididas las reglas y configuración con las que el equipo se siente cómodo, el paso final será decidir los umbrales para hacer que la build falle. Esto permite tener builds válidas con ciertos niveles de infracciones según la severidad de las mismas pero que, superados esos niveles, la build finalmente falle y os obligue a corregirlas.
Para hacer esto, editamos una vez más el archivo build.gradle:

codenarc {
    // Es necesario eliminar esta opción
    //ignoreFailures = true

    maxPriority1Violations = 0
    maxPriority2Violations = 5
    maxPriority3Violations = 9
}

Así, la build no fallará a menos que superemos alguno de esos umbrales.

Conclusiones

Hemos visto por qué es importante asegurar el estilo y la calidad del código en nuestro proyecto y cómo una herramienta de análisis estático de código como CodeNarc nos puede ayudar a conseguirlo. Además también hemos comprobado que es muy fácil de añadir a un proyecto y de configurar y personalizar para adaptarlo a nuestras necesidades.

Porque en ocasiones no basta sólo con creer que escribimos buen código y además también testearlo, sino que hay que tener herramientas que nos aseguren su calidad, homogeneidad y estilo. Para todo esto cuando se trata de código Groovy, sin duda CodeNarc es el mejor.

Más información | CodeNarc En Genbeta Dev | Testeando tus aplicaciones Java con Spock: tests más expresivos, fáciles de leer y mantener

También te recomendamos

La siguiente maravilla del mundo podría ser construida por un robot: estos son sus límites

Venus.js, herramienta open source para ejecutar tests unitarios en Javascript

Verdades y mentiras sobre el autismo y las pruebas de software

-
La noticia CodeNarc: Análisis estático de código Groovy fue publicada originalmente en Genbeta Dev por Iván López .

¿Es cierto que 3 mil millones de dispositivos ejecutan Java?

24/04/2017
Artículo original

Si has instalado Java alguna vez habrás visto el siguiente banner:

en el que "sacan pecho" diciendo que más de 3 mil millones* de dispositivos ejecutan Java.

*: El billón estadounidense es diferente al nuestro. "billion" en inglés americano se refiere a "miles de millones", mientras que en España (y el resto del mundo, en realidad) se refiere a millones de millones, por lo que la cantidad correcta es la que indicamos.

¿Qué hay de cierto en esa afirmación? ¿Son sus números realmente tan grandes?

Lo cierto es que esa estimación es muy conservadora y hace muchos años que deberían haber actualizado ese banner. En realidad existen muchos más dispositivos que usan Java por debajo. Java es intrínseco ?

Veamos algunas cifras proporcionadas por ellos mismos pero bastante realistas:

  • 1.100 millones de sistemas de escritorio tienen Java instalado. A esto ayuda que se ejecute en cualquier sistema operativo de escritorio que se te ocurra: Windows, Linux, Mac, FreeBSD, Solaris... Piensa en uno cualquiera y seguro que tiene una máquina virtual de Java.
  • 3.000 millones de móviles ejecutan Java. No solo es que sea la base en la que sustenta el sistema operativo más utilizado del mundo, Android, sino que la mayor parte de los teléfonos "tontos" desde el siglo pasado usaban (y usan) Java por debajo. Solo Nokia en sus tiempos lanzó más de 300 modelos basados en esta tecnología. De hecho Oracle dice que se venden cada año 31 veces más teléfonos con Java que móviles con Android o iOS.
  • El 100% de los aparatos de Blu-Ray del mercado usan Java. El 100%. Todos. Esto se debe a que el estándar BD-J para contenidos extra está basado en Java ME (la "J" en el nombre es de Java) A pesar de su declive debido al vídeo en streaming, solo en 2010 había ya en el mercado más de 300 millones.
  • Cada año se fabrican 1.400 millones de tarjetas inteligentes (smart cards o Java cards) (de crédito, de seguridad y de otros tipos) que ejecutan una pequeña máquina virtual Java. Hay miles de millones en el mercado. Es probable que tengas alguna encima y ni siquiera lo sepas.
  • Java está debajo de todo tipo de aparatos: impresoras, webcams, televisiones inteligentes, equipamiento médico, sistemas de entretenimiento y navegación de coches, terminales de pago con monedas, máquinas de cobro en autopistas...
  • Existen decenas de miles o quizá millones de aplicaciones de servidor escritas en Java. Solo por citar un par de ejemplos conocidos: Twitter gestiona más de 400 millones de tweets nuevos al día en una aplicación basada en Java, y Netflix sirve más de 2.000 millones de contenidos diarios con una arquitectura Java en su interior.

Total, que en realidad no solo esa cifra es cierta, sino que se queda muy corta y es probable que la otra cifra que dan en su sitio de 15.000 millones de dispositivos que ejecutan Java esté más cerca de la realidad.

O sea, que si aprendes Java aprendes el lenguaje más utilizado del mundo, con más ofertas de trabajo y con el mayor número de sitios en donde poder utilizarlo.

¿Qué lenguajes de programación se usan más los fines de semana?

21/04/2017
Artículo original

Este artículo es una traducción de esta entrada de Julia Silge en el blog de Stack Overflow, con su permiso.

Para mí los fines de semana son principalmente para pasar en familia, leer por placer, y para trabajar en los proyectos de código abierto en los que estoy implicada. Estos proyectos de fin de semana se solapan con mi trabajo aquí en Stack Overflow, pero no son exactamente lo mismo. Muchos desarrolladores trastean con proyectos personales para aprender o para medrar profesionalmente (¡o para pasarlo bien!) y en Stack Overflow damos apoyo a todo tipo de tecnologías, ya sea profesional o por afición. Cuando las personas están programando, estamos disponibles para responder a sus preguntas. Pero, ¿sobre qué lenguajes hay más preguntas los fines de semana en comparación con los días laborables?

Usemos nuestro conjunto de datos StackLite público en Kaggle para explorar las diferencias entre las preguntas que se publican de lunes a viernes y los fines de semana. Este conjunto de datos está a disposición de todo el mundo para poder ser analizado; puedes usar un Kernel de Kaggle para analizar cualquier duda sobre las preguntas y las etiquetas en Stack Overflow.

Comparando etiquetas

Para este análisis, usaremos preguntas que no hayan sido borradas y etiquetas reutilizadas en más de 10,000 preguntas. Hemos definido los fines de semana usando las fechas UTC, lo cual no abarcará el fin de semana de todos los usuarios. En total, esta segmentación incluye 10,451,274 preguntas entre semana y 2,132,073 preguntas los fines de semana. Aquí la gran diferencia en el número global se debe a que la mayoría de las personas usa Stack Overflow para su trabajo los días laborables, y observamos este patrón tanto en el número de preguntas publicadas como en el tráfico a nuestra web.

Debido a este patrón entre semana/ fin de semana, no nos interesa si las etiquetas se usaban más los fines de semana que entre semana; lo normal es que todas las etiquetas sean más utilizadas entre semana. Lo que sí nos interesa es conocer qué etiquetas tienen un ratio mayor en relación con las preguntas publicadas el fin de semana en comparación con las preguntas de entre semana, y viceversa.

¿Qué etiquetas de las preguntas tienen la mayor diferencia de frecuencia relativa?

Etiquetas con mayor diferencia de frecuencia relativa?

Para explicar esto un poco mejor, veamos unos cuantos números. El lenguaje de programación Haskell supone un 0.365% de las preguntas del fin de semana en este conjunto de datos, pero solo un 0.21% de las preguntas entre semana, indicando que es extrañamente popular los fines de semana. Sin embargo SharePoint supone un 0.0683% de las preguntas del fin de semana, y un 0.188% de las preguntas de entre semana, demostrando que se usa más los días laborables.

Me produce una gran alegría que el lenguaje de programación funcional Haskell encabece las tecnologías de fin de semana, porque básicamente podemos decir que esta soy yo:

Yo no he aprendido Haskell, ¡pero mi reconocimiento a los que usáis los fines de semana para hacerlo! Y ahora aceptadme esta broma sobre Haskell, que es un lenguaje popular entre académicos y matemáticos pero no utilizado habitualmente en entornos empresariales.

¡Hagamos otras observaciones!

  • Vemos que algunas tecnologías de bajo nivel son populares los fines de semana, tales como C, C++, punteros, y ensamblador, además de etiquetas relacionadas con matemáticas, tales como algoritmo, recursividad, y (por supuesto) matemáticas.
  • Heroku y Meteor son plataformas de aplicaciones comúnmente utilizadas para prototipado rápido, lo cual puede sugerir que están siendo utilizadas para proyectos de aficionados los fines de semana.
  • Muchas de las tecnologías de fin de semana están vinculadas con Microsoft, incluyendo etiquetas relacionadas con Excel, SQL Server, VBA, y T-SQL. Otras comprenden tecnologías de empresa como Oracle.

También podemos visualizar estas relaciones comparando el número total de preguntas con las frecuencias relativas:

Las etiquetas que están más a la derecha en este gráfico (JavaScript, Java, C#, PHP, etc.) tienen más preguntas realizadas, y la etiquetas más a la izquierda menos. Las etiquetas que aparecen cerca de la línea discontinua tienen más o menos la misma cantidad de preguntas los fines de semana que entre semana, y las etiquetas que están más alejadas de la línea discontinua muestran las mayores diferencias entre el fin de semana y entre semana.

Podemos observar de nuevo que la mayoría de las etiquetas populares que son desplazadas de entre la semana están vinculadas con Microsoft (C#, ASP.NET, SQL Server, Excel, VBA) y que muchas de las tecnologías desplazadas del fin de semana incluyen cosas como C y C++, y también lenguajes más noveles com Swift y Node.js.

Trabajando durante el fin de semana

También podemos usar este conjunto de datos para evaluar cómo los desarrolladores han cambiado la forma de usar estas tecnologías con el paso del tiempo. Podemos usar una simulación para encontrar etiquetas cuya proporción de fin de semana (el porcentaje de preguntas que se realizan durante el fin de semana) ha variado más con el tiempo. Para etiquetas con más de 20,000 preguntas, ¿sobre cuáles se está publicando menos los fines de semana en comparación con el pasado?:

Aquí vemos etiquetas como Ruby on Rails y Scala que los desarrolladores usaban con un ratio más alto los fines de semana hace varios años, pero que ahora usan a un ritmo menor los fines de semana y mayor en días laborables. Estas tecnologías estaban más orientadas al fin de semana antaño, pero hoy en día suponen proporcionalmente una parte mayor de la vida laboral de los desarrolladores. El sistema de control de versiones SVN también ha caído en su uso el fin de semana en estos años; probablemente la aparición de GitHub (lanzado en 2008) ha llevado a que menos personas usen SVN para gestionar el código de los proyectos personales de fin de semana.

Si buscamos las etiquetas que más han crecido los fines de semana, vemos el motor de vídeo-juegos Unity3D, y un gran número de etiquetas usadas para crear aplicaciones móviles. Parece que los desarrolladores están diseñando ahora cada vez más vídeo-juegos y apps los fines de semana que en los años anteriores. ¡Una gran manera de pasar el fin de semana!

Hemos usado datos totalmente accesibles para hacer este análisis, y esperamos ver qué encuentran otros desarrolladores de nuestra comunidad explorando los productos de datos que ofrecemos. Nosotros en el equipo de datos usamos conjuntos de datos como este para responder a diferentes dudas sobre cómo entender, contratar y conectar con desarrolladores. Para ver cómo podemos resolver tus dudas usando datos y análisis, aprende más sobre Developer Insights en Stack Overflow.

Página Siguiente