JCeb's Blog

Programación, investigación, proyectos, vida y mas…

Archive for the ‘Ocio’ Category

OSlides

with 5 comments

Hola, he andado desaparecido, pero bueno es debido a que he iniciado una empresa con otras personas, para ofrecer servicios en línea, ya luego seguramente contaré al respecto, por ahora traígo uno de los proyectos que he desarrollado en Mozilla México, el proyecto se llamó al principio MozMXSlides, pero lo he renombrado a OSlides, pues he abreviado OpenWeb como solamente O y bueno pues el proyecto consiste de una presentación en HTML5 con CSS3 transitions y javascript.

Esta presentación que he estado trabajando en los últimos 3 meses, ha sido ya presentada por Chris Hoffman en Paraguay, la he presentado en el Simpositi3, se ha utilizado en el Foro Internacional de Software Libre en Tapachula y otros más eventos en la republica Mexicana.

La presentación actualmente cuenta con un efecto de zoom-rotatorio para cada slide. Seguramente en futuras versiones ofreceremos personalización de eventos y mil y un cosas más, por lo pronto la presentación es límitada, pero bastante útil sobre todo para exponer y demostrar lo interesante del movimiento openweb.

si quieren ver un demo en vivo pueden ver la presentación de Firefox4 por Mozilla México.

http://mozilla-mexico.org/slides/firefox4/

Les dejo la liga a la página del proyecto en github, donde lo pueden bajar y probar:

http://julianceballos.github.com/MozMX-Slides/

Written by JCeb

21 diciembre, 2010 at 5:42 am

Proyecto de Software colaborativo online

with 4 comments

Muchas veces sucede que decimos “vamos a trabajar en linea”, trabajar en línea es muy recomendable, pero hay que saber cómo hacerlo, ya que de ello depende el éxito de nuestro proyecto.

Existen herramientas sugeridas para hacer este desarrollo, personalmente recomiendo:

Un administrador de versiones

¿Qué es?, bueno el administrador de versiones sirve para que cuando programamos un código vayamos controlando el progreso que vayamos obteniendo conforme el paso del tiempo.

Administrador de versiones colaborativo
¿Qué es?, así como podemos controlar nuestro código por persona, puede ser que cada participante quiera controlar su progreso, pero además, plantiemos la siguiente pregunta:
¿Cómo le hacemos para que Juanito Perez me pase la parte que le tocó?, bueno para resolver ese problema podemos usar uno de muchos administradores de versiones colaborativos que hay, por mencionar algunos:

-GIT
-SVN(Subversion)
-CVS
-HG(Mercurial)

Con estos administradores de versiones colaborativo podemos responder la pregunta anteriormente planteada y resolvemos la administración de nuestro producto al ír generando versiones.

Administrador de proyectos
¿Qué es?, bueno el administrador de proyectos sirve para que allí se anoten y establezcan las tareas y responsabilidades por proyectos y por persona, tambien sirven para medir el progreso de un proyecto, en lo personal porqué los he usado recomiendo 2:

-Project Pier
-Active Collab

Wiki
Uno de los últimos sistemas para administrar contenido que han surgido, lo interesante en las wikis es que se pueden hacer contenidos colaborativos de manera muy sencilla.

¿Para que nos puede servir?, la wiki puede sernos de utilidad para expresar los objetivos del proyecto a las personas que se vayan incorporando conforme la marcha. También puede servirnos para colocar temas acerca de colaboraciones que cada integrante desee aportar, ha aportado y hacer documentación que ayude a los desarrolladores que en futuro se deseen integrar.

Lista de correos
La comunicación es muy importante, por ello debe existir una lista de correo, donde con enviar el mensaje a la lista, este se distribuye entre todos los integrantes de la lista y no es necesario mandar mensajes a cada persona del equipo de trabajo.
Las herramientas que puedo recomendar porqué las conozco son:
– Mailman
– google groups

Salas de conferencia
Muy bien en determinados momentos es necesario tener que vernos y hablarnos, por ello existen sistemas de conferencia como skype, dimdim, entre muchos otros para hacer conferencias por voz y/o video.

Administrador de bugs
Cómo ninguna herramienta es perfecta, es necesario tener un sistema para administrar los bugs que tanto usuarios como desarrolladores logren detectar, así también como sugerencias para el mejoramiento continuo del producto. Personalmente porqué estoy familiarizado recomiendo BugZilla, que es fácil de usar y muy completa funcionalmente.

Ejemplo práctico
Como no todo es simplemente explicar y ya con ello entenderan todo, aquí va un ejemplo práctico.

El proyecto se llama “test”

