VERSION ACTUAL :

Inicio de sesión

Raulito el Friki

Raulito El Friki

COMENTARIOS

EN LINEA

Hay actualmente 0 usuarios conectados.

NUEVOS

  • maestrodenada
  • usetecknics
  • ivanferraz
  • erasmo1916
  • l-xan

Agregador de canales de noticias

“Profe, ¿y esto para qué vale?”, mi conferencia en el II CEAM CLM

Gaussianos - Mar, 02/10/2015 - 05:45

El pasado día 16 de enero de 2015 tuve el honor de dar la conferencia de clausura del II CEAM de Castilla-La Mancha invitado por Juan Martínez Tébar. La charla en cuestión llevaba como título Profe, ¿y esto para qué vale?, y el objetivo de la misma fue dar algunas ideas, con ejemplos concretos, para responder a esa pregunta tan repetida por los alumnos de los distintos niveles educativos.

Podéis ver la charla completa en el siguiente vídeo:

"Profe, ¿y esto para qué vale?" Gaussianos en el II Congreso de Enseñanza y Aprendizaje de las Matemáticas from CRFP CLM on Vimeo.

Y no quiero dejar escapar esta oportunidad para destacar que en este evento tuve la oportunidad de conocer, entre otras personas, a Antonio Pérez Sanz y a Fernando Cuartero, además de poder compartir tiempo y conversación con el propio Juan Martínez Tébar, con Juan Medina (que también participó en el evento hablando de Owlas) y con José Ángel López Mateos y su compañera (no recuerdo el nombre), a los que además les tengo que agradecer que me devolvieran sano y salvo a mi humilde morada.

Entra en Gaussianos si quieres hacer algún comentario sobre este artículo, consultar entradas anteriores o enviarnos un mensaje.

Construye tú también el poliedro de Császár.

Optimiza el HTML, CSS, JS e imágenes de tu sitio web con Gulp

Skatox - Lun, 02/09/2015 - 08:00

Uno de los retos de los desarrolladores web al momento de crear páginas web, es encontrar el equilibrio perfecto entre ofrecer un sitio con excelente apariencia visual y usabilidad, pero cuyo tamaño sea lo menor posible para que la carga sea rápida. Pues un sitio web rápido permite: tener mas visitas con el rendimiento actual del servidor, se ahorran costos de ancho de banda, los usuarios sienten que es una buena página y navegan mas tiempo por ella, entre otras. Este procedimiento incluye varias tareas que realizan muchos desarrolladores web como: usar las versiones reducidas (comprimidas) de Javascript, comprimir y ofuscar nuestro código del lado del cliente,  optimizar las imágenes del sitio, comprimir los archivos CSS, combinar todos los archivos CSS y Javascript en un sólo archivo (para cada tecnología) para reducir el número de conexiones, etc. Algo que no es complicado pero consume tiempo y que se debe repetir cada vez que se hacen cambios en el sitio.

Gulp

Como este proceso es repetitivo y consume tiempo, lo mejor es hacer un script que automatice cada etapa, pero hoy en día existen herramientas como que nos permite facilitar todo lo mencionado anteriormente. En este artículo hablaré sobre Gulp, una herramienta para automatizar tareas que hace lo mismo que GruntJS pero es mas fácil de usar y entender.

¿Cómo empezar?

Para instalarlo, lo hacemos a través Node Package Manager de forma global para que se instale como un comando del sistema y poder ejecutarlo en cualquier parte:

npm install -g gulp

Luego en la raíz del proyecto creamos un archivo gulpfile.js donde especificaremos las tareas a realizar:

var gulp = require('gulp');
gulp.task('default', function() {
});
Añadir una tarea

