Factorsim »
En FactorSim, no sólo ayudamos a nuestros clientes con sus proyectos tecnológicos. También nos gusta plantearnos retos internos que a veces rompen con los esquemas habituales en los que nos solemos mover.
Este en concreto nos hará revivir nuestra infancia.
La idea surgió pensando en nuestra niñez, en las horas que muchos de nosotros pasábamos en salones recreativos gastando monedas de 25, 50 y 100 pesetas en jugar. Siempre pensé que si fuera rico tendría mi propio salón recreativo 
Dicho y hecho, manos a la obra:
Montar el mueble
Gracias a haber trabajado un tiempo en la fábrica de muebles de mi padre, compré unos plafones de melamina negra enormes y con una super máquina de cortar madera y algunos planos/esquemas por internet hicimos la carcasa
http://clubmegazone.blogspot.com.es/p/monta-tu-propia-recreativa-en-casa.html
Componentes de una recreativa
La circuitería la compramos en una fábrica que vende componentes de recreativas, palancas y botones, pensamos en comprar también el circuito para poner monedas pero se nos escapaba un poco de presupuesto y al final pusimos simplemente un botón que al pulsarlo es como si metieras dinero.
Ejemplo de web donde podemos comprar componentes:
http://www.hardcore-gamer.net/tienda/index.php/cPath/302_381/sort/3d/page/1
Enlazar el hardware de la recreativa con el hardware del PC
Como enlazamos todos los botones y palancas a nivel de hardware con un ordenador? sencillo, con un IPAC.
http://www.ultimarc.com/ipac1.html
En pocas palabras, IPAC es un puente intermedio que conecta los botones y palancas a tu teclado. Básicamente, hace que cuando pulsas un botón es como si pulsaras la tecla “K”, por ejemplo. Así lo único que tienes que hacer es configurar los juegos para que usen las teclas correctas.
El resultado final de realizar las conexiones quedaría algo así:
Si si, lo se, esta muy desorganizado, tengo pendiente ordenar los cables
Para poder encender el ordenador desde fuera de la recreativa, instalamos un botón más que conecta directamente a la placa base del PC y es como si tuvieras el botón de power del PC en un botón de la recreativa 
Software y Hardware del PC
La máquina que hay dentro es:
- Intel(R) Core(TM)2 Duo CPU E4500 @ 2.20GHz
- 2GB RAM
- 300GB HDD
- VGA compatible controller: Advanced Micro Devices [AMD] nee ATI RV610 video device [Radeon HD 2400 PRO]
A nivel de sistema operativo hemos puesto una Xubuntu que está configurada de forma que haga autologin y al entrar en el entorno gráfico lance el frontal de selección de juegos, el QMC2.
http://qmc2.arcadehits.net/wordpress/
La recreativa tiene instalado servicio de SSH y se puede acceder a ella a través de la red y administrar o actualizar cualquier cosa
Haciendo pruebas con Xubuntu y ajustando configuraciones…
Listo, a jugar!
Con todo esto ya estamos listos! Ahora sólo queda… JUGAR!
Como mejoras que tenemos pendientes,haremos unos vinilos para decorar la carcasa, en breve los tendremos listos, os prometo hacer un nuevo post con el resultado final.
Factorsim »
FactorSim, estuvo allí.:)
Fueron unas conferencias muy interesantes, pudimos conocer de primera mano lo último que se está cociendo en html5.
Se debatió mucho la idea de webapp vs app (portabilidad vs rendimiento).
La idea de desarrollar sobre la base estandar de html5 y así tener tu aplicación funcionando en los múltiples dispositivos sin coste adicional es muy atractiva, me recuerda al eslogan de JAVA “write once, run anywhere”.
El contra que tiene sería el rendimiento de la aplicación en cuanto a efectos de transiciones y mover mucho contenido o en videojuegos, el rendimiento pobre del objeto canvas. La mayoría de estos problemas se deben a que los navegadores no soportan a full html5
Estos problemas tienen una solución mágica, la encontramos en que en realidad una webapp no es exactamente eso, es una app nativa pequeña + webapp , me explicaré mejor.
Si nuestra webapp es lenta porque el navegador no implementa bien ciertas funciones o simplemente porque no implementa cosas, desarrollamos un app nativa por ejemplo para apple, esta app lanza una especie de navegador creado por nosotros y le incrusta su propio objeto canvas que sí implementa las funciones de javascript que necesitamos para que nuestra aplicación vaya fluida.
Como ejemplo podemos ver el framework de CocoonJS
En mi humilde opinión, estos frameworks son bastante oportunistas ya que su tiempo de vida será relativamente corto ya que cuando los navegadores X soporten cada vez mas html5 nos encontraremos que tendrá menos sentido tener si quiera esa app nativa para acelerar.
También pudimos escuchar por parte de Mozilla Foundation la idea de romper con los “markets” de aplicaciones que queramos o no nos atan a grandes compañías como apple o google.
La idea de Mozilla con su webOS para móvil es que el navegador y html5 sean la base para el desarrollo, así conseguimos desarrollar sobre un estandar y no estamos atados a ninguna compañia, además nuestras aplicaciones pueden distribuirse vía web tranquilamente (si lo se, con android puedes poner un apk en la web y descargarlo pero no es lo mismo)
Cabe destacar también que webOS ha sido diseñado para ser muy rápido y así poder funcionar en dispositivos baratos y de poca potencia. Explicaron que en webOS tienes acceso a funciones muy importantes de forma bastante directa saltándote muchas cosas para ganar velocidad, como ejemplo en unas pocas lineas de código puedes acceder al uso del teléfono para llamar o acceder a la agenda de contactos.
Como podréis imaginar, es un tema peliagudo ya que el usuario queda expuesto a mas aplicaciones maliciosas.
Por último me gustaría recordar la fantástica ponencia que hizo Miguel Ángel Pastor, en la que considero que sirvió para bajar un poco los pies a tierra y recordar a la gente que para el desarrollo “serio” de videojuegos en javascript es muy muy lento. Un lenguaje débilmente tipado y no compilado es una combinación mortal
Factorsim »
Ayer fue lanzado Google Drive, el servicio de almacenamiento que competirá otros como DropBox, Skydrive, etc.
El servicio empieza con un espacio de 5GB, ampliables a 25GB por 2,49 dolares al mes o a 1TB por 50 dolares.
El lanzamiento de Google Drive también influye sobre los que tengamos cuenta de Gmail ya que veremos incrementado su espacio.
Un tema interesante será ver como Google hace frente al uso del espacio con contenido bajo copyright, y mas con todo lo que ha pasado con MegaUpload.
Factorsim »
El titular es una frase a la que me tengo que enfrentar a diario en mi trabajo y no es nada fácil ya que si te quedas corto, te tumban el servidor y si te pasas, eres muy caro.
Estimar que requerimientos se necesitan tanto de maquinaria hardware como ancho de banda, es muy complicado ya que deberíamos contextualizar sobre que es lo que nuestro servidor va a servir, se que a veces es imposible saberlo, pero entonces mi lema es “divide y vencerás”. Teniendo buenos sistemas de monitorización de cada servicio que damos, podemos tener una visión general de cuando hará falta ampliar el ancho de banda o el hardware de máquina.
FactorSim trabaja mucho en implantación de Moodle como sistema de formación para empresas y cuando nuestro clientes parten de 0 y no tienen por donde empezar, tenemos que hacer un estudio aproximado según la cantidad de usuarios y los accesos medios que nos da el cliente.
Usando la documentación oficial de moodle encontramos una primera aproximación bastante buena:
http://docs.moodle.org/20/en/User_site_capacities
The general rule of thumb for a single server is that the approx max concurrent users = RAM (GB) * 50 and the approx max browsing users = Approx max concurrent users * 5. As an example, a university with 500 total computers on campus and 100 concurrent users at any time will need approx 2GB of RAM on the one server to support the number of concurrent users.
Viene a decir que necesitamos 1GB RAM por cada 50 usuarios concurrentes.
También tenemos una herramienta muy útil y que nos puede dar información esencial para tener una estimación aproximada a algo real.
ApacheBench
http://httpd.apache.org/docs/2.0/programs/ab.html
Mediante una linea de comando en bash podemos obtener fácilmente lo siguiente:
ab -n 100 -c 10 http://campus.factorsim.es/
Con este comando, estamos generando 100 peticiones repartidas en 10 hilos de ejecución de apache.
Como podréis comprobar, hay información muy útil:
- Total de bytes transferidos
- Cuantas peticiones atendemos por segundo (casi 11 peticiones por segundo, guau! )
- Tiempo medio dedicado por petición
- Velocidad de transferencia (recibimos a 205,84 Kbytes/segundo)
- Interesantes porcentajes como que el 50% de las peticiones se sirvieron en menos de 1 segundo!
Ni que decir que ApacheBench es software libre y se distribuye bajo Licencia de Apache.