VERSION ACTUAL :

Inicio de sesión

Raulito el Friki

Raulito El Friki

COMENTARIOS

EN LINEA

Hay actualmente 0 usuarios conectados.

NUEVOS

  • jcdavivi
  • jhafierroagu
  • manuelito2016
  • atomocartun
  • JLNavigator

Agregador de canales de noticias

[Solucionado] LibreOffice no autocorrige en español

eliasbrasa - Jue, 07/07/2016 - 10:49

Tras instalar Kubuntu 16.04 me di cuenta que LibreOffice no autocorregía los textos en español.

¿Cómo arreglarlo? Es sencillo, solo hay que instalar el paquete myspell-es bien con el terminal o usando el gestor de paquetes que te guste (en mi caso Synaptic)

En la consola bastará introducir: sudo apt-get install myspell-es

Y seguir los pasos (contraseña e instalar otro paquete que viene asociado)

Una vez hecho esto se acabó el problema.

Fuente original: EBDL.


Las causas justas

Jose Salgado - Mié, 07/06/2016 - 22:47

Fantástico, has conseguido acabar la carrera de derecho, luego hiciste el curso de acceso a la abogacía y lo has aprobado. Atrás quedan las horas de estudio, las clases, las prácticas, los exámenes, todo eso ya es parte de tu pasado que va a dar forma a tu presente porque ahora eres abogado, ahora puedes defender la justicia, la ley y todos esos conceptos que te llevaron a escoger esta profesión sobre el resto de posibilidades.

Comunidad: Derecho

Tags: Profesión, Carrera, Oficio, Profesional

Esta entrada ha aparecido en Exelisis, haz click para leer Las causas justas

El problema del destructor y el submarino

Gaussianos - Mié, 07/06/2016 - 04:30

Hace unos días, un lector del blog, Manel Amorós, me hizo llegar un problema que había visto en un comentario de un artículo relacionado con matemáticas que se había publicado en un medio de comunicación. Aunque el comentario no tenía mucho que ver con la temática del artículo en sí, el problema suscitó el interés de varios lectores, Manel incluido. Por ello os lo planteo hoy en Gaussianos.

No os voy a dejar el enunciado literal que se propuso en ese artículo, ni el enlace del mismo (lo pondré más adelante, cuando se haya resuelto aquí). Os agradecería que ninguno de vosotros lo ponga en ningún comentario.

Ahí va el enunciado tal cual me lo envió Manel:

Un destructor y un submarino se encuentran separados una distancia D (suponemos distancias horizontales, dado que el problema se desarrolla en el plano). En un momento dado, ambos empiezan a moverse a velocidades constantes, siendo la velocidad del barco superior a la del submarino. El submarino se mueve obligatoriamente en linea recta, pero el barco desconoce la dirección que ha tomado el submarino. ¿Existe alguna trayectoria del barco que garantice que en algún momento se encontrará sobre la vertical del submarino?

Hala, a pensar, que nunca viene mal. Que se os dé bien.

Tarjetas broadcom en fedora

Fedora Nicaragua - Mié, 07/06/2016 - 01:22

De vez en cuando, en fedora tenemos un pequeño problemas con la tarjeta wifi de nuestras tarjetas broadcom.En esta pequeña entrada veremos como solucionar ese problema asi de simple.

primero hay un paquete llamado kmod-wl creo, en todo caso existe broadcom-wl b43-tools b43-fwcutter

El b43-fwcutter es el extrator de firmwar

intenta instalar este paquete

luego rpmfusion-nonfree-updates

intentamos reiniciar y vemos que pasa

La juventud se cura con el tiempo, la estupidez no

Jose Salgado - Mar, 07/05/2016 - 22:35

Hombre Jose, acércate que tenía ganas de hablar contigo hace tiempo. ¿Sabes quién soy?, me imagino que no por la cara que estás poniendo, pero ahora te lo explico. ¿Te acuerdas cuando eras pequeño, creo que estabas haciendo tercero de EGB y se acabo el curso y todos tus amigos se marchaban de vacaciones y te pusiste a llorar porque añorarías a tus amigos?, ¿te acuerdas de como reaccionaron tus padres?, si, veo que te acuerdas, la verdad es que tocaron unos padres que hicieron lo que pudieron pero realmente no daban para más.

Comunidad: RRHH

Tags: juventud, Experiencia, Arriesgarse

Esta entrada ha aparecido en Exelisis, haz click para leer La juventud se cura con el tiempo, la estupidez no

No es lo que soy, es lo que crees que soy

Jose Salgado - Lun, 07/04/2016 - 20:25

Reconozco que tengo un grave problema de autoestima, y lo peor de todo es que este problema se agudiza en los momentos más importantes, específicamente cuando tengo que venderme.

Comunidad: Marketing

Tags: Promoción, Imagen, Marca, Marca Personal, Talento, Miedos

Esta entrada ha aparecido en Exelisis, haz click para leer No es lo que soy, es lo que crees que soy

RadioLiberada: podcast de Software Libre

Skatox - Lun, 07/04/2016 - 08:00

Siempre cuando estoy trabajando en la computadora, me gusta escuchar de fondo música, conferencias o programas de radios. Uno de los que me gusta es Radioliberada, un podcast realizado en San Cristóbal (la misma ciudad de donde vivo) por varios miembros de la comunidad de software libre local Gnuchox.

Temas de RadioLiberada

Este programa de radio comenta principalmente sobre software libre: las últimas noticias de esa cultura, nuevos programas, recomendaciones, entre otros. Adicionalmente, en algunos programas se tratan temas relacionados a la cultura libre, tales como películas de informática, agricultura libre y mas. El formato del mismo son conversaciones entre los locutores e invitados, pues son conversaciones informales entre amigos y hace mas amena la escuchar, también comparten buena música no popular (para mí) entre segmentos y puedes descubrir nuevas bandas.

Logo de Radioliberada

Logo de Radioliberada

