emporio armani,fake rolex for sale,rolex sea dweller,panerai,iwc,richard mille,replica watches,bell ross,a lange sohne,cheap replica watches,jaeger lecoultre,rolex explorer,corum,rolex milgauss,breguet,piaget,franck muller,chopard

Trying to get pure-ftpd running on an OpenVZ virtual server and getting this message?

[ERROR] Unable to switch capabilities : Operation not permitted

Shut the VPS down, enter the host via SSH and enable needed capabilities for your VPS (where $VPS_ID is your VPS id, ie 101, 102…)

for CAP in CHOWN DAC_READ_SEARCH SETGID SETUID NET_BIND_SERVICE NET_ADMIN SYS_CHROOT SYS_NICE CHOWN DAC_READ_SEARCH SETGID SETUID NET_BIND_SERVICE NET_ADMIN SYS_CHROOT SYS_NICE; do vzctl set $VPS_ID --capability ${CAP}:on --save; done

That’s it :-)

Para quien no lo sepa, desde Noviembre de 2010 se viene celebrando una reunión mensual de programadores, sysadmins, diseñadores y en general gente técnica o creativa de la comarca del Maresme. Se le dio el nombre de Maresme Developers Meetup, y tiene su hashtag en Twitter: #maresmedev.
Tenemos un grupo en Googlegroups al que cualquiera se puede suscribir si desea conocer las fechas de las próximas reuniones y de lo que en ellas se va a hablar, y en breve montaremos un site, quizá un blog, en el que colgar los slides y vídeos de las techtalks.
Por el momento nos comunicamos por Twitter y en la mailing, y las slides las compartimos en Slideshare.

La última reunión tuvo lugar ayer (viernes 18 de Febrero de 2011), y la charla corría a mi cargo. Era una pequeña presentación del movimiento Nosql, haciendo un ligero repaso por encima a Redis y a Mongodb.

En realidad yo no sé mucho sobre el tema. Se ha puesto de moda en los últimos dos años, y por pura curiosidad programé mi último proyecto (Fantastic Love Machine) usando Rails 3 y Redis… símplemente con el ánimo de aprender.
La buena prensa de Mongodb me llevó a indagar un poco hace un par de semanas, y después de ver cómo funciona y probar un Orm para Ruby llamado Mongoid, decidí migrar la aplicación.

El resultado es que ahora conozco un poquito como funcionan ambos sistemas, y aproveché el meetup mensual de la #maresmedev para presentar las cuatro cositas que he aprendido en este tiempo.

Y bueno… cómo no: aquí están los slides :-)

Ha tardado varios meses en llegar. Últimamente Abel y yo hemos estado hasta ariba de trabajo, y por eso no hemos podido mantener el nivel de updates que había al principio en el proyecto. Pero hemos vuelto y venimos con fuerza.
En un principio salimos sólo en inglés porque el servicio nos parecía muy atractivo y no queríamos restringirlo al público español. No obstante la mayoría de usuarios son españoles, cosa que es normal porque casi todos vienen recomendados por gente de nuestro entorno.
Muchos se han encontrado al principio con la barrera del idioma, no entienden cómo funciona o lo que tienen que hacer para registrarse, qué es un wish, cuál es la finalidad del site… bueno pues ya no hay excusa heheh

Desde hoy Uwish tiene versión en inglés y en español :-)

Echadle un vistazo, enviadnos vuestras críticas o sugerencias, y sobretodo poned al día vuestras listas ahora que están a punto de venir los reyes magos!!

PD: Feliz año nuevo 2011 a todos!!

Los que me conocen saben que me da muchísima rabia programar aplicaciones para Facebook. Y en realiad no es porque me dé rabia Facebook como plataforma (soy twittero de corazón), sino porque el desarrollador está dejado de la mano de dios en cuanto a aplicaciones de Facebook se refiere.

No obstante Facebook es la plataforma ideal para lanzar proyectos que requieren una capa social. Y esto es Fantastic Love Machine.

Se trata de una aplicación que permite al usuario encontrar amantes (o una pareja estable, allá cada cual heheh) entre su círculo habitual de amigos. Funciona de la siguiente manera:

  • El usuario instala la aplicación, y elige las amigas o amigos que le gustan.
  • Los amigos y amigas hacen el mismo proceso
  • Si el usuario ha marcado a una chica, y a su vez ella también le ha marcado a él, la aplicación les avisa a los dos en secreto

Es una aplicación divertida y seguro que a más de uno le ayuda a encontrar novia… o algún ligue asegurado heheh

Como anécdota comentar que la he desarrollado en Rails 3, y como base de datos he usado Redis en lugar de Mysql para experimentar. De momento no he usado ningún ORM, aunque viendo la dificultad de realizar búsquedas entre los documentos ya le tengo echado el ojo a Ohm, y se lo implementaré en breve.

