Archive | November 2013

Growth Hackers: la evolución del marketing digital

¿De qué te sirven esos 10 mil followers o esos 5000 likes si no sabes cómo usarlos para hacer crecer tu negocio? Para salvar al mundo de la #amenaza#de#los#hashtags, los likes y los retuits han llegado los Growth Hackers.

Esta es una posición casi desconocida en las startups latinas, pero en el mágico mundo de Silicon Valley es normal tener a uno de estos genios del marketing online, que no se quedaron en la vieja escuela del mercadeo, escribiendo publirreportajes para hablar genialidades de tu empresa (que no creerían ni tus parientes que tanto te quieren y desean que tu negocio crezca mucho) o inventando tuits divertidísimos para que tengas la fortuna de leerlos -incluso en domingo- mientras recuerdas lo triste que es vivir.

Los Growth Hackers representan la evolución del marketing digital actual: son los encargados de que tus cifras crezcan y generen conversiones. Profesionales del mercadeo, obsesionados por los datos, por segmentar a tu público, entender sus motivaciones, y crear nuevos productos: algo así como unos antropólogos geeks.

¿Cómo reconocer a un Growth Hacker?

¿Y si te da por hacernos caso y empezar a buscar a un Growth Hacker para ponerlo a trabajar en tu startup?

¿Cómo diferenciarlo de un mono?

Tiene menos vello corporal y un IQ con 100 puntos más. Antes que nada exígele hacer una prueba online de inteligencia.

¿Cómo diferenciarlo de un asesino serial?

Practícale el test de Rorschach. Si en todas las figuras ve métricas, números creciendo y conversiones, y tiene la palabra tráfico tatuada en la frente, no es un asesino serial, ni el hombre al que buscan los de Criminal Minds. Es un Growth Hacker.

¿En qué se diferencian de Claude Lévi-Strauss?

Hacen antropología y se interesan por las motivaciones humanas, pero les gusta hacerlo con datos que analizan con ayuda de computadores y de Internet: son geeks humanos, demasiado humanos, que quieren entender por qué haces lo que haces en la red y usarlo en beneficio del negocio.

¿Cómo lo diferencias de un community manager?

Su trabajo no se limita a generar reportes, crear y mantener conversaciones en redes sociales. No son gerentes ni administradores de comunidades. Él hablará de crecimiento de métricas específicas y tendrá ideas acerca de cómo convertirlas en dinero o negocios, o cómo conducir a tus usuarios a una nueva etapa de crecimiento. Los reportes de viernes llenos de gráficas y los vanity metrics no están en su léxico.

¿Cómo lo diferencias de un robot?

Si sus ojos brillan cada vez que le hables de analizar el comportamiento de tus usuarios en tu sitio o en tus redes no es un robot. Sienten verdadera pasión por los datos, por rastrear y mejorar las métricas.

Algunas técnicas usadas por los Growth Hackers

  • Aplicar las sagradas reglas del SEO: crear sitios muy bien estructurados para que Google no pueda resistirse a amarlos.
  • Segmentación y creación de comunidad: crear comunidades en redes sociales segmentando al público desde el comienzo. Si vendes pizzas, empieza por buscar a toda la gente que ama la pizza: es muy simple.
  • Standing on the shoulders of giants: mientras se consolida tu comunidad puedes buscar apoyo de comunidades con varios millones de fans, views, o followers. Una inversión de dinero para que mucha gente te conozca parece una buena idea para empezar.
  • Personalización de emails: de acuerdo a la acción que cada usuario ejecute en tu sitio. Generan muchas conversiones y tráfico de retorno. Algunos servicios que puedes usar son customer.io, mailgun.com o Mailchimp.
  • Mantener un blog: en el que hablas de diferentes temas siempre en relación con el core de tu negocio, pero que cuenten historias y enganchen a tu público. Créenos, un blog que logra generar vínculos con su público puede convertirse en la mejor forma de analizar a tus clientes.

¿Por qué deberías preferir los servicios de un Growth Hacker antes que los de un Community Manager? Sencillo: porque analiza e interpreta los datos. Y lo más importante: sabe cómo usarlos.

Si quieres enterarte más puedes ver este vídeo:

Enviar comentario

via Cristalab http://feeds.cristalab.com/~r/clab/~3/XIoNzRachfU/

Configurar Base de Datos y crear tablas con Laravel

En los tutoriales anteriores, vimos una introdución al framework Laravel y aprendimos cómo instalar Laravel y Composer. De ahora en adelante comenzaremos un tutorial teórico – práctico de Laravel.

Crear un módulo de Usuarios con Laravel

Si bien no es el módulo más emocionante del mundo, lo considero práctico dado que hace falta en la mayoría de las aplicaciones. Para comenzar, necesitamos configurar nuestra base de datos y crear la tabla de usuarios.

Cómo configurar la base de datos en Laravel

Lo haremos en cuatro sencillos pasos:

1 – Abrimos el archivo database.php localizado en:

Código :

app/config/database.php

2 – En la línea 29, encontraremos lo siguiente:

Código :

'default' => 'mysql'

Si estamos trabajando con MySQL, como es mi caso, dejaremos la línea intacta, sino editaremos el valor entre comillas a sqlite, pgsql, etc. según sea el caso.
[nota:d297ccd53a]Entre las bases de datos soportadas por defecto en Laravel encontramos: MySQL, SQL Lite, PostgreSQL y SQL Server.[/nota:d297ccd53a]