El nivel de los temas es para todo público por lo que es agradable para escuchar mientras trabajas, haces ejercicio, manejas, entre otros.  Así que entra a RadioLiberada y suscríbete para estar actualizado sobre la cultura libre.

La entrada RadioLiberada: podcast de Software Libre aparece primero en El blog de Skatox.

Necesitamos hombros de gigantes

Jose Salgado - Dom, 07/03/2016 - 20:10

Ahora no tengo conexión pero estoy convencido que una persona que ha influido y mucho en el desarrollo de la ciencia y la tecnología dijo una vez: he visto más lejos porque me he sentado en hombros de gigantes[1]. Que traducido a la gente que no tiene internet como yo viene a decir que el ha conseguido llegar a ciertos logros gracias a que otros habían hecho avanzar la ciencia antes que él y su mérito fue seguir el camino que le habían enseñado.

Comunidad: Management

Tags: Cooperación, Colaboración, Aprendizaje, Cultura

Esta entrada ha aparecido en Exelisis, haz click para leer Necesitamos hombros de gigantes

Servidor LAMP en Fedora 24

Blog 1 - Sáb, 07/02/2016 - 00:56
Algo que me encanta de Fedora es que configurar un servidor LAMP es una tarea bastante sencilla. A continuación describo como hacerlo. Instalamos el servidor web(apache httpd) la forma más sencilla(todos estos comandos como root) dnf groupinstall "Web Server" **si muestra algún error de versiones (workstation, nonproduct) usar: dnf groupinstall "Web Server" --skip-broken Después el servidor Vanhttp://www.blogger.com/profile/04797995971024335249noreply@blogger.com28

Hazlo o no lo hagas, pero no lo intentes

Jose Salgado - Jue, 06/30/2016 - 21:10

En algunas ocasiones querer no es suficiente, no sirve sólo tener la intención o la voluntad, hay que ponerlo todo para que un proyecto funcione y consiga tomar cuerpo.

Comunidad: Management

Tags: Tesón, Objetivo, Determinación, Resiliencia

Esta entrada ha aparecido en Exelisis, haz click para leer Hazlo o no lo hagas, pero no lo intentes

Apache Maven

HelloIT - Jue, 06/30/2016 - 10:51

maven-logo-black-on-whiteRecupero un post que ha estado en borradores un largo tiempo, pese a que ahora esté de moda Gradle :)

Teniendo en cuenta que vengo del mundo PHP, estaba empezando a documentarme sobre Apache Maven (una herramienta para la gestión -compilación, reporting y documentación- de proyectos Java) y sin tener demasiada idea, me ha parecido que tiene cierta similitud con Apache Ant. Como no podía ser de otra manera, no soy el primero que se ha preguntado en qué se diferencia Apache Ant de Apache Maven, y en StackOverflow dan un par de respuestas interesantes:

"Ant is an imperative build system, whereas Maven is a declarative build system" -> Un script ant le dice a ant qué ha de hacer, mientras que un script maven le dice a maven qué es lo que quieres conseguir, y maven se encarga de hacerlo.

Maven nació con la intención de estandarizar la creación de proyectos Java, definir de forma clara en qué consiste un proyecto determinado, facilitar la publicación de la información del proyecto y permitir la compartición de los ficheros JAR entre diferentes proyectos.

Fuente: https://maven.apache.org/what-is-maven.html

Instalación de Apache Maven

Aunque podemos encontrar Maven en los repositorios oficiales de Fedora, en la web de Maven describen el siguiente proceso de instalación:

Descomprimimos y ubicamos el directorio de Apache Maven:

wget http://mirror.cogentco.com/pub/apache/maven/maven-3/3.3.1/binaries/apache-maven-3.3.1-bin.tar.gz tar -zxvf apache-maven-3.3.1-bin.tar.gz sudo mv apache-maven-3.3.1 /usr/local/apache-maven

Posteriormente, añadimos el directorio "bin" de Maven al Path:

export PATH=$PATH:/usr/local/apache-maven/bin

Maven necesita contar con el JDK de Java, pues no basta únicamente con el JRE. Hay que indicarle al JAVA_HOME la ruta a la ubicación del JDK. En mi caso:

export JAVA_HOME=/usr/java/jdk1.8.0_31

Podremos verificar la correcta instalación de Maven ejecutando:

mvn --version

Fuente:
http://maven.apache.org/download.cgi#Installation

Artifacts

Un build de Maven producirá uno o más "artifacts". Un artifact no es más que un fichero .jar (también pueden ser de otros tipos, como .war o .ear) resultado de la compilación del proyecto, que se deploya en el respositorio de Maven.

POM.xml

El fichero pom.xml (Project Object Model), es la pieza central de la configuración de un proyecto Maven. Contiene toda la información importante del proyecto, como por ejemplo las dependencias del proyecto, los plugins o los "goals" ("objetivos" que queremos alcanzar) que pueden ejecutarse, e incluso la versión del proyecto, la descripción, developers, mailing lists...

El "Super POM" de Maven es el POM por defecto de Maven. Todos los ficheros pom.xml, a no ser que explícitamente especifiquen lo contrario, extienden del Super POM. [Más info]. Así pues, en un fichero pom.xml, por lo menos deberemos especificar lo siguiente:

  • modelVersion: indica qué versión del Object Model usa este POM. Es poco frecuente que cambie la versión, pero aun así este parámetro es obligatorio. En la documentación oficial indica que actualmente debe setearse a "4.0.0".
  • groupId: identificador único para la organización o grupo que ha creado el proyecto. Típicamente se base en el FQDN de tu organización. P.ej. "org.apache.maven.plugins".
  • artifactId: indica la base del nombre (única) para el artifact principal que generará el proyecto. El proyecto puede tener artifacts secundarios que también incluirán esta base como parte de su nombre. Un artifact producido por Maven debería tener la forma <artifactId>-<version>.<extension>, p.ej. "myapp-1.0.jar".
  • version: indica la versión del artifact generado por el proyecto. Si la versión contiene la palabra "SNAPSHOT", indicará que el proyecto está en estado de desarrollo.

