02-getting-started.md.erb

---
title: Empezando
slug: getting-started
date: 0002/01/01
number: 2
points: 1
photoUrl: http://www.flickr.com/photos/ikewinski/9511230392/
photoAuthor: Mike Lewinski
contents: "Instalaremos Meteor.|Conoceremos los 5 tipos de paquetes que maneja Meteor.|Estableceremos la estructura de ficheros de nuestra aplicación."
paragraphs: 49
---

Las primeras impresiones son las que cuentan. La instalación de Meteor debería ser muy sencilla y, en la mayoría de los casos, sólo cuesta 5 minutos ponerlo en marcha.

Para empezar, si estamos usando Mac OS o GNU/Linux, podemos instalar Meteor con el siguiente comando desde la consola:

~~~bash
curl https://install.meteor.com | sh
~~~

Si estás usando Windows, echa un vistazo a la guia oficial de instalación: [install instructions](https://www.meteor.com/install) en la web de Meteor. 

Se instalará el ejecutable `meteor` en nuestro sistema y lo dejará listo para empezar a usar Meteor.

<% note do %>

### *Sin* instalar Meteor

Si no podemos (o no queremos) instalar Meteor de forma local, recomendamos usar [Nitrous.io](http://nitrous.io/).

Nitrous.io es un servicio que te permite ejecutar aplicaciones y editar el código directamente en tu navegador, y hemos escrito una breve guía para ayudarte a ponerte en marcha.

Sólo tienes que seguir [esta guía](https://www.discovermeteor.com/blog/meteor-nitrous) hasta completar la sección "Installing Meteor", y luego seguir con este capítulo a partir de la sección "Crear y ejecutar una aplicación".

<% end %>

### Creando una simple aplicación

Ahora que tenemos instalado Meteor, vamos a crear nuestra aplicación. Para ello, utilizaremos la herramienta de línea de comandos `meteor`:

~~~bash
meteor create microscope
~~~

Este comando crea un proyecto básico listo para usar. Cuando termina, deberíamos ver un directorio llamado `microscope/`, que contiene lo siguiente:

~~~bash
.meteor
microscope.css
microscope.html
microscope.js
~~~

La aplicación que se ha creado es una aplicación básica que demuestra sólo algunas sencillas pautas.

A pesar de que nuestra aplicación no hace casi nada, ya podemos ejecutarla. Para hacerlo, volvemos al terminal y escribimos:

~~~bash
cd microscope
meteor
~~~

Ahora abrimos `http://localhost:3000/` (o su equivalente `http://0.0.0.0:3000/`) en el navegador y deberíamos ver algo como esto:

<%= screenshot "2-1", "Hello World de Meteor" %>

<%= commit "2-1", "Un proyecto básico." %>

¡Enhorabuena! ya tenemos nuestra primera aplicación Meteor funcionando. Por cierto, para parar la aplicación, todo lo que hay que hacer es abrir la pestaña terminal donde se ejecuta y pulsar `ctrl+c`.

Si estás utilizando Git, este sería un buen momento para iniciar el repositorio con `git init`.

<% note do %>

### Bye Bye Meteorite

Hubo un tiempo en el que Meteor utilizaba un gestor de paquetes externo llamado Meteorite. Desde la versión 0.9.0 de Meteor, Meteorite ya no es necesario, ya que sus características se han incorporado a Meteor.

Así que si encuentras referencias a `mrt` de Meteorite a lo largo de este libro o mientras lees material relacionado con Meteor, puedes reemplazarlo con total seguridad por el habitual `meteor`.

<% end %>

### Añadir un paquete

Ahora vamos a usar el sistema de paquetes de Meteor para incluir el framework [Bootstrap](http://twitter.github.com/bootstrap/) en nuestro proyecto:

Esto no es distinto de añadir Bootstrap de la forma habitual, incluyendo manualmente los ficheros CSS y JavaScript, excepto en que confiamos en el mantenedor del paquete para que lo mantenga actualizado para nosotros.

Ya que estamos, añadiremos también el paquete [Underscore](http://underscorejs.org/). Underscore es una librería de utilidades JavaScript, y es muy útil cuando necesitemos manipular estructuras de datos.

El paquete `bootstrap` lo mantiene el usuario `twbs`, por lo que el nombre completo del paquete es `twbs:bootstrap`.

El paquete `underscore` forma parte de los paquetes "oficiales" incluidos en Meteor, lo que quiere decir que no hay que incluir el nombre del autor:

~~~bash
meteor add twbs:bootstrap
meteor add underscore
~~~

Fíjate que estamos añadiendo Bootstrap **3**. Algunas de las capturas de este libro están tomadas de una versión antigua de Microscope con Bootstrap **2**, por lo que podrían parecer ligeramente diferentes.

<%= commit "2-2", "Añadido el paquete bootstrap." %>

Tan pronto como agregues el paquete Bootstrap, deberías notar un cambio en el aspecto de nuestra aplicación:

<%= screenshot "2-1b", "Con Boostrap." %>

Al contrario de la forma “tradicional” en la que incluimos recursos externos, no tenemos que agregar enlaces a ningún fichero CSS o JavaScript, ¡porque Meteor lo hace por nosotros! Esta es sólo una de las muchas ventajas de los paquetes Meteor.

<% note do %>

### Una nota sobre los paquetes

Al hablar acerca de los paquetes en el contexto de Meteor, vale la pena ser específico. Meteor puede usar cinco tipos básicos de paquetes:

- El mismo núcleo de Meteor está dividido en diferentes **paquetes de la plataforma Meteor**. Están incluidos en cada app y probablemente nunca tengas que preocuparte por ellos.
- Los paquetes ordinarios se conocen como "**isopacks**", o paquetes isomórficos (paquetes que funcionan en los dos lados, cliente y servidor). Los paquetes **First-party**, como `accounts-ui` o `appcache`, están mantenidos por los desarrolladores de Meteor y [vienen incluidos en Meteor](http://docs.meteor.com/#packages).
- Los **paquetes de terceros** son paquetes isopacks que otros usuarios han subido al servidor de paquetes de Meteor. Puedes echarles un vistazo en [Atmosphere](http://atmosphere.meteor.com) o con el comando `meteor search`.
- Los **paquetes locales** son paquetes personalizados que puedes crear tu mismo y colocarlos en el directorio `/packages`.
- Los **paquetes NPM** (Node.js Packaged Modules) son paquetes de Node.js. A pesar de que no funcionan por defecto con Meteor, *pueden* ser utilizados por los tipos de paquete anteriores.

<% end %>

### La estructura de una aplicación Meteor

Antes de empezar a escribir código debemos estructurar de forma adecuada nuestro proyecto. Para asegurarte de que dispones de un entorno limpio y claro, abre el directorio `microscope` y borra los archivos `microscope.html`, `microscope.js`, y `microscope.css`.

A continuación, crea cuatro directorios dentro de `/microscope`: `/client`, `/server`, `/public` y `/lib`.

Ahora, crearemos dos archivos vacíos `main.html` y `main.js` dentro de `/client`. Por ahora, no te preocupes si esto rompe completamente la app, empezaremos a rellenar los nuevos ficheros en el siguiente capítulo.

Debemos mencionar que algunos de los directorios que hemos creado son especiales y Meteor tiene reglas para ellos:

- El código de `/server` se ejecuta en el servidor.
- El código de `/client` se ejecuta en el cliente.
- Todo lo demás se ejecuta en las dos partes, cliente y servidor.
- Las cosas estáticas (fuentes, imágenes, etc.) van en el directorio `/public`.

Y también es útil saber como Meteor decide en que orden cargan los ficheros:

- Los archivos de `/lib` se cargan antes que nada.
- Los archivos con nombre `main.*` se cargan *después* que todos los demás.
- Todo se carga por orden alfabético según el nombre del fichero.

Ten en cuenta que aunque Meteor tiene todas estas reglas, en realidad no nos obliga a utilizar una estructura de archivos predefinida. Así que la estructura que sugerimos es sólo nuestra forma de hacer las cosas, no son reglas inamovibles.

Os animamos a echar un vistazo a la [documentación oficial Meteor](http://docs.meteor.com/#structuringyourapp) para conocer más detalles acerca de la estructura de las aplicaciones.

<% note do %>

### ¿Meteor es MVC?

Si hemos usado otros frameworks, como Ruby on Rails, puede que nos preguntemos si las aplicaciones de Meteor adoptan el patrón [MVC](http://es.wikipedia.org/wiki/Modelo_Vista_Controlador) (Model View Controller).

La respuesta corta es no. A diferencia de Rails, Meteor no impone ninguna estructura predefinida para su aplicación. Así que en este libro vamos a exponer código de la forma que más sentido tenga para nosotros, sin preocuparnos demasiado por las siglas.

<% end %>

### ¿Público?

Bueno, mentimos. En realidad no vamos a necesitar `public/` por la sencilla razón de que Microscope no utiliza ningún archivo estático. Pero como en la mayoría de aplicaciones se van a incluir al menos un par de imágenes, pensamos que era importante incluirlo.

Por cierto, te puedes haber dado cuenta de que se ha creado un directorio oculto llamado `.meteor`. Aquí es donde Meteor almacena su propio código. Cambiar cosas aquí dentro es, en general, una muy mala idea con las únicas excepciones de los archivos `.meteor/packages` y `.meteor/release`, que se utilizan, respectivamente, para listar nuestros paquetes y para establecer la versión de Meteor que queremos utilizar.

<% note do %>

### Underscores vs CamelCases

Lo único que vamos a decir sobre el viejo debate del guión bajo (`my_variable`) contra el camelCase (`myVariable`) es que en realidad no importa el que elijas, siempre y cuando lo adoptes en todo el proyecto.

En este libro, utilizamos camelCase porque es la forma habitual en JavaScript (después de todo, es JavaScript no java_script!).

Las únicas excepciones a esta regla son los nombres de los archivos, para los que se van a utilizar guiones bajos (`my_file.js`), y las clases CSS, para las que usaremos guiones (`.my-class`). La razón es que en el sistema de archivos, el subrayado es lo más común, mientras que en la propia sintaxis, CSS ya utiliza guiones (`font-family`, `text-align`, etc).

<% end %>

### El CSS de nuestra aplicación

Este libro no trata sobre CSS. Así que para evitar entrar en detalles de estilo, hemos decidido que la hoja de estilos esté disponible desde el principio, así, no será necesario preocuparse por ella nunca más.

Meteor carga el CSS minimizado y de forma automática, por lo que, a diferencia de otros recursos estáticos, va en `/client`, no en `/public`. Vamos a crear el archivo `client/stylesheets/style.css` y a añadirle este CSS:

~~~css
.grid-block, .main, .post, .comments li, .comment-form {
  background: #fff;
  border-radius: 3px;
  padding: 10px;
  margin-bottom: 10px;
  -webkit-box-shadow: 0 1px 1px rgba(0, 0, 0, 0.15);
  -moz-box-shadow: 0 1px 1px rgba(0, 0, 0, 0.15);
  box-shadow: 0 1px 1px rgba(0, 0, 0, 0.15); }

body {
  background: #eee;
  color: #666666; }

#main {
  position: relative;
}
.page {
  position: absolute;
  top: 0px;
  width: 100%;
}

.navbar {
  margin-bottom: 10px; }
  /* line 32, ../sass/style.scss */
  .navbar .navbar-inner {
    border-radius: 0px 0px 3px 3px; }

#spinner {
  height: 300px; }

.post {
  /* For modern browsers */
  /* For IE 6/7 (trigger hasLayout) */
  *zoom: 1;
  position: relative;
  opacity: 1; }
  .post:before, .post:after {
    content: "";
    display: table; }
  .post:after {
    clear: both; }
  .post.invisible {
    opacity: 0; }
  .post.instant {
    -webkit-transition: none;
    -moz-transition: none;
    -o-transition: none;
    transition: none; }
  .post.animate{
    -webkit-transition: all 300ms 0ms;
    -moz-transition: all 300ms 0ms ease-in;
    -o-transition: all 300ms 0ms ease-in;
    transition: all 300ms 0ms ease-in; }
  .post .upvote {
    display: block;
    margin: 7px 12px 0 0;
    float: left; }
  .post .post-content {
    float: left; }
    .post .post-content h3 {
      margin: 0;
      line-height: 1.4;
      font-size: 18px; }
      .post .post-content h3 a {
        display: inline-block;
        margin-right: 5px; }
      .post .post-content h3 span {
        font-weight: normal;
        font-size: 14px;
        display: inline-block;
        color: #aaaaaa; }
    .post .post-content p {
      margin: 0; }
  .post .discuss {
    display: block;
    float: right;
    margin-top: 7px; }

.comments {
  list-style-type: none;
  margin: 0; }
  .comments li h4 {
    font-size: 16px;
    margin: 0; }
    .comments li h4 .date {
      font-size: 12px;
      font-weight: normal; }
    .comments li h4 a {
      font-size: 12px; }
  .comments li p:last-child {
    margin-bottom: 0; }

.dropdown-menu span {
  display: block;
  padding: 3px 20px;
  clear: both;
  line-height: 20px;
  color: #bbb;
  white-space: nowrap; }

.load-more {
  display: block;
  border-radius: 3px;
  background: rgba(0, 0, 0, 0.05);
  text-align: center;
  height: 60px;
  line-height: 60px;
  margin-bottom: 10px; }
  .load-more:hover {
    text-decoration: none;
    background: rgba(0, 0, 0, 0.1); }

.posts .spinner-container{
  position: relative;
  height: 100px;
}

.jumbotron{
  text-align: center;
}
.jumbotron h2{
  font-size: 60px;
  font-weight: 100;
}

@-webkit-keyframes fadeOut {
  0% {opacity: 0;}
  10% {opacity: 1;}
  90% {opacity: 1;}
  100% {opacity: 0;}
}

@keyframes fadeOut {
  0% {opacity: 0;}
  10% {opacity: 1;}
  90% {opacity: 1;}
  100% {opacity: 0;}
}

.errors{
  position: fixed;
  z-index: 10000;
  padding: 10px;
  top: 0px;
  left: 0px;
  right: 0px;
  bottom: 0px;
  pointer-events: none;
}
.alert {
          animation: fadeOut 2700ms ease-in 0s 1 forwards;
  -webkit-animation: fadeOut 2700ms ease-in 0s 1 forwards;
     -moz-animation: fadeOut 2700ms ease-in 0s 1 forwards;
  width: 250px;
  float: right;
  clear: both;
  margin-bottom: 5px;
  pointer-events: auto;
}
~~~
<%= caption "client/stylesheets/style.css" %>

<%= commit "2-3","Estructura de ficheros reorganizada." %>

<% note do %>

### Una nota sobre CoffeeScript

En este libro vamos usar JavaScript puro. Pero si quisiéramos usar CoffeeScript, bastaría con añadir el paquete CoffeeScript y estaríamos listos para continuar:

`meteor add coffeescript`

<% end %>