Una tarea es un conjunto de procesos, por ejemplo, optimizar el código JS consiste en: reemplazar algunas liberias por sus versiones CDN, utilizar las versiones minificadas de librerías de terceros, luego concatenar los archivos, minificar y actualizar las referencias en el HTML. Cada uno de estos procesos podemos encontrarlos en el buscador de complementos de Gulp (en caso de no existir alguna puedes crearla y publicarla en Github) y se instalan con npm.

Gulp posee una importante característica: su sistema de flujos entre tareas. Cada una de ellas recibe un conjunto de data (generalmente archivos), realiza un proceso en ella y produce nueva data para ser enviada como entrada a otro flujo. Esto permite a tareas que modifiquen gran de archivos, hacer este procedimiento en RAM y solo escribir en el disco cuando ya se ha terminado de procesar todos los archivos, por lo que se ejecutará muy rápido.

Para verlo en acción, haremos una tarea para reducir el tamaño de los archivos JS como ejemplo, entonces nuestro primer paso es instalar el plugin uglify con NPM:

npm install --save-dev gulp-uglify

Luego se deben hacer dos cosas en el archivo gulpfile.js, una es importar esta el complemento en las dependencias y asignarla a una variable, luego con esta variable podemos ejecutar la función que se encargará de (en este caso) reducir el tamaño del código javascript. Para ello debemos hacer lo siguiente:

var uglify = require('gulp-uglify');
gulp.task('comprimir', function() {
gulp.src('lib/*.js')
.pipe(uglify())
.pipe(gulp.dest('dist'))
});

Como podrás observar, hemos creado una tarea llamada comprimir , que recibe un conjunto de archivos (los archivos JS ubicados dentro de /lib), crea una tubería y ejecuta uglify que se encargará de comprimir cada uno de los archivos, finalmente entrega el resultado a la tubería que se enviará a la ruta de destino (esta se puede definir a donde uno desee). Así sucesivamente podemos ir creando procesos como los mencionados anteriormente y luego agruparlo en unas tareas mas generales, por ejemplo, tareas para generar una versión para depurar (cuya fuente no este comprimida), una versión para producción, una versión de producción para pruebas, entre otros. Esto lo puedes hacer al final haciendo algo como esto:

gulp.task('produccion', ['comprimir', 'copiar','cdn', 'less']);
Ejecutar las tareas

Finalmente puedes ejecutar el comando gulp en la raíz de tu proyecto y empezará a realizar todas las tareas de forma automática. En caso de que quieras ejecutar solo una tarea, puedes pasar por parámetro el nombre de la tarea:

gulp produccion

Con esto generas la versión de producción, o  por ejemplo, si tienes una tarea llamada less para generar los archivos CSS desde LESS, simplemente ejecuta:

gulp less
Tareas recomendadas

Para optimizar un sitio web, generalmente utilizo imagemin, jshint, minify-css, notify, imagemin-pngquant, uglify, usemin. Con estas puedo comprimir imágenes, mejorar el código javascript, concatenar archivos, reducir el tamaño, entre otros. Aunque te recomiendo leer un artículo de Addy Osmani sobre optimización de webs, pues lista una gran cantidad de tareas que puedes ir probando para usar al momento de mejorar tus sitios.

Finalmente, como te darás cuenta con Gulp puedes crear sitios web mas óptimos y ahorrando mucho tiempo. Existen una gran cantidad de tareas existentes que puedes agregar a tu proyecto y facilitar tu trabajo, por eso te recomiendo chequearlas en el buscador de plugins de Gulp y si no existe, puedes crearla y ayudar a otros programadores que necesiten algo similar.

Libro: Seguridad en Unix y Redes

elj0na - Sáb, 02/07/2015 - 00:16

Partiendo la lectura de un nuevo libro SEGURIDAD EN UNIX Y REDES

Seguridad_Unix_Redes-OpenLibra-350x459


FEDORA 21 RELEASE PARTY LEON!!!!