3 – Usamos PHPMyAdmin o cualquier otra herramienta de nuestra preferencia para crear la base de datos, en mi caso, con PHPMyAdmin y MySQL crearé una DB llamada “pruebalaravel”:

Código :

CREATE DATABASE `pruebalaravel` ;

4 – Una vez creada la DB debemos indicarle a Laravel el nombre de nuestra base de datos y un usuario con acceso a ella, para MySQL tenemos en el mismo archivo database.php lo siguiente (línea 55):

Código :

      'mysql' => array(
         'driver'    => 'mysql',
         'host'      => 'localhost',
         'database'  => 'pruebalaravel',
         'username'  => 'root',
         'password'  => 'CLAVE_ULTRA_SECRETA',
         'charset'   => 'utf8',
         'collation' => 'utf8_unicode_ci',
         'prefix'    => '',
      ),

Allí cambiamos ‘database’ por el nombre de nuestra base de datos:

Código :

'database'  => 'pruebalaravel',

Y más abajo el usuario que hayan configurado cuando instalaron MySQL, comúnmente ‘root’, luego, en la línea siguiente, el password que dependiendo de su instalación pudiese estar en blanco o ser una clave ultra secreta.

Una vez configurada la DB, veamos:

Cómo crear las tablas en la base de datos con Laravel

Para ello usaremos migraciones.

Las migraciones permiten configurar y modificar la estructura de una base de datos. Creando una especie de “control de versiones” de base de datos que puede ser usada por una o más personas dentro del equipo de desarrollo.

Por ejemplo:

  1. Inicialmente crearemos una tabla llamada “users”.
  2. En unas semanas necesitaremos otra tabla llamada “tasks”.
  3. Luego agregaremos un campo adicional llamado “role” en la tabla “users” para dividir los administradores de los usuarios normales.

Cada uno de estos pasos implicará crear una migración diferente con la que el framework sabrá cómo modificar la base de datos, tanto hacia el nuevo esquema (del paso 1 al paso 2) como al esquema anterior (por ejemplo: de vuelta al paso 2 desde el paso 3).

Ahora veamos:

Cómo instalar el sistema de migraciones en Laravel

Abrimos nuestra consola o terminal (recuerden usar la consola instalada por GIT si usan Windows) y tipeamos lo siguiente:

Código :

php artisan migrate:install

[nota:d297ccd53a]Artisan es la interface de comandos de consola que trae Laravel[/nota:d297ccd53a]

Si configuramos bien la base de datos deberíamos recibir el siguiente mensaje:

Código :

Migration table created successfully

(Sino recibes este mensaje, vuelve al punto anterior sobre configurar la base de datos y revisa que todo esté bien)

¿Tabla de migración creada con éxito?
Sí, si vuelves a tu herramienta de base de datos (ej. PHPMyAdmin) verás la siguiente tabla:

Esta es una sencilla tabla que usa Laravel para conocer el estado de la migración en tu servidor, por ahora está vacía.

Siguiente paso:

Crear nuestra primera migración con Artisan y Laravel

Para ello ejecutamos el siguiente comando:

Código :

php artisan migrate:make create_user_table

Si todo salió bien, recibiremos un mensaje similar a éste:

Código :

Created Migration: 2013_09_03_211545_create_user_table
Generating optimized class loader

El primer mensaje (migración creada…) nos indica que fue creado el archivo donde vamos a:

Crear el esquema de nuestra tabla usando el Schema Builder

Abrimos el archivo localizado en:

Código :

app/database/migrations/2013_09_03_211545_create_user_table.php

[nota:d297ccd53a] El nombre del archivo además de lo especificado por nosotros (create_user_table) contiene una fecha/hora que permite indicarle al framework el orden en que fueron creadas las migraciones, en mi caso 2013_09_03_21…[/nota:d297ccd53a]

Ok, abrimos el archivo, tenemos la siguiente estructura:

Código :

<?php

use Illuminate\Database\Migrations\Migration;

class CreateUserTable extends Migration {

   /**
    * Run the migrations.
    *
    * @return void
    */
   public function up()
   {
      //
   }

   /**
    * Reverse the migrations.
    *
    * @return void
    */
   public function down()
   {
      //
   }

}

Básicamente tenemos una clase llamada CreateUserTable y dentro tiene dos métodos up and down.

El método up servirá, en este caso, para definir nuestra tabla, reemplacemos el método vacío por lo siguiente:

Código :

/**
 * Run the migrations.
 *
 * @return void
 */
public function up()
{
        Schema::create('users', function($table)
        {
            $table->increments('id');
            
            $table->string('email');
            $table->string('password');
            $table->string('full_name');
            
            $table->timestamps();
        });
}