El resto de elementos del pom.xml, si no los indicamos, cojerán los valores por defecto del Super POM.

Es importante saber que el "fully qualified artifact name" lo forman los valores anteriores, tal que así: <groupId>:<artifactId>:<version>. Un ejemplo (cogido directamente de la documentación oficial) sería "com.mycompany.app:my-app:1".

Dependencias y módulos

También será habitual encontrar módulos y dependencias.

Para las dependencias, puede resultar muy útil configurar la sección "dependencyManagement" la cual permite definir las versiones de las dependencias en el parent. Así, podremos prescindir de la versión en las dependencias de los módulos definidas en la sección "dependencyManagement" del parent, pues estas dependencias usarán la versión definida ahí, manteniendo así las versiones en un único punto.

Si tenemos módulos y dependencias, cuidado con la herencia de configuraciones comunes (dependencias, plugins, recursos...).

Fuentes:
http://maven.apache.org/guides/introduction/introduction-to-the-pom.html

Plugins

Tal y como indica la documentación oficial, se podría decir que Maven es un framework que ejecuta plugins. Un plugin no es más que un conjunto de objetivos (goals) con un mismo propósito. P.ej. el plugin "jboss-maven-plugin" tiene varios objetivos para trabajar con Jboss.

Si como proponen en la guía "Maven en 5 minutos" ejecutamos el siguiente comando desde el que será el directorio que hará de repositorio...

mvn archetype:generate -DgroupId=com.mycompany.app -DartifactId=my-app -DarchetypeArtifactId=maven-archetype-quickstart -DinteractiveMode=false

...le estaremos indicando a Maven que se ejecute el objetivo "generate" del plugin (archetype) "archetype", al cual le pasamos además varios parámetros.

A partir de aquí, las configuraciones dependerán de nuestro proyecto, los plugins y de cómo lo enfoquemos.

Fuentes:

https://www.youtube.com/watch?v=VOkgaq__Ff8
http://www.genbetadev.com/java-j2ee/introduccion-a-maven
http://maven.apache.org/guides/getting-started/maven-in-five-minutes.html
http://maven.apache.org/guides/getting-started/index.html

Tabus, límites y censuras

Jose Salgado - Mié, 06/29/2016 - 20:51

Ayer me ocurrió algo curioso, comenté una noticia y al cabo de cinco minutos las respuestas que tenía criticaban no solo la noticia, sino que añadían conceptos que no tenían nada que ver para darle mayor gravedad. Era algo como el chiste en el que un amigo le dice al otro, ¿que te pasa?, tienes mala cara. El amigo le contesta que se le había muerto la mujer, y le responde con la cara muy seria, pues vaya día llevamos a ti se te muere la mujer y a mí se me ha estropeado el bolígrafo.

Comunidad: Marketing

Tags: Tabú, Libertad, Expresión, Presión

Esta entrada ha aparecido en Exelisis, haz click para leer Tabus, límites y censuras

La vida no es un sprint sino una maratón

Jose Salgado - Mar, 06/28/2016 - 21:37

Dicen los que saben de astrofísica que si usáramos el símil de un año para definir el tiempo que ha transcurrido desde el Big Bang hasta ahora, los seres humanos seríamos el último segundo del día treinta y uno de diciembre. Es cierto que es una cuestión de escalas, pero esto debería darnos cierta perspectiva a la hora de gestionar nuestro propio tiempo.

Comunidad: RRHH

Tags: Tiempo, Gestión, Marco, Objetivos

Esta entrada ha aparecido en Exelisis, haz click para leer La vida no es un sprint sino una maratón

Aprendiendo Python 3

HelloIT - Mar, 06/28/2016 - 13:41

python3
Bueno, este artículo contiene una serie de apuntes que me han parecido interesantes, referentes a un curso sobre Python 3. Así pues, no es ni mucho menos, un curso de Python 3, pero con suerte le será de utilidad a alguien (además de a mí mismo). De momento, aquí el primer post que he creado mientras he ido avanzando en el curso.

1. Introducción 1.1. ¿Por qué Python?
  • Escritura eficiente: requiere escribir menos código que otros lenguajes
  • Lenguaje de alto nivel y propósito general
  • Funciona bajo cualquier sistema operativo
  • Popular y gratuito
  • Cercano al pseudo-código, enfatiza la legibilidad
1.2. ¿Qué es Python?
  • Soporta múltiple paradigmas de programación (orientación a objetos, funcional, etc.)
  • Type checking done at runtime
  • Gestión automática de la memoria / garbage collector
  • Modular (core pequeño, extensible con módulos)
  • El código python puede ser paquetizado en un único ejecutable listo para distribuir (ej. dropbox)
  • Open-Source
  • Uno de los objetivos más importantes de los "pythoneros" es que sea un lenguaje divertido de usar
  • Creado por Guido van Rossum (aka BDFL)

Implementaciones más importantes

  • CPython: escrito en C, compila programas python en bytecode intermedio (.pyc) listo para ser ejecutado por una máquina virtual. Es la implementación que se suele usar por defecto.
  • PyPy: python escrito en python. Objetivo: velocidad (en el interprete de python)
  • Jython: compila en Java bytecode, para ejecutarse en cualquier JVM. Puedes usar librerias de Java desde el código Python.

Por ejemplo, si tenemos código Java ya hecho, y queremos extender este código, pero no sabemos Java (o estamos más cómodos con Python) podemos usar Jython para importar las clases existentes Java y extender sus funcionalidades con nuevo código Jython.

Otro concepto importante, es el código Python debe seguir la filosofía "pythonica", es decir, que siga las guías para expresar lo que quiere de la mejor forma posible: "debería haber una (y preferiblmente sólo una) forma obvia de hacerlo".

1.3. Python 2 vs Python 3