primero se crea el proyecto, uno del equipo lo crea y… ¿Cómo lo creo?, bueno simplemente basta con entrar a github.com y abrir la cuenta, luego nos dice github si queremos crear un nuevo repositorio, por lo que debemos llenar la información que se nos requiere y una vez realizado esto nos da las instrucciones github.com paso a paso.

Pero no nos dice nada más respecto a como trabajar con nuestro equipo.

Para poder trabajar en equipo debemos de realizar lo siguiente:

Cómo administrador
1. Ir al repositorio del proyecto en este caso llamado “test”
2. Presionar el boton que dice “admin”
3. Ir a la sección que dice “colaboradores”
4. Añadir al/los colaboradores

Como colaborador
1. Ir a las configuraciones de nuestra cuenta
2. Clic en donde dice Llaves SSH públicas
3. Clic en agregar llave pública ssh
… ¿Cómo creo mi llave publica?, bueno github nos dice cómo en estas ligas:
http://help.github.com/mac-key-setup/ para OSX
http://help.github.com/msysgit-key-setup/ para Windows
http://help.github.com/linux-key-setup/ Para Linux

4. Clonar el proyecto, esto se hace de la siguiente forma:
Se accede al sitio del proyecto por ejemplo:

http://github.com/julianceballos/test

Ahí dice en un cuadro la ruta a copiar y conectarse por medio de ssh, algo así: git@github.com:julianceballos/test.git
Así que para clonar el proyecto debemos hacer:

$ git clone git@github.com:julianceballos/test.git

Hecho esto debe de crearse una carpeta llamada test
5. Una vez clonado nuestro proyecto, podemos comenzar a hacer colaboraciones, como modificar los archivos existentes o crear nuevos archivos, por ejemplo si hemos creado un nuevo archivo o aun más, una carpeta con archivos dentro simplemente basta con hacer:

$ git add carpeta/*
$ git add archivo_nuevo

6. Establecer punto de resguardo, esto es una vez que digamos tener una etapa de nuestro desarrollo, lista, hacemos un commit, para que sirve el commit?, es como un punto de respaldo, siempre que querramos podemos navegar entre los commit y podemos ver como quedó nuestra aplicación en un momento determinado, para hacer commit solo basta con:

$ git commit -am 'he llegado a un punto de satisfaccion'

7. Subir los cambios o continuar trabajando. Cuando hayamos terminado una mejora en nuestra parte del proyecto podemos subir los cambios o continuar trabajando en local y hacer commits cada vez que sintamos que es necesario guardar un historico de nuestro desarrollo. Si en cambio sentimos que ya estamos listos para subir las mejoras porqué se acerca una fecha de revisión o algo, solo basta con hacer:

$ git push origin master

8. No olvidar antes de hacer un push, primero hacer un pull, es decir primero jalar el repositorio para comprobar que tenemos una versión de todas las fuentes actualizadas.

Hasta este punto todo bien, a excepción de cuanto no hacemos pull, dejamos de revisar las actualizaciones del repositorio, modificamos archivos que a otra persona le han correspondido, usamos el master para experimentar, etc. Usualmente si se distribuye bien el código por módulos, se puede tener durante el proceso de desarrollo una programación correcta y jamás habrá problemas, pero como bien dicen “Si hay la probabilidad de que suceda, sucederá”, así que veamos una manera de resolver el problema de incompatibilidades en las versiones, fechas y nombres de los archivos. Para esto existen las famosas RAMAS de desarrollo, por ejemplo:

Partamos de un tronco común que es este caso en github se llama MASTER, este tiene ramas(sip, como un árbol), las ramas pueden ser:

- MASTER
– Modelos
– Vistas
– Controladores

Pero Modelos puede tener ramas y esas ramas son los desarrolladores que participan en esta capa del proyecto, por ejemplo:

- MASTER
– Modelos
– Juan
– Emmanuel
– Paco
– Vistas
– Controladores

¿Y qué son las ramas?, simplemente son una copia de su origen, por ejemplo Emmanuel es una copia de Modelos, que a su vez Modelos es una copia de MASTER, lo que sucede es que Modelos es una composición de MASTER con código nuevo que se ha generado por el equipo dedicado a esa área, la rama Juan es una composición de MASTER+Modelos + Código que Juan ha agregado para evitar que haya incompatibilidades entre los código que sus otros compañeros estan escribiendo.
Para generar branches solo basta con hacer:

$ git branch myBranch

Para cambiar entre branches solo basta con escribir:

$ git checkout myBranch

Para ver en que branch nos encontramos:

git branch

Aparecerá marcada con un * la rama en la que nos encontramos.

Una vez programadas las cosas el administrador del proyecto es quien tiene que mezclar todos los códigos de los participantes, esto se hace con un merge:

$ git merge mybranch

Lo que sucede es que lo que se haya programado en mybranch se mezcla con lo que se tiene en el branch donde te encuentras ubicado.

Listo, hacemos push y ya quedó nuestro proyecto, basicamente eso estará sucediendo todo el tiempo, cada quien hace su parte, se mezclan y se lanzan por versiones.

Para establecer las versiones solo basta con hacer:

$ git tag -a v1.0 -m 'Test 1.0'

Para subir el tag:

$ git push origin v1.0

Para subir todos los tags:

$ git push origin --tags

Al bajar desde la página de Github todos los tags apareceran listados, disponibles para descargar el de tu preferencia.

Por otra parte, el wiki que tiene github es útil y nos evita tener que crear uno, para que sirve?, es posible ahí escribir todas las partes en que consiste el proyecto e incluso escribir a quien le corresponde cada parte, por otro lado no es la mejor manera, por lo que para asignar y autoasignarse tareas es preferible utilizar el project pier, la lista de correos es para ponerse de acuerdo y la wiki simplemente para escribir objetivos, las caracteristicas del producto por versión y muchas otras cosas, como el equipo de desarrollo, etc.

Los medios de comunicación sean de voz o video son geniales para tener reuniones pseudo presenciales con el equipo de desarrollo, para tomar desiciones sobre lo que se puede mejorar, agregar al producto, etc.

Bueno espero este post sea de utilidad, no es una guía definitiva, es para tener una ídea de como trabajar en equipo, en lo personal me ha servido todo lo mencionado y no he tenido probemas =). Saludos.

Written by JCeb

3 septiembre, 2010 at 11:36 pm

No confundas tu vaso XD

leave a comment »

Bueno este artículo es una cosa ociosa que surgió de mi mente.

Seguramente les ha pasado que van con los amigos y uno va a rellenar los vasos y siempre buscan una manera de diferenciarlo. Bueno esta es una manera de no confundirlo, si se dan cuenta en la tapa hay 3 indicadores para saber el contenido del vaso.

Si analizamos la tapa con esos 3 indicadores podemos tener 8 combinaciones posibles de estados. Usenlos para diferencias los vasos ;) y nunca más se confundan jeje! =D.

P.D. Si le quitan la tapa se chingan XD JAJAJAJAJA!. Saludos a todos.

Written by JCeb

2 agosto, 2010 at 2:31 am

Publicado en Ocio

Tagged with , , ,

Mi aventura por el mundo apple

with 3 comments

Pues me he pasado al lado de la luz, tranquilidad y simplicidad sobre todo, he comprado una macbook pro de 13″.

¿Porqué?, bueno comenzaré a desarrollar en cocoa con unos compañeros un producto de administración personal, así que he hecho esta inversión.

Hasta ahora estoy feliz, las aplicaciones que recomiendo son:

-Komodo

-Things

-Pomodoro

-Twittie

-Adium

-Thunderbird

-Firefox

-Xpad

-Sequel Pro

-Openoffice

-MenuMeters

-Burn

-ShiftIt

-UnrarX

-VirtualBox ó Parallels

-Skype

-Cyberduck

Las herramientas son para desarrolladores jeje!, pero varias son de proposito general =).

Por el lado de desarrollo ya he realizado 3 pequeños ejemplos y ya le voy agarrando la onda al cocoa. Un gran framework a mi parecer, lo seguiré checando para ya comenzar a trabajar lo más pronto posible.

Gracias por leer este post.

Written by JCeb

20 julio, 2010 at 9:28 pm

Publicado en Desarrollo, Investigación, Ocio

Tagged with , , ,

Objetivos 2010

leave a comment »

Hola, bueno hago públicos mis objetivos para este año =).

  • Consolidar empresa de desarrollo de tecnologías para logistica y planeación
  • Consolidar Asociación Civil Nacnati
  • Evangelizar el desarrollo de addons para Mozilla
  • Evangelizar el desarrollo de comandos para Ubiquity aunque este descontinuado el proyecto

Written by JCeb

24 junio, 2010 at 1:35 am

Publicado en Desarrollo, Investigación, Ocio

Getting Things Donde & Pomodoro

with 3 comments

Hola amigos, este artículo lo escribo para compartir lo que he sentido en el poquito tiempo que he estado combinando GTD con Pomodoro, primero que nada les dejo aquí dos enlaces donde pueden leer que es pomodoro y que es GTD.

http://es.wikipedia.org/wiki/Getting_Things_Done

http://templocreativo.com/blog/productividad-la-tecnica-del-pomodoro/167

http://www.pomodorotechnique.com/

http://www.davidco.com/

Bueno despues de haberse documentado de que son estos dos temas de los que les voy a hablar de cómo combinarlas =). En mi experiencia son compatibles y no tienes porque pelearte con ellas, facilmente puedes usarlas, pero claro habrá que hacer algunas excepciones a ciertas reglas y eso.

Bueno vamos al grano, para explicar como combinarlos pues tengo que poner ejemplos y bueno comencaré diciendo que estos métodos son compatibles puesto que GTD es para administración de tareas y Pomodoro es para administrar tiempos.

  1. Bueno supongamos que llegamos a la oficina, nos sentamos, respiramos y comenzamos.
  2. Lo primero que vamos a hacer es usar alguna aplicación o lo que sea para administrar nuestros tiempos como dice pomodoro, arrancamos el primer pomodoro.
  3. Lo que haremos en este primer pomodoro es planificar nuestras actividades como GTD dicta, acciones próximas, proyectos, en espera y algún día. Claro si nos lleva muy poco tiempo, es decir menos de 5 minutos interrumpimos el pomodoro y reiniciamos con un nuevo pomodoro.
  4. Durante el pomodoro vamos realizando tareas que hemos anotado en GTD y conforme vayamos realizando vamos marcandolas como hechas.
  5. Luego cuando llega el break, nos tomamos 2 minutos para usar alguna referencia que nos ayude a que cuando regresemos del break no olvidemos donde nos quedamos.
  6. Una vez finalizados los 2 minutos nos vamos al break respetando lo que dice Pomodoro, es decir que durante el break no hagamos ningun esfuerzo mental y dejemos que el cerebro se relaje.
  7. Bueno, regresamos a nuestro trabajo con un nuevo pomodoro y lo primero es leer donde nos quedamos para rapidamente tomar el hilo de lo que estabamos haciendo.
  8. Transcurridos los 4 pomodoros como dice pomodoro pueden tomar un descanso entre 15 y 30 minutos.

Bueno así es cómo yo he combinado Pomodoro con GTD, recomiendo la aplicación:

http://mytomatoes.com

Written by JCeb

30 mayo, 2010 at 3:20 am

Publicado en Desarrollo, Investigación, Ocio

configuración de mod_python con apache

with 2 comments

apache
mod_python

Aquí les dejo un rápido post sobre como configurar el mod_python con apache, no es para principiantes, pero si lo eres no te preocupes, te dejo estas ligas donde lo explican más desmenuzado:

http://bishoujolinux.comxa.com/2010/01/django-y-opensuse-una-poderosa-combinacion/

http://stackoverflow.com/questions/582631/setting-up-django-with-mod-python-apache-on-suse-with-alias

http://www.esdebian.org/foro/32475/configuracion-django-apache2-modpython

En lo personal me agrada más wsgi pero me dió flojera instalarlo en opensuse ya que no lo trae por default y vi más fácil configurar el apache con mod

_python para ejecutar un sistema del trabajo en django.
Los pasos son:

1. Instalar mod_python

2. Activar mod_python en las configuraciones del apache que por lo general estarán en /etc/apache2/

3. Crear un archivo lla

mado python.conf dentro de /etc/apache2/conf.d/

4. Agregar el siguiente contenido a python.conf

<Directory /srv/www/htdocs/asireports/>
  SetHandler python-program
  PythonHandler django.core.handlers.modpython
  SetEnv DJANGO_SETTINGS_MODULE settings
  PythonOption django.root /srv/www/htdocs/asireports
  PythonDebug On
  PythonPath "['/srv/www/htdocs/asireports']+sys.path"
  DirectoryIndex settings.py
</Directory>

5. Guardamos el archivo, copiamos nuestro proyecto a la ruta que definimos y tendremos que cambiar algunas cosas en nuestro código, ya que como hemos puesto asireports como directorio del apache ya no es directorio de proyecto si no una carpeta y en nuestros settings tendremos que eliminar de todos lados asireports que era el nombre en este caso de mi proyecto. Por ejemplo ROOT_URLCONF=asireports.urls ahora será ROOT_URLCONF=urls

y en las urls del proyecto tendremos que agregar a cada una asireports, por ejemplo /direccion ahora será /asireports/direccion

Hechos estos cambios, debe de funcionar nuestro apache con Django. Se aceptan mejoras al contenido, lo hice rápido por lo que omití muchos detalles. Saludos.

Written by JCeb

4 mayo, 2010 at 11:39 pm

Publicado en Desarrollo, Investigación, Ocio

Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.