Dentro tenemos un llamado al [url=http://es.wikipedia.org/wiki/Facade_(patr%C3%B3n_de_dise%C3%B1o)]facade[/url] Schema::create que nos permite crear el esquema de una tabla usando una interfaz de PHP orientada a objetos, es decir, como si nuestra tabla fuera un objeto.

Schema::create acepta como primer parámetro el nombre de nuestra tabla, en este caso: “users”

El segundo parámetro es una closure o función anónima al cual se le inyecta el objeto $table, dicho objeto nos permitirá definir los campos de nuestra tabla, por ejemplo:

Código :

$table->increments('id');

Le dice a Laravel que nuestra tabla tendrá un campo de tipo auto incremento llamado id, el cual es muy común en MySQL.

Luego le decimos a Laravel que necesitamos un campo string llamado email:

Código :

$table->string('email');

Pero en MySQL no existe el campo de tipo “string”…

Laravel se encarga de ello convirtiendo al tipo adecuado de acuerdo a la base de datos que hayamos configurado al principio, en el caso de MySQL nuestro campo resultante será de tipo VARCHAR.

Lo mismo para password y full_name, al final tenemos lo siguiente:

Código :

$table->timestamps();

¿?

Básicamente este método le dice a Laravel que queremos crear 2 campos, uno llamado “created_at” y otro “updated_at” ambos de tipo TIMESTAMP que servirán para saber cuando fue creado o modificado cada uno de los registros de nuestra tabla.

Ok, ¿Están listos? Vamos a ejecutar la migración: vamos de nuevo a la consola y escribimos lo siguiente:

Código :

php artisan migrate

Si todo salió bien recibiremos un mensaje así:

Código :

Migrated 2013_..._create_user_table

Ahora corremos a ver el PHPMyAdmin y…

Voilà!

Sé que están emocionados con nuestra nueva tabla, pero -aunque suene doloroso- tendremos que deshacernos de ella, no se preocupen, crearemos una nueva más tarde y nadie notará la diferencia:

Reemplacemos el método down por lo siguiente:

Código :

   /**
    * Reverse the migrations.
    *
    * @return void
    */
   public function down()
   {
      Schema::drop('users');
   }

Sí:

Código :

Schema::drop('users');

Es el fatídico método que eliminará nuestra recién creada tabla users, ahora tomen valor y escriban en la consola:

Código :

php artisan migrate:rollback

Recibiremos el siguiente mensaje:

Código :

Rolled back: 2013...create_user_table

Indicándonos que migración se ha descartado. Corremos a PHPMyAdmin pero nuestra tabla users… no está, it’s gone… Se ha ido.

¡No puede ser!

Rápidamente regresamos a la consola y tipeamos de nuevo:

Código :

php artisan migrate

Volvemos a PHPMyAdmin y ¡Nuestra tabla users está de nuevo con nosotros! Déjenla allí por ahora, la necesitaremos en un próximo tutorial.

Además de agregar drama a nuestra vida, el rolled back sirve tanto si cometimos un error definiendo una tabla, como si queremos regresar nuestra base de datos a un estado anterior. Más adelante aprenderemos un poco más sobre las migraciones en Laravel.

Es todo por ahora ¿Qué les pareció el tutorial? Cuéntanos en los comentarios. Además me gustaría saber si quieren que les explique un poco más sobre programación orientada a objetos en PHP 5.3, por ejemplo: ¿Qué es un namespace? En un próximo tutorial.

[nota:d297ccd53a]Usa los enlaces claves dentro del mismo tutorial para descubrir artículos interesantes relacionados con el tema.[/nota:d297ccd53a]

Espero les haya gustado esta tercera parte, nos vemos en los comentarios y en la siguiente entrega.

Saludos a todos

Enviar comentario

via Cristalab http://feeds.cristalab.com/~r/clab/~3/6LDpmUBw2kg/

Porqué elegir Laravel en vez de Codeigniter

Empezar a programar con PHP nunca ha sido sencillo. El sitio oficial tiene una documentación muy completa de todas las funcionalidades del lenguaje, sin embargo, no es un buen punto de partida para aprender a hacer algo funcional, por ejemplo un módulo con PHP.

Empezando mi carrera autodidacta para ser desarrollador web, recuerdo que imprimí TODA la documentación de PHP y la leí completa durante unas vacaciones.

Hice lo mismo con la documentación de MySQL. Al final no sabía hacer NADA.

[nota:daad7b1aed]Sí me sirvió de referencia aprender qué hacían las funciones del lenguaje, aunque hoy en día sigo consultando el sitio a menudo.[/nota:daad7b1aed]

Entonces comencé a buscar tutoriales más prácticos de PHP. Por ejemplo las memorias de un aprendiz. ¿Alguien lo recuerda?

Pero hoy en día si quieres trabajar con PHP además tienes que:

Elegir el Framework adecuado

Esto quiere decir que tenga:

  1. Un desarrollo activo: te garantiza corrección de problemas de seguridad, mejoras, etc.
  2. Una comunidad activa: la vas a necesitar cuando no sepas cómo hacer algo.
  3. Buena documentación: puede ser el mejor framework del mundo pero si nadie sabe cómo usarlo no sirve de nada.

Pero la mayoría de los frameworks ya tienen eso: Symfony, Codeigniter, Laravel, entre otros, entonces:

¿Cuál framework elegir?

Hace unos años atrás era una respuesta difícil, mi decisión estaba entre Symfony y Codeigniter, a mí me gustaba más Symfony pero mi equipo de trabajo prefería el segundo.

Symfony era y sigue siendo complejo, muy difícil de aprender, por otro lado, CodeIgniter muy fácil de aprender porque es muy simple, carece de muchas utilidades necesarias en un verdadero framework.

[nota:daad7b1aed]En Symfony 1.4 gastaba el 80% del tiempo investigando cómo hacer algo y corrigiendo bugs y el 20% ejecutando, mientras que en CodeIgniter solo 20% investigando pero 80% ejecutando.[/nota:daad7b1aed]

De vuelta al 2013

Hoy en día Symfony 2 es el framework para PHP más robusto que existe, Fabien Potencier, su creador, es una máquina escribiendo código. Es increíble tener en PHP componentes como el DOM crawler (disponible también en Laravel) que te permite recorrer y revisar desde PHP el código HTML como lo harías con Firebug y eso se lo debemos a Fabien.

Sin embargo, Symfony parece no estar escrito para seres humanos. Sólo algunos pocos privilegiados son capaces de aprovechar todo su potencial.

Lo que hace que muchos se hayan ido a CodeIginter, pero…

Porqué elegir Laravel en vez CodeIgniter

CodeIgniter no ofrece nada más allá de sencillez, después de leerte su documentación en un día y tener que enfrentarte a las necesidades de un proyecto real quedas en frente de una carpeta de modelos vacía preguntándote ¿Y ahora qué? Es allí donde:

  • Si eres experto, instalas plugins o construyes un sub-framework encima de CodeIgniter para suplir sus carencias.
  • Si eres principiante empiezas a lanzar un montón de líneas de código en un controlador.

Codeigniter miente y no tiene ORM propio

Sólo tiene un constructor de queries que ellos dicen que es una versión “modificada” del patrón de diseño Active Record pero eso es falso.

El patrón Active Record permite trabajar tus tablas como si fueran clases y tus filas como objetos, con Laravel puedes (así como con Ruby on Rails):

Código :

$user = new User;
$user->name = ‘Duilio’;
$user->save(); // This is awesome

En Codeigniter sería esto:

Código :

$this->db->insert(‘users’, array(‘name’ => ‘Duilio’); // No active record at all

PHP 5 en adelante está orientado a poner a disposición de sus programadores el potencial de la programación orientada a objetos. Si bien el enfoque de la base de datos de Codeigniter fue funcional en un tiempo, ya quedó en el pasado.

Laravel en constraste tiene un ORM llamado Eloquent y además tiene un constructor de queries llamado Fluent, ambos superan al “Active record” del otro framework.

No incentiva al uso de plantillas en las vistas

En Codeiginiter:

Código :

<ul>

<?php foreach ($addressbook as $name):?>

<li><?=$name?></li>

<?php endforeach; ?>

</ul>

Contrastado con Laravel:

Código :

<ul>
@foreach ($addressbook as $name)

<li>{{ $name }}</li>

@endforeach

</ul>

La documentación de CodeIgniter miente de nuevo al decir que los pseudo-lenguajes de plantillas, como el sistema de plantillas Blade de Laravel, son más lentos en ejecutarse. Esto no es cierto porque todos al final se compilan a código PHP, y lo que se leerá una y otra vez será PHP y no pseudo-lenguaje.

CodeIgniter ofrece un parser de plantillas muy simple, pero éste pierde el concepto de un VERDADERO lenguaje de plantillas: convertir etiquetas de <?=name?> a {{ name }} es sólo la punta del iceberg.

Un verdadero lenguaje de plantillas debe tener herencia de plantillas (layouts) y muchas otras características que Smarty, Twig poseen, allí Blade de Laravel no se queda muy atrás.

Super Controlador al rescate…

Como Codeigniter es tan básico, muchos programadores terminan escribiendo la mayor parte de la lógica de sus aplicaciones en un solo lugar: el controlador.

Por ejemplo la clase de rutas es tan simple, que se queda corta en los proyectos de la vida real y no queda más que lidiar con los segmentos de las URL desde el controlador, donde ya tu aplicación debería saber qué hacer.

Incluso en el mismo núcleo de Codeigniter, el controlador es una especie de super clase que está a cargo de casi todo, como lo demuestra esta imagen:

Al tratar de solucionar todos los problemas en una sola capa estarás escribiendo un código difícil de leer y mantener y no estarás aprovechando las funcionalidades que un framework en el año 2013 debe tener para ti.

Laravel tiene rutas, modelos, eventos, filtros, etc. que permiten que tus controladores puedan verse así:

Código :

    public function edit($user)
    {       
        return View::make('admin.users.form')->with('form', $form);
    }

[nota:daad7b1aed]Puedes configurar una URL users/{id} para que Laravel consulte la BD por ti, te traiga el usuario correspondiente a la ID o lance un 404 si no es encontrado, todo eso antes de llegar al controlador.[/nota:daad7b1aed]

En contraste con lo que sería Codeigniter:

Código :

    public function edit($id)
    {
        $user = $this->db->select('users', array('id' => $id));
        
        if (is_null ($user)) $this->error404();
        
        //etc...
    }

Revisen la documentación de Codeigniter vs la de Laravel en el tema de rutas y comparen la diferencia.

Laravel es FÁCIL

Hace años justificaba que la gente trabajara con Codeigniter, Symfony es muy complejo y otras alternativas como CakePHP son inciertas.

Hoy en día en el mundo de PHP tenemos un framework que está bien hecho, combina las mejores prácticas de desarrollo y hace que nosotros, programadores de PHP podamos escribir un código del cual sentirnos orgullosos.

En tu primer proyecto con Laravel usarás el 40% del tiempo para documentarte, otro 40% para desarrollarlo y un 20% para contemplar cuán genial quedó tu código.

Hoy puedes comenzar a dominar un mejor framework desde aquí en Cristalab: Lee su Introducción, Instalación, Configuración, rutas, controladores, plantillas y finalmente crea tu primer módulo con Laravel paso a paso.

Usen los comentarios abajo o mi twitter @sileence si tienen dudas o quieren más tutoriales de Laravel.

¡Saludos!

Enviar comentario

via Cristalab http://feeds.cristalab.com/~r/clab/~3/N6uzeQrxlrQ/

10 hechos que debes saber de Nokia y Microsoft

Nokia, una empresa finlandesa que construyó la industria móvil que hoy disfrutamos, siempre había tenido CEOs europeos hasta que Android y iOS los llevaron a una crisis.

Y entonces…

Stephen Elop era director de Office en Microsoft y renunció para ser CEO de Nokia

Elop recibió un Nokia con 34% del marketshare de smartphones (hoy es el 3.4%)

Elop se comprometió al 100% con Windows Phone, mató Symbian, Meego y cualquier esperanza de adoptar Android

Asus, Samsung, etc han hecho teléfonos y tablets con Windows, pero tras hoy nadie hará más con Windows 8 que no sea Microsoft

Microsoft compra la división de hardware de Nokia por €3,800 millones y las patentes por €1,650 millones. Gracias a ESTA gestión de Elop:

En contraste, Skype costó €6,500 millones

Ballmer abandona el puesto de CEO, Elop fuerte candidato a reemplazarlo

¿Saben antes de Microsoft donde trabaja Stephen Elop? Macromedia. La vendió a Adobe.

Oh yeah.

Enviar comentario

via Cristalab http://feeds.cristalab.com/~r/clab/~3/vB22laAbYu0/

El futuro del periodismo está en su especialización, no en los medios

journalism

Arianna Huffington es la fundadora, presidenta y editora en jefe del medio online The Huffington Post. Es autora de trece libros, fue premiada con el Pulitzer en el año 2012. Además, ha sido nombrada como una de las mujeres más influyentes del mundo por la Revista Time en los años 2006 y 2011. Sus estudios los realizó en la Universidad de Cambridge, en la cual obtuvo su pre grado y su maestría en economía.

Arianna expresa que con los medios de comunicación tradicionales “Hemos tenido muchas autopsias, pero no suficientes biopsias de los hechos, y es algo que tiene que cambiar.” Es decir que la investigación periodística no se está llevando a cabo como se debe. Los periodistas se han encargado de pelear por la primicia y no de investigar a fondo los sucesos para mantener a la población mejor informada.

Esto se asemeja al punto de vista de Antonio Rubio, expresado en una entrevista, quien manifiesta que los nuevos periodistas deben buscar la especialización porque éste es el futuro de la profesión. Rubio, de origen español, es uno de los periodistas de investigación más relevantes a nivel mundial. Su trayectoria ha sido productiva y ha desatado varios escándalos dentro de su país por la revelación de información sobre los políticos.

La evolución de los medios

La creadora de The Huffington Post manifiesta que es tiempo de dar un giro en la conversación, debemos dejar de hablar del futuro de los periódicos para hablar del futuro del periodismo. Es decir que la profesión se puede ejercer de cualquier manera, aunque no existan medios impresos.

El trabajo que están realizando en Knight Lab de la Universidad de Northwestern, respalda el discurso de Huffington. Miranda Mulligan, encargada del laboratorio, expresa que la creación de herramientas y soluciones tecnológicas para mejorar la práctica son una solución. La industria del periodismo está sufriendo un renacimiento, no se está acabando. Es por esto que debemos enfocarnos en su evolución para aprender a utilizar las herramientas tecnológicas disponibles y no en preocuparnos por la desaparición de los medios tradicionales.

Distinguir los viejos medios de los nuevos es algo irrelevante. El periodismo se ha encargado de evolucionar y esto ha traído varias ventajas. Actualmente, podemos seguir una noticia que los medios han dejado de reportar gracias al Internet. Además, todos tienen la libertad de comunicar y manifestarse de manera online. Esto genera que la censura, prácticamente, disminuya o no se convierta en una barrera para las personas que desean transmitir información, conocimiento u opinión.

Los grandes cambios

En Buenos Aires se realizó la Hacks/Hackers Media Party en la Ciudad Cultural Konex. Durante esta reunión desarrolladores, diseñadores y periodistas abordaron temas de suma importancia bajo el lema de “reiniciar el periodismo”. Según Jacqui Maher, programadora de The New York Times, el futuro del periodismo está en la interactividad que éste pueda tener. Esto generaría que las personas se interesaran más por la profesión, lo que está sucediendo a su alrededor y sobre cómo darle una mejor perspectiva.

El periodista Juan Carlos Romo explica que las herramientas tecnológicas facilitan la información y es por esto que las personas, en su mayoría, dejan de comprar los medios impresos. Esto se debe a que los periódicos no tienen la interactividad que tienen los medios en línea. En la prensa impresa no se puede comentar o dar retroalimentación para fomentar la discusión sobre los distintos temas que se plantean.

Las tendencias del periodismo

En el nuevo periodismo se están dando tres tendencias, según lo que explica Huffington. La primera consiste en el Jardín del Edén, que se refiere directamente al florecimiento de las conversaciones y opinión personal, lo cual fomenta el involucramiento de todas las personas para participar del periodismo.

La segunda es la serpiente que tienta a las personas, esta es una metáfora que explica que las personas tienen la tendencia de estar online las 24 horas de los 7 días que tiene la semana, es decir, una conexión full-time. La tercera es que las personas ahora se enfocan en buscar algo de significado, ya no se ocupan solamente de obtener información y consumirla.

Según el efecto Flynn, los coeficientes intelectuales (IQ) han aumentando cada década a partir del siglo XX. Sin embargo, en el artículo de la influyente mujer se expresa que nuestra capacidad para la resolución de los problemas que surgen no está a la altura del IQ. Este efecto ha traído varios cambios culturales, sociales y económicos. Actualmente existe la tendencia de familias con menos integrantes, mejor nutrición en los niños, una mejor educación, entre otros.

En conclusión, los medios tradicionales no van a desaparecer. Los nuevos medios no vinieron para sustituir a los tradicionales, sino que surgieron como una evolución de lo que ya existía. La lectura de los periódicos no va a cambiar, es tarea de éstos acoplarse a las nuevas tecnologías para mantenerse. No obstante, el futuro de los medios de comunicación se encuentra en los medios digitales. Las nuevas tecnologías de la comunicación se van a conectar con lo mejor de los medios tradicionales y esto hará que el periodismo mejore de manera exponencial. La interacción es el futuro. ¿Qué opinas la respecto?


Alvaro Lainfiesta para Maestros del Web.
Agrega tu comentario | Enlace permanente al artículo


Síguenos en: @maestros | Fan page

via Maestros del Web http://www.maestrosdelweb.com/editorial/futuro-del-periodismo/

5 Mitos de los Pre-Procesadores de CSS

Cristalab es la comunidad donde aprendí muchísimo de lo que uso hoy en día en mi trabajo. Desde hace dos años que vivo en Londres, Inglaterra y trabajo en una Agencia Digital llamada Cyber-Duck Ltd como Front End Developer. Los que me conocen por aquí, saben que llevo unos 10 años trabajando en internet, que amo mi trabajo y también que me encanta hablar y escribir sobre este tema.

Recientemente fui invitado a hablar en una conferencia sobre diseño web, y escogí hablar sobre los mitos de los pre-procesadores de CSS. Durante mi investigación, Freddie me ayudó a distribuir una encuesta que probablemente muchos de ustedes llenaron, sobre el uso de estos. Aquí están los resultados junto con el resto de la charla.

¿Qué son los Pre-procesadores de CSS?

Yo los veo como un método de agregar dinamismo a un lenguaje muy estático como lo es CSS. Este dinamismo viene en forma de funciones, variables, mixins y extends.

Porcentajes de Uso

En mi encuesta procuraba determinar el porcentaje de uso de los diferentes procesadores disponibles actualmente, así como el porcentaje de gente que no usa ninguno. Esto es lo que descubrí:

Latinoamerica: En este gráfico, podemos ver como un altísimo porcentaje de desarrolladores no utiliza ningún tipo de procesador de CSS (alarmante!).

Europa: Podemos ver como no solo el porcentaje que no utiliza ningún procesador es notablemente inferior, sino que además la gran mayoría de desarrolladores tiene Sass como su procesador preferido.

¿Por qué usar pre-procesadores?

Muchos desarrolladores tienen razones particulares para usar (o no usar) un procesador de CSS específico, pero las más comunes son las siguientes:

  • CSS es repetitivo.
  • CSS no tiene variables.
  • Es Inflexible, y complicado de reusar.
  • Sitios web complejos se vuelven complicados de mantener.

La inhabilidad de anidar selectores obliga a repetirlos una y otra vez al escribir CSS común. La falta de variables hace que el código no sea reusable, ya que detalles específicos como colores, tamaños y fuentes tienen que ser escritos directamente en cada hoja de estilos.

Los mitos

En orden de popularidad de menor a mayor:

  • Disminuye el rendimiento a los sitios.
  • Agrega complejidad al proceso de desarrollo.
  • Tiene dependencias que deben ser cubiertas.
  • Se pierde control sobre el código final.
  • Muy complicado de depurar.

Bull. Crap.
Vamos a desmentir uno a uno estos mitos:

Disminuye el rendimiento a los sitios

Este mito proviene del hecho que Less está basado en un compilador escrito en JavaScript que es capaz de compilar “en vivo” una hoja de estilos, por lo que muchos principiantes publicaron las hojas de estilo en archivos Less en vez de pre-compilarlas para producción.

Todos los procesadores compilan el código a CSS común y corriente, el cual además puede automáticamente ser comprimido y minificado para reducir tamaño de archivo. Por otro lado, facilitan el concatenar varios archivos en uno solo para reducir HTTP requests, por lo tanto de puede decir que aumenta el rendimiento, no lo disminuye.

Agrega complejidad al proceso de desarrollo

Anidar selectores se hace natural al escribir código, de la misma forma que las variables son naturales en muchos lenguajes y representan una forma más fácil de lidiar con valores que se repiten a lo largo de la hoja de estilos.
Al final, no es obligatorio usar toda la funcionalidad de Sass para que sea productivo, e incluso puedes escribir CSS plano y Sass lo procesará como si nada (No Less ni Stylus), de esta forma puedes empezar a usarlos y poco a poco ir incorporando la funcionalidad.

Tiene dependencias que deben ser cubiertas

Por un lado, todo entorno de desarrollo tiene sus dependencias, y las de procesadores de CSS no son en ningún caso complicadas o difíciles de instalar y configurar. Por otro, en la web de hoy en dia, si no usas un pre-procesador, necesitas un post-procesador (a menos que seas un completo masoquista).

Agregar prefijos de navegador, o simplemente minificar el código es prácticamente automático con cualquier pre-procesador, de lo contrario es necesario el paso extra usando alguna herramienta externa para lograr este objetivo. Mas adelante hay una lista de herramientas que facilitan este proceso.

Se pierde control sobre el código final

Sass no se escribe por sí solo. Esto significa, que si tu código final es horrible, tu código Sass es horrible (y muy probablemente tu actual CSS tambien es horrible).

Todos los pre-procesadores actuales tienen la opción de compilar código en su forma expandida, con comentarios y saltos de línea, etc, para que puedas revisar tus selectores, y el estilo durante el desarrollo, y así identificar posibles problemas o detalles que puedan mejorarse.

Muy complicado de depurar

Si escribes código organizado, no debería ser complicado de depurar. Usar archivos separados para cada componente o sección de tu sitio e importarlos con @import, esto ayuda mucho para depurar, al final todos se concatenan en un solo archivo para producción.

El proceso está mejorando día a día, incluso las últimas versiones de Chrome Canary (versión de desarrollo) incluyen soporte a “sourcemaps” con Sass (solo versión 3.3) que mapean los archivos Sass en vez del archivo CSS, indicando archivo original y número de línea de la regla inspeccionada, facilitando su localización.

En mi experiencia, el costo de la depuración es muy bajo comparado con el beneficio de usar procesadores.

Recursos

Siempre recurre a la documentación, los tres principales pre-procesadores cuentan con muy buena documentación online, haz buen uso de ella.

Esta es una lista (no exaustiva) de herramientas gráficas que ayudan en el desarrollo, para Mac, para Windows, algunas multiplataforma, unas de pago y otras gratis:

Otras herramientas interesantes son Grunt! Buildr y Brunch.io que además hacen muchas otras cosas.

¿Cuál es el mejor?

En mi opinión, Sass tiene varias ventajas como lo son su rápido y activo desarrollo, soporte de grandes empresas (Google), y el hecho de que su estilo es muy parecido a CSS hace el cambio aun más fácil, aparte que es el único que actualmente soporta Sourcemaps (Less está en proceso de implementarlo, Stylus lo está considerando). En cualquier caso, asegúrate de que la opción que elijas se adapta bien a tu proceso y que simplemente se sienta bien en tu caso particular. Si todavía no lo usaste, aquí tienes una Introducción a Sass y Compass.

Cabe mencionar, que es importante saber cómo funciona CSS antes de intentar usar un pre-procesador, ya que ésta es la mejor forma de saber que tu código esta bien escrito y bien estructurado.

Espero que este artículo te ayude a tomar una buena decisión con respecto a los pre-procesadores de CSS, y por cualquier duda, pregunte.

Enviar comentario

via Cristalab http://feeds.cristalab.com/~r/clab/~3/RMvnIqz8JLo/

Cómo instalar Laravel y Composer

En el capítulo anterior, les mostré un poco sobre la fácil sintáxis de Laravel. También les mencioné brevemente que detrás de esta interfaz que nos permite casi hablarle al framework: “redireccioname a”, “haz una vista… con este parámetro/valor”, debajo de todo eso se esconde una arquitectura SÓLIDA de desarrollo, haciendo a Laravel un framework de PHP ideal tanto para principiantes como para expertos.

Mi intención era despertar la curiosidad en la herramienta, si estás acá, quizás tuve éxito. Ahora es momento de ver cómo instalar Laravel y Composer.

Requisitos para Instalar Laravel

Laravel es un framework para PHP, obviamente tiene como requisito tener instalado… PHP, en este caso, la versión de PHP 5.3.2. Además necesitaremos la extensión MCrypt de PHP. También necesitan un servidor web como Apache y una base de datos como MySQL. Hay cientos de artículos sobre cómo conseguir todo esto, también hay herramientas como XAMPP que instalan todo esto por tí.

Más adelante necesitarán el módulo Rewrite (mod_rewrite) de Apache. Si han trabajado antes con otros frameworks sabrán de qué les hablo, sino, por ahora les comento que es un módulo que hace posible URLs amigables como las de Cristalab:

Código :

cristalab.com/tutoriales/introduccion-a-laravel-c111339l/

En vez de:

Código :

cristalab.com/tutoriales.php?id=c111339I.

Estas son útiles para los motores de búsqueda y también para los usuarios. En otro tutorial hablaremos de esto.

También necesitarán un conocimiento básico de PHP, es un “plus” si saben de programación orientada a objetos o si ya han usado otros frameworks. Igual trataré de explicar todo detalladamente y además tenemos la sección de comentarios donde pueden hacer preguntas, con suerte además de mí, otros usuarios también quieran ayudar a aclarar dudas.

Cómo instalar Laravel y Composer

Si tienen experiencia con PHP sabrán que éste es un lenguaje interpretado, básicamente una library para PHP (un framework por ej.) no es más que una serie de archivos .php dentro de carpetas dentro de sub-carpetas, y para instalarlo por lo general no hace falta más que descargar archivos de un repositorio GIT o de una página, descomprimirlos en algún lado y listo.

Para instalar Laravel 4, hace falta un paso extra. Pero no nos preocupemos, en realidad es una ventaja que nos pondrá no sólo a Laravel sino a miles de paquetes a nuestra disposición, me refiero a Composer.

Composer

Composer es un excelente manejador de paquetes y dependencias entre paquetes para PHP.

¿Qué son dependencias y paquetes?

Imagina que tienes un pequeño proyecto como ir de viaje de una ciudad a otra y para hacerlo necesitas un medio de transporte, en este caso, digamos, un automóvil.

Si fueras un programa de software el automóvil sería un paquete, y tu viaje sería la aplicación que "depende" de él.

Entonces, en este caso, Composer viene siendo como el personaje Tank de la película Matrix, tú le dices “Composer, necesito un auto para mi viaje” y Composer se encarga de buscar el paquete auto e instalarlo para ti. Luego “auto” le dirá a Composer que necesita también un paquete motor, otro paquete sistema de frenos, y así sucesivamente. Composer irá buscando e instalando cada paquete y las dependencias de cada subpaquete, recursivamente, hasta armar el auto, todo lo cual será transparente para ti.

Cómo instalar Composer

Aquí tienen las instrucciones de la página oficial, básicamente hay dos formas:

Instalar Composer en Linux:

Ejecuten desde su consola el siguiente comando:

Código :

curl -sS https://getcomposer.org/installer | php

O si no tienen CURL instalado:

Código :

php -r "eval('?>'.file_get_contents('https://getcomposer.org/installer'));"

Si todo sale bien ya podrán usar Composer con el siguiente comando:

Código :

php composer.phar

[nota:ebb4095d9f]Instalar Composer globalmente.
Es mejor instalar y tener disponible Composer en todo todo el sistema, para ello hay que renombrar el archivo a “composer” (sin extensión) y moverlo a /usr/local/bin.

Si no tienes el directorio /usr/local/bin puedes ejecutar echo $PATH en la consola para obtener las carpetas adecuadas.
[/nota:ebb4095d9f]

Instalar Composer en Windows:

Descarga el instalador desde aquí o desde la página oficial (para desconfiados), ejecútalo y presiona: siguiente, siguiente, finalizar.

También les hará falta una consola de GIT, yo uso ésta. Mismo proceso: descarguen, ejecuten, siguiente, siguiente, finalizar.

Instalar Laravel

Una vez instalado composer, usando la consola/terminal (si estamos en Windows usaremos la consola de GIT que recien instalamos), vamos a nuestra carpeta de proyectos, por ejemplo: cd /var/www o /home/usuario/proyectos_web/ o /c/xampp/httpdocs/ y allí tipeamos:

Código :

composer create-project laravel/laravel pruebalaravel 

[nota:ebb4095d9f]

Para usuarios de Linux que no instalaron Composer globalmente:

(El comando sería php composer.phar y necesitarían obviamente tener el archivo composer.phar en la misma carpeta desde donde ejecutan el comando)[/nota:ebb4095d9f]

Tiempo de ir por un café.

Mientras nos tomamos un descanso, Composer se encargará de descargar el proyecto base de Laravel, el framework y todas sus dependencias.

Si son curiosos verán cómo la consola va descargando decenas de paquetes que serán usados por Laravel más adelante.

Algunos de estos paquetes pertenecen al framework Symfony.

¿Symfony?

Sí, antes cuando elegíamos un framework como Codeigniter, Symfony o Cake, elegíamos una herramienta y descartábamos las otras. Si nos gustaba lo fácil que era Codeigniter pero también nos gustaba el ORM de symfony 1.4 teníamos que decidirnos por uno o por otro, o elegir Codeigniter y buscar en foro tras foro cómo integrar el ORM usado por symfony nativamente (Doctrine 1.2 en este caso) en Codeigniter, cruzar los dedos y esperar que todo saliera bien.

O supongamos que queríamos crear un nuevo CMS para PHP, pero aún así estábamos totalmente satisfechos con la forma en cómo symfony maneja las rutas. No había forma fácil de usar sólo las rutas de symfony, porque era un framework "acoplado" y teníamos que elegir usar todo o nada.

Con la salida de proyectos como Symfony 2 y Composer, esto cambió radicalmente. De hecho la versión Symfony 2 fue liberada como un conjunto de componentes que pueden ser usados por separado, de manera que proyectos como Drupal 8 integran ciertos componentes de Symfony, y así lo hace Laravel.

Todo lo cual lleva el desarrollo de PHP a otro nivel, donde nosotros, los programadores podemos aprovechar el trabajo de otros y fácilmente poner parte de nuestro trabajo al alcance de otros, en vez de seguir reinventando la rueda una y otra vez.

Pero volviendo a la instalación de Laravel…

Una vez que se complete la descarga de los paquetes, verificamos nuestro directorio, el cual debe lucir similar a éste:

..con todas las carpetas instaladas por Composer.

Y, como personas impacientes que somos, también iremos corriendo al navegador, y tipearemos, en mi caso:

Código :

http://localhost/laravelpruebas/public

[nota:ebb4095d9f]

Directorio público:

(Es importante acceder a la carpeta /public que es la puerta de nuestro proyecto para la web, más adelante veremos esto en detalle)[/nota:ebb4095d9f]

Y si todo ha salido bien:

Si leíste “you have arrived” en tu navegador, estás listo para la tercera parte, sino tienes varios días, los comentarios de abajo y Google para investigar qué salió mal y prepararte para la siguiente entrega, donde explicaré lo que contienen las carpetas y archivos instalados por Composer, entre otros temas.

Stay tuned :)

Enviar comentario

via Cristalab http://feeds.cristalab.com/~r/clab/~3/Vyen3aNCRfg/