Más info en la fanpage de FLM en Facebook.

Como muchos ya sabíais, ayer (Viernes, 10 de Septiembre de 2010) inauguramos la nueva oficina de Sysdivision.

Como un poquito de historia, comentar que Sysdivision es el nombre de la empresa que monté en 2005 con mi amigo Mauro. El se fue después de unos dos años, y yo continué adelante sólo. Con mucho esfuerzo he pasado los siguientes tres años y medio trabajando en mi casa, como cualquier otro freelancer.
El último cliente que ha contratado mis servicios requiere mucha atención y dedicación, y he contratado a Daniel Álvarez para que mantenga el código que yo hice hasta ahora. Y como el despacho de mi casa es muy pequeñito para los dos, he alquilado un local en el que hemos montado la oficina de la empresa.

Ha sido un curro de verdad fuerte fuerte: modificar la instalación eléctrica, pintar las paredes, limpiar todo (suelos, lavabos…), comprar en Ikea los muebles necesarios y montarlos… y lo hicimos todo desde el viernes pasado a las 13:00 hasta el domingo a las 22:00.

Aquí unas fotos de lo que nos entregaron, y el resultado final…

A la inauguración de ayer vinieron varios amigos… mi mujer Ana, mi hermano Sergio, mi nuevo compañero Dani Álvarez, su chica Mónica y un amigo llamado Oriol, Iván y Sergi de Iluro@adis, Eloi y Elric de Zen, Txus y Oriol de Codegram, Iván Fontán de NTT, Mauro Pompilio de Xing y Jordi Valverde de Eclipsi Networks.

A todos mil gracias por venir, nos hizo muchísima ilusión inaugurar nuestra oficina y lo pasamos genial en compañía de vosotros. Aquí las fotos…

Algunos no salen en las fotos porque el fotógrafo (Jordi Valverde) se tuvo que ir antes de que llegasen algunos de los invitados heheh. Y me estoy dando cuenta que tampoco sale un elemento importante: montamos un proyector que contínuamente pasaba la peli de Tron (la clásica) en la pared.

De nuevo muchísimas gracias a todos los que vinisteis. Fue una inauguración genial, y esperamos que esta nueva etapa sea larga y próspera!

Those who know me also know that one thing I’m specially concerned about is the importance of writing good documentation on everything you do. Specially for technical projects. Maybe it is not important for coders or designers, but for a sysadmin I think it should be definilety mandatory. If you get cool things working together but you don’t write any documentation, you won’t be able to play that music again.

Also, I am working in Ruby on Rails development since about 2 years ago. One of the things I have to do usually is to set up servers for hosting projects. And sometimes I have to set up a server for project development and tracking. These are the steps you can follow to set up a Ruby on Rails based server for development tracking.

1. Get a server

There are plenty of choices around the internet, some of them come completelly installed and prepared for deploying your app. They usually work the same way traditional LAMP hostings used to do, but using ssh key authentication instead of FTP sessions… some of them have also web based backend panels for deploying, migrating and managing your app gems.

I prefer to set up an empty GNU/Linux vanilla server, so that I can host everything I need, my way, no worries if PHP, Ruby or whatever. I can set up a relay mailserver, netfilter routing, traffic shaping, services for monitoring and differential backups that I can periodically rsync to my office local server. This is the way a sysadmin thinks, something that coders not always understand.

If you want to set up a development server I recomment you to take a look at most basic Linode VPS. Their control panel will let you run and destroy any Linux distro, setup and resize partitions, add failover addresses, disk space, processor and memory. And of course you’ll have full SSH root access. So I find it very useful and flexible for my needs.

Some considerations:

  • You’ll have to set up a DNS name for the server IP, i.e: http://devel.somedomain.net
  • You’ll need root access on the server. I’ll suppose you are working on a local computer, remotely logged via SSH to your server
  • I usually build my servers using Debian (Lenny for now), but a basic knowledge of any other distro package system will let you adapt my guide to your preferred system
  • I’ll suppose you’ve set up a specific environment for running your app on the development server (I usually call it beta)

2. Install screen

You may partially lose your work if for any reason your local computer hangs during the process. So it’s recommendable to install and use screen for working on a detachable console terminal. This way, if your computer shuts down, you’ll be able to boot again, ssh into your server and recover your screen session.

apt-get install screen

You’ll maybe want to set up your screen sessions to look nicer than withe on black, and give you some additional information of the remote system. I use a copy of the screenrc configuration file from my friend r0sk, it’s simple and nice and works sweet.

wget -c http://ivanhq.net/stuff/_screenrc
mv _screenrc ~/.screenrc

Enter screen

screen

3. Base system

You’ll need an unprivileged user to host your web apps. I usually create a web user