Fedora Nicaragua - Jue, 02/05/2015 - 10:26
Este es un Repost del Articulo Publicado por Franko Ramírez en su blog para que aparezca en el Planet Fedora, en la Fiesta de Lanzamiento trabajaremos en indexar su blog al Planet.

Por favor visiten la publicación original en: https://networkfreesoft.wordpress.com/2015/02/05/fedora-21-release-party-leon/



Buenas noches, es para mí un honor poder anunciar que para este próximo sábado 7 de Febrero del año en Curso, se estará dando la primer actividad de Fedora en la ciudad de León, Nicaragua, comenzando desde las 2:30 con conferencias para todos los gustos y necesidades.
La actividad tendrá lugar en uno de los auditorios del edificio básico de la UNAN León. Contaremos con la participación de la Comunidad Local y de la Comunidad de Fedora Nicaragua.
Entre los participantes expositores tenemos a Neville Cross, embajador de Fedora en Nicaragua y uno de los principales promotores del Sistema Operativo. Además de él, contaremos con la participación de William Moreno quien llevará una charla sobre Cockpitp y otra sobre Emprendedores. Cabe destacar que tanto William como Neville no son informáticos de Estudio pero si de aplicación, lo cual viene a demostrar y desmentirde que el Software Libre está únicamente enfocado en aquellos con altos conocimientos de computación.
Omar Zapata y Franko Ramírez, miembros de la comunidad de Fedora León y parte del staff organizativo del mismo, impartirán una charla sobre Arduino y Fedora. Arduino es una plataforma de Open Hardware con gran potencial de desarrollo para pequeños sistemas domóticos e industriales.
Otra de las charlas que realmente motiva a muchos estudiantes de informática, sistema y telemática es la conferencia sobre Fedora Server, el último release de la versión en Servidores de Fedora promete dar de que hablar para bien y dejar a muchos boquiabiertos con las innovaciones que traen tanto en términos de funcionalidad como de seguridad, tan importante esta última que se ha decidido llegar una charla sobre ella para el día del evento.
Por último, la presentación de la comunidad, formas de colaborar y sobre todo, las mejoras que trae la última versión oficial del aclamado sistema operativo Fedora en la charla del Release Party promete llevar la experiencia a otro nivel con una mesa de instalación para aquellos que decidan a probar esta alternativa diferente al software convencional.
Ven y anímate este 7 de Febrero y déjate enamorar en este mes del amor y la amistad de un sistema diferente, estable y seguro y de una comunidad local naciente, pero con ánimos de hacer grandes cosas en pro del conocimiento libre.
Para mayor información puedes seguir el evento en Facebook, haciendo click al siguiente enlace: https://www.facebook.com/events/1021081117905336/?fref=ts

Configuración inicial de un servidor CentOS

HelloIT - Jue, 02/05/2015 - 07:07

centosHace ya unos años, y sin ningún software de administración tipo Puppet/Chef/Ansible, creamos un documento para que todos los técnicos pudieran decir la suya respecto a los pasos a dar tras instalar un sistema operativo Linux (CentOS en nuestro caso), con tal de no olvidarnos ninguno e ir mejorando entre todos este proceso de configuración inicial de un servidor. Eso significa que si tú, amado lector, tienes cualquier sugerencia de mejora, no dudes en dejarla en los comentarios.

Hoy en día, ese documento, muy pensado para instalaciones CentOS 6, tanto en entornos Cloud Computing como para en máquinas propias, es algo parecido a lo que listo a continuació.

NOTA: No te tomes todos los puntos al pie de la letra, seguramente querrás valorar si lo que propongo a continuación tiene sentido en tu entorno antes de aplicarlo, y seguro que más de un punto es mejorable.

1. Actualización del SO

Tras la instalación, es una buena idea forzar un update para estar a la última de los paquetes de nuestro SO.

yum update
2. Deshabilitar selinux

