lunes, 26 de enero de 2009

script/console con más información

Hacer que cuando usamos el comando script/console, podamos saber lo que tarda en buscar un registro de nuestra BBDD. Por ejemplo el primer post de la tabla POSTS

¿Cómo?
En la raiz de nuestra App, comprobamos desde Terminal con el comando ls -a
que no tengamos creado ya el archivo(.irbrc)
Si no lo tenemos creado, lo creamos y le metemos esto:
script_console_running = ENV.include?('RAILS_ENV') && IRB.conf[:LOAD_MODULES] && IRB.conf[:LOAD_MODULES].include?('console_with_helpers')
rails_running = ENV.include?('RAILS_ENV') && !(IRB.conf[:LOAD_MODULES] && IRB.conf[:LOAD_MODULES].include?('console_with_helpers'))
irb_standalone_running = !script_console_running && !rails_running

if script_console_running
require 'logger'
Object.const_set(:RAILS_DEFAULT_LOGGER, Logger.new(STDOUT))
end

Para crear este archivo hacemos: pico .irbrc esto nos abrira el editor pico. Aquí copiamos el
código que muestro en cursiva y luego pulsamos ctrl+o para guardar el archivo y ctrl+x
para salir del editor de consola pico.

Una vez hechos estos cambios, hacemos: script/console y ahí veremos esto:
script/console
Loading development environment (Rails 2.0.2)
>> Post.find(:first)
SQL (0.000587) SET NAMES 'utf8'
SQL (0.000779) SET SQL_AUTO_IS_NULL=0
Post Load (0.001305) SELECT * FROM `posts` LIMIT 1
Post Columns (0.059535) SHOW FIELDS FROM `posts`
=> #

Como puedes ver, en negrita te muestra los tiempos que tarda la BBDD en hacer las consultas.

¿Qué me muestra script/console si no hago nada de eso?
script/console
Loading development environment (Rails 2.0.2)
>> Post.find(:first)
=> #
Como puedes ver te suelta una información más reducida.

Esto lo he visto aquí [1] y una otra aproximación más sencilla aquí [2]
[1] http://toolmantim.com/articles/system_wide_script_console_logging
[2] http://weblog.jamisbuck.org/2007/1/8/watching-activerecord-do-it-s-thing

Debugging a Rails Application

Cuando estamos desarrollando una App, es muy recomendable depurar o debugearla para ver por ejemplo que valor toma una variable en un determinado momento. O para danos cuenta de que no está tomando ninguno...

De lo que he mirado por el momento sobre el tema de debug (poner a punto) el código, esto es con lo que me quedo:
  1. <%= debug @post %>: Es como un echo de PHP, pero mejor porque te imprime toda la variable de instancia(@post) en la vista.
  2. <%= [1, 2, 3, 4, 5].inspect %> # [1, 2, 3, 4, 5] Útil para imprimir hash y array como string en la vista.
  3. logger.debug "Person attributes hash: #{@person.attributes.inspect}": Esto también esta bien, por ejemplo te puedes dejar recaditos en el controlador, y cuando hagas SCRIPT/SERVER, los veras por el terminal (ej.: esto debería de dar...)
  4. Ruby-debug: Es una gema que nos permite parar la App y meternos dentro de nuuestro código, saber el valor de las variables en ese punto de ejecución, establecer breakpoints,...Ahora lo voy a explicar con un poco más de detalle
Ruby-debug
Lo primero que tenemos que hacer es instalar la gema ruby-debug:
sudo gem install ruby-debug

Lo segundo que debemos de hacer es poner la palabra debugger en la línea del código donde queramos parar.

Después lo que hay que hacer es iniciar el servidor : script/server --debugger
(de momento ruby-debug sólo funciona con mongrel y webrick)

Nota el uso de --debugger. Con esto le estamos diciendo al servidor que arranque en modo debugeo:

Una vez que el servidor haya arrancado, tenemos que navegar por nuestra app e ir a la acción en la que hemos colocado
la palabra debugger. Ej.: Si lo has puesto en el metodo new del controlador historias, tendrás que intentar pulsar el link que te lleva a crear una nueva historia
vamos que te lleva a la acción new. Entonces notaras que el navegador se queda parado y no llegas a ver la pantalla con la vista new.html.erb.