mkdir /home/web
groupadd service
useradd -d /home/web -s /bin/bash -g service web
chown -R web:service /home/web/
passwd web        # type your preferred password here

Add contrib and non-free repositories to your Apt sources file (vim /etc/apt/sources.list)

deb http://ftp.us.debian.org/debian lenny main contrib non-free
deb-src http://ftp.us.debian.org/debian lenny main contrib non-free

Update your sources and then your system

apt-get update
apt-get upgrade

Edit your SSH server config file to disallow root login and enable SSH key authentication (vim /etc/ssh/sshd_config)

# change next line, swap "yes" for "no"
PermitRootLogin no
 
# uncomment next line
AuthorizedKeysFile      %h/.ssh/authorized_keys

Restart your SSH service

/etc/init.d/ssh restart

Install build-essentials for compiling and installing the environment dependencies

apt-get install build-essential

Install Postfix for using as MTA relay server, or MySQL Debian packages will install Exim (which I don’t really like)

apt-get install postfix

# select: internet site
# MTA's outgoing domain name: somedomain.net

4. Backports

Because of some software versions being old and deprecated on the APT sources, and some other not being present, an alternative repository can be set up for installing newer versions. The backports repository.

wget -O - http://backports.org/debian/archive.key | apt-key add -

Edit your APT sources file (vim /etc/apt/sources.list)

deb http://www.backports.org/debian lenny-backports main contrib non-free

Update your system again

apt-get update

5. MySQL

Install mysql service, and its ruby bindings package

apt-get install mysql-server mysql-client libmysqlclient15-dev libmysql-ruby

Create a database for your project (mysql -uroot -p)

mysql> CREATE DATABASE yourapp_beta;
mysql> GRANT ALL PRIVILEGES ON yourapp_beta.* TO yourapp_username@localhost IDENTIFIED BY 'your_superhacker_password123';

6. Ruby, Rubygems and Rails

Install the Ruby stuff, I prefer to use backports at this point to ensure latest versions.

apt-get -t lenny-backports install ruby1.8-dev ruby1.8 ri1.8 rdoc1.8 irb1.8 libreadline-ruby1.8 libruby1.8 libopenssl-ruby

Add unversioned links for the newly created binaries

ln -s /usr/bin/ruby1.8 /usr/local/bin/ruby
ln -s /usr/bin/ri1.8 /usr/local/bin/ri
ln -s /usr/bin/rdoc1.8 /usr/local/bin/rdoc
ln -s /usr/bin/irb1.8 /usr/local/bin/irb
ln -s /usr/bin/gem /usr/local/bin/gem

Install Rubygems from source, so you can update it directly whenever you want. Otherwise the system will update it for you, only when new packages for your distro are available.

cd /usr/local/src
wget -c http://production.cf.rubygems.org/rubygems/rubygems-1.3.7.tgz
tar zxvfp rubygems-1.3.7.tgz
cd rubygems-1.3.7
ruby setup.rb

Link gem binary to an unversioned name

ln -s /usr/bin/gem1.8 /usr/bin/gem

Update rubygems (not really needed, but just in case)

gem update
gem update --system

Install Rails

gem install rails

7. Image processing

Youll surelly want a plugin for cropping and thumbnailing images, maybe attachment_fu or paperclip. They both can work with Imagemagick.

apt-get install imagemagick

8. Apache

There are different web server layouts for hosting your application. Some people likes Nginx+Mongrel, some other prefer Apache+Passenger, others prefer Nginx+Passenger… I love Apache. Maybe because its syntax simplicity, its flexibility or maybe simply because as a sysadmin I’ve been working for years with it.

Install Apache

apt-get install apache2.2-common apache2-mpm-prefork apache2-prefork-dev libssl-dev

Rename default virtualhost

a2dissite default
mv /etc/apache2/sites-available/default /etc/apache2/sites-available/devel_somedomain_net

Edit that virtualhost (vim /etc/apache2/sites-available/devel_somedomain_net)and configure it with the minimum options to work. I’m adding a basic HTTP authentication so only people you give the password can see your project (it’s a development server heheh).

<VirtualHost *:80>
        ServerName devel.somedomain.net
        RailsEnv beta
        DocumentRoot /home/web/sites/devel.somedomain.net/current/public
 
        CustomLog /var/log/apache2/devel_somedomain_net/access.log combined
        ErrorLog /var/log/apache2/devel_somedomain_net/error.log
 
        <Directory /home/web/sites/devel_somedomain_net>
                AuthType Basic
                AuthName "Members Only"
                AuthUserFile /home/web/sites/.htpasswd_devel_somedomain_net
                <limit GET PUT POST>
                        require valid-user
                </limit>
        </Directory>
</VirtualHost>

Enable your new virtualhost

a2ensite devel_somedomain_net

As the unprivileged user running the service, create the application directory and the HTTP Auth passwords file

