Que es un programming bootcamp? Vale la pena? Mi experiencia en MakersAcademy

TL;DR :)

Si tomanos la definición exacta de wikipedia sobre Bootcamp veréis que se trata de un campo de entrenamiento. Teniendo esta definición en mente la podemos aplicar a cualquier cosa.

Como todo en esta vida hay ['hypes', 'trendings','está de moda'] y los programming bootcamps no iban a ser una excepción.

A que público va destinado? Necesito saber programar?

Llevo un tiempo leyendo que programar es un ['skill','habilidad'] y como tal uno puede entrenarse para llegar a tener esos conocimientos.

Todo el mundo puede llegar a tener esos conocimientos? Pues yo creo que no, de la misma manera que no a todo el mundo se le da bien cocinar, conducir... Ante todo debes de disfrutar con lo desconocido ya que muchas veces tendrás que utilizar herramientas completamente nuevas para ti.

En la mayoría de estos Bootcamps has de superar un test para ser aceptado, no estan midiendo tu nivel de programación sino más bien tu manera de solventar problemas. Se suele aceptar a un 10% de los aplicantes.

En todos estos centros te diran que puedes ser programador sin tener un solo conocimiento sobre programción. Esta afirmación en parte es verdadera aunque yo creo que si tienes una noción mejor que mejor. En mi caso me estoy dando cuenta de que si no hubiera aprendido lo que he aprendido en estos últimos años andaría algo perdido a cerca de ciertos conceptos básicos.

FYI all of them are in English.

En mi caso voy a asistir a makersAcademy que está en London.

Para quien viva en España tiene la posibilidad de ir a Ironhack, hay un centro en Madrid y otro en Barcelona.

Otro sitio al cual os podrías apuntar en Barcelona sería SkyLab Coders, he tenido la oportunidad de hablar con uno de los fundadores y su prioridad se centra en que el alumno aprenda las últimas tendencias dentro del mundo web aka <3 javascript everywhere. Algo bueno que he sacado de la conversación es saber que ya tienen unos cuantos recruitment partners.

Que voy a aprender?

Vas a aprender las mejores prácticas a la hora de programar (es exactamente lo que necesito!). Lo que vas a aprender va a depender bastante de la academía en la que te apuntes. En mi caso son 12 semanas non-stop de sol a sol, en otros casos son 8 semanas, en otros hasta te puedes quedar a dormir... En sí debes y vas a vivir el código, tendrás tantas cosas para hacer que no podrás pensar en nada más que código. Cool!

En este mundo tech todo va tan rápido que las tecnologías que aprendas pueden variar pero en sí los principios son los mismos. Aprender un lenguaje de programción (la opción mayoritaria sería Ruby), metodologías como OOP (Object Oriented Programming), TDD (Test Driven Development), BDD (Behavior Driven Development), Agile practices, Databases, front end development...

Todo el temario de mi Académia

BootCamping at MakersAcademy

La vida en MakersAcademy (por el momento) es increíble, las oficinas estan situadas en el centro de todo el cotarro tecnologíco de London. El espacio en donde desarrollas tu vida es grande, con salas para reuniones, lecturas, mesas con 48 monitores.

En sí el día a día sería el siguiente:

  1. Lectura a primera hora sobre el temario de esa semana.
  2. Dedicarle tiempo al proyecto de la semana.
  3. Algunos dias hay yoga para desconectar con el estrés.
  4. Charlas ofrecidas por profesionales del sector.
  5. Lactura a primera hora de la tarde sobre el temario.
  6. Más tiempo para tu proyecto.
  7. Los viernes suele ser el día de los "challenges".

Semana 1

The basics

La primera semana es la más relajada de todas, presentación del staff y el alumnado.

Se empieza por los fundamentos de Ruby, Git y usar la línea de comandos. El proyecto de la semana sería hacer un directorio que contenga el nombre de todos los estudiantes de la cohorte.

A finales de semana nos han presentado la manera de escribir auténtico software, utilizando tests antes de escribir la primera línea de código. Que?

Yo me pregunté lo mismo, pero cuando vi el concepto me quedé fascinado.

TDD (Test Driven Development) La idea detrás de este proceso para crear software se basa en ir escribiendo tests sobre las funcionalidades que quieres, de manera que siempre te den errores para tu interpretarlos y saber como tienes que escribir el código.

Para todos los tests se utiliza RSpec gem de Ruby