En py3readiness.org se encargan de listar cuales de los 360 módulos más populares de Python están listos para funcionar con Python 3. A día de hoy, 307/360.

Podemos migrar código Python 2 a 3 con la librería 2to3, y al revés con 3to2.

1.4. Gestor de paquetes de Python

El gestor de paquetes de Python recomendado es "pip" (Python Package Index), el cual suele incluirse con la propia instalación de Python. Tenemos un listado de los paquetes disponibles por aquí.

Un comando interesante es "pip freeze" el cual lista todos los paquetes actualmente instalados, con sus versiones.

pip freeze > requirements.txt
2. Python 2.1. Ejecutando un script python

a) Directamente, pasándole como parámetro el script al intérprete

python3.4 myscript.py

b) Haciendo ejecutable nuestro script tras añadirle el shebang correspondiente.

[adri@localhost ~] head -1 myscript.py #!/usr/bin/env python3.4 [adri@localhost ~] chmod u+x myscript [adri@localhost ~] ./myscript.py

NOTA: Python checkea el código en tiempo de ejecución, no en tiempo de compilación, excepto para errores de sintaxis (por ejemplo si usas la función "print" sin acordarte de los paréntesis). Ésto es importante tenerlo en cuenta, pues si tienes por ejemplo un "if", sólo se checkeará el código de la "rama" del if a la que entre, pero no el resto.

2.2. Módulos

Puedes incluir otros scripts python ubicados en tu mismo directorio (que serán módulos para nosotros) con "import".

import myotherfile

Estos otros módulos, no tienen porqué importarse siempre desde otro script, si no que podrían poderse ejecutar directamente como un script standalone (sin que le llame ningún otro script). Para ello, podemos usar el siguiente if desde el módulo a importar para definir un comportamiento diferente si se está llamando con un import desde otro script o si se está ejecutando directamente.

# Ejecutamos este código en cualquier caso print('Esto se ejecutará siempre')   # Definimos la función main def main(): print('Estoy en standalone')   # Sólo si estoy en standalone, llamo al main if __name__ == "__main__": main()

NOTAS:

  • Este módulo, una vez importado, nos permitirá en cualquier caso llamar a la función main desde el script que lo ha importado, pues no deja de ser una función más del módulo. La función se llamará via el namespace del módulo, tal que así: myotherfile.main().
  • Tras la primera ejecución de nuestro script, el cual importa un módulo, el módulo importado quedará cacheado y almacenado (ya compilado, y por tanto se tratará de un fichero bytecode .pyc, pero aun así ejecutable) dentro del directorio __pychache__. Sólo se cachearán los módulos importados.
3. Aprendiendo python 3.1. Variables

Una característica muy chula de python es que puedes asignar el valor de varias variables en una sóla línea, tal que así:

a, b = 0, 1 a, b = b, a+b

Hay que tener en cuenta, pero, que el código anterior da como resultado a=1, b=1, pues en el momento de ejecutar la segunda línea, a=0 y b=1.

Variables inmutables

Al cambiar el valor de una variable de este tipo, en realidad se está destruyendo el objeto y creando uno nuevo. La variable tendrá pues, un nuevo "id" al cambiarle el valor.

>>> a=3 >>> id(a) 139803787806208 >>> a=a+1 >>> id(a) 139803787806240

Son inmutables las variables de tipo primitivo, como ints, floats o strings.

Variables mutables

Las variables mutables, en cambio, pueden cambiar de valor manteniendo el objeto. Por defecto, este tipo de variables deben entenderse como "etiquetas" o "alias" sobre un valor. Así pues, asignar la variable x a la y, significa que y será un alias de x, y por tanto, ambas apuntarán al mismo valor.

>>> x = [a,b,c] >>> y = x >>> x.append[d] >>> y [a,b,c,d]

Si se quiere hacer una copia de una variable mutable en otra, se puede hacer una "shadow copy" o una "deep copy" (explicado al final del post).

Son mutables, por tanto, los tipos de dato más complejos, como los arrays.

Más sobre in/mutabilidad

3.2. Tipos básicos

Números

Podemos usar las expresiones típicas para realizar operaciones, como suma (+), resta (-), multiplicación (*), división (/), potencias (**), resto -o "mod"- (%) y división entera (//).

Por defecto, una división no entera devolverá un float.

Strings

Un string se define por comillas simples, dobles comillas, o 3 dobles comillas (para múltiples líneas sin necesidad de \n). Escapamos, como es habitual, con "\".

Podemos usar la función print() para printar los carácteres especiales, como:

print("esto es una linea\ny esta es otra línea")

También podemos no tratar los carácteres especiales y printar el string tal cual:

print(r"Esto se printará e\n una única línea")

a) Concatenación

Concatenamos strings con "+".

b) Indexación

Podemos "indexar" strings, es decir, referirnos a un carácter concreto en función de su posición en el string.

>>> a='Hola' >>> a[0] 'H'

También contando hacía atrás.

>>> a[-1] 'a'

c) Substrings (+ rangos)

Con un rango en la indexación conseguimos un substring. Atención, el inicio del rango se incluye, pero el fin se excluye. Si no se especifica uno de los 2 valores del rango, se cojerá lo que pertoque (inicio o fin).

>>> a='Cadena' >>> a[0:2] 'Ca' >>> a[:3] 'Cad'

Tenemos la opción adicional del "slice", como tercer parámetro del "rango", que nos permite seleccionar cada "n" posiciones del string. El siguiente ejemplo devolvería las posiciones pares de todo el string:

>>> a='Cadena' >>>print(a[1:0:2]) 'Cdn'

d) Inmutabilidad
Los strings son inmutables, así que no puedes modificarlos directamente:

>>> a='Cadena' >>> a[0] = 'K' TypeError

Listas

Podemos tener listas que incluyan diferentes tipos de datos, e incluso listas anidadas:

>>> lista = [1, 2, 3, 4] >>> lista = [1, 2, "tres", 4] >>> lista = [1, 2, [2.25, 2.5, 2.75], 3, 4]