Ahora es momento de que vayas al terminal en el que iniciaste el servidor:
script/server --debugger
Deberías de ver que el Terminal no sigue mostrando información y permanece a la espera. Deberías de ver algo así:
(rdb:13)

Esto quiere decir que el servidor se ha parado y que ahora puedes usar los comandos que te da ruby-debug.

Si más muestro los comandos que a mi me han parecido más útiles:

help
: te muestra todos los comandos de ruby-debug
help
: te muestra ayuda de un comando en concreto.
list:
te muestra tu código. Por donde esta el debugger pasando en ese momento.
backtrace o where
: Muy bueno para aprender. Te muestra todos los archivos de rails que participan en la realización de la petición:
ej.: de backtrace:
#0 PostsController.index
at line /PathTo/project/app/
controllers/posts_controller.rb:6

#1 Kernel.send
at line /PathTo/project/vendor/rails/
actionpack/lib/action_controller/base.rb:1175
#2 ActionController::Base.
perform_action_without_filters
at line /PathTo/project/vendor/rails/
actionpack/lib/action_controller/base.rb:1175
#3 ActionController::Filters::
InstanceMethods.call_filters(chain#ActionController::Fil...,...)
at line /PathTo/project/vendor/rails/
actionpack/lib/action_controller/filters.rb:617
...

En una petición de New a mi controller intervenían 29# archivos
frame n
: Para saltar a uno de esos 29# archivos y ver como se ejecuta el código de Rails y el tuyo y ver que variables hay en juego.
instance_variables
: con este te saca un Array con todas las variables de instancia definidas en ese momento...útil
var instance :
Muestra las variables de instancia de un objeto:
ej.:

(rdb:9) var instance Post.new
@attributes = {"updated_at"=>nil, "body"=>nil, "title"=>nil, "published"=>nil, "created_at"...
@attributes_cache = {}
@new_record = true

En este ejemplo se ven las variables de instancia del objeto (Post.new)
display
: Le dices, muestrame esta variable (por ejemplo @post) según avanzo por el código (con NEXT por ejemplo) y cada vez que avanzas te va diciendo
el valor que va tomando @post. tambien se le puede decr que te lo deje de mostrar undisplay @post.
step
: Avanza por el código como next
pero la diferencia es que next avanza linea por linea y step avanza de bloque de ejecución en bloque de ejecución.

Hay tres formas de poner breakpoints
break
: La palabra break y un nº de linea. P.ej.: si estoy en la linea 3 y quiero parar el código en la nº 5, pongo break 5
break file:line [if expresion]
: Pones la palabra break y después un path a un archivo (ej.: /Users/web/RoR/App/rails2/restblog/app/models/user.rb) aunque
nuestro debugeo haya empezado en un controller, podemos apuntar a cualquier archivo de nuestra App. Despues de los dos puntos hay que especificar el nº de
linea de ese archivo en el que ponemos el break. Lo último no lo he usaro
[if expresion], pero sirve para poner una condición al break, y si se cumple, se ejecuta,
y si no, pasa del break.


break class(.|#)method [if expression]:
pone el break en el metodo de clase(.) o metodo de instancia de esa clase(#):
"set breakpoint in method (. and # for class and instance method respectively) defined in class. The expression works the same way as with file:line.
"
Lo que yo
entiendo lo muestro con un ejemplo:
Tengo un archivo User.rb con un metodo
latest_post definido en el que pilla los últimos 4 post de ese usuario
def latest_post
posts.find(:all, :order => 'id DESC', :limit => 4)
end

Supongamos que yo inicio mi debugger en el controller del modelo User (users_controller.rb). en el metodo index de este controller:


def index
debugger
@users = User.find(:all)
respond_to do |format|
format.html # index.html.erb
format.xml { render :xml => @users }
end
end
el método que hemos definido en el modelo user (en user.rb) -->
latest_post

Lo usamos en la vista index del modelo User (index.html.erb)

<% for user in @users %>
<%= user.latest_post_title %>
<% end %>
vale, ¿situados? ahora si queremos meter un break haremos:
(rdb:5) break User#latest_post

Ahora cuando le demos a cont para continuar el código se nos parara en user.rb:line 4 que es donde hemos definido el metodo en el modelo.

Una vez puestos los break hay 4 comandos que son útiles:
info breakpoints
: te dice los breaks que has puesto ej.:
(rdb:5) info breakpoints
Num Enb What
1 y at users_controller.rb:15
2 y at User:latest_post_title

En este caso he puesto 2 break
enable breakpoints:
Autoexplicativo, habilita los todos los break
disable breakpoints: Autoexplicativo, deshabilita los todos los break
delete n: Borra el break n cuyo nº sabes con info breakpoints
Creo que está bien ruby-debug. A mi me puede hacer la vida más fácil.


Unos links útiles para iniciarte en el debugeo de una App.
De ellos he sacado la información que he puesto en este post:


[1]
http://guides.rubyonrails.org/debugging_rails_applications.html
[2]
http://www.sitepoint.com/article/debug-rails-app-ruby-debug/

sábado, 24 de enero de 2009

Links sobre Git un version control (system) (VCS)

Pues eso, ahora en 2009, es el VCS de moda en el mundo Rails. Tengo previsto mandar una App a producción. Una pequeña, de prueba. Un tontería, pero lo quiero hacer bien, así que voy a aprender a hacer un deployment en condiciones con Git y Capistrano

En este Post dejaré tutos que vea interesantes sobre Git ...
[4] es una página en la que se explica porque nos deberíamos decantar por Git. Por cierto, Git lo hizo Linus Torvals (el creador de Linux) en 2005.

[1] http://www.kernel.org/pub/software/scm/git/docs/user-manual.html
[2] http://www.buildingwebapps.com/podcasts/6894-version-control-with-git/show_notes
[3] http://github.com/guides/home
[4] http://es.whygitisbetterthanx.com/

Comandos útiles para mysql y mysqladmin

Pues eso, para manejar nuestra BBDD desde el terminal. Dos enlaces a dos páginas que dan los comando más usuales para estas tareas. Para mysql [1] y mysqladmin[2].

NOTA:
Por favor, si alguien conoce más recursos útiles sobre estos dos comandos, que deje un comentario y yo los agragare a la lista lo antes posible. Gracias

[1] http://www.pantz.org/software/mysql/mysqlcommands.html
[2] http://luauf.com/2009/01/21/15-usos-practicos-de-mysqladmin/

lunes, 19 de enero de 2009

Ruby QuickRef

Pues eso, aquí [1] dejo una página que tine una referencia bastante completa de cosas como las palabras reservadas en ruby, las variables predefinidas, breve explicación de como se define una clase,...en fin muchas cosas que tal vez un día no encuentres y aquí lo tienes a mano. Anuque seguro que la documentación oficial también está muy bien, y está página con el tiempo estará desactualizada,...pero mientras pueda servir

Actualización:
Aquí dejo otra página que recoge la Doc de Ruby, rails y Rspec [2] Tiene muy buena pinta. La App que está detrás parece estar muy bien hecha. Muchas estadísticas, un estilo visual limpio en las vistas, todo muy organizado,...me gusta.

[1] http://www.zenspider.com/Languages/Ruby/QuickRef.html
[2] http://apidock.com/

domingo, 18 de enero de 2009

Hacer un archivo ruby(.rb) ejecutable desde el Terminal de Mac OS X

1- Hacemos un archivo.
sólo ponemos una linea. Por no complicar
puts "Hola mundo. Desde un ejecutable."

2-Lo guardamos
Lo guardamos como hello_word.rb

3-Lo ejecutamos desde el Terminal
ruby hello_word.rb
NOTA:
Asegurate de posicionarte en el Terminal en el mismo directorio que has guardado el archivo (hello_word.rb).
Supongamos que lo hemos guardado en nuestro escritorio
a-Abrimos nuestro Terminal. Por defecto nos sitúa en la raíz de nuestro usuario:
/Users/andres. Pero queremos ir un nivel más abajo /Users/andres/Desktop
¿cómo?
cd Desktop y ya estamos donde esta nuestro archivo.
Ahora ponemos esto: ruby hello_world.rb
Nos muestra : Hola mundo. Desde un ejecutable.

Bien!
¿Pero y si queremos ejecutar el archivo sin tener que llamar explícitamente a ruby?
Hay que hacer 3 cosas
  1. Dar permisos de ejecución a nuestro archivo: chmod +x hello_word.rb
  2. Poner el PATH donde se encuentra nuestro ejecutable de ruby en la 1ª Linea de nuestro archivo: #!/usr/local/bin/ruby. Poniendo esto nuestro archivo tendra acceso a todos los comandos de Ruby.
  3. Ejecutarlo de la siguiente manera: ./hello_word.rb. No sé que significa el [./], si alguien lo sabe que deje un comentario.
Aún no le he sacado todo el partido a convertir nuestro código en ejecutable, pero seguro que lo tiene.

Comandos Terminal Mac OS X

Hola, este va ha ser un hilo abierto indefinidamente. A menos que se haga muy grande y haga una segunda parte.
¿De que va a tratar?Pues muy senillo. Cuando trabajo desde el terminal tengo que usar comandos. Acabo de empezar con esto asi que no los tengo en la cabeza. Este va a ser el lugar donde los voy a situar y describir.
Como siempre, si veis que alguno se puede definir mejor o esta mal explicado no teneis más que escribirme un comentario. Bueno sin más voy a empezar a poner algunos:

cd: [change directory] Te permite cambiar de directorio
ej.: estoy en /Users/andres y quiero ir a /Users/andres/Desktop. Fácil: cd Desktop.Nota: Si empiezas a poner el nombre del directorio ej.: cd Desk... y presionas tabulador [->|] el terminal te termina de escribir el nombre del directorio donde quieres ir.

pwd: [ print working directory] Pues eso. Al principio cuando empiezas a trastear con el terminal, te sientes perdido. Entonces pones esto en la linea de comandos y te muestra donde estas. Ej.: Si me encuentro en mi escritorio pwd me dirá /Users/andres/Desktop.
rm: [remove] Elimina un file(archivo). No te pide confirmación, así que asegurate de que lo quieres eliminar. ej.: rm miarchivo.jpg
rmdir: [remove dir] Eliminas un directorio vacío. ej.: rmdir micarpetavacia
rm -rf: Borra una caperta y todo lo que contenga. r [recursive] y f [force].

ls: [list] sin argumentos muestra el listado de carpetas del directorio actual (véase la variable de entorno $pwd). Este comando (como todos los demás) esta estupendamente explicado en la wikipedia ahí aparece una lista muy completa de los argumentos con los que se puede acompañar ls. Yo personalmente sólo he usado ls sólo o con el argumento -a que lo que hace es mostrar también los archivos ocultos, que son los que van precedido por un punto (ej.: .bash_login) Este archivo NO lo verás si no haces esto en el directorio donde esta ls -a

which: [which] Te dice donde esta alojado el ejecutable del comando que pones detras de which. Ej.: which ruby en mi caso da /usr/local/bin/ruby.

whereis: [where is] Es similar a which, la diferencia es que te dice donde esta el ejecutable el ejecutable/binario que viene por defecto con el sistema "he whereis utility checks the standard binary directories for the specified programs"
. En mi caso whereis ruby da como resultado /usr/bin/ruby

sábado, 17 de enero de 2009

Instalar Ruby, Rubygems, Rails, Mongrel y MySQL en Mac OS X 10.5 (Leopard)

Acabo de adquirir (hace unos meses, pero hasta ahora no me había puesto) un fabuloso iMac con MacOS X Leopard. Como ya comente en mi post de presentación, lo que más me interesa cuando me siento delante de un ordenador es aprender nociones de desarrollo de App web.
Más concretamente me interesa aprender a desarrollar App web con Rails que es un Framework
que se apolla en el patrón de desarrollo MVC (modelo-vista-controlador). Pero bueno, este no es un post para explicar conceptos, que por otro lado todos podemos aclarar con una búsqueda rápida en Google. Este es un post práctico que se apolla en el gran trabajo realizado por Dan Benjamin alguien que realmente entiende del tema. Así que lo único que hare aquí será enlazar con tres de sus artículos que son los que me han servido a mi para tener todo el software necesario para montar un entorno de desarrollo en Mac OS X 10.5.

Lo primero que dire es que Mac OS X Leopard viene con Ruby y con Rails enstalados de serie. ¿Por que instalarlos nosotros mismos? Voy a citar los motivos que da Dan Benjamin en el primero de los articulos [1].
  1. Para poder desarrollar nuestras App con las últimas versiones de Rails y Ruby, sin tener que esperar a que sean actualizadas por Apple.
  2. El dice que donde están instaladas las versiones de Rails y Ruby que vienen con el SO, son susceptibles de ser cambiadas en una de las actualizaciones automáticas de Apple. Esto nos puede traer problemas según Dan Benjamin.
  3. EL autor hace mucho incapie en instalar todo en usr/local esto lo explica en el segundo artículo que recomiendo [2] "using usr/local". Recomiendo leer con atención este. A mi me han quedado algunas cosas claras que son importantes para que podamos trabajar cómodos en el Terminal de nuestro Mac.
  4. El último motivo que da es para aprender. yo también apollo este motivo. No hay nada como hacer las cosas uno mismo. ¡Ojo! no digo reinventar la rueda. Pero sí ver como funcionan las cosas.
El último articulo que voy a citar de Dan Benjamin es para realizar la descarga y compilación de MySQL [3]. Tengo que decir que en los tres está todo estupendamente explicado, sin embargo yo intente hacer esto mismo hace un año y no lo conseguí. Si acabas de empezar y te falta background para entender alguno de los conceptos que aparecen. Puedes hacer dos cosas, o darte de cabezazos y dejarlo por imposible, o seguir navegando y aprendiendo hasta que todo lo que nombra te sea más familiar. Al final se consigue. como ya he dicho son tutoriales practicos, si sigues los pasos tendrás todo instalado.

Antes de terminar el post, quiero dejar algunas definiciones de algunos conceptos que no tenía claros y gracias a la gente de la lista de RoR en castellano me han quedado claros (gracias a Isaac, cartucoGL, Guillermo y Manuel).

------------------------------------------------------------------------------------------------------------------
NOTA:
Algunas de las definiciones que voy a poner están expresadas con mis propias palabras, así que puede que esten mal o se puedan ampliar, si quieres dejar un comentario para mejorar el post, sera bien recibido.
------------------------------------------------------------------------------------------------------------------
$PATH: Es una variable del SO. Que sirve para decir al Terminal y a los scripts que hagamos por ejemplo en Ruby donde están los ejecutables de Ruby, Rails, mysql...

Comando EXPORT: export es un comando de unix-like para setear variables de entorno, en este caso estás seteando la variable de entorno PATH que la usa el sistema operativo y un millar de aplicaciones unix-like para buscar automaticamente executables, es decir, si tu haces desde la linea de comandos "grep loquesea", el binario grep está en un directorio especificado en el PATH y por esto el sistema operativo lo encuentra y lo ejecuta. El orden de búsqueda va en función del orden en el que aparecen los directorios en el PATH, por esto, si tienes un binario "ruby" en /usr/local/bin/ruby y otro en /usr/bin/ruby, en función de que directorio tengas ANTES en el path, te ejecutará uno o otro cuando pongas "ruby" en la linea de comandos. Si no lo pusieras en el path tendrias que poner /usr/local/bin/ruby para ejecutar el ruby que tu quieres y no el que el sistema encuentra.


NOTA: Puedes ver todas las variables de entorno ejecutando export sin
parametros
host:~ user$ export
declare -x Apple_PubSub_Socket_Render="/
tmp/launch-QXYN2p/Render"
declare -x COMMAND_MODE="unix2003"
declare -x DISPLAY="/tmp/launch-x3MvM8/:
0"
declare -x HOME="/Users/user"
declare -x LANG="es_ES.UTF-8"
declare -x LOGNAME="user"
declare -x MANPATH="/usr/share/man:/usr/
local/share/man:/usr/X11/man"
declare -x OLDPWD="/Users/user"
declare -x
PATH="/opt/local/bin:/opt/
local/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin"
declare -x PWD="/Users/user/dbm"
declare -x SECURITYSESSIONID="ab233ca1"
declare -x SHELL="/bin/bash"
declare -x SHLVL="1"
declare -x TERM="xterm-color"
declare -x TERM_PROGRAM="Apple_Terminal"
declare -x TERM_PROGRAM_VERSION="240"
declare -x USER="user"

Comparativa de sistemas UNIX: Antes he dicho que hay momentos en los que un determinado tutorial te queda grande, no entiendes lo suficiente. En este link se hace una comparativa de SO UNIX
si a tí te puede servir aprovechalo. A mi de momento me queda grande.

Por último pondre 2 preguntas que me surgieron mientras seguía los articulos:

¿Mac OS X trae el .bash_login creado por defecto?

No,no lo trae creado. Hay varios archivos que se cargan donde poder poner variables de entorno y en general inicializar.
/etc/profile
~/.profile
~/.bash_login
~/.bash_profile
~/.bashrc
Obviamente los que empiezan por .bash son solo para cuando uses la shell bash.

¿En cual de los tres debería de poner lo de: "export PATH="/usr/local/bin: /usr/local/sbin:$PATH" ?
Estudia tus necesidades y decide cual usar. Yo lo he puesto en .profile en mi home. Por cierto la home tuya está /User/tunombre.

Hasta aquí la instalación de todo el entorno de desarrollo en Mac OS X para empezar a trastear con Rails. Luego seguro que habra que instalar otras herramientas (Git o subversion por ejemplo o librerías para la manipulación de imágenes con Ruby) pero eso será otro día.

Para cualquier rectificación o duda no dudes en poner un comentario

Enlaces de Dan Benjamin:
[1] http://danbenjamin.com/articles/2008/02/ruby-rails-leopard
[2] http://danbenjamin.com/articles/2005/11/using_usr_local
[3] http://danbenjamin.com/articles/2007/11/installing-mysql-on-mac-os-x

Presentación, ¡hola!

Hola, primero de todo me presento. Soy Andrés, un recién iniciado en esto del "desarrollo" de software. Entrecomillo desarrollo porque ni soy licenciado en informática, ni desarrollador profesional. Soy sólo alguien a quien le gusta aprender.

¿De qué voy a hablar?
Bien, aprender está bien, pero en esta vida hay que centrarse en algo o el cerebro no te da para aprender todo lo que se ha hecho, se está haciendo y se está pensando en hacer...
Básicamente de lo que va este artículo, y en principio el blog es:
  1. Sobre desarrollo o uso de lenguajes de servidor (concretamente Ruby, aunque puede que toque algo de PHP)
  2. Desarrollo de UI para App web ((x)HTML, css y javascript (AJAX) ).

Todo lo que acabo de nombrar NO flota en el aire por arte de magia, detrás están los servidores que son SO (en general Linux) así que también hablare de como poner en producción una App en un servidor. Una App web también requiere del uso de una BBDD. A mi me gusta MySQl, así que puede que salgan cosas sobre ella.

¿Por qué hago un Blog?
Mi motivo es muy sencillo, cuando uno está aprendiendo, tira por muchos caminos diferentes, de algunos sacas cosas en claro y de otros no. Es una pena que las cosas que me quedan claras se pierdan en algún rincón de mi pequeña memoria. ¿no?
Osea que sí, lo hago básicamente para mí, no para ti, ni para ti. Pero si esto que escribe alguien, a modo de apunte, sin talento para escribir y sin formación específica te puede ayudar, me sentiré muy feliz!

Manos a la obra
No me voy a enrollar más, ya conoces lo suficiente de mi. Lo que voy a hacer a continuación es escribir mi primer apunte.

Espero que algo de lo que escriba te pueda servir, y si no es así, sigue buscando, porque "la verdad esta ahí fuera" :-)