Siguiendo la metodología de más arriba hemos hecho el juego del FizzBuzz

Este sería el primer test que tendríamos que escribir, si pasamos RSpec al directorio veremos un error que nos dirá que no reconoce la clase FizzBuzz.

require ".lib/fizzbuzz"
describe "FizzBuzz" do
    it "should be divisible by 3" do
        expect(FizzBuzz.is_divisible_by_three?(3)).to be true
    end
end

Ahora lo que tendríamos que hacer sería escribir el código necesario para pasar el error.


class FizzBuzz  
    def self.is_divisible_by_three?(number)
        number % 3  ==  0
    end
end 

RED -- GREEN -- REFACTOR --> Holly words!

El challenge del viernes va sobre la línea de comandos.

Valoración semanal

Esta semana ha sido plácida, me he dado cuenta de que empiezo a moverme muy a gusto con la línea de comandos. El proyecto y challenge han sido terminados a tiempo

Semana 2

Intermediate Ruby and Git

Desde esta semana he decidido hacer todos mis proyectos con dos branches para Git, una master y otra develop en la que estoy haciendo todo el trabajo.

Me había olvidado de hablar sobre el Pair programming, técnica en la que programas por parejas. Alguien escribe un test erróneo y el siguiente lo arregla y escribe otro test erróneo para el siguiente y looping hasta que se acaba.

El proyecto de la semana es reproducir el sistema de alquiler de bicis que hay en Londres.

Estamos usando TDD con RSpec y los conceptos introducidos sobre OOP (Object Oriented Programming). Bastante fascinante ver como puedes recrear todo el proceso con código.

El challenge de la semana ha sido trabajar con lo aprendido a cerca de Git.

Valoración semanal

El pair programming por el momento es complicado, de 5 he conectado con 2. A cerca del temario lo voy entendiendo pero el tema de los tests es algo complicado, sobretodo tener que pensar en el más simple detalle. Tiempo al tiempo.

Semana 3

Test-driven development and object-oriented programming

En esta semana continuamos con el proyecto de las bicis modificandolo con lo introducido.

Después de haber repetido el proyecto unas 4 veces estoy siendo capaz de resolver algunos tests por mi cuenta. Estoy encontrando al TDD muy interesante y difícil a la hora de programar.

Sin lugar a dudas hay que aprenderse la sintaxis que usa RSpec, entender el funcionamiento de ruby y cambiar la manera de pensar.

Cuando se usa RSpec debes de recrear el comportamiento que quieres que tu programa tenga. Cada vez que testeas una clase puedes hacerla interactuar con otras non-existentes classes. Se hace creando un objeto (double) al que podrás modelar como quieras con tal de que vayas superando los tests para la clase con la que estás trabajando.

De esta manera cuando te toque crear la clase que has estado utilizando para interactuar ya tendrás disponible alguna información de como tiene que ser la clase que estás creando.

Para el Challange de la semana teníamos que recrear el tránsito de un aeropuerto utilizando TDD. El resultado ha sido aceptable pero con mal sabor de boca. Las soluciones me tardan mucho en salir.

Valoración semanal

El lunes tuve un bajón bastante grande pero fue debido al pair programming, a veces depende de con quien te emparejes puede dar la sensación de que estas perdiendo el tiempo por lo que acabe la semana trabajando solo. Noté la diferencia.

Semana 4

Further TDD and OOP

Esta semana he decidido empezar un proyecto personal para mirar de entender todo el proceso. Como cocinero que soy he acabado por intentar recrear la transición que ocurre dentro de un restaurante.

He empezado aplicando los conceptos de domain model y CRC card, y así poder empezar los tests sabiendo de que se compone mi proyecto.

El proyecto de esta semana se basa en construir el juego de los 'BattleShips' en ruby usando RSpec y orientandolo a usar clases.

Hay que trabajar por equipos, primera gran prueba de fuego como equipos. Para empezar hemos seguido los conceptos que describo más arriba, domain model y CRC card. Las primeras disputas ya han salido a la palestra; yo consideraba que teníamos que hacer una clase para los jugadores pero los demás como que estaban en desacuerdo. Suelo equivocarme pero no esta vez.

Con el proyecto de los barcos se nos ha presentado diferentes maneras de escribir software usando OOP. Se basa en usar los principios de la SOLID programming, son 5.

  1. Single Responsibility Principle.
  2. Open/Closed Principle.
  3. Liskov Substitution Principle.
  4. Interface Segregation Principle.
  5. Dependency Inversion Principle.