Igual que con los strings, podemos referirnos a un elemento de la lista por su posición, o a una sublista (lo cual, en realidad devuelve una nueva lista). Para referirnos a un elemento de una lista anidada, lo haremos:

>>> lista = [1, 2, [2.25, 2.5, 2.75], 3, 4] >>> lista[2][0] 2.25

Las listas son mutables, con lo que podemos modificarlas refiriéndonos a una posición o rango concreto, variando también su tamaño.

3.3. Estructuras

If
Así iría un if con sus diversas posibilidades:

if x < 0: print("x menor que cero") elif x == 0: print("x igual a cero") else: print("x mayor que cero")

No hay switch/case en Python. Usaremos "elif" como sustituto.

While
Tampoco tiene historia el bucle while:

i = 1 while i < 10: print(i) i = i + 1

For
En un bucle for, iteraremos por los diferentes elementos de un objeto.

words = ['uno','dos','tres'] for word in words: print(word)

Si se quiere iterar sobre un objeto, que hemos de modificar dentro del bucle, quizá nos interese iterar sobre el objeto original (sin modificar) pese a que se modifique dentro del bucle. Para ello, podemos hacer una copia del objeto con "[:]", lo cual nos permitirá que pese a que durante el bucle, modifiquemos el objeto (el cual quedará modificado tras salir del bucle) las iteraciones se realizarán sobre el objeto original.

i = 0 words = ['uno','dos','tres'] for word in words[:]: print(word) if word == 'tres': words.append('cuatro')   print(words,len(words))

Ésto dará como resultado:

uno dos tres ['uno', 'dos', 'tres', 'cuatro'] 4

Especialmente interesante es saber que un "for" puede tener su propio "else", que se ejecutará cuando la lista por la que itera el for se termine, pero no se ejecutará si el for acaba por un "break". Dentro del "for" también podemos tener "continue" el cual salta directamente a la siguiente iteración del bucle sin acabar lo que restara de la iteración actual.

NOTA: Otra declaración interesante es "pass" la cual en realidad no hace nada, pero nos puede venir bien si por ejemplo necesitamos declarar una función pero no vamos a implementarla ahora, o una clase vacía (una clase no puede estar vacía, de ahí que usemos "pass").

3.4. Funciones

Definiremos una función con la clave "def", seguido del nombre de la función y los parámetros entre paréntesis, como viene siendo habitual. Deberemos definir una función antes de poder usarla (en python el código se ejecutará de forma secuencial, así que obtendrás un error si realizas la llamada a la función antes de la definición de la misma).

def myfunction(var_1,var_2): """My docstring""" #Something return var_3, var_4

NOTA: Podemos devolver más de una variable a la vez.

Opcionalmente (pero recomendable, si queremos hacer las cosas bien en python) las primera línea de código dentro de la función conformarán el docstring que no es más que una descripción del propósito de la función. Esta información se podrá recuperar con "help(myfunction)" o "print(myfunction.___doc___)". Hay herramientas que generan documentación a partir de los docstrings. Tenemos las siguientes convenciones:

  • La primera línea del docstring será un resumen del propósito de la función, seguido de una línea en blanco
  • A partir de ahí, pasaremos a describir en detalle la función

Respecto a las variables dentro de una función, podemos usar la clave "global" al referirnos a una variable global definida anteriormente (y fuera de la función), con tal de poder asignarle un nuevo valor dentro de la función. No hace falta usar la clave "global" para definir una variable global si únicamente queremos consultar su valor.

a="A es global" b="B es global"   def myfunction(): """"Testing purposes""" print(a) # Printará "A es global" global b b="B es global y he modificado su valor" print(b) # Printará "B es global y he modificado su valor"   print(a) # Printará "A es global" print(b) # Printará "B es global y he modificado su valor"

Si en el ejemplo anterior no usaráramos la clave "global", la función estaría símplemente usando una variable local llamada, casualmente, igual que la variable global b. Si has programado antes, ésto no tiene misterio.

Respecto a los argumentos en las funciones, si pasamos argumentos que son variables immutables y los modificamos dentro de la función, al ser immutables, se estará creando un nuevo objeto dentro de la función que tendrá ámbito local, por lo tanto, la modificación sólo afectará localmente a la variable dentro de la función. Sin embargo, si pasamos como argumentos variables mutables, estaremos pasando la referencia al objeto, y si modificamos la variable dentro de la función, esta modificación se realizará sobre el objeto original con lo cual la modificación persistirá aun cuando salgamos de la función.

s = [0, 1]   def myfunction(s): s[1]=2   print(str(s)) # Printará "[0, 2]"!!!

NOTA: Todo en python es un objeto, incluso las funciones. Puedes asignar una función a otra (newfunc = myfunc) y lo que estarás haciendo en realidad es crear un alias, igual que con las variables immutables.

 

NOTAS:
A. Python permite hacer asignación de múltiples variables a la vez, tal que así:

a, b = 1, 2

Cualquier entero diferente de cero es "True". También cualquier tipo de datos de tamaño mayor que cero. Por tanto, cero es "False", así como cualquier tipo de dato de tamaño 0 (como un array vacío).

B. PEP8 es el estándar de formato de Python.
Komodo Edit (la versión gratuita de Komodo) como IDE + Addon "Perfect Python" para el PEP8.
O usando Komodo Edit 9 > http://forum.komodoide.com/t/enable-pep8-in-komodo-edit-9/1740

Más:
https://docs.python.org/3/reference/
http://forum.komodoide.com/t/enable-pep8-in-komodo-edit-9/1740

C. Shadow copy y deep copy: Por defecto usaremos "shadow copy", lo cual será más que suficiente para la mayoría de ocasiones. La shadow copy copiará los objetos de primer nivel, pero no los anidados, que quedarán por referencia (se hará referencia al objeto original, el cual no se habrá copiado!!). Así por ejemplo, de la siguiente lista, [a, b] sería una lista anidada (o de segundo nivel) la cual no se incluiría en una "shadow copy" si no que se le haría referencia, con lo que si se cambiara un valor, también se cambiaría en la lista original.

