Solo por recordarlo fácilmente, para remover filas duplicadas en una hoja de cálculo usando Libreoffice / Openoffice:
Espero que con esto lo recuerde más fácilmente la próxima vez.
Go big or go home es una especie de mantra para las startup, si la ambición de la compañia no es varios ordenes de magnitud mas grande que su estado actual -lo cual es perfectamente posible, puede ser por falta de visión o por cotas superiores de mercado muy cortas- generalmente no es atractiva para las personas que no tienen un afecto especial por hacer funcionar dicha startup (el afecto a la idea es un motor invaluable para toda compañía).
La ambición de una compañía generalmente la miden por la respuesta a algunas preguntas comunes, ¿cúal es el tamaño del mercado? es una de las primeras que se deben responder, para hacerlo hay varias alternativas, dentro de las más comunes está la presentación de cifras estimadas por consultoras de mercado internacionales o cifras concretas de valores actuales de inversión en el contexto en los que se mueve la startup, esto implica usar numeros muy grandes (xx billones -generalmente billones de notación estadounidense 10 ^ 9- de zz al año), sin embargo creo que la forma más atractiva para mostrar esos tamaños de mercado deberia ser más gráfico e involucrar órdenes de magnitud.
De hecho, me gustaria poder expresar el tamaño del mercado de Solocontrata,me como una sucesión gráfica que muestre algo tangible y termine en algo que es dificilmente imaginable como en la ilustración de los tamaños de objetos celestes. Si algún artista gráfico quiere los datos para arriesgarse a ilustrarlo, con gusto nos comunicamos y trabajamos en ello.
En Solocontrata.me desarrollamos nuestro frontend y middlend usando python y para el backend usamos grails. Como es de esperarse en un proyecto sencillo la cantidad de dependencias no es muuuy grande pero aun así con las constantes mejoras en las librerías y los cambios de versión puede llegarse a algo parecido al aborrecible Dependency Hell.
Hace un par de días un amigo que esta trabajando en la migración a software libre para una gran entidad pública me dijo que no habia encontrado la forma de grabar macros en libreoffice -en esta entidad pública existen cantidad de documentos con macros grabadas anteriormente-, sin esta herramienta sus hojas de cálculo serian casi inútiles puesto que es la forma de automatizar mucho trabajo para ellos.
Sucede que en Libreoffice (y Openoffice) el archiconocido grabador de macros se encuentra desactivado por defecto, para habilidatarlo es necesario entrar la menú Herramientas->Opciones->General->Activar grabación de macros, sin embargo el uso es algo extraño, la secuencia general es más o menos asi:
Bueno, yo no uso mucho los macros asi que mi experiencia es limitada, sin embargo, son secuencias de StarBasic (oh no, Basic sigue vivo!!!) -aunque en Libreoffice 3.6 soportan otros lenguajes como BeanShell, Python y Javascript- así que con algo de pensamiento ordenado y un poco de ayuda con el API no deberían dar tanto problema.
La mejor guía en español es la oficial, tiene imágenes a todo color y tiene un acercamiento muy correcto para familiarizarse con las macros.
Los juegos de video son una industria enorme, una forma de deporte y un sueño de casi todos los que empezamos a codificar en los 90′s. Con el acceso a motores y librerías para generar juegos sencillos (Quien no recuerda largas noches en la universidad trabajando con Allegro?) varios nos acercamos un poco al rol de creadores que al de jugadores.
Ahora en Colombia nos encontramos con un apoyo -tardío e inusitado, falta ver si exitoso- por parte del gobierno para la creación de contenido en entretenimiento digital, dentro de esa categoría se encuentra el desarrollo de video juegos.
Creo que hay un espacio intermedio entre los jugadores y los productores de videojuegos en el que nos encontramos quienes sabiendo algo de programación y teniendo aún poca experiencia en la producción de juegos queremos acercarnos a la industria. Creo que la forma ideal de hacerlo es mediante las competencias de programación de agentes autónomos.
Existen varios torneos en los que a partir de un API pública los desarrolladores generan implementaciones que juegan un juego y que tienen reglas claras y referencias para realizar pruebas con las cuales es posible empezar a pensar de la forma necesaria y conocer algunos de los requisitos para hacer videojuegos sin necesidad de hacer un salto de carrera inmediato, entre otras me gustaría destacar tres:
Es un torneo organizado de forma anual por el porta Javahispano, se desarrollan equipos de fútbol que compiten en un torneo mundial, hay premios en efectivo para los cuatro primeros puestos y el desarrollo es muy sencillo. En la web existen varios videos con partidos jugados durante la competencia.
Es un torneo organizado desde 2009, se usa Java para las implementaciones, tiene divisiones para agentes jugadores, generación de niveles (escenarios, tableros) y uno muy interesante para agentes que compiten para pasar un test de Turing (el público compara el juego del agente contra el de un humano y decide cual es humano).
Uno de mis juegos favoritos -nunca he sido buen jugador, pero como en el fútbol eso no le quita emoción- que cuenta con un API en C++ y Wrappers para programar los agentes usando Java, Python, Lua, C# (Mono) e incluso Prolog (Porqué no PHP? jajaja toma eso @srdraka). Este sí que es un desafio y hay varias tesis de grado de maestría que han competido.
Generalmente cuando se hace algún tipo de libreria en Java se empaqueta en un artefacto .jar, para gestionar el ciclo de construcción de una aplicación (entre ellas la gestión de dependencias) se puede usar Maven u otra herramienta similar (ant, ivy, gradle).
Ahora bien para publicar los artefactos al equipo y dejarlos disponibles se puede usar un ftp, dav o un gestor completo como Artifactory o Nexus, sin embargo con soluciones como Bitbucket o Github es buena idea mantener todo junto (más aún si Bitbucket permite repositorios privados tanto en Mercurial como en Git).
Para ello simplemente tenemos que configurar en el pom.xml de nuestro proyecto para que haga un deploy local del artefacto y luego publicarlo en bitbucket (git) mediante el ciclo commit , push. Finalmente cuando se necesite usar la dependencia en otro proyecto solo hay que agregar la configuración de repositorios para descargar la dependencia. Por ahora un pom.xml de ejemplo:
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>org.simmetrics</groupId>
<artifactId>simmetrics</artifactId>
<version>1.6.2</version>
<packaging>jar</packaging>
<name>simmetrics</name>
<description>SimMetrics is a Similarity Metric Library, based on previous work by http://sourceforge.net/projects/simmetrics/</description>
<url>https://bitbucket.org/Nickmancol/simmetrics</url>
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<altDeploymentRepository>releases::default::${project.baseUri}/mavenRepo/releases/</altDeploymentRepository>
</properties>
<developers>
<developer>
<id>@Nickmancol</id>
<name>Nicolas Bohorquez Gutierrez</name>
<email>nicolas.bg@gmail.com</email>
<timezone>America/Bogota</timezone>
</developer>
</developers>
<scm>
<connection>scm:hg:http://bitbucket.org/Nickmancol/simmetrics</connection>
<developerConnection>scm:hg:http://bitbucket.org/Nickmancol/simmetrics</developerConnection>
<url>http://bitbucket.org/Nickmancol/simmetrics</url>
</scm>
<distributionManagement>
<repository>
<id>releases</id>
<url>https://bitbucket.org/Nickmancol/simmetrics/raw/tip/mavenRepo/releases/</url>
</repository>
<snapshotRepository>
<id>snapshots</id>
<url>https://bitbucket.org/Nickmancol/simmetrics/raw/tip/mavenRepo/snapshots/</url>
</snapshotRepository>
</distributionManagement>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>2.3.2</version>
<configuration>
<source>1.5</source>
<target>1.5</target>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-javadoc-plugin</artifactId>
<executions>
<execution>
<id>attach-javadocs</id>
<goals>
<goal>jar</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-source-plugin</artifactId>
<executions>
<execution>
<goals>
<goal>jar</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
<profiles>
<profile>
<id>deploy-snapshot</id>
<properties>
<altDeploymentRepository>snapshots::default::${project.baseUri}/mavenRepo/snapshots</altDeploymentRepository>
</properties>
</profile>
</profiles>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.8.1</version>
</dependency>
</dependencies>
</project>
Corresponde a un proyecto para actualizar una librería para el cálculo de similitud entre dos cadenas de texto usando diferentes métricas, originalmente publicada en sourceforge (CVS) sin mantenimiento desde hace 5 años.
En las lineas 34 a 43 se declaran los repositorios para distribución del artefacto. En la linea 16 se declara la propiedad altDeploymentRepository que sobreescribe la publicación del artefacto en el repositorio por una ruta local directorio del proyecto/mavenRepo/releases cuando se ejecuta la tarea de maven deploy. Finalmente en las lineas 82 a 89 se declara un profile para sobreescribir la propiedad altDeploymentRepository cuando se hace deploy de un snapshot.
Cuando se necesita usar un recurso estático en una clase java generalmente se usa un llamado a getResource*:
Class.getResourceAsStream("/ruta/archivo") //null
ClassLoader.getResourceAsStream("/ruta/archivo") //null
ClassLoader.getResource("/ruta/archivo").openStream() //null
this.class.getResource("/ruta/archivo") //esta debería funcionar
Thread.currentThread().contextClassLoader.getResourceAsStream("/ruta/archivo") //debería funcionar
en grails nuestros recursos estáticos deben encontrarse en la ruta src/java para que se encuentren disponibles tanto para todos los entornos (incluidas pruebas unitarios), sin embargo, el uso de las alternativas anteriores no aprovecha la interfaz de Spring org.springframework.core.io.Resource que nos varias ventajas sobre la carga normal de recursos.
Para hacerlo existen varias formas, entre ellas:
ApplicationHolder.application.parentContext.getResource("classpath:$filePath") //deprecated desde 2.0
new UrlResource( StaticResourceLoader.getResource("/ruta/archivo")) //mi preferida
La última opcion hace uso de la clase StaticResourceLoader disponible desde la versión 1.2 de grails y tiene como ventajas extra el evitar usar clases deprecated y permitir ser usada en test unitarios sin tener que hacer ningun mock.
Un asunto con el desarrollo de grails es la gestión de dependencias, cada vez que se ejecuta un comando (grails run-app, grails test-app, grails install-plugin xxx) el entorno verifica las dependencias (librerias, plugins, etc) declaradas para el proyecto.
En nuestros proyectos grails este periodo de tiempo tomaba de 30 a 90 segundos!!! lo cual es más que suficiente para permitir más que una leve distracción (a.k.a solo leo este articulo y listo…) así que optamos por instalar una instancia de Artifactory para tener un repositorio maven local que almacenara las dependencias sin tener que ir a hacer el chequeo a los repositorios centrales.
Eso bajó los tiempos a 10-12 segundos puesto que aún era necesario el uso del repositorio centralizado de plugins de grails que usaba (si, hasta marzo de 2012) Subversion.
Sin embargo, desde hace unos pocos días gracias JFrog los plugins se han migrado a un repositorio estándar y en nuestra instancia de Artifactory solo tuvimos que agregar un nuevo repositorio externo apuntando a http://grails.org/plugins para dejar unicamente configurados en los proyectos (BuildConfig.groovy) nuestro repositorio Artifactory:
repositories {
/*grailsPlugins()
grailsCentral()*/
grailsHome()
mavenLocal()
mavenRepo "http://x.x.x.x:8081/artifactory/libs-release"
mavenRepo "http://x.x.x.x:8081/artifactory/plugins-release"
//
/*mavenCentral()
mavenRepo "http://snapshots.repository.codehaus.org"
mavenRepo "http://repository.codehaus.org"
mavenRepo "http://download.java.net/maven/2/"
mavenRepo "http://repository.jboss.com/maven2/"*/
}
Lo que nos permite bajar los tiempos de verificación de dependencias a 3-4 segundos!!!!. Gracias a Germán Franco por toda la ayuda en la instalación y gestión de servidores de Alephsa.
Cuando se presenta un emprendimiento ante posibles personas interesadas (jueces, inversionistas, socios) entre otras muchas cosas (la confianza que inspira el líder, el equipo de trabajo, etc) dos obvias (lo obvio solo es obvio hasta cuando alguien lo dice) son la idea y la implementación. En una de las charlas a las que tuve el gusto de asistir un exitoso inversionista nos contó – de forma simplificada, obviamente – cómo evaluaba la cantidad de dinero que podría invertir en una idea cuando se la presentaban.
El producto entre una valoracion subjetiva de la idea y una evaluación de la calidad de la implementación es una buena aproximación inicial al valor que podría invertirse en el emprendimiento. Los valores de la siguiente tabla son subjetivos.
Asî que una idea mala con una implementaciôn excelente puede valer un millón de dolares, pero una excelente idea con una mala implementaciôn no vale mas un almuerzo. En el #SWCol 3 he visto ideas buenas aunque solo hasta esta tarde vamos a poder ver las implementaciones.
Este fin de semana se celebra el tercer Start up Weekend Bogotá en su tercera edición, hasta el momento es el que mayor atención ha suscitado entre el público no especializado (una gran labor de los organizadores entre ellos especialmente @luis3etancourt ) y parece que va a ser todo un hito en eventos tecnológicos.
Yo lamento no participar esta vez, sin embargo voy a ir a rondar porque me gusta el ambiente y porque creo que la congregación de nerds y geeks es un caldo de cultivo excelente para encontrar alternativas y nuevas miradas a la esfera. por tanto quisiera dejar una lista de las cosas que espero ver.
Espero verlos a todos allá y felicidades por al iniciativa.
Escrito por Nickman
Dejar un comentario