Otro grupo de principios que se usaría en la programación sería la

  1. Singleton
  2. Tight Coupling
  3. Untestability
  4. Premature Optimization
  5. Indescriptive Naming
  6. Duplication

Para salirte de tus dudas lee este interesante artículo que he encontrado sobre la diferencia entre ambas.

From stupid to solid code

El challenge consiste en explicar como funciona el método Array.inject() usando Ruby. En si debes de extender los métodos que posee la clase Array o crear una clase nueva que sea decendiente de la clase, si os parece un trabalenguas aún es más complicado recrearlo. Otra tarea sería hacer un servicio para un Takeaway usando Twilio de manera que cuando mandes tu orden recibas un sms de confirmación y la hora de entrega.

Valoración semanal

Si soy sincero me ha costado bastante cojer el "quid de la cuestión", en parte porque cada miembro del equipo piensa de una manera y tú código acaba reflejando como piensas. A parte decir que es difícil trabajar con depende de que personas, nuestro head coach siempre nos dice que el código que escribimos es NADA pero parece que algunas personas no lo entienden.

Semana 5

Introduction to web development

Mi proyecto del KitchenFlow lo tengo un poco apartado pero más que nada por tiempo. Esta semana he empezado/acabado otro que me ha servido para entender un poco más como debo de usar los tests en BDD, voy creando tests que me obligan a tenerlos que arreglar, a muchos compañeros les ha encantado Respect for RSpec.

Esta semana toca hacer una web del proyecto anterior, los hemos terminado? diríamos que más bien cojea un poco. Me he dado cuenta que depende de como crees la parte lógica de tu programa vas a tener problemas a la hora de querer hacerlo interactivo.

Esta semana ha sido hasta ahora la mejor de todas, más que nada porque nos han empezado ha hablar de como funciona el mundo web y unas pinceladas de HTML y CSS. Mi alegría viene porque he visto que el sacrificio que he realizado estos años picando desde la cueva han servido de algo.

Pero no todo es de color de rosas ya que 'yet another framework' y 'yet another BDD tool'

El framework es Sinatra basado en Ruby, decir que lo que hay que hacer es usarlo y usarlo para entender lo que hace. Había oído hablar de él pero nunca tuve tiempo de prestarle atención, ahora que veo como funciona es increíble, ver como enlazas Ruby con la web y como puedes obtener datos de los usuarios.

La nueva tool para testear BDD es Cucumber, lo mas fascinante es que se usa para testear el Front End de tus aplicaciones, si amigos el contenido web también se testea. Ya empiezo a tener la sensación de que si inicio un proyecto sin los tests es como si estuviera haciendo algo maligno.

Cucumber me ha encantado, tanto que he decidio hacer una Front End con Sinatra para el TwilioTakeaway para entenderlo aún más. El proceso es el mismo que RSpec, escribes el comportamiento que el usuario debería tener cuando usa tu app/web, el test falla por lo que te obliga a construir la estructura HTML que estas describiendo para pasar el test.

Desde mi punto de vista lo veo como un selector CSS al que le añades comportamiento.

El challenge de la semana consiste en hecer un Front End para el juego de piedra-papel-tijeras

Valoración final

Buahhh!!! la semana que viene ya estamos a mitad de curso. Por el momento me veo bien, la semana pasada tuve algún día de bajon pero en esta no, lo del grupo como que funcionó a medias ya que desde que se dijo que podíamos trabajar solos casi todos los grupos se disolvieron.

Que si pienso en mi futuro trabajo? no tengo tiempo para ello vivo en una zone donde solo estoy comiendo y viviendo código. Parezco un y-nq-- de conocimiento.

Semana 6

Databases and user management

Con el challenge de la semana pasada ya hemos empezado a usar Heroku para tener nuestros proyectos disponibles en internet, un poco confuso al principio pero nada imposible, es cuestión de prueba/error.

Esta es una de las semanas más importantes de todo el curso. Se aprende sobre usuarios, como gestionarlos y a manejar Bases de Datos. El proyecto semanal se basa en hacer un bookmark manager utilizando, RSpec, Capybara, Postgres, Ruby, HTML y CSS.