>>> [1, 2, 3, [a, b]]

La "deep copy", como su nombre indica, sí que copiaría todos los niveles, así que hay que ir con cuidado si se usa con un objeto con múltiples objetos anidados.

Cualquier tiempo pasado, fue pasado

Jose Salgado - Lun, 06/27/2016 - 22:13

‘Hace unos días un padre del colegio al que van mis hijas me envió una imagen de una revista de cuando los dinosaurios poblaban la tierra. Era un listado de fotos de niños, con su descripción, aficiones, edad y algún que otro dato más. En aquella época este tipo de publicaciones lo más normal del mundo, nuestros padres no tenían demasiados problemas en que enviáramos nuestra información y que quedara disponible para todo el mundo.

Comunidad: Derecho

Tags: Normas, Seguridad, Libertad

Esta entrada ha aparecido en Exelisis, haz click para leer Cualquier tiempo pasado, fue pasado

You have to do what you have to do

Jose Salgado - Dom, 06/26/2016 - 20:06

Hay una corriente, no se si filosófica o milenarista, que afirma que nuestro destino ya está definido y cualquier acto o decisión que podamos tomar ya estaba marcada de antemano. El concepto de libertad es una palabra vacía y que no tiene sentido ya que realmente somos piezas en un engranaje que simplemente cumplimos con lo que estamos predestinados a hacer.

Comunidad: RRHH

Tags: Predeterminado, Indeterminado, Futuro, Acciones

Esta entrada ha aparecido en Exelisis, haz click para leer You have to do what you have to do

La conjetura de Steinberg es…¡falsa!

Gaussianos - Dom, 06/26/2016 - 14:25

La teoría de grafos es una de las ramas de las matemáticas que más movimiento está teniendo en los últimos años, en lo que se refiere a investigación y a aplicaciones a problemas “reales”.

Dentro de la teoría de grafos, los problemas relacionados con coloración de grafos tienen gran interés dentro de los especialistas de esta rama.

Y dentro de los problemas de coloración de grafos, la conjetura de Steinberg ha sido uno de los problemas abiertos que más han interesado a los estudiosos en la materia.

Bien, pues (parece ser que) tenemos resultado para este problema: la conjetura de Steinberg es falsa. En lo que sigue, vamos a dar una idea sobre qué es eso de la coloración de grafos y hablaremos de esta interesante conjetura.

Aunque en Gaussianos ya hemos hablado en otra ocasiones sobre grafos, no está mal recordar algo sobre ellos. Un grafo es un conjunto V (distinto del vacío) de puntos, llamados vértices, y un conjunto de líneas A, llamadas aristas, cada una de las cuales une dos de sus vértices. Si dos vértices están unidos con al menos una arista, se dice que dichos vértices están conectados.

Un grafo plano es un grafo que puede dibujarse en un plano con la condición de que dos aristas cualesquiera no se cortan en ningún punto que no sea un vértice. En la siguiente imagen podéis ver un grafo plano y uno que no lo es (de hecho es el famoso grafo de Kuratowski K_{3,3}):

plano-noplano

Un ciclo en un grafo es una sucesión de vértices v_1, \ldots ,v_n, v_1 en la que cada vértice de la lista está conectado con el siguiente y donde no hay vértices repetidos (excepto el primero y el último). Vamos, lo que todos esperaríamos que fuera un ciclo. La longitud de un ciclo es el número de vértices distintos (equivalentemente, el número de aristas) que contiene. Un ciclo de longitud n se suele denominar n-ciclo. Aquí tenéis dos ciclos, uno de longitud 3 (el verde) y otro de longitud 5 (el rojo):

ciclos

Una coloración de un grafo es una asignación de etiquetas (colores) a los vértices de dicho grafo de manera que dos vértices conectados tengan distinto color. Si el número de etiquetas es pequeño, suelen usarse colores para etiquetar los vértices. Si este número es grande, suelen usarse números enteros positivos: 1,2, \ldots , m. Si en la coloración se usan k colores, se dice que tenemos una k-coloración. Aquí tenéis como ejemplo una 3-coloración del grafo anterior:

3coloracion

The Three Color Problem

Ya tenemos todo lo necesario para introducir el tema principal de esta entrada. La cuestión central de toda esta historia es el coloreado de mapas. El resultado más conocido en relación con esto, como muchos ya sabréis, es el famosísimo teorema de los cuatro colores, demostrado por Kenneth Appel y Wolfgang Haken en 1976.

La primera noticia que se tiene sobre la coloración de mapas con tres colores es un paper de Arthur Cayley de 1879. Ese mismo año, Alfred Kempe también lo trata en su trabajo sobre el teorema de los cuatro colores (que, por cierto, contenía una demostración incorrecta de este resultado); y, más adelante, Percy Heawood también habla de él en sendos trabajos que datan de 1890 y 1898, respectivamente.

Pero es en 1958 cuando el Three Color Problem pasa a tener entidad de problema propio gracias a Herbert Grötzsch, siendo Oystein Ore en 1967 quien lo elevó a los altares. Recomiendo el paper The state of the Three Color Problem [Annals of Discrete Mathematics, 55, 21 1-248 (1993)], de Richard Steinberg, a quienes estén interesados en más datos relacionados con la historia de este problema.

El Three Color Problem pregunta, básicamente, lo siguiente:

¿Bajo qué condiciones pueden ser coloreadas las regiones de un mapa plano con tres colores de manera que no haya dos regiones con frontera común que tengan asignado el mismo color?

Como cada región de un mapa puede interpretarse como un vértice y la frontera común de dos regiones puede asociarse con una arista, un problema de coloreado de mapas puede interpretarse como un problema de coloreado de grafos.