Selinux es una herramienta útil, pero que no compensa, y proporciona más dolores de cabeza de los que pretende solucionar. Es por eso que proveedores como RackSpace o Hetzner proveen sistemas con Selinux deshabilitado de fábrica. Si aún así quieres trabajar con Selinux, seguramente este sea el momento de configurarlo adecuadamente. En caso contrario, símplemente deshabilitalo tal y como sigue:

vi /etc/selinux/config SELINUX=disabled

Tras deshabilitarlo, será necesario reinciar el sistema para activar los cambio. Así pues, reinicia para evitar tener problemas con los próximos pasos.

3. Usuarios de sistema

Especialmente si se trata de una máquina creada a partir de una AMI (Amazon), pero en general con cualquier instalación del SO que no sea la oficial, se deberá revisar el archivo /etc/passwd en busca de usuarios creados en la propia AMI, y:

    • Cambiar el password del usuario de root
    • Deshabilitar (ponerles como shell un /sbin/nologin) o eliminar los usuarios innecesarios
    • Crear los usuarios (no root) que se usarán para conectar con el sistema via SSH.
    • Crear el Grupo de usuarios que se usará para aceptar conexiones SSH (por ejemplo "sshusers") y añadir a él los usuarios que usaremos para conectar via SSH (se habla de ésto en profundidad en el punto 5).

Para crear el grupo, bastará con ejecutar:

groupadd sshusers

Tras ello, podremos añadir los usuarios que tendrán acceso SSH al grupo, editando el fichero de grupos:

vi /etc/group

Además, se recomienda revisar el fichero sudoers para tener una idea de los usuarios que tienen permisos para hacer sudo, y quitar del mismo a los usuarios innecesarios.

cat /etc/sudoers

Recuerda usar "visudo" si vas a editar este fichero.

4. Cambiar useradd por defecto

Otra costumbre que tenemos es cambiar el default template del comando useradd para que los usuarios que se crean sin especificar shell, por defecto no tengan acceso a ninguna shell. Así evitaremos tener, por descuido, usuarios con acceso a la shell que no deberían tenerlo. Para ello, bastará con editar el fichero "useradd" e indicar como shell "/sbin/nologin":

vi /etc/default/useradd SHELL=/sbin/nologin/
5. Configurar OpenSSH correctamente

Se deberá revisar el fichero de sshd para permitir únicamente los métodos de conexión seguros. En este punto hay un muchas posibilidades y seguramente ésto sea suficientemente complejo como para contar con su propio post, así que te recomendaría documentarte un poco sobre cómo configurar OpenSSH de forma segura, antes de aplicar nada.

En mi caso, en este post me centraré en:

  • Asegurar que el protocolo de conexión es seguro
  • No permitir acceso SSH como root
  • Únicamente permitir acceso SSH a los usuarios autorizados (nunca "root"). En el ejemplo se tratará de los usuarios que pertenezcan al grupo "sshusers" que hemos creado en el punto 3.
  • Controlar el número de accesos para evitar ataques

Bastará con aplicar las siguientes directivas en el fichero de configuración "/etc/ssh/sshd_config":

Protocol 2 PermitRootLogin no MaxAuthTries 3 PasswordAuthentication yes MaxStartups 3 AllowGroups sshusers

Después de modificar, reiniciar el servicio sshd sin abandonar nunca el terminal actual, pues en caso de equivocarnos en algún punto, el terminal actual nos permitirá modificar la configuración de OpenSSH aun cuando hayamos cerrado el acceso por error.

/etc/init.d/sshd restart

Así pues, abriremos un nuevo terminal (repito: sin cerrar el actual) e intentaremos conectar con un usuario del grupo sshusers para comprobar que funciona. Una vez dentro, comprobaremos que también podemos cambiar a root sin mayores problemas:

su root -

Otra buena práctica, es intentar conectar por SSH directamente con root para verificar que en efecto, no podemos.

6. Configurar iptables