Como que soy un enamorado de CSS he decidido que a partir de este mismo instante voy a empezar a usar Sass (Syntactically Awesome Stylesheets) for every single project. Me estoy adelantando unas semanas pero si ya he utilizado una herramienta parecida (Stylus) y entiendo el quid de la cuestión, porque no?

Empezamos a hacer los tests de una manera híbrida entre RSpec y Capybara. Al principio me pensaba que Capybara era como un puro selector CSS al cual le añadimos tests. Tengo cierta razón pero una de las finalidades de Capybara es el poder enseñar los tests a personas del equipo sin ningún background en programación pero que sean capaces de entender que hace el proyecto. Al final en ciertos casos es mejor utilizar plain english antes que un selector CSS.

Para las bases de datos estamos utilizando Postgres que utiliza SQL. Desde siempre SQL me daba una sensación de tedioso/pesado, mi única experiencia (si es que se puede llamar así) se basada en haber utilizado wordpress y no me gustaba.

Ahora que lo he visto desde 0 tiene toda mi simpatia, a grandes rasgos consiste en crear tablas que contengan hileras con los datos que queremos alamacenar. Más tarde hay que ir creando otras tablas que nos servirán para explicar la relación que mantienen las tablas entre ellas.

Hemm!! Pero como podemos usar esas tablas en nuestro código escrito en ruby? Como no hay una ruby gem para eso y es increíblemente inteligente. Estaríamos hablando de una técnica llamada ORM(Object relational mapping), la cual convierte datos procedentes de diferentes sistemas a algún lenguaje de programación orientada a objetos.

Para comunicar bases de datos SQL con ruby tenemos DataMapper, su funcionalidad consiste en envolver nuestra DB con métodos escritos en ruby para así poder hacer CRUD (Create Read Update Destroy) con los datos de la DB.

Para que nos quede claro el concepto de la semana el challenge del fin de semana tenemos que hacer un clon de Twitter llamado Chitter, a ver que tal

Valoración semanal

Aunque la cosa se complica por segundos, cada día veo más cerca mi meta. He hecho tan bien de asistir a Makers.

Siento/percibo que gracias a mi determinación/perseverancia podré cambiar de professión al final del curso. Ahora que estamos haciendo Front-End veo que sé de lo que hablo por lo que me está dando bastante confianza.

No es por desanimar pero ahora que estoy en el ecuador del curso veo que hay ciertos alumnos que lo están pasando mal, con caras estresadas, githubs vacíos, cada día con nuevas tecnologías/lenguajes que pueden abrumar.....

Aún no tenemos desertores pero viendo que la semana que viene toca javascript (por fin!!), no me extrañaría que alguien se haga el harakiri.

Buahhh, Sass me ha encantado, creo que ya no podré dejar de usarlo, habrá alguna herramineta para testear CSS? seguro que sí.

Semana 7

Front-end technologies

La cohorte de Seniors ya se han graduado por lo que ahora somos nosotros. Este lunes empieza un nuevo grupo, half term uy uy uy!!!

Esta semana ha sido Front End puro y duro, estoy teniendo mucha confianza en los skills (que ya tenía) y los que voy cogiendo. Incluso he dado una charla sobre CSS, muy newbie pero al menos me quito las vergüenzas a mis 17 en cada pierna.

Por fin javascript!! El incomprendido, el que me ha abierto la puerta en este mundillo. Esta semana se han hecho 3 mini proyectos escritos en javascript, Rock-Paper-Scissors-Spock-Lizard, github-profiles y un termostato. Todos ellos han servido para empezar a testear javascript. Ahh! los tests, sí más tests pero en esta ocasión se hacen usando un BDD framework que se llama Jasmine.

También hemos aprendido a usar Mustache, un generador de html dinámico escrito en javascript. Con el proyecto Github hemos empezado a usar APIs y AJAX que viene a ser la piedra angular del internet, compatiendo información.

Cuesta un poco adaptar tu mente a todo este proceso de ir testando cada pedacito de código que escribes pero cuando lo piensas muy detenidamente te das cuenta de que siguiendo este patron estas creando software sin problemas, hay que decir que incluso escribiendo cada test en el momento de probar tu aplicación te sigues encontrando problemas, eso si seguro que muchísimos menos.

Esta semana me he liado un poco, me refiero a que tengo esta “mania” de intentar hacer más de lo que piden y en alguna ocasión he tenido que empezar de 0 porque era too much.