Y por ahí va la cosa, por coloreado de grafos. En 1976, el propio Richard Steinberg establece la conjetura que actualmente lleva su nombre:

Conjetura de Steinberg:

Todo grafo plano que no contenga ni 4-ciclos ni 5-ciclos es 3-coloreable.

Es decir, si un grafo no tiene ciclos de longitud 4 ni ciclos de longitud 5, entonces pueden colorearse sus vértices con 3 colores de manera que no haya vértices conectados que compartan color.

Hasta hace poco, había habido acercamientos a dicha conjetura. Posiblemente, el más interesante surgió a partir de una sugerencia del gran Paul Erdős. Erdős sugirió buscar si existía una constante k que cumpliera que todo grafo sin ciclos de longitud 4,5, \ldots , k era 3-coloreable. Borodin, Glebov, Raspaud y Salavatipour, mejorando resultados anteriores, demostraron en Planar graphs without cycles of length from 4 to 7 are 3-colorable [J. Combin. Theory Ser. B 93 (2005), 303–331] que k \le 7.

Y más o menos en este punto es en el que estábamos…hasta hace bien poquito (en julio de 2006, se publicaba una supuesta demostración de la veracidad de la conjetura de Steinberg que no fue aceptada como correcta). En abril de este año 2016, Vincent Cohen-Addad, Michael Hebdige, Daniel Král, Zhentao Li y Esteban Salgado ha demostrado que la conjetura de Steinberg es falsa. En su trabajo Steinberg’s Conjecture is False, construyen un contraejemplo para dicha conjetura. Es decir, construyen un grafo plano que no contiene ni 4-ciclos ni 5-ciclos y que no es 3-coloreable. Para ello, comienzan construyendo un grafo G_1 (arriba a la izquierda en la imagen) con ciertas propiedades; a partir de él construyen un segundo grafo G_2 (arriba a la derecha); y para finalizar construyen un grafo G (abajo) a partir de este último que cumple que no tiene ni 4-ciclos ni 5-ciclos y que además no es 3-coloreable:

En el paper que acabo de enlazar podéis ver la demostración de este hecho.

Bien, la conjetura de Steinberg es falsa, problema resuelto. Pero el Three Color Problem sigue abierto, todavía no sabemos si ese k cuya búsqueda sugirió Erdős es 7 ó 6. Estaremos atentos a futuras novedades.

Fuentes y enlaces relacionados:

Esta entrada participa en la Edición 7.5 del Carnaval de Matemáticas, cuyo anfitrión es el blog Series Divergentes.

Cuándo ha sido la última vez que te carcajeaste

Jose Salgado - Jue, 06/23/2016 - 10:36

Carcajear, sonreír, descuajaringarse, troncharse, partirse el pecho, tenemos muchas opciones para definir un estado de ánimo caracterizado por el uso de los músculos faciales, enseñar los dientes, abrir la boca, tener los ojos cerrados, llorar y en ocasiones quedarnos sin aire para respirar.

Comunidad: Management

Tags: Reír, Ambiente, Trabajo, Retos, Superar

Esta entrada ha aparecido en Exelisis, haz click para leer Cuándo ha sido la última vez que te carcajeaste

La política nos afecta a todos

Jose Salgado - Mar, 06/21/2016 - 21:25

Emprender, anda que no ha vendido esta frase. Emprendedores, autónomos y toda esta horda de personas que ni son empleados ni son empresarios porque están en un lugar intermedio dónde no llega la luz del sol. Como soy uno de los que vivo en este contexto y como me han preguntado que pienso sobre estos temas, aquí voy a escribir sin necesario orden ni concierto, y asumiendo que son reflexiones que tendrían que ser pasadas por algún tipo de modelo para verificar que pueden ser válidas y aplicables.

Más emprendedores

Comunidad: Management

Tags: Reformas, Economía, Empleo, Cotizaciones, Paro

Esta entrada ha aparecido en Exelisis, haz click para leer La política nos afecta a todos

Ansible + OpenStack: No Panda-monium here!

Rbergeron - Mar, 06/21/2016 - 13:51

Screen Shot 2016-06-19 at 1.38.22 PM
If, like myself, you are a frequent reader of technology-related articles on the internet, you may have seen this article come across your radar last Friday afternoon. Especially if the panda was as eyecatching for you as it was for myself.

Written by the nice folks over at The New Stack, the article speculates that one of the reasons for Ansible’s popularity in the world of containers is, quite simply, the popularity of Ansible in general. Citing results from the most recent OpenStack user survey, the author states:

Ansible made up a 14-point deficit compared to six months ago to become virtually tied with Puppet as the leading way to deploy/configure OpenStack clusters. Why this is the case, we’re not sure. However, one reason may be that Ansible’s online community is particularly strong.

checklistpanda-300pxNot sure why Ansible is growing so fast in popularity with OpenStack users? This must be why the Panda is so puzzled. Right?

Let me clear that up with a list of answers.

From a panda. (Incidentally, credit to Máirín Duffy, who actually created both of these pandas in her design work for the Fedora Project community. Super coincidence!)

Simplicity

Simplicity, ease of use, and a low learning curve are characteristics frequently cited as reasons folks have chosen Ansible — and in the ever-so-slightly (:D) complex world of OpenStack, the ability to abstract away some of that complexity gives users (admins, cloud consulevarmers, I hate the word “users”…) more time to work on other things.

Well. You know what LeVar Burton would say here.

Naveen Joy of Cisco elaborated on this particular point in his talk at the OpenStack Summit earlier this year in Austin, Texas, titled “Kubernetes Automation on OpenStack Using Ansible,” before following up with the long list of benefits.

“We did not want complexity in our automation. Kubernetes and OpenStack are complex for a reason;  they provide a lot of functions and a lot of knobs that you can customize and tune, APIs, a number of projects, variables that you can customize. But automation framework — we wanted it to be simple. We didn’t want to learn another manifest language to get this going. So, Ansible, we looked at it, and said, here’s the way to go…”