Tengo la sensación de que mientras escribo estas líneas, la explicación queda obsoleta, pues en las nuevas versiones basadas en RHEL7 iptables ha sido substituido por firewalld. En cualquier caso, respecto a iptables, usaremos un script cuya base servirá para únicamente aceptar las conexiones de entrada que se especifiquen de forma explícita.

Para ello, crearemos un fichero con el siguiente código (adaptado a las necesidades) para posteriormente ejecutarlo una vez, lo cual dejará iptables configurado.

cd path_to_scrips_folder vi set_iptables.sh
#!/bin/bash # Flush chains iptables -F INPUT iptables -F FORWARD iptables -F OUTPUT iptables -F   # Set up default policies iptables -P INPUT DROP iptables -P FORWARD DROP iptables -P OUTPUT ACCEPT   # Related and localhost iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A INPUT -p icmp -j ACCEPT iptables -A INPUT -i lo -j ACCEPT   # Custom rules. Ej: # iptables -A INPUT -p tcp --dport 80 -j ACCEPT # iptables -A INPUT -p tcp --dport 443 -j ACCEPT   # Save settings service iptables save   # List rules iptables -L -v

Una vez añadidas las reglas necesarias, deberemos asegurarnos de que iptables se ejecuta al inicio, y posteriormente dar permisos de ejecución al script para poder aplicar los cambios.

chkconfig iptables on chmod 750 set_iptables.sh ./set_iptables.sh
7. Revisar los procesos de inicio

Se recomienda también, ver qué procesos se están ejecutando de inicio con la máquina, y deshabilitar aquellos que no interesen. Este punto está pensado para instalaciones de imágenes que no sean la Oficial de CentOS, como las AMIs de AWS o las imágenes predefinidas de RackSpace o Hetzner.  En general, si no te has bajado tú la imágen de CentOS de la página oficial, es interesante revisar este punto.

Con el siguiente comando, podremos listar los procesos que pueden ejecutarse al inicio, según el runlevel.

chkconfig --list
8. Configurar la zona horaria y el servicio de NTPd

Otro punto clave es mantener la hora de todos los sistemas sincronizada y actualizada, para evitar discrepancias. Para ello, podemos valernos de ntpd, el cual si no viene instalado se puede obtener con yum (yum install ntp).

grep -v "^$" /etc/ntp.conf | grep -v "^#" driftfile /var/lib/ntp/drift restrict default kod nomodify notrap nopeer noquery restrict -6 default kod nomodify notrap nopeer noquery restrict 127.0.0.1 restrict -6 ::1 includefile /etc/ntp/crypto/pw keys /etc/ntp/keys server 0.es.pool.ntp.org server 1.europe.pool.ntp.org server 2.europe.pool.ntp.org
chkconfig ntpd on /etc/init.d/ntpd restart

Además de ntp, me gusta asegurarme de contar con la zona horaria especificada en mis servidores. Aquí tienes la documentación oficial.

cat /etc/sysconfig/clock ZONE="Europe/Madrid"
ln -sf /usr/share/zoneinfo/Europe/Madrid /etc/localtime
9. Revisar /etc/resolv.conf

Por lo general, cada proveedor que nos ofrezca una instalación propia de CentOS, incorporará sus propios servidores de nombres, que en la mayoría de casos serán más que suficientes para resolver las DNS. Sin embargo, será bueno revisar este fichero para asegurarnos de que efectivamente hay definidos unos servidores de nombres, y que éstos están funcionando o nos fiamos de ellos.

10. Modificar el hostname de la máquina

Revisar /etc/sysconfig/network para configurar un hostname correcto para nuestro servidor.

HOSTNAME=nombre.dominio

Hace falta reiniciar para aplicar los cambios

11. Modificar ulimit

Revisar el ulimit del servidor y aumentarlo según sea necesario. En las últimas versiones de CentOS estos parámetros vienen con valores más acordes a los tiempos actuales.

ulimit -a