El challenge del fin de semana consiste en recrear la página de twitter.com, no es por alardear pero me ha salido muy pero que muy parecida. Para muestra un botón.

Twitter.com

ByverTweet.es

Available to be hired

Valoración semanal

En sí el curso es durillo pero no porque todo sea complicado sino porque te das un festín de conocimiento en un plazo muy corto de tiempo y asimilar todo ese contenido cuesta. Si no hubiera estado aprendiendo por mi cuenta estaría sufriendo de lo lindo.

Mi sensación? A modo personal buena pero el grupo que acaba de entrar son 28 personas (nosotros 24/23) y no se el porque pero estando en la oficina si miras al horizonte solo ves "gente nueva" y pocos sitios libres para sentarse. Por lo que si le añades que hay un profesor que esta semana ha dejado de trabajar y aún no hay reemplazo.... Do the maths!

Semana 8

Front-end technologies again!

Ya nos han avisado que el temario va cambiando en función de muchas cosas sin ir más lejos esta semana en vez de empezar con Ruby on Rails continuaremos con javascript y justamente toca Node.js

Será el destino pero cuando miraba al temario me preguntaba porque no nodejs? y tanto Ruby on Rails.

Nodejs una plataforma escrita enteramente en Javascript la cual nos permite construir aplicaciones rápidas y escalables. Node.js usa un modelo de I/O non- blocking por lo que le permite ser eficiente, ligero y perfecto para aplicaciones a tiempo real y las que requieren un alto consumo de datos.

Para poder usar nodejs, lo tendrás que instalar en tu ordenador, no entraré en detalles pero tan bien deberías de instalarte npm

Si en Ruby tenemos irb (interactive ruby) para poder jugar con el lenguaje con node.js tenemos REPL, para iniciar la consola interactiva tan solo hay que teclear node

La piedra angular de todo proyecto basado en nodeJs sería el archivo package.json. Con tan solo echarle un vistazo puedes adivinar de que se trata el proyecto:


{
  “name”: “MakersPost”,
  “version”: “0.0.1"
  “description”: “some silly project”
  “author”: “byverdu@gmail.com”,
  “scripts”: {
      “start”: “node app.js”,
  },
  “dependencies”: {
      “express”: “*”,
       “mocha”: “*”
  }
} 

Si vamos a usar un boilerplate generator este archivo y otros miles se generan solos por lo que uno puede empezar a trabajar casi instantáneamente, el problema sería que genera muchos archivos de los cuales puede que ni uses. En Makers nos intentan inculcar la idea de que lo más sencillo es lo que mejor funciona y bien cierto que es. Para que usar esos miles de archivos si depende de cual se tu proyecto ni los vas a usar.

Por ejemplo para crear un servidor en nodejs tan solo necesitas estas líneas de código:


// file saved as app.js

var http = require('http');
http.createServer(function (req, res) {
  res.writeHead(200, {'Content-Type': 'text/plain'});
  res.end('Hello World\n');
}).listen(1337, '127.0.0.1');
console.log('Server running at http://127.0.0.1:1337/');
// visit http://127.0.0.1:1337/

Tal y como ocurre con ruby tenemos disponibles unos cuantos frameworks con los que empezar a trabajar en nuestro proyecto. Podríamos decir que el más conocido es Express. Para node también tenemos generadores de plantillas (Jade), preprocesadores de CCS (Stylus) y prácticamente cualquier herramienta que exista en otros lenguajes de programación.

Para testear tus proyectos tenemos el framework mocha, el cual me ha dejado muy buen sabor de boca por ejemplo lo veo mucho más completo que Jasmine, está basado en nodejs y todo el proceso de testear se hace mediante el terminal, no como en Jasmine que debes de hacerlo a traves del navegador.


$ npm install -g mocha
$ mkdir test
$ $EDITOR test/test.js

var assert = require("assert")
describe('Array', function(){
  describe('#indexOf()', function(){
    it('should return -1 when the value is not present', function(){
      assert.equal(-1, [1,2,3].indexOf(5));
      assert.equal(-1, [1,2,3].indexOf(0));
    })
  })
})

$  mocha



  ✔ 1 test complete (1ms)

La verdad es que esta semana he hecho bastantes proyectos basados en node, una app para chatear a tiempo real usando websockets, una caja registradora y como no una re-edición del FizzBuzz.