That said — making the deployment and management of an OpenStack cloud a little bit easier isn’t the only way in which simplicity matters. The simplicity of using Ansible with OpenStack, or really, Ansible with *anything*, also endears it to many folks — including Major Hayden of Rackspace, who explained further during his session in Austin, “Automated Security Hardening with OpenStack-Ansible.”

“The reason we love it is because there’s no agent required – there’s nothing actually that you have to install on the server to use Ansible with it. So you can deploy from your laptop, you can deploy from a bastion server, you can deploy from Jenkins, you can deploy from wherever you like. But you don’t have to go in on the other end and install ruby, and install 56 other things — you just have to make sure the other end has Python, which, if you’re running OpenStack… I certainly hope you have that installed, otherwise your installation is going to go in a bad direction.”

Versatility

Want to know one of my great “cloud” pet peeves? It’s that people say “users” all the time, and “users” can imply all types of different audiences to different folks. The operators? The sysadmins? The actual consumer of the cloud who just wants to do things on it? Who knows who we’re talking about!

What I do know is this: Users of OpenStack clouds — at any of those levels — are able to use Ansible. It’s useful to all of those groups. And, possibly even more importantly: this usefulness applies to Ansible in use cases everywhere. And in a lot of cases — people aren’t making a move to Ansible because it’s awesome with OpenStack. They’re coming as “users” of new OpenStack deployments and Ansible is *already what they’re using*, because it is so versatile.

Spencer Smith from Solinea explains their reasoning, as part of the consulting side of their company, for using Ansible in deploying Kubernetes, in this clip of their talk from OpenStack Summit.

“And I should say that we chose Ansible mainly because our clients are already using Ansible. They’ve developed expertise internally — so we didn’t want to compromise that, but still wanted to give them a way to deploy Kubernetes.”

Community

Let’s take a look at this snippet from the article: “Why this is the case, we’re not sure. However, one reason may be that Ansible’s online community is particularly strong.”

Well. I suppose it would be pretty easy for us to pat ourselves on the back and say, “Yep! More than 17 thousand stars on GitHub! Over 1400 people in #ansible on IRC! Over 2200 unique contributors to Ansible and its modules! Nearly 180 meetups with 35 thousand members around the world!” — and throw in a quaint mic drop gif, and walk away.

But the truth is: the combination of Ansible and OpenStack isn’t awesome, and thus, growing in use, because of the strength of the Ansible community. It is because of the work and collaboration and self-promotion of the group of folks who care about Ansible AND OpenStack — even without a formalized, central hub.

Here’s just a quick list of a few of the pockets of OpenStack + Ansible work:

(Note: I am super lazy at linking. But lucky for you, I have links to nearly all the projects listed below captured right here, which you can reference from this day forward!)

  • OpenStack “Big Tent” projects using Ansible: Kolla (OpenStack services in Docker containers). Openstack-ansible (OpenStack in LXC containers). Bifrost (Ansible + Ironic for bare metal). Openstack-ansible-security (automated deployment of security enhancements, based on the Security Technical Implementation Guide from the United States government).
  • OpenStack & Ansible users sharing their magic outside of the big tent: Ursula. Folks at Cisco. HP’s Helion. The fine humans at Catalyst Cloud (who, by the way, really get open source).  And plenty of other awesome examples by individuals and companies and projects are out there. 
  • OpenStack community members contribute and maintain OpenStack-related code inside of Ansible. Ansible’s OpenStack modules (more than 30 of them!) allow users / operators / consumers of OpenStack clouds to perform various functions on or in or to their cloud. These modules are literally used every single day by OpenStack’s infrastructure team to utilize OpenStack’s cloud, which, unsurprisingly, is an OpenStack cloud; also unsurprisingly, the maintainers for these modules in Ansible are largely members of OpenStack’s infrastructure team.
  • OpenStack is built with help from Ansible. OpenStack’s code is continuously tested and integrated prior to any commit — ensuring that small bits of bad code aren’t breaking life for the developers in a gigantic, incredibly busy project.  How do they do it? With the help of Zuul, an automation system built by OpenStack’s infrastructure team, for the OpenStack community, and used by more than 50 other open source communities as well. How does Zuul do this magic? It used to be with Jenkins. It’s now performed with Ansible

The truth is — none of these, alone, are the single reason for the growth of Ansible usage in conjunction with OpenStack. And it’s not just community, or Ansible’s simplicity, or versatility. It’s all of it, working together, compounding upon their collective successes.

Circling Back

Those of us who have spent time thinking Super Heady Deep Thoughts about open source and communities of practice have heard of “the virtuous circle” — a term which has many interpretations to be found on the internets (go figure!). But I find that this one, from this report on Sustainability in Open Source Commons, is spot on.  The author describes the virtuous circle as: “where good initial products attract users, which then potentially attract a new developer, which leads to more improvements. Our research clearly shows that successful projects have a potentially significant user community and that this user community drives project continuity.”

For the Ansible community, this pattern isn’t just limited to “Ansible + OpenStack.” I’d argue that it is repeating itself all over the place with a variety of Ansible + projects and/or practices. Containers. Working with orchestration tools like Kubernetes. AWS. Windows. Networking and its glorious SDN/NFV/TLA future. I could go on and on.

Ansible’s users and contributors consistently blow my mind in their usage of Ansible: how they are making it useful with other open source projects, and improving their day to day workflow. That they do so while also collaborating and sharing with other users and building communities of practice around Ansible EVERYWHERE just leads to more involvement, and more improvements, and more usage of Ansible all around. And enables those of us working for Ansible to do what we’ve always done: Follow our users — because, as users, they know what’s important and useful to them far more than we could ever dream to.

Which really means that Ansible and OpenStack — or Ansible and container orchestration — or Ansible and networking — isn’t thriving simply because of “the virtuous circle.”

It’s that the Ansible community has turned that circle into more of a virtuous venn diagram.

 


Páginas

Suscribirse a Fedora-es sindicador