su - web
mkdir -p /home/web/sites/devel.somedomain.net
 
htpasswd -c /home/web/sites/.htpasswd_devel_somedomain_net username1
htpasswd /home/web/sites/.htpasswd_devel_somedomain_net username2
....

exit

Create the apache log directory for your app

mkdir -p /var/log/apache2/devel_somedomain_net

Install Passenger

gem install passenger
passenger-install-apache2-module

Create a file for loading passenger module into Apache (vim /etc/apache2/mods-available/passenger.load). Be careful with versions on the names as they may have changed.

LoadModule passenger_module /usr/lib/ruby/gems/1.8/gems/passenger-2.2.15/ext/apache2/mod_passenger.so
PassengerRoot /usr/lib/ruby/gems/1.8/gems/passenger-2.2.15
PassengerRuby /usr/bin/ruby1.8

Enable passenger module

a2enmod passenger

Change the user and group executing Apache service to match your unprivileged user (vim /etc/apache2/envvars)

#export APACHE_RUN_USER=www-data
#export APACHE_RUN_GROUP=www-data
export APACHE_RUN_USER=web
export APACHE_RUN_GROUP=service

Restart Apache

/etc/init.d/apache2 restart

9. Git and Gitosis

If you don’t want to pay a Github account and you don’t want your source to be visible to everyone, you’ll want to host your own Git server. There are different choices for that, but I like Gitosis because it’s simple and I can manage it from my command line, only editing a config file.

Install Git

apt-get -t lenny-backports install git-arch

Gitosis is written in Python, so you need to install python’s setup-tools in order to install Gitosis

apt-get install python-setuptools

Clone and install Gitosis

cd /usr/local/src
git clone git://eagain.net/gitosis.git
cd gitosis
python setup.py install

Create a new unprivileged user for hosting Gitosis and its repositories. It does not need a password (so it can’t log in) but it needs a shell as all management occours using an SSH session.

adduser \
--system \
--shell /bin/sh \
--gecos 'git version control' \
--group \
--disabled-password \
--home /home/git \
git
 
usermod -g service git

Upload your ssh public key to the server, leave it in /tmp/ and call it user@host.pub being user@host the final string specified into the file itself (ivan@mbp-local, or something similar)

Initialize Gitosis using the SSH key you just uploaded, which will be the Gitosis admin

su - git
gitosis-init < /tmp/ivan\@ibelmonte-mbp.local.pub

In your local computer clone the Gitosis repository so you can manage it from now on

git clone git@devel.somedomain.net:gitosis-admin.git

Enter the gitosis-admin directory and check the contents. It has to show a filename called gitosis.conf and a directory called keydir.

10. Add a repository for your app

Edit the Gitosis config (vim gitosis.conf) and add a new group, formed with one user (or more, separated with spaces), and its repository

[group your_app_name]
members = user1@host1 user2@host2 ...
writable = your_repo_name

Make sure to put user’s keyfiles into the keydir directory, following the previously mentioned format. Upload your changes.

git add .
git commit -a -m "Added user2 to your_app group"
git push

In your local computer you can now create an application and add its files to the repo

rails your_app
cd your_app
git init
git remote add origin git@devel.somedomain.net:your_app.git
git add .
git commit -a -m "Initial import"
git push origin master:refs/heads/master

11. Capistrano

You’ll want to deploy your software to your newly configured server. Capistrano is the best choice I know, since it creates versioned directories to let you roll back and forth, remotely run tasks on the hosted version of your app, place a custom “under maintenance” page, etc…

Install Capistrano

gem install capistrano

Capify your application

cd /path/to/your/app
capify .

Create a recipe (vim config/deploy.rb)

# set a target name, so you can also use it to deploy to a production server

# set :targetname, 'www'
set :targetname, 'devel'
 
if targetname == 'devel'
  set :rails_env, 'beta'
end
 
set :application, "#{targetname}.somedomain.net"
set :deploy_to, "/home/web/sites/#{application}"
set :user, "web"
set :runner, "web"
set :repository, "git@devel.somedomain.net:your_app.git"
set :deploy_via, :remote_cache
set :copy_exclude, [".git", ".gitignore"]
set :scm, :git
set :use_sudo, false
 
# Master branch of course. If not, change
#
# set :branch, master
 
ssh_options[:forward_agent] = true
 
role :app, "#{targetname}.somedomain.net"
role :web, "#{targetname}.somedomain.net"
role :db,  "#{targetname}.somedomain.net", :primary => true
 
namespace :deploy do
  desc "Restarting passenger with restart.txt"
  task :restart, :roles => :app, :except => { :no_release => true } do
    run "touch #{current_path}/tmp/restart.txt"
  end
 
  [:start, :stop].each do |t|
    desc "#{t} task is a no-op with mod_rails"
    task t, :roles => :app do ; end
  end