También hemos tenido el placer de conocer a CoffeScript, un compilador para Javascript. Los cerebritos del curso se han puesto ha crear un editor de archivos online usando node pero escribiendolo en CoffeScript, la verdad 'Too deeper for me', entiendo el concepto detrás de CoffeSctipt pero empezar de esa forma es..... En si voy a empezar a usar CoffeScript para escribir my front end Javascript.

El challenge de la semana sería un refresco de todo lo aprendido en ruby.

Valoración semanal

Esto va viento en popa, empiezo a tener la sensación de que quiero que esto acabe pero quiero que el curso sea más largo, hay tanto que aprender!!

Esta semana hemos tenido la charla sobre la bolsa de trabajo que ofrece MakersAcademy. En sí para entrar en el sorteo debes de tener un Github implecable. Por ahora el mío es aceptable, de lo que si que estoy orgulloso por ahora es que llevo un streak de 45 días seguidos (Get a life mate!) y un total de 746 commits. Not bad viendo que hay gente de mi misma cohorte que no han llegado a los 100, os preguntaréis que han estado haciendo todas estas semanas?, yo me hago la misma pregunta pero al final, who cares?

Volviendo al tema de los trabajos, después de oir la charla creo que puedo encajar en este mundillo. Trabajar 50 horas semanales? Por dios si he estado toda mi vida currando más horas que esas en una cocina. Tal vez a alguien le pite los oídos pero por ahora veo esto como un "juego", pasarme el día delante del mac? solo es brain consuming.

Semana 9

Ruby on Rails

Thank good that I still alive. El cansancio empieza a hacer mella en el cuerpo, me siento bastante zombie picando teclas todo el santo día, el pero sería que voy en buen camino.

So, Ruby on Rails. Rails es un framework escrito en ruby que te permite hacer aplicaciones bastante rápido, interesante pero parece un caballo desbocado. Si, todo es como muy sencillo y mágico pero "behind the curtains" hay mucho trabajo hecho.

Por ejemplo para empezar una aplicación en Rails debes de trabajar un poco con el terminal.

rails new yelp_clone -d postgresql -T

# La opción -T desactiva la suite de tests 
# La opción -d te permite escoger la database 

Rails trabaja con ActiveRecord::Base

Active record pattern

In software engineering, the active record pattern is an architectural pattern found in software that stores its data in relational databases.

Los objetos Active Record no especifican sus atributos de manera directa, sino más bien toma los valores de la tabla de la DB a la cual estan enlazados. Añadir, remover o cambiar dichos atributos se hace directamente en la base de datos. Cualquier cambio es reflejado instatáneamente en los objetos de Active Record.

Para crear la base de datos para el proyecto con el que estamos trabajando tan solo debemos añadir estos comandos al terminal, como no Rails se encargará del resto.

 bin/rake db:create db:migrate # Creates DB
 bin/rake db:create RAILS_ENV=test # Test enviorenment

Voy a omitir el proceso de crear tests, pero que quede claro que uno debe de testear.

Ahora que ya tenemos la base de datos creada ya podemos ir añadiendo los controllers y models que necesitemos para hacer funcionar la aplicación.

Para ello debemos de utilizar los siguiente comandos:

bin/rails g controller restaurants
bin/rails g model restaurant name:string rating:integer 

Una vez generado el controller debes de añadir esa ruta (resources :restaurants) al archivo routes.rb.

Un comando muy interesante sería rake routes el cual te permite visualizar todas las rutas disponibles para ese controller, este sería un ejemplo:


restaurants GET /restaurants(.:format)          restaurants#index
            POST/restaurants(.:format)                restaurants#create
new_restaurant GET/restaurants/new(.:format)                             restaurants#new
edit_restaurant GET/restaurants/:id/edit(.:format)                        restaurants#edit
restaurant GET/restaurants/:id(.:format)                             restaurants#show
           PATCH/restaurants/:id(.:format)                             restaurants#update
           PUT/restaurants/:id(.:format)                             restaurants#update
           DELETE /restaurants/:id(.:format)                             restaurants#destroy

La verdad es que si miramos con detalle el output nos puede ayudar bastante a entender como Sinatra funciona.

Hay que ir con cuidado ya que un error en este paso hará que tengas información con errores ortográficos y te puedes volver algo loco.

El controller siempre en plural y el model en singular, para los model las posibles columnas de la DB se especifican name:string.

Siempre después de añadir o trabajar con la DB acuerdate de especificar esos cambios mediante db:migrate