La instrucción anterior nos mostrará los límites de procesos en ejecución por usuario configurados en nuestro sistema. La siguiente tabla muestra los límites y qué significan cada uno.

# - core - limits the core file size (KB) # - data - max data size (KB) # - fsize - maximum filesize (KB) # - memlock - max locked-in-memory address space (KB) # - nofile - max number of open files # - rss - max resident set size (KB) # - stack - max stack size (KB) # - cpu - max CPU time (MIN) # - nproc - max number of processes # - as - address space limit (KB) # - maxlogins - max number of logins for this user # - maxsyslogins - max number of logins on the system # - priority - the priority to run user process with # - locks - max number of file locks the user can hold # - sigpending - max number of pending signals # - msgqueue - max memory used by POSIX message queues (bytes) # - nice - max nice priority allowed to raise to values: [-20, 19] # - rtprio - max realtime priority   # Para kernels anteriores a 2.2.5, no podemos superar los 1024. Espero que no sea tu caso :-)

Modificaremos el archivo /etc/security/limits.conf y nos aseguraremos de modificar por lo menos, los límites correspondientes a nproc y nofile.

Cuidado, podría ser que en el server existiera el fichero llamado "90-nproc.conf" con un límite que sobreescribe los ulimits del fichero limits.conf:

/etc/security/limits.d/90-nproc.conf

Tras reiniciar el sistema veremos como los límites han adquirido los nuevos valores.

12. Connection Tracking

El connection tracking es el proceso del Kernel encargado de gestionar las conexiones que afectan al servidor. Así pues, las conexiones que podemos ver con un netstat, tienen un límite. Si se trata de un servidor web que va a soportar muchas conexiones o de un postfix que va a enviar muchos mails y por tanto va a abrir muchas conexiones, sería una buena idea revisar estos parámetros. Si quieres profundizar sobre el la tabla de conntrack, ya hablamos de ella hace un tiempo aquí.

Necesitaremos:

cat /proc/meminfo MemTotal: 49521980 kB
uname -m x86_64

Con ésto, usaremos la siguientes fórmula:

CONNTRACK_MAX = RAMSIZE (in bytes) / 16384 / (x / 32)

Por ejemplo:

CONNTRACK_MAX =  (49521980 x 1024) / 16384 / (64 / 32) = 1547561,875 => 1547561

Ahora sabremos el número máximo de conexiones que podemos gestionar, y lo modificaremos en el /etc/sysctl.conf:

# Número máximo de asignaciones (calculo prévio) net.netfilter.nf_conntrack_max=1547561 # Timeout de 12 días en established (lo cambiamos a 12h) net.netfilter.nf_conntrack_tcp_timeout_established=43200 # Otros parámetros que podrían ser útiles ##net.core.somaxconn=65535 ##net.netfilter.nf_conntrack_tcp_timeout_time_wait=40 ##net.netfilter.nf_conntrack_expect_max=4096

Tras modificar los parámetros, deberemos aplicar los cambios y verificar que en efecto se han hecho efectivos:

sysctl -p cat /proc/sys/net/netfilter/nf_conntrack_max

Como muchas de las secciones de este post, los cambios se habrán aplicado en todas las sesiones tras el reinicio del server.

13. Mejorar el history

Puede ser muy interesante aumentar la capacidad del history del sistema, así como guardar la fecha en la que se ejecutó un determinado comando. Como "root", podremos mejorar el "history" de la máquina creando un script personalizado para el profile:

vi /etc/profile.d/custom.sh #Custom global bash parameters #Adding time to history and increasing it to 10000 linesexport HISTTIMEFORMAT="%h %d %H:%M:%S " HISTSIZE=10000

Tras el reinicio del server ya tendremos nuestro flamante "history" funcionando.

14. Mensaje de bienvenida

Otro punto interesante es el de mostrar un mensaje de bienvenida personalizado al loguearse al servidor. Es fráncamente fácil de conseguir, pues bastará con dejar el mensaje en el fichero motd:

vi /etc/motd ################################################################################## # Welcome to my super server # # All connections are monitored and recorded # # Please, disconnect IMMEDIATELY if you are not an authorized user! # ##################################################################################
15. Monitorización

Añade la máquina a tu sistema de monitorización (¿Alguien dijo Nagios?). Bajo mi punto de vista es importante que este punto se incluya dentro de la configuración inicial de un server, y no como un extra, pues en caso contrario, corres el riesgo de que el día a día retrase la monitorización del sistema y después tengas que correr para que el servidor no salga a producción sin estar monitorizado.

16. Backups

Tres cuartas partes de lo mismo respecto a los backups: no dejes la configuración del sistema de backups del server para más adelante, prepáralo todo ya. Recuerda que es interesante (por no decir imprescindible) guardar los backups fuera de la máquina, junto con los ficheros de configuración del server.

Ah, y asegúrate de que funcionan.

 

Hay otros muchos puntos que podrían tratarse aquí, y que dependerán de los servicios que alojará nuestro servidor, como por ejemplo si queremos habilitar IPv6 y por consiguiente configurar ip6tables, o si estamos instalando un servicio MySQL quizá querramos asegurarnos de que los logs se rotan con logrotate, así como que la configuración del servidor MySQL usa un fichero ibdata para cada tabla InnoDB. Si estás con Apache, recuerda configurar el timezone en el php.ini para evitar llenar de warnings los logs.

En cualquier caso, si has llegado a leer hasta aquí, seguramente tengas algo que aportar, así que no dudes en plasmar tus opiniones en los comentarios.

 

Fuentes:

Alfresco Tuning Shortlist

Tony de la Fuente - Jue, 02/05/2015 - 05:57
During last few years, I have seen dozens of Alfresco installations in production without any kind of tuning. That makes me thing that 1) nobody cares about performance or 2) nobody cares  about documentation or 3) both of them! I know people prefer to read a blog post instead the product official documentation. Since Alfresco […]

Mi entrevista en Coders Venezuela sobre desarrollo de WordPress y mas

Skatox - Mié, 02/04/2015 - 08:10

Hace unas semanas acepte la invitación de Osledy Bazo para participar en un proyecto de un podcast para Coders Venezuela sobre desarrolladores web Venezolanos, porque desde hace varios años soy seguidor del sitio y me gusta participar en este tipo de cosas. La entrevista, esta centrada en el desarrollo para WordPress, donde he estado realizando trabajos y plugins de código abierto desde hace tiempo. Sin embargo, en algunas partes hablo un poco sobre mi vida personal, trabajos, ideas, la academia, entre otras cosas.

En fin, les recomiendo escuchar la entrevista y si les gustó, compártanlo para apoyar este proyecto, pues me parece interesante para conocer programadores locales.

Enlace del podcast:

Segundo Podcast de Coders Venezuela – Miguel Angel Useche sobre desarrollo de plugins para WordPress.

Cuando dejas de ser el director de tu orquesta

Jose Salgado - Dom, 02/01/2015 - 18:05

jam session

El tiempo, a pesar de ser relativo, es un elemento que condiciona nuestro día a día. Podemos ejecutar dos acciones en un día o quizás veinte, depende de nuestro negocio, sector, etc.. Pero lo que está claro es que más allá del tiempo como factor de la física, en todo negocio hay algo tan o más importante que el tiempo, el tempo.

Cualquier aficionado a la música, ya sea melómano, punk-rocker o heavy es consciente de la importancia de este factor a la hora de interpretar una partitura. No es lo mismo un un adaggio que

Esto es un resumen del artículo Cuando dejas de ser el director de tu orquesta escrito para Exelisis. Visita la web para más información y compártelo si crees que es interesante.

Páginas

Suscribirse a Fedora-es sindicador