end

12. SSH keys

In order to deploy your app without typing any password, you’ll have to set up a SSH key authentication between you and the unprivileged user of the server (web user).

Copy the content of your local ssh keyfile (commonly ~/.ssh/id_rsa.pub) and paste at the end of /home/web/.ssh/authorized_keys on the server. You’ll want to repeat this process for each developer so they can also deploy without typing a password.

You’ll also need to generate a SSH key for your web user on the server, and add it as a member of the repo in gitosis. Otherwise you won’t be able to deploy your app, because the server won’t let itself access to the repo for fetching.

13. Redmine

Redmine is one of those powerful tools that make your life easier when working with other developers, designers, webmasters and CEO’s… it helps you to keep tracking of issues, bugs, timings, files and documents, wikis and it also lets you graphically browse your repositories. If you’ve never tested it, now it’s your time.

NOTE: you’ll need to create a new entry on your DNS server. Set up a CNAME called redmine pointing to devel.somedomain.net

Redmine needs mod_rewrite support on Apache

a2enmod rewrite

You’ll need subversion to checkout the source code of Redmine

apt-get install subversion

Su to your unprivileged user

su - web

Checkout the code

cd sites
svn co http://redmine.rubyforge.org/svn/tags/1.0.1/ redmine.somedomain.net
cd redmine.somedomain.net

Create a database for redmine (mysql -uroot -p)

mysql> CREATE DATABASE redmine CHARACTER SET utf8;
mysql> GRANT ALL PRIVILEGES ON redmine.* TO redmine@localhost IDENTIFIED BY 'redmine123';

Edit Redmine’s database configuration file (vim config/database.yml)

production:
  adapter: mysql
  database: redmine
  host: localhost
  username: redmine
  password: redmine123
  encoding: utf8
  socket: /var/run/mysqld/mysqld.sock

Place a secret key for Redmine cookies on its environment file, inside the Initializer block (vim config/environment.rb)

config.action_controller.session = { :key => "_redmine_somedomain_com_session", :secret => "578359e95c3f2sj9enw10amkd81508ff" }

Migrate the database

env RAILS_ENV=production rake db:migrate

Edit the SMTP configuration for Redmine to be able to send notification emails (vim config/email.yml)

production:
  delivery_method: :smtp
  smtp_settings:
    address: "smtp.somedomain.net"
    port: '25'
    domain: "somedomain.net"
    authentication: :login
    user_name: "your_username"
    password: "your_password"

If you want to relay over Gmail or your domain’s email is hosted on Google apps, you’ll need to install a tls authentication plugin

ruby script/plugin install git://github.com/collectiveidea/action_mailer_optional_tls.git

Use this config for use with Gmail / Google apps

production:
  delivery_method: :smtp
  smtp_settings:
    tls: true
    address: "smtp.gmail.com"
    port: '587'
    domain: "gmail.com"   # use "somedomain.net" in case of Google Apps
    authentication: :plain
    user_name: "your_username"
    password: "your_password"

Exit su, and become root again

exit

Create a new Apache virtualhost (vim /etc/apache2/sites-available/redmine_somedomain_net)

<VirtualHost *:80>
        ServerName redmine.somedomain.net
        RailsEnv production
        DocumentRoot /home/web/sites/redmine.somedomain.net/public
 
        CustomLog /var/log/apache2/redmine_somedomain_net/access.log combined
        ErrorLog /var/log/apache2/redmine_somedomain_net/error.log
</VirtualHost>

Create an Apache log directory for redmine

mkdir /var/log/apache2/redmine_somedomain_net/

Enable your new virtualhost and restart Apache

a2ensite redmine.somedomain.net
/etc/init.d/apache2 restart

14. Start writing Ruby on Rails

Here comes the funny part. Enjoy! ;-)

Es una discusión que he tenido con varias personas últimamente. Cada vez son más los sitios web en los que no hace falta registrarse y se puede acceder usando la autenticación de Facebook o la de Twitter.

Yo tengo una red social (Uwish), y no ofrecemos esa posibilidad. En lugar de eso, es necesario registrarse para tener un usuario propio. También tenemos nuestro propia capa social, es decir que tienes que definir tu red de amigos de forma independiente a Facebook o a Twitter. Dicho de otra forma: tu usuario de Uwish es propio de Uwish, y tus amigos en Uwish no tienen por qué ser tus amigos en otras redes.

Esto plantea la discusión sobre lo beneficioso o contraproducente de reinventar la rueda. La mayoría de las personas con las que hablo están a favor de añadir el botón de Facebook Connect bajo el login para evitar al usuario tener que registrarse, y también están a favor de que los amigos en Uwish sean los que ya tiene el usuario en Facebook. El argumento es evitar tener que hacer algo que ya está programado y que además funciona muy bien. Y es cierto. Y tienen razón. En casi todo…