Si queremos añadir alguna columna más a nuestro objeto ActiveRecord es tan sencillo como teclear este comando:

rails g migration AddAddressToRestaurants address:text
Con todo lo que hemos generado hasta ahora ya podemos empezar a tener algo decente con lo que trabajar. Para crear relaciones entre diferentes ActiveRecord de nuestra base de datos debemos de especificarlo via terminal.
bin/rails g controller reviews 
bin/rails g model review opinion:text rating:integer

# Este comando es el que crea la relación

bin/rails g migration AddRestaurantIdToReviews restaurant:belongs_to

Ahora lo que debes de especificar es esa relación con las rutas

resources :restaurants do 
  resources :reviews
end

No te olvides de db:migrate después de cada paso.

Lo genial de Rails es que ya hay muchas cosas predefinidas, por ejemplo para agregar la utenticación de usuarios tan solo debes de instalar una ruby gem, en este caso sería gem 'devise'.

Que quieres gestionar fotos gem 'paperclip' ;
Integración con Facebook gem 'omniauth' ;
Subir las fotos a Amazon gem 'aws-sdk' ;

Supongo que te haces una idea de lo sencillo que a priori parece. Digo a priori porque no todo es copy/paste ya que en algunos casos debes de indagar como hacer funcionar lo que quieres en tu App, pero con la documentación y Google llegarás lejos.

Podrá parecer lioso pero en un día puedes tener una app con cara y ojos.

Por fin terminé el challenge del Chitter (fake twitter), me ha costado lo mío pero después de haber visto Rails las ideas me quedaron un poco más claras.

Para esta semana el challenge sería hacer Instagram usando Rails.

Valoración semanal

Esto empieza a llegar a su fin, la semana que viene ya se escogen los proyectos finales y los grupos.

En mi caso estoy bastante al día con todo los proyectos que hemos realizado. La semana que viene tengo mi charla con los chicos que te buscan trabajo, a ver que tal.

Semana 10

More Ruby on Rails

Última semana de clases, es cuando el polluelo debe de empezar a intentar sus primeros vuelos fuera del nido. Dejando atrás las metáforas, en esta semana me va a dar tiempo de completar los proyectos que tengo atrasados y así empezar el proyecto con la sensación de tener los deberes hechos.

El miércoles será el día en que se presenten las ideas de los proyectos en los que vamos a trabajar por 2 semanas.

Sorpresa para esta semana, de miércoles a viernes vamos a girar las tuercas y haremos 3 languajes in 3 days.

Los dos primeros días de la semana han sido para ir consolidando los conocimientos en Rails haciendo Q&A sobre los diferentes problemas que uno se ha encontrado.

Mi problema sería Rails itself, bromas a parte he sido capaz de ”finalizar” yelp y sí es bastante asequible hacer una web app ya que gran parte del trabajo consiste en saber que Ruby gems vas a necesitar en tu proyecto y saber como integrarlas entre ellas.

Ahora puedo entender porque al Head coach no le gusta ni un pelo ya que no tienes la sensación de estar construyendo un proyecto sino más bien agregando cosas a cosas, por lo que podréis notar a mi tampoco me acaba. He llegado a la conclusión de que prefiero mil veces usar Sintatra, pero lo que realmente me gusta es node.js. No se, javascript me tiene robado el corazón.

Los 3 lenguajes en 3 días ha sido una buena experiencia, los elegidos han sido; meta-programming in ruby, io y clojure.

Como ya dije el miércoles ha sido el día de la presentación de los proyectos, como siempre algunos han sido muy estúpidos, otros imposibles y algunos espectaculares. El viernes se dirán los grupos de los proyectos finales.

De los 3 proyectos que se tenían que escoger mi primera elección era y ha acabado siendo Spark, es como un Arduino pero con la posibilidad de estar siempre conectado a los dispositivos mediante WIFI y así poder controlarlos.

En nuestro caso nos hemos decidido conectar una impresora y un lector de tarjetas RFID

Semana 11/12

Final project

Estas dos últimas semanas han sido para que te sumerjas en un simulacro de proyecto real el cual debes de acabar en 10 días, la presión está servida. Por suerte mi grupo es una buena combinación entre back end y front end por lo que todo ha ido bastante smooth. El último viernes es la presentación de los proyectos.

Valoración final del curso.

