Skip to content

Skhorn/training

 
 

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

FLUID Training: Aprender Haciendo

Este es el repositorio de código con el cual FLUID realiza sus procesos de selección de nuevo personal y formación del personal interno. La filosofia de este repositorio es fomentar el aprendizaje a partir de la solución activa de problemas y no mediante simple lectura pasiva.

Al hacer los retos publicos buscamos los siguientes objetivos:

  1. Fomentar la solución de retos no resueltos,

  2. Si el reto esta resuelto, fomentar la solución del reto de otra forma,

  3. Si el reto esta resuelto, hacer evidente la similitud de la nueva solución.

  4. Darle vida al código financiado por FLUID en los procesos de formación e inmersión,

  5. Permitirle los clientes de FLUID visualizar la calidad de entregables de una persona en particular de nuestro equipo,

Los efectos colaterales de esta decisión permiten a FLUID:

  1. Utilizar la infraestructura de GitHub para analizar la calidad y velocidad del desarrollo de las personas en formación,

  2. Desde etapas tempranas familiarizar a potenciales talentos con las herramientas (git, asciidoc, python, etc) y conceptos (automatización, pruebas de unidad, integración continua, linting) que utilizarán en su labor diaria en FLUID,

  3. Hacer visible a la comunidad y al equipo de trabajo el trabajo de otras personas (presión de pares),

Requerimientos

Para proceder a acceder a este repositorio y enviar información de entrenamiento debe registrarse en GitHub.

Candidato

Si usted es un candidato que aun no trabaja en FLUID debera registrarse usando su correo electronico personal y creando el ID de GitHub que más le guste.

Talento

Si usted es un talento que trabaja actualmente en FLUID debe registrarse usando su correo electronico corporativo login@fluid.la y el ID de GitHub debe ser loginatfluid.

Una vez realizado este registro usted podra enviar soluciones de retos al repositorio correspondiente.

Formato

Para la generación de documentación el lenguaje que debe utilizarse es AsciiDoc. Estos archivos debe finalizar siempre en la extensión .asc.

Para la generación de soluciones en código fuente debe utilizarse la extensión y guias de estilo propias del lenguaje. Adicionalmente utilizar los linters propios del lenguaje en su modo más estricto. Si tiene en cuenta la recomendación anterior por favor en el mensaje de Pull-Request enviar la salida de los linters sonbre los archivos correspondientes.

Cuando un reto tenga una solución en código y en documento (asc), presentar en la versión documenta el código fuente sin comentarios, de forma secuencial, manteniendo la indentación y utilizando el resaltado de código (syntax highlighting) propio de GitHub y asciidoc:

[source,python]
----
print('Hola mundo')
----

Este es un ejemplo de un archivo que cumple totalmente con estas indicaciones. El código fuente puede encontrarse aquí.

Un ejemplo más extenso de uso de AsciiDoc en GitHUb se encuentra aquí.

Finalmente los archivos deben tener líneas máximas de 79 caracteres, utilizar espacios en vez de tabuladores, evitar las lineas vacias al final del archivo y los espacios en blanco al final de la linea. Parametrice su editor de texto favorito (ojala Emacs o Vi) para que le facilite esta tarea.

Contenido

Los articulos que se construyan deben seguir completamente la línea editorial definida aquí. Esta linea editorial aplica tanto a articulos relacionados con la solución de retos, como articulos de seguridad en general.

En función de la calidad de los articulos, FLUID puede decidir publicarlos inmediata o posteriormente en dicho blog y anunciar su publicación a los clientes suscritos a su blog. Una medida de la calidad del contenido generado por usted es el numero de articulos que resultan en publicaciones en nuestro blog.

Estructura

Los soluciones a los retos se almacenan en la carpeta llamada challenges. En esta carpeta se debe manejar la siguiente estructura:

  • sitio (directorio)

    • código del reto (directorio)

      • login de github.extensión (archivo de solución)

Un ejemplo de esta estructura es:

El nombramiento de los archivos y directorios a menos que en esta guia se especifique lo contrario, debe realizarse en idioma ingles, en minuscula, sin caracteres especiales y en caso excepcional de requerir espacios usar _ (guion abajo) como sustituto.

La extensión esta dada por el lenguaje en el cual se soluciona, o por asc si es un documento.

Los articulos generados por usted y que no correspondan a una solución de retos deben estar en la carpeta articles siguiendo la siguiente estructura:

  • login de github (directorio)

    • titulo del articulo (directorio)

      • readme.asc (archivo)

      • imagen.png (imagen requerida)

Archivos Especiales

Dentro de cada reto deben existir como archivos especiales los siguientes:

LINK.txt

Contiene la URL al enunciado del reto en la plataforma correspondiente (Ejemplo).

DATA.txt

Contiene los casos de prueba con los cuales se han verificado los retos. En muchos casos provienen del sitio original, pero durante el desarrollo se crear otros que pueden ser necesarios.

Versionamiento

Todos los archivos relacionados con la resolución de retos, construcción de articulos se deben almacenar en este repositorio GIT en la estructura de retos indicada.

Todos los archivos y cambios a archivos o adiciones relacionados con la solución de un reto deben agruparse en un solo commit. Al final del día se espera un solo Pull Request que se encargue de solicitar la integración a la rama oficial del repositorio.

Propiedad Intelectual

Los derechos patrimoniales sobre el contenido de este repositorio se encuentran definidos en el archivo COPYRIGHT.

La licencia y privilegios que tienen los usuarios de este repositorio se encuentran definidos en el archivo LICENSE.

Realizar envio de Pull-Request al mismo implica la cesión de derechos patrimoniales. Por ende la información aqui contenida puede ser usada por el propietario (Fluidsignal Group S.A.) para cualquier fin comercial, siempre preservando los derechos morales de sus autores.

Envio

Cada vez que usted realice proceso de formación usted debera reportar su avance en el ranking mundial accediendo al siguiente formulario.

Este archivo debe referenciar la URL correspondiente al pull request que contiene los archivos asociados al avance que se reporta. Un ejemplo de un pull request.

Plagio

La idea de tener las soluciones disponibles para su visualización propone un reto para el plagio, ¿como mostrarle al mundo las soluciones y evitar el plagio? El plagio no es un problema tecnico, es un problema moral de atribuirse un código que no fue realizado como propio.

Para evitar el plagio precisamente buscamos la visibilidad y la declaracion explicita de autoria de cada algoritmo en un lugar centralizado, de esta forma queda evidencia clara de la atribución y puede ser sometido a escrutinio publico el acto de plagio.

Es decir, el modelo actual propuesto, evita el plagio a partir de la transparencia total. No hay que hacer nada mas, cada Pull Request es una declaración de autoria y la ubicación de la solución en el lugar donde facilite el calculo de similaridad le hace a un humano encontrar el plagio.

De todas formas FLUID trabaja activamente en aplicar tecnicas de detección de similitud algoritmica sobre todo el código que sea enviado. En particular usando: MOSS.

Dudas

Cualquier duda que tenga durante este proceso por favor dirigir un correo a careers@fluid.la con las preguntas correspondientes.

About

Solving hacking and programming challenges

Resources

License

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published

Languages

  • Python 32.7%
  • Java 19.9%
  • C# 14.2%
  • JavaScript 10.0%
  • C 8.9%
  • Ruby 7.1%
  • Other 7.2%