Released Acts As Decimal
Lately we have been working on some Rails 3 projects where we were handling price attributes. Since prices are naturally floating point variables (12.95, 297.50...) we felt like they had to be treaten like those, but still, in order to avoid precision losses (prices are sensitive, you know!), we wanted to store them as integers in the database.
Why don't we just make a really simple gem?
Then we came up with this tiny gem, and we are proud to introduce it to our readers! It even might make your developer lives a bit easier :)
The gem is hosted on Github and released also in Gemcutter, so it is really easy to install and use. It depends only on ActiveRecord 3.0.0.
In your Gemfile:
gem 'acts_as_decimal'
Then, in your model:
class Product < ActiveRecord::Base
acts_as_decimal :price # Defaults to 2 decimals, or...
acts_as_decimal :price, :decimals => 5 # ... as you wish!
end
Now you store and retrieve :price as a floating point:
product = Product.new
product.price = 12.30
product.price # => 12.30
But you still have access to the raw database integer value through :price_raw:
product.price_raw # => 1230
product.price_raw = 4309 # => product.price == 43.09
Furthermore, you get some nice humanizers for free. Note that all humanizers return a string, not a float.
product = Product.new
product.price = 3900400.40
product.humanized_price
# => "3.900.400,40"
product.humanized_price(:thousand_delimiters => false)
# => "3900400.40"
We are also planning on developing some Remarkable matchers for this as soon as we can!
And that's all. We hope that you find this useful and, if you feel it lacks any nice feature, we encourage you to contribute! :)
Publiquem Acts As Decimal
Darrerament hem estat treballant amb alguns projectes de Rails 3 on necessitàvem tractar amb preus. Ja que els preus són naturalment variables de punt flotant (12.95, 297.50...) enteniem que havien de ser tractats com a tals, però malgrat tot, per a evitar pèrdues de precisió (els preus són sensibles, ja se sap!), volíem desar-los com a enters a la base de dades.
Per què no fem una simple gemma aleshores?
Llavors se'ns va acudir de fer aquesta petita gemma, i ens enorgullim de presentar-la als nostres lectors. Potser fins i tot fa les vostres vides de desenvolupador una mica més agradables :)'
La gemma està allotjada a Github i publicada també a Gemcutter, de manera que és molt fàcil d'instal·lar i fer servir. Depèn només d'ActiveRecord 3.0.0.
Al vostre Gemfile:
gem 'acts_as_decimal'
Aleshores, al vostre model:
class Product < ActiveRecord::Base
acts_as_decimal :price # Defaults to 2 decimals, or...
acts_as_decimal :price, :decimals => 5 # ... as you wish!
end
Ara podeu desar valors a :price i recuperar-los com a punt flotant:
product = Product.new
product.price = 12.30
product.price # => 12.30
Però també teniu accés a les dades en enter de la base de dades a través de :price_raw:
product.price_raw # => 1230
product.price_raw = 4309 # => product.price == 43.09
A més, està disponible també un humanitzador per a l'atribut. Tingueu en compte que retorna una cadena, no un punt flotant.
product = Product.new
product.price = 3900400.40
product.humanized_price
# => "3.900.400,40"
product.humanized_price(:thousand_delimiters => false)
# => "3900400.40"
Estem pensant també en desenvolupar alguns matchers per a Remarkable de seguida que poguem!
I això és tot. Esperem que ho trobeu d'utilitat, i si considereu que li falta alguna funcionalitat interessant, us animem a contribuïr! :)'
Publicamos Acts As Decimal
Últimamente hemos estado trabajando en algunos proyectos con Rails 3 donde necesitábamos tratar con precios. Puesto que los precios son naturalmente variables de punto flotante (12.95, 297.50...) entendíamos que debían ser tratados como tales, pero sin embargo, para evitar pérdidas de precisión (¡los precios son sensibles, ya se sabe!), queríamos guardarlos como enteros en la base de datos.
Por qué no hacemos una simple gema entonces?
Entonces se nos ocurrió hacer esta pequeña gema, y nos enorgullece presentarla a nuestros lectores. Quizás hasta hace un poco más llevaderas vuestras vidas de desarrollador :)
La gema está alojada en Github y publicada también en Gemcutter, de modo que es muy fácil de instalar y usar. Depende sólamente de ActiveRecord 3.0.0.
En vuestro Gemfile:
gem 'acts_as_decimal'
Entonces, en vuestro modelo:
class Product < ActiveRecord::Base
acts_as_decimal :price # Defaults to 2 decimals, or...
acts_as_decimal :price, :decimals => 5 # ... as you wish!
end
Ahora podéis guardar valores en :price y recuperarlos como punto flotante:
product = Product.new
product.price = 12.30
product.price # => 12.30
Pero tenéis también acceso a los datos en entero de la base de datos a través de :price_raw:
product.price_raw # => 1230
product.price_raw = 4309 # => product.price == 43.09
Además, está disponible también un humanizador para el atributo. Tened en cuenta que devuelve una cadena, no un punto flotante.
product = Product.new
product.price = 3900400.40
product.humanized_price
# => "3.900.400,40"
product.humanized_price(:thousand_delimiters => false)
# => "3900400.40"
Estamos pensando también en desarrollar algunos matchers para Remarkable enseguida que podamos!
Y eso es todo. Esperamos que lo encontréis útil, y si consideráis que le falta alguna funcionalidad interesante, os animamos a contribuir! :)
Modern Warfare 2: Ghost painting
If you've read some previous posts of our blog or you have a look through our site, you could note that for us developing, especially in Ruby, is a hobby.
But in addition to developing, we like other things. For instance, Josep Jaume and Txus play in different bands, but one hobby we all share is Call of Duty. One character of the game is called Ghost and has a rather odd looking (here you can find all the information).
Since we liked him and we needed something to cheer up the office, we asked Silvia to do a painting (in oil) for us.
So here is the final painting and its different stages (you can also view the album directly at flIckr):
If you look at the last image, you'll notice an AW label. If you wonder what the heck is this, its our clan: AntiWaste (we'll need another day to explain where this comes from, as it has its own story).
Quadre Modern Warfare 2: Ghost
Si heu llegit algunes de les anteriors entrades del nostre blog o heu fet un cop d'ull per la web, haureu pogut notar que per nosaltres el fet de desenvolupar, especialment en Ruby, és una afició.
Però a part de programar, també ens agrada fer d'altres coses. Per exemple, tan el Josep Jaume com el Txus toquen en grups de música, però una de les aficions que tenim en comú és el Call of Duty. Doncs resulta que un dels personatges del joc és diu Ghost, i té una pinta bastant curiosa (aquí podeu trobar tota la informació).
Com que ens va agradar el personatge i necessitavem animar d'alguna manera l'oficina, li vam demanar a la Silvia si ens podia fer un quadre (a l'oli).
Així doncs, aquí teniu el resultat final i tota l'evolució del quadre (també podeu veure l'àlbum directament a flickr):
Si us fixeu en la última imatge del quadre, veureu que hi ha un segell on es llegeix AW. Si us pregunteu què coi és això, es refereix al nostre clan: AntiWaste (un altre dia explicarem d'on ve aquest terme, ja que té la seva pròpia història).
Cuadro Modern Warfare 2: Ghost
Si habéis leído algunas de las anteriores entradas de nuestro blog o ha habéis echado un vistazo por la web, habréis podido notar que para nosotros el hecho de desarrollar, especialmente en Ruby, es una afición.
Pero aparte de programar, también nos gusta hacer otras cosas. Por ejemplo, tanto Josep Jaume como Txus tocan en [grupos] (http://www.kayomalayo.com) de música, pero una de las aficiones que tenemos en común es Call of Duty. REsulta que uno de los personajes del juego se llama Ghost, y tiene un pinta bastante curiosa (aquí podéis encontrar toda la información).
Como nos gustó el personaje y necesitábamos animar de alguna manera la oficina, le pedimos a Silvia si nos podía hacer un cuadro (al óleo).
Así pues, aquí tenéis el resultado final y toda la evolución del cuadro (también podéis ver el álbum directamente en flickr):
Si os fijáis en la última imagen del cuadro, veréis que hay un sello donde se lee AW. Si os preguntáis qué coño es esto, se refiere a nuestro clan: AntiWaste (otro día explicaremos de dónde viene este término, ya que tiene su propia historia).
Date validation with Rails 3
Since the first Rails 3 versions came out, we've been playing and using it with new projects. In one of these projectes we needed to validate that a date was before or after, so looking at rails guides and some posts we coded our first Rails 3 validator.
Introducing date_validator
As you can read in the Github's repo description, this is a very simple date validator. To install it:
gem sources -a http://gemcutter.org # If you haven't done it before
gem install date_validator
Its only dependency is ActiveModel, so you can use it either in Rails 3 models or in any custom class (after requiring ActiveModel), in a really easy manner way:
validates :expiration_date, :date => { :after => Time.now, :before => Time.now + 1.year }
For now these are the available options you can use:
:after
:before
:after_or_equal_to
:before_or_equal_to
Pretty much self-explanatory!
Don't forget the tests: remarkable_date_validator
And last but not least, if you use Remarkable (specifically the Rails 3 fork) also install the gem with remarkable matchers:
gem install remarkable_date_validator
And in your model specs:
should_validate_date_of :expiration_date, :date => {:after => Time.now, :before => Time.now + 1.year}
Anyone fancies forking the project and adding some shoulda matchers?
Validació de dates en Rails 3
Des de que han començat a sortir les primeres versions de Rails 3 hem estat jugant i provant-lo per a nous projectes. Amb un dels projectes necessitavem validar que unes dates fossin abans o després d'altres, així que seguint les guies de rails i algun post vam fer el nostre primer validator per Rails 3.
Us presentem date_validator
Tal i com diu la descripció al repositori de Github, es tracta d'un validador de dates molt simple. Per a instal·lar la gema només cal:
gem sources -a http://gemcutter.org # Si no ho heu fet abans
gem install date_validator
La única dependència que té és ActiveModel, o sigui que tan ho podeu fer servir en models de Rails 3 com en qualsevol classe (incloent-hi ActiveModel, és clar), i tot d'una manera molt senzilla:
validates :expiration_date, :date => { :after => Time.now, :before => Time.now + 1.year }
Les opcions que hi ha disponible per ara són:
:after
:before
:after_or_equal_to
:before_or_equal_to
No cal explicar per a què serveix cada opció, no?
No oblidem els tests: remarkable_date_validator
I per últim, però no per això menys important, si feu servir Remarkable (concretament el fork per Rails 3) instal·leu també la gema amb els matchers pel remarkable:
gem install remarkable_date_validator
I al specs dels vostres models:
should_validate_date_of :expiration_date, :date => {:after => Time.now, :before => Time.now + 1.year}
Algú s'anima a fer un fork amb matchers per shoulda?
Validación de fechas en Rails 3
Desde que empezaron a salir las primeras versiones de Rails 3 hemos estado jugando y probandolo para nuevos proyectos. En uno de los proyectos necesitabamos validar que unas fechas fueran antes o después de otras, así que siguiendo las guías de rails y algún post hicimos nuestro primer validador para Rails 3.
Os presentamos date_validator
Como se puede leer en la descripción del repositorio de Github, se tratra de un validador de fechas muy simple. Para instalar la gema solo hay que hacer lo siguinte:
gem sources -a http://gemcutter.org # Si aún no lo habéis hecho
gem install date_validator
La única dependencia que tiene es ActiveModel, o sea que lo podéis usar en modelos de Rails 3 o en cualquier otra clase (requiriendo ActiveModel, claro), y todo de una manera muy simple:
validates :expiration_date, :date => { :after => Time.now, :before => Time.now + 1.year }
Las opciones que hay disponibles por ahora son:
:after
:before
:after_or_equal_to
:before_or_equal_to
¿No hay que explicar para que sirve cada opción, no?
No nos dejemos los tests: remarkable_date_validator
Y por último, pero no por eso menos importante, si utilizáis Remarkable (en concreto el fork para Rails 3) instalad también la gema con los matchers para remarkable:
gem install remarkable_date_validator
Y en los specs de vuestros modelos:
should_validate_date_of :expiration_date, :date => {:after => Time.now, :before => Time.now + 1.year}
¿Alguien se anima a hacer un fork con los matchers para shoulda?
Abusamos de les gemas? Modularidad vs mantenibilidad
Antes de empezar, me gustaría recomendar a todo lector-programador que se suscriba al blog de Plataformatec, que es la empresa donde trabaja José Valim, uno de los programadores más activos actualmente en la comunidad de Rails.
Es a raíz de un artículo en su blog: How everyone is inserting technical debt in their applications, , y de una conversación muy fructuosa con Francesc Esplugas que decidí a hacer este post.
Los plugins nos ahorran trabajo
No seré yo quien atente contra esta afirmación. Una gran ventaja del ecosistema de Rails, y de la propia filosofía de Ruby, es la modularidad. Programar sin pensar en la sustitución de módulos, el intercambio, el reaprovechamiento ... Es un suicidio. La tarea de un programador hoy en día es, en gran parte, montar un enorme rompecabezas de código donde deberá fabricar algunas piezas, pero cuantas menos sean mejor.
Estás diciendo obviedades.
¡Eh! ¿Ahora los titulares tienen opinión propia? Bueno, sí, eso ya lo sabe todo el mundo. En resumen, basándose en esta filosofía, la receta para empezar toda aplicación de Rails es, claramente:
- Definir los requisitos
- Identificar funcionalidades
- Hacer un paseo por GitHub y hacer una lista de todas aquellas gemas que nos puedan hacer la vida más fácil
- Crear un Gemfile con todas las que nos parezcan adecuadas (o un
config.gem) - Empezar a construir nuestros controladores y modelos entendiéndolos como una nueva "capa de abstracción" sobre las gemas que hemos incluido.
- (Opcional) Dejar todo a medias por pereza, porque no sabemos diseñar las vistas, o para ir a ver un episodio de Doctor Who.
Erreur!
Nos hemos dejado un punto relevante y, me atrevo a decir, totalmente imprescindible:
- Revisar cuidadosamente la calidad del código de los plugins que hayamos decidido integrar en nuestra aplicación
y más importante aún:
- Verificar que el diseño se adapta a nuestra filosofía y manera de trabajar, que consta de documentación, y que tiene uno o más mantenedores activos.
Las dos caras de la moneda: Dos actitudes extremas ante esta problemática.
La entusiasta: Me encantan las joyas. ¡Cómo brillan! ¡Mi aplicación quedará preciosa con todas estas gemas!
Pros: Inicio del proyecto más fácil. Modularidad, actualización automática de funcionalidades sin intervención directa. Agilidad. Apoyo de la comunidad, documentación. Convenciones, estándares, interfaces
Contras: Posibilidad de llegar a puntos muertos si los plugins no están bien mantenidos. Arrastre de porciones de código innecesarias. Introducción de elementos de imprevisibilidad, dependencias externas no controladas.
El cauto: Prefiero hacerlo yo, que quién sabe qué habrá tocado este plugin. No me gustan los CMS y, de hecho, tampoco los Frameworks.
Pros: Control absoluto sobre el código. Diseño coherente y cohesionado. Resolución rápida de problemas simples sin necesidad de recurrir a artificios ni convenciones. A mi manera
Contras: Fuerte carga de trabajo. Difícil mantenimiento por parte de personas externas, posibilidad de dejar abiertas vulnerabilidades por falta de rodaje del código. En ocasiones, habrá que reinventar la rueda.
¿Cuál es la buena? ¿Dejo de programar y me retiro a las islas Mêlée?
No hay una conclusión clara. Hay programadores para todo; hay que saber hasta qué punto se puede estirar de la cuerda sin que se rompa, no es bueno ningún extremo. Qué aburrido, ¿verdad?
La manera como lo enfocamos en codegram es: Utilizamos plugins si y sólo si aprovechamos una gran parte de su potencial y si tenemos garantías de que el programador que lo mantiene sabe lo que se hace y tiene perspectivas de futuro.
Para cerrar el círculo, y para hacer el post algo más tangible, podemos listar varios plugins que cumplen este criterio y que usamos sin lugar a dudas:
- inherited_resources: Base REST por tus controladores.
- carrierwave: Subida de archivos basada en rack para Rails, Merb y Sinatra.
- devise: Sistema de autenticación flexible basado en rack.
- haml: Templating engine sustituto de erb. Le acompaña un generador de CSS similar a Less.
- simple_form: Formularios automatizados á la formtastic.
- compass: Autoría de CSS en Ruby / Rails.
Abusem de les gemes? Modularitat vs mantenibilitat
Abans de començar, m'agradaria recomanar a tot lector-programador que es subscrigui al blog de Plataformatec, que és l'empresa on treballa en José Valim, un dels programadors més actius actualment en la comunitat de Rails.
És a arrel d'un article en el seu blog: How everyone is inserting technical debt in their applications, i d'una conversa força fructuosa amb en Francesc Esplugas que em vaig decidir a fer aquest post.
Els plugins són un estalvi de feina
No seré qui atempti contra aquesta afirmació. Una gran gràcia de l'ecosistema de Rails, i de la pròpia filosofia de Ruby és la modularitat. Programar sense pensar en la substitució de mòduls, l'intercanvi, el reaprofitament... És un suïcidi. La tasca d'un programador avui en dia és, en gran part, muntar un enorme trencaclosques de codi on haurà de fabricar algunes peces, però com menys siguin millor.
Estàs dient obvietats.
Ei! Ara els titulars tenen opinió pròpia? Bé, sí, això ja ho sap tothom. En resum, basant-se en aquesta filosofia, la recepta per a començar tota aplicació de Rails és, clarament:
- Definir els requisits
- Identificar funcionalitats
- Fer una passejada per Github i fer una llista de totes aquelles gemes que ens puguin fer la vida fàcil
- Crear un Gemfile amb totes les que ens semblin adequades (o un
config.gem) - Començar a construïr els nostres controladors i models entenent-los com una nova "capa d'abstracció" sobre les gemes que hem inclòs.
- (Opcional) Deixar-ho tot a mitges per mandra, perquè no sabem dissenyar les vistes, o per anar a veure un episodi de Doctor Who.
Erreur!
Ens hem deixat un punt rellevant i, m'atreveixo a dir, totalment imprescindible:
- Revisar curosament la qualitat del codi dels plugins que haguem decidit integrar a la nostra aplicació
i, més important encara:
- Verificar que el disseny s'adapta a la nostra filosofia i manera de treballar, que consta de documentació, i que té un o més mantenidors actius.
Les dues cares de la moneda: Dues actituds extremes davant d'aquesta problemàtica.
L'entusiasta: M'encanten les joies. Com brillen! La meva aplicació quedarà preciosa amb totes aquestes gemes!
Pros: Inici del projecte més fàcil. Modularitat, actualització automàtica de funcionalitats sense intervenció directa. Agilitat. Suport de la comunitat, documentació. Convencions, estàndars, interfícies
Contres: Possibilitat d'arribar a punts morts si els plugins no estan ben mantinguts. Arrossegament de porcions de codi no necessàries. Introducció d'elements d'imprevisibilitat; dependències externes no controlades.
El caut: Prefereixo fer-ho jo, que qui sap què haurà tocat aquest plugin. No m'agraden els CMS i, de fet, tampoc els Frameworks.
Pros: Control absolut sobre el codi. Disseny coherent i cohesionat. Resolució ràpida de problemes simples sense necessitat de recórrer a artificis ni a convencions. A la meva manera
Contres: Forta càrrega de treball. Difícil manteniment per part de persones externes, possibilitat de deixar obertes vulnerabilitats per falta de rodatge del codi. En ocasions, caldrà reinventar la roda.
Quina és la bona? Deixo de programar i em retiro a les illes Mêlée?
No hi ha una conclusió clara. Hi ha programadors per a tot; s'ha de saber fins a quin punt es pot estirar de la corda sense que es trenqui, no és bo cap extrem. Què avorrit, oi?
La manera com ho enfoquem a codegram és: Utilitzem plugins si i només si n'aprofitem una gran part del seu potencial i si tenim garanties de que el programador mantenidor sap el que es fa i hi té perspectives de futur.
Per tancar el cercle, i per a fer el post una mica més tangible, us podem llistar uns quants plugins que compleixen aquest criteri i quem fem servir sense lloc a dubte:
- inherited_resources: Base REST pels teus controladors.
- carrierwave: Pujada d'arxius basada en rack per rails, merb i Sinatra.
- devise: Sistema d'autenticació flexible basat en rack.
- haml: Templating engine substitut de erb. L'acompanya un generador de CSS similar a Less.
- simple_form: Formularis automatitzats à la formtastic.
- compass: Autoria de CSS en Ruby/Rails.
From scratch to Codegram HQ in 48 hours | The Go Project™
Although Codegram exists since last August, it has been just two months since we moved into our new offices. To understand this process we should briefly explain our history.
The three partners at Codegram met while working at Links40 as a whole development team. There we also began to dive into Ruby on Rails. After analyzing the company situation, we thought that it would be a good idea to outsource the whole development team to make it more independent and productive; this way we would gain some freedom, lowering the company's costs and keeping their core business at the same time. Taking advantage of the company's move to their new offices in Sant Cugat del Valles, in March 2009 we began the aforementioned outsourcing process, which eventually ended with the creation of Codegram as a separate and independent start-up.
Despite we were formally independent from Links40, they let us a work space in their offices until, around December of last year, we decided it was time to leave the nest: The Go Project™ was born.
The Go Project™
After considering several options concerning our new location, we decided to establish ourselves at Viver d'empreses de Terrassa (a local incubator service), thanks to the many advantages they offered us. And so was the process:
- February 4: We signed the lease with the Business Incubator of Terrassa. The place, although it was large enough for three people, was not yet ready to use for work.
- February 5: We went to Ikea to buy furniture (yes, everything except the shiny computers comes from Ikea)
- Weekend of February 6 and 7: after having the place repainted and cleaned three times, and even changed the lights, we assembled all the furniture and computer equipment. Finally, the once cold and empty hole became Codegram Headquarters... in less than 48 hours!
But 12 pictures are worth a post, so here is a small visual testimony of the whole process :)
De la nada a Codegram HQ en 48 horas | The Go Project™
Aunque Codegram existe desde el pasado Agosto, sólo hace dos meses que estamos en nuestras nuevas oficinas. Para poder entender este proceso explicaremos brevemente nuestra historia.
Los tres socios de Codegram nos conocimos trabajando en Links40, donde constituíamos el departamento de desarrollo y donde empezamos a adentrarnos en el mundo de Ruby on Rails. Tras analizar la situación de la empresa, pensamos que sería una buena idea externalizar el departamento de desarrollo para hacerlo más independiente y productivo, de esta manera nosotros ganábamos libertad y la empresa seguía manteniendo el núcleo de sus actividades con un coste menor. Aprovechando la mudanza de la empresa a unas nuevas oficinas en Sant Cugat del Vallès, en Marzo del 2009 se comenzó el proceso de externalización, el cual culminó finalmente en la creación de Codegram como empresa aparte y totalmente independiente.
A pesar de que formalmente éramos independientes de Links40, decidieron seguir cediéndonos un espacio de trabajo en sus oficinas hasta que, hacia el Diciembre del pasado año, decidimos que era el momento de abandonar el nido: había nacido The Go Project™.
The Go Project™
Tras valorar varias opciones donde establecernos, decidimos establecer Codegram en el Viver d'empreses de Terrassa, por las numerosas ventajas que nos ofrecían. Y así fue el proceso:
- 4 de Febrero: Firmamos el contrato de alquiler con el Viver d'empreses de Terrassa. El local, si bien era lo suficientemente grande para los tres, no estaba aún preparado para entrar a trabajar.
- 5 de Febrero: Fuimos a comprar muebles en Ikea (sí, TODO lo que hay excepto los ordenadores y un puff viene de Ikea)
- Fin de semana del 6 y 7 de Febrero: después de limpiar y repintar tres veces el local entero, montar el suelo y cambiar los fluorescentes, montamos todos los muebles y ordenadores. Finalmente, el frío y vacío zulo que teníamos como local se convirtió en Codegram Headquarters en poco más de 48 horas.
Pero 12 fotos valen más que todo un post, así que aquí tenéis un pequeño testimonio gráfico de todo el proceso :)
Del no res a Codegram HQ en 48 hores | The Go Project™
Tot i que Codegram existeix des del passat Agost, només fa dos mesos que estem a les nostres noves oficines. Per a poder entendre aquest procés explicarem breument la nostra història.
Els tres socis de Codegram ens vam conèixer treballant a Links40, on constituïem el departament de desenvolupament i on vam començar a endinsar-nos en el món de Ruby on Rails. Després d'analitzar la situació de l'empresa, vam pensar que seria una bona idea externalitzar el departament de desenvolupament per a fer-lo més independent i productiu; d'aquesta manera nosaltres guanyàvem llibertat i l'empresa seguia mantenint el nucli de les seves activitats amb un cost menor. Aprofitant la mudança de l'empresa a unes noves oficines a Sant Cugat del Vallès, al Març del 2009 es va començar el procés d'externalització, el qual va culminar finalment en la creació de Codegram com a empresa apart i totalment independent.
Malgrat que formalment erem independents de Links40, van decidir seguir cedint-nos un espai de treball a les seves oficines fins que, cap al Desembre del passat any, vam decidir que era el moment d'abandonar el niu: havia nascut The Go Project™.
The Go Project™
Després de valorar diverses opcions on establir-nos, vam decidir-nos per establir Codegram al Viver d'empreses de Terrassa, pels nombrosos avantatges que ens oferien. I així va ser el procés:
- 4 de Febrer: Vam firmar el contracte de lloguer amb el Viver d'empreses de Terrassa. El local, si bé era prou gran pels tres, no estava encara preparat per a entrar a treballar-hi.
- 5 de Febrer: Vam anar a comprar mobles a l'Ikea (sí, TOT el que hi ha excepte els ordinadors i un puff ve de l'Ikea)
- Cap de setmana del 6 i 7 de Febrer: després de netejar i repintar tres vegades el local sencer, muntar el terra i canviar els fluorescents, vam muntar tots els mobles i ordinadors. Finalment, el fred i buit forat que teníem com a local es va convertir en Codegram Headquarters en poc més de 48 hores.
Però 12 fotos valen més que tot un post, així que aquí teniu un petit testimoni gràfic de tot el procés :)
RSS feed (català)