Estoy más que contento de haber hecho el curso, en si mis principales metas eran 2.

  1. Ver si era capaz de seguir el ritmo del curso.
  2. Conseguir mi soñado trabajo.

El primer punto lo he conseguido con creces, al terminar el curso he sido capaz de hacer todos los proyectos que me han mandado y a más a más hacer algunos personales. Mi cuenta de Github estaba ready to go.

El segundo punto estoy en ello, mi grata sorpresa fue que tan solo acabar la propia académia me ha contratado para que les implemente un diseño en su web. Por lo visto se me da bien el CSS3.

Mi satisfacción final sería del 80/20.

He aprendido muchísimo, cosas que por mi cuenta nunca hubiera sido capaz de entender o incluso imaginar. De la cosa que estoy más contento es de haber sido introducido en el mundo del Test Driven Development, dios que vicio que son los tests.

A partir de ahora solo concibo escribir código si antes ha sido testeado, se que en algunos casos los tests son falsos positivos y ando haciendo algunas trampillas para que salgan en verde pero es tan solo cuestión de tiempo.

Ten una cosa clara, no por pagar vas a acabar con un trabajo. Tienes que dedicarle muchas horas, en mi caso han sido entre 8/12 horas diarias, poco dormir, picar mucho código, ver mucha información nueva a diario.... Como puedes ver no es sencillo pero tampoco imposible.

Dadícale el 100% de tu tiempo desde el primer día, habrá a gente que le funcione pero en mi caso he necesitado get into the zone casi cada día, por lo que he socializado bien poco con tal de deicarle todo lo posible (también soy un bicho raro).

Ha habido gente en mi curso que más bien se han dedicado a socializar y a esperar a que suene la campana, la cual creo que no suene. Un reflejo de que hayas conseguido tu meta va a ser como termina tu cuenta de Github. Si son 3 meses de curso como mínimo deberías tener unos 500/600 commits.

Para muestra un botón, mi cuenta después de un mes de haber acabado MakersAcademy:

No me gusta compararme con la demás gente pero he acabado entre la posición 5-10 de 24 contendientes, not bad for my age.

Te consiguen trabajo? Si pero tampoco dependas de ello como tu principal fuente de búsqueda y muevete por tu cuenta, piensa que al final de cada grupo hay como 20 personas que quieren su soñado trabajo por lo que la competición es férrea aunque se diga que allí no vas a competir.

Para que te busquen trabajo debes de tener tu Github impecable y con todos los proyectos terminados, en mi caso así ha sido por lo que allí estoy.

Por ejemplo hasta ahora (19-11-14), he realizado 5 entrevistas por teléfono y todas han sido gracias a mi esfuerzo y búsqueda. Bloody phone interviews. En tres de ellas he pasado la primera criba :), que vendría a ser la propia entrevista por teléfono. Pero en si todo apunta bien.

Cuales son mis pegas? Ya he vivido este tipo de Booms para una escuela, me ocurrió cuando fuí a la escuela de hostelería en Barcelona.

Me explico, aunque su meta sea enseñar tienen que hacer dinero con ello. Si quieres tener más alumnos porque no das avasto con las solicitudes piensa en equilibrar ese número extra de alumnos con más profesores y un espacio mayor para meter a la jauría.

Hablando de jauría, a veces más que personas somos animales y eso se ha visto reflejado en algunos. A veces la oficina es muy ruidosa y la gente muy incívica pero la verdad esto es algo que la propia académia no puede controlar.

A día de hoy se que a finales de año se mudan a una nueva oficina y que ya tienen más ayudantes, pero en mi caso no me sirve porque ya he terminado.

Aunque tenga mis pegas he acabado muy contento, reitero que no por pagar vas a conseguirlo y que debes de dedicarle muchas horas.

Después de 5680 palabras puedo dar por terminado el post.

6/2/2015

Albert como que te olvidabas decir que has conseguido tu trabajo de programador, al final gracias a la académia por lo que estoy más que agradecido. En 2015 empieza una mueva etapa de mi vida.

Stay tunned!

Recursos de interes:

http://byverdu.es/recursos-online-para-aprender-a-programar-como-codecademy-y-treehouse/

http://byverdu.es/que-es-un-programming-bootcamp-vale-la-pena-como-asistir-a-uno-y-no-morir-en-el-intento/

Otra entrada interesante que eplica los pasos a seguir para ser developer. https://websitesetup.org/become-web-developer/

comments powered by Disqus