Para empezar, Uwish es una red con un funcionamiento muy similar al de Twitter. De hecho cuando la desarrollamos siempre pensamos en las bondades de Twitter, y las desventajas (para nosotros lo son) de Facebook. En general Twitter tiene un modelo abierto, todo el contenido de un usuario es público y cualquiera puede verlo y subscribirse a él, a menos que el usuario bloquee su perfil explícitamente y lo haga privado.
Uwish funciona exactamente igual. Y nos inspiramos en esta forma de funcionar para desarrollar su capa social.

De hecho, planeamos la integración con Twitter desde el principio, mientras que la integración con Facebook surgió posteriormente como argumento de valor añadido, y en varias ocasiones hemos estado tentados de retirarla debido a la complejidad de desarrollo con la antigua API Rest, y también en parte debido a las políticas de privacidad y la estructura de permisos.

El planteamiento es el siguiente: siendo que el contenido de un usuario en Uwish es abierto, es necesario mostrar un perfil público para cada uno de los usuarios. Y cada uno tiene su propia dirección. Por ejemplo:

Si os fijáis, cada usuario está identificado por un nickname (ivan, jazze, anita, cih…) y cada uno tiene una página de perfil público construida con su nickname.
Esto nos plantea el primer problema. Si incluimos el login a través de Facebook tenemos dos opciones:

  • Al entrar la primera vez, hacer que el usuario elija un login de perfil
  • Construir un login de perfil con su nombre y apellido por defecto, algo como jose_fernandez

En el primer caso… ¿nos ahorramos el registro, pero después le pedimos que elija un nickname?
Me parece un proceso más confuso que un simple registro con email y contraseña. Es decir: entras usando tu Facebook, pero dentro te piden que escojas un nombre de usuario porque el de Facebook no sirve… no me convence, la verdad.

En el segundo caso… no me parece bonito que algunos tengan un nickname, y los que entran usando Facebook muestren forzosamente sus datos personales (nombre y apellido). De hecho tenemos muchos usuarios que al registrarse proporcionan sólamente el nickname y no sus datos personales. Nosotros queremos ofrecer la libertad de hacerlo así.

Ofrecer el login a través de Twitter nos permitiría usar el nickname de Twitter para Uwish. Eso ya está mejor. El problema es que el usuario ivan de Twitter se registre en Uwish, donde el nickname ivan ya está ocupado. Entonces pedimos al usuario que elija otro nickname. Esto lleva a la situación en que con el login de Twitter se entra a Uwish, pero el perfil tiene allí otro nickname distinto. No me gusta.

Resultado: es conflictivo en cualquiera de los casos.

Por otro lado mucha gente dice que debemos hacer una aplicación de Facebook. Yo pienso que no. Soy partidario de desarrollar una integración limitada y con cuidado.

Para quien no lo sepa, existen dos tipos de aplicaciones de Facebook:

  • aplicaciones en canvas
  • aplicaciones en iframe

Las primeras son esas que transcurren dentro del entorno de Facebook, y utilizan el login de Facebook y la capa social (las relaciones con los amigos) de Facebook. A ojos del usuario, es como si la aplicación viviese dentro de Facebook.
Las segundas son páginas web externas que interactúan con Facebook pero no transcurren dentro del marco de Facebook.

Para colmo existen dos formas de hacer una aplicación para Facebook: con XHTML o con FBML. El primero es el lenguaje habitual con el que se programan todas las páginas web. El segundo es un lenguaje propio de Facebook con el que fácilmente se puede diseñar una aplicación que use botones, barras, enlaces y estilos como los de Facebook, de forma que el usuario tenga la impresión de estar usando el propio Facebook.

Todo esto son cosas que se deben valorar cuando se desarrolla una aplicación social y se quiere integrar con otras redes sociales. Nosotros pensamos que los usuarios son personas, no maceteros de cerámica, y se les puede pedir hasta un punto.

Integrar Uwish con Facebook plenamente supondría lo siguiente:

  • El usuario accedería a través de Facebook, con su cuenta de Facebook
  • Dentro tendría botoneras como las de Facebook, barras como las de Facebook, botones like como los de Facebook…
  • Al entrar, Facebook le pediría una serie de permisos que el usuario debería aceptar para usar la aplicación (igual que pasa con Farmville y todas las demás)
  • Como resultado, el usuario desde el primer momento tendría la sensación de estar en un entorno completamente integrado en Facebook

Eso lleva al usuario a pensar que sus contenidos y el uso que hace de la aplicación está amparado por las reglas de privacidad de Facebook (que dicho sea de paso, cambian como los girasoles cada dos meses). Pensaría que todo queda entre él y sus amigos de Facebook.

Pero Uwish en realidad, por detrás estaría creando una página de perfil pública en la que se expondría su grafo social, sus datos personales (nombre y apellido) y todos los contenidos, que por supuesto todo el mundo puede ver y a los que cualquiera se puede suscribir. En breve le empezarían a llegar mensajes por email conforme gente que ni siquiera conoce le está followeando, se ha copiado algunos de sus wishes o le ha dejado un shout en su shoutbox.

Si a muchos usuarios les cuesta entender lo que es un wish o un timeline, ¿cómo se puede pretender que entienda lo que implica entrar a un site usando la autenticación de Facebook, pero ateniéndose a unas políticas de uso y privacidad propias?

Nosotros pensamos que a la larga esto sólo puede hacer que muchos usuarios se den de baja. No buscamos hacernos con millones de usuarios. Buscamos hacernos con los usuarios que realmente quieran crear y compartir listas de deseos.

Por eso planteo siempre esta polémica: yo no creo que sea malo integrar un site con Facebook. Lo que pienso es que se debe saber cuándo es bueno hacerlo y cuándo no.

Integrar la granjita de Farmville o las galletitas de la suerte es bueno, porque sirve para que una aplicación que no aporta nada se llene de usuarios que no almacenan ninguna información. Hacen un uso impersonal, no es relevante.

Ahora bien, Lastfm (por ejemplo) no incorpora todas estas cosas. El usuario que se registra en Lastfm sabe lo que está haciendo, y desea hacer uso del servicio porque sabe de qué va. La información que el site almacena son gustos musicales, hábitos de consumo personales al fin y al cabo. Y no es algo con lo que la plataforma deba jugar si quiere mantener un público fiel.

Spotify por otro lado ha incorporado una pequeña parte a Facebook en su última versión, permitiendo que los usuarios compartan sus listas de reproducción a través de su grafo social en Facebook. Pero toda la actividad transcurre en el software de Spotify. Tampoco se puede acceder con la cuenta de Facebook, el que quiere usar la plataforma tiene que registrarse en ella.

Al final todo es una decisión que se debe tomar, y no existe una opción mejor que otra. Lo importante es meditarlo bien, porque de esta decisión puede derivar más del 50% del uso que se haga del servicio, y eso puede acabar definiendo las reglas del modelo de negocio.

Yo personalmente soy partidario de incorporar sólo algunas cosas puntuales. La web social masiva tal como la entendemos hoy día (Facebook y Twitter, básicamente) puede cambiar en poco tiempo. Puede ser una moda pasajera, o puede que en breve aparezca un competidor fuerte y éstas pierdan relevancia, y con ellas su sistema centralizado de autenticación y su grafo social.
Integrar un site completamente a estas plataformas significa atar a ellas su destino.

Finalmente aclaro que Uwish tiene integración con ambas plataformas, aunque limitada. Actualmente el usuario puede conectar su perfil a Facebook y a Twitter desde su pantalla de configuración, y de ese modo sus contenidos de Uwish aparecerán reflejados en su muro y en su timeline.
Planeamos incorporar otras cosas, planeamos replicar en Uwish parte del grafo social externo, pero nunca relegarlo. Y también planeamos usar ambas plataformas para que el usuario pueda invitar a otros amigos a nuestra comunidad.

Todo esto supone una integración limitada. No sabemos si es la mejor forma, pero tenemos tanto cariño a nuestro proyecto que no nos tomamos estas cosas a la ligera.

Me alegraría que esto sirva de reflexión a otros :-)

He leído el soporte de Google y un montón de foros. He probado varios tips, pero ninguno ha conseguido reanimarlo.
No sé qué le ha pasado, de repente no se ha encendido. La batería carga, el led naranja lo indica, y la he dejado cargando hasta que se ha puesto verde que indica que está cargada al 100%.
Pero no se enciende.

La garantía de Google/HTC cubre fallos de hardware, siempre que no hayas desbloqueado el bootloader. Yo tenía el bootloader desbloqueado, el teléfono rooteado y le había flasheado varias rom’s. Así que no puedo tirar de garantía.

Tengo ganas de llorar.
Nexus one RIP.

Después de abrir anteayer las puertas de Uwish, enviamos un boletín por correo a los beta-testers para comunicarles la noticia y agradecerles el tiempo y la paciencia dedicados. Tardó muy poco en verse alguna que otra mención en Facebook y Twitter… pero lo que no esperaba de ninguna de las maneras era el efecto de red social que se avecinaba. Durante todo el domingo estuvieron apareciendo enlaces en los muros y twitters de muchos de mis amigos esparciendo la voz (como cantaba el mail original: spread the word!)
El primer enlace que ví me hizo ilusión, el segundo también. Me hizo gracia ver el tercero, y el cuarto… pero al llegar la noche y ver toda la gente que se había hecho eco, me quedé encogido y abrumado. Aunque algunos son amigos muy íntimos y ya cabía esperar que me hiciesen este favor, con otros nos conocemos desde hace poco o mantenemos muy poco contacto. No pedí nada a nadie, no tuvo nada que ver conmigo, ellos mismos tomaron la iniciativa de ayudarme. Y no tengo palabras suficientes para expresar mi gratitud.

He recogido algunos de los enlaces y menciones de mi muro (no sé lo que se cocerá en el de Abel, o en los de otros amigos) y los quiero compartir a modo de agradecimiento. Si me dejo alguno por favor decídmelo por email y lo añadiré.

Sobre la PRIVACIDAD: por supuesto si alguien no quiere figurar sólo me lo tiene que decir y quitaré su imágen.

Las imágenes están disponibles al ampliar este artículo…

Read the rest of this entry »

Hace ya un año que mi amigo Abel y yo hablábamos por un chat y decíamos: pues podríamos montar algo, algún proyecto… no sé, algo divertido para poner online. No fueron pocas las reuniones que se sucedieron durante los siguientes meses, en las que planeamos y estructuramos varios tipos de proyectos. Primero fue un sisistema de Wishlists (listas de los deseos), luego un random chat (un chat aleatorio en el que nunca sabes con quién vas a hablar)…. y así con varias ideas. Para todas hicimos esquemas, análisis funcional y de requerimientos del proyecto, y hasta bocetos de pantallazos.
Finalmente optamos por volver a las Wishlists porque nos gustaba. Y es que deseos todo el mundo tiene, y es bonito desear cosas. Resultaba un proyecto divertido y en el que era agradable trabajar.

Hicimos los correspondientes análisis y esquemas, y finalmente le buscamos un nombre. En un principio adquirimos netwishr.com y ya nos gustaba…. pero en breve descubrimos la existencia de la terminación .sh, y no tardamos en comprar el nombre definitivo: uwi.sh.
En español no tiene significado, pero en inglés sí: se pronuncia igual que you wish, que traducido significa tú deseas y es un nombre que suena my bien. Además, para los que no hablan inglés es más fácil aprenderse las letras UWI que todo el carro de Netwishr.

El diseño de los logotipos corrió primero de mano de mi amigo Marc Zamora para el de Netwishr, que no llegó a ver la luz porque aunque el diseño era muy molón, acabamos desechando el dominio y cambiando ligeramente el enfoque. En este sentido tengo que agradecer a Marc su trabajo y disculparme por que al final no se haya publicado.
Después mi amiga Glòria Langreo (aka Eunice Szpillman) nos hizo el logo definitivo que ahora luce en la página de Uwish, así como varias versiones de las moscas.

Para Diciembre de 2009 empezábamos a montar un servidor de desarrollo, los sistemas de seguimiento y los repositorios, y empezamos a programar a un ritmo bastante tranquilo. En Febrero de 2010 teníamos una primera versión con poquitas funcionalidades, pero que estaba muy chula. Adquirimos un servidor potente y pusimos la primera versión online, pero en fase Beta cerrada con invitación. Esto significa que tenías que pedir invitación para registrarte, o te tenía que invitar alguien que ya estuviese registrado. Esta fase duró aproximadamente 2 meses, durante los que se inscribieron unos 60 beta-testers.

El pasado sábado (anteayer) 24 de Abril de 2010, abrimos las puertas de nustro site. Sin invitación, para todos. Por fín, Uwish es una realdad.

Para entender de lo que se trata, Uwish
es una red social para copartir listas de deseos. Cuando uno se registra, crea un perfil en el que va añadiendo deseos (ropa, perfumes, teléfonos, cosas para el coche, etc…). Estos deseos, si se quiere, se pueden clasificar en listas para tenerlos bien agrupados. El objetivo es que los amigos y familiares tengan un sitio donde ir a buscar cuando llegue el cumpleaños, y así no fallar con el regalo :-)

Entre las cosas más guays que le hemos programado, las siguientes:

  • Copiar un wish: si alguien ha introducido ya un wish y a tí te gusta, no tienes que introducirlo otra vez, te lo puedes copiar de él.
  • Conexión con redes sociales: Si quieres puedes conectar tu perfil con tu Facebook y tu Twitter. Así cuando añadas wishes, tus amigos los verán al momento aunque no tengan registro en Uwish.
  • Aviso de cumpleaños: Cuando faltan 15 días para tu cumpleaños, envía un email a tus followers (usuarios de Uwish que han conctado su perfil al tuyo) para avisarles, y les envía algunos de tus wishes como sugerencia.

Acabamos de abrir, el proyecto está recién lanzado, pero yo estoy muy my emocionado y espero que se extienda todo lo posible, porque de verdad es muy muy divertido.

Estáis tod@s invitad@s: Join Uwish NOW! :-D.