Leyendo un libro “El prodigio de los números” que me regalo un dilecto amigo, el administrador de “Cacería de spammers“, me encontré con los números repfigit (REPetitive FIbonacci-like diGIT) o numero de Keith.

Un repfigit o número de Keith es un número entero, superior a 9, tal que sus dígitos, al comenzar una secuencia de Fibonacci, alcanzan posteriormente el referido número. Un ejemplo es 47, porque la secuencia de Fibonacci que comienza con 4 y 7 (4, 7, 11, 18, 29, 47) alcanza lo 47. Otro ejemplo es 197: 1+9+7= 17, 9+7+17= 33, 7+17+33= 57, 17+33+57= 107, 33+57+107= 197.

Un repfigit puede ser una secuencia de Tribonacci que tiene tres dígitos en el número, y de Tetranacci si el número tiene cuatro dígitos, etc.

Podemos encontrar esta secuencia en la bases de datos de secuencias “The On-Line Encyclopedia of Integer Sequences®” con el identificador “A007629“.

Este desafio consiste en escribir un programa que encuentre todos los números de Keith menores a 100000000. ¿Se animan?

La siguiente es la primera entrega de un breve tutorial que desarrolle sobre el editor VIM, la idea es mostrar las caracteristicas propias del editor y las provistas por plugins que lo potencia para tener un excelente editor que asiste a un desarroladore en su tarea.

Espero que les guste.

Desafio SQL

Posted by RetroMan | Desafios

El siguiente problema surgió de una necesidad de una amigo de estudiar discontinuidades en un campo autoincremental en mysql, que carece de secuenciadores, o de un pseudomotor numerador.

La siguiente consulta devuelve una secuencia continua del 1 al 1000:

Se pide modificarla para que genere números del 1000 al 10000 inclusive, se recomienda evitar el uso de LIMITAdicionalmente, si es posible reducirla para optimizar su ejecución.

 

 

Sea s(m) el menor numero n tal que m divide a n!
Así tenemos por ejemplo que el menor numero “n” tal que m=10 sea divisor de n! es n=5.
5! = 120 y 120 es el menor factorial divisible por 10. Así  s(10)=5
Escribir un programa que calcule cual es el menor numero cuyo factorial sea divisible por 25.

Todo indica que es el momento de comenzar a jugar con Django y las cosas que nos tiene preparado, dijimos que vamos a comenzar a trabajar en un entorno de tipo LAMP donde luego vamos a mostrar como desplegar una app completa de Django. Por el momento vamos por el principio.

Así comienza una serie de artículos de El Codigo K, recomendable.

Makefiles son una forma sencilla de organizar la compilación de código. Este tutorial es un muy simple ejemplo de lo que se puede hacer con “make”, pero pretende ser una guía de principiantes para que pueda crear rápida y fácilmente sus propios archivos make para pequeños proyectos.

Vamos a tomar el código de ejemplo del articulo anterior. Lo que representaría un típico programa principal, algo de código funcional en un archivo separado, y un archivo de inclusión, respectivamente.

 

 

Normalmente, se compilará esta colección de código ejecutando el siguiente comando:

Este comando compila los dos códigos fuente involucrados en la creación del binario ejecutable “main” el parámetro -I. le dice al compilador que los archivos de inclusión .hpp los tiene que buscar en el directorio actual “.”

Por desgracia, este enfoque de la compilación tiene dos problemas. En primer lugar, si se pierde el comando de compilación o se cambia de computadora tiene que volver a escribir desde cero el comando. En segundo lugar, si sólo está haciendo cambios a un archivo .cpp, recompilar todos los archivos de código fuente cada vez que necesita recompilar demanda mucho tiempo y es poco eficiente. Ambos problemas se puede solucionar mediante el uso de un archivo “Makefile” con las instrucciones necesarias para la generación del ejecutable.

El makefile más simple que se podría crear sería algo como:

 

Si pones estas regla en un fichero llamado Makefile o makefile  y ejecutas “make” en la línea de comandos se ejecutará el comando de compilación como esta escrito en el makefile.

Se pone luego del nombre del ejecutable que se generara el símbolo : seguido de los archivos de codigo fuente que son necesarios para su creación y en la linea siguiente el comando de compilación necesario. Es importante destacar que antes de la llamada al compilador en la segunda linea hay un “Tab

Con el fin de ser un poco más eficiente, vamos crear un nuevo archivos Makefile:

 

Ahora hemos definido algunas constantes CC y CFLAGS. Resulta que estos son constantes especiales que se usan para decirle a make como queremos compilar. En particular  CC es el macro que especifica el compilador que vamos a usar usar, y CFLAGS es la lista de las banderas a pasar al comando de compilación. Al poner los archivos de objetos – main.o y suma.o – en la lista de dependencias y en la regla, make sabe que debe compilar primero las versiones .cpp individualmente, y luego construir el ejecutable.

El uso de esta forma de makefile es suficiente para la mayoría de proyectos de pequeña escala. Sin embargo, hay una cosa que falta: la dependencia de los archivos de inclusión. Si se va a realizar un cambio en suma.hpp, por ejemplo, que make no vuelva a compilar los archivos .cpp. Con el fin de solucionar este problema, tenemos que decirle make que todos los archivos .cpp dependen de ciertos archivos .hpp. Podemos hacer esto escribiendo una regla simple y agregarlo al archivo MAKE.

 

Esta adición creamo primero la macro DEPS, que es el conjunto de archivos .hpp de los que  los archivos .cpp dependen. Entonces definimos una regla que se aplica a todos los archivos que terminan en el sufijo .o. La regla dice que el archivo .o depende de la versión .cpp del archivo y los archivos .hpp incluidos en la macro DEPS. La regla luego dice que para generar el archivo .o, make necesita compilar el archivo .cpp usando el compilador definido en la macro CC. La bandera -c dice que genere el archivo de objeto, -o $@ dice para ponga la salida de la compilación en el archivo con el nombre en el lado izquierdo de los :,  $< es el primer elemento de la lista de dependencias, y  la macro CFLAGS se define como lo hicimos anteriormente.

Bueno este es un simple tutorial con ejemplos de como usar la herramienta Make. Aun así apenas nos asomamos a ver todo el potencial que nos ofrece.

 

En nuestro articulo anterior Cómo organizar tu código fuente en C++  definíamos algunas pautas para organizar nuestro código en varios archivos a fin de mejorar su tratamiento. En este articulo vamos a ver como hacer esto con un ejemplo simple, tomemos para ello el siguiente ejemplo que suma dos números a través de una función:

Vamos a retirar la función suma a un nuevo archivo, para ello necesitamos crear en realidad dos nuevos archivos y modificar el original. Por una parte tendremos la implementación de la función suma en un nuevo archivo llamado en este caso suma.cpp:

Que simplemente contiene la implementación de la función suma, para poder incorporar esta implementación en otros códigos fuentes es preciso que creemos un nuevo archivo con la definición de la función, para hacerlo, creamos ahora un archivo llamado suma.hpp donde podemos observar que la h hace referencia a header.

Acá tenemos unicamente la definición de la función y un par de directivas de preprocesador, veamos de que se trata.

La primera parte se llama un guardia de cabecera o header guard en ingles, estas lineas impiden que un archivo de cabecera sea cargado mas de una vez mediante #include. Sirve para proyectos de software muy extensos especialmente.

La segunda parte es el contenido real del archivo .hpp, que debe ser las declaraciones de todas las funciones que queremos otros archivos puedan ver. Todos nuestros archivos de cabecera deben tener una extensión .hpp.

Finalmente el archivo principal main.cpp queda de la siguiente manera:

Observe que la segunda linea incluye las funciones definidas en suma.hpp que se implementan en suma.cpp. Ahora ya las podemos usar libremente y a discreción a lo largo de este código fuente.

Julio Cesar tenía la premisa de “Divide y Triunfaras”, y muy mal no le fue en sus conquistas. Vamos a ver como organizar nuestro código fuente dividiéndolo en fragmentos de código más fáciles y cómodos de manejar, vamos a aprender cómo hacerlo y bajo qué criterios.

Muchos programas simples se pueden escribir en un solo archivo fuente en C++, pero, cualquier proyecto serio va a necesitar dividir en varios archivos con el fin de ser más manejable.

Sin embargo, muchos programadores que recién comienzan no se dan cuenta de cuál es la importancia de esto, sobre todo porque algunos ya lo intentaron y se encontraron con tantos problemas que decidieron que no valía la pena el esfuerzo.

Este artículo intenta explicar por qué hacerlo y en un próximo artículo cómo hacerlo correctamente.

Voy a llamar a los archivos estándar de C ++ (por lo general con extensión .cpp) “archivos de codigo fuente”. Esto será para distinguirlos de los “archivos de cabecera” (por lo general con extensión .h o .hpp).

¿Por qué dividir el código en varios archivos?

La primera pregunta que algunos programadores novatos se hacen cuando ven un directorio lleno de archivos de código fuente es, “¿por qué no está todo en un solo archivo?”

La división de cualquier proyecto de tamaño razonable nos provee de algunas ventajas, las más significativas de las cuales son las siguientes:

  • Acelerar la compilación – la mayoría de los compiladores trabajan en un archivo a la vez. Así que si todos sus 10000 líneas de código se encuentra en un archivo, y cambian una línea, entonces usted tiene que recompilar 10000 líneas de código. Por otro lado, si sus 10000 líneas de código se distribuyen uniformemente a través de 10 archivos, a continuación, cambiar una línea única requerirá compilar solo 1.000 líneas de código. Las 9000 líneas en los otros 9 archivos no necesitarán volver a compilarse.
  • Aumentar organización – La división de su código a lo largo de líneas lógicas, será más fácil para usted (y los otros programadores del proyecto) para encontrar funciones, variables, declaraciones, etc.
  • Facilitar la reutilización de código – Si el código está cuidadosamente dividido en secciones que operan en gran medida de forma independiente el uno del otro, esto le permite utilizar ese código en otro proyecto, que le ahorra un montón de tiempo y trabajo en volver a escribir el código.
  • Compartir código entre los proyectos – El principio aquí es el mismo que con el tema reutilización. Al separar cuidadosamente código en determinados archivos, se hace posible que los múltiples proyectos que utilizan algunos de los mismos archivos de código sin duplicarlos. El beneficio de compartir un archivo de código entre los proyectos y no sólo utilizando la copia y pega es que cualquier corrección de errores realizados en ese archivo o archivos de un proyecto afectará el otro proyecto, por lo que ambos proyectos pueden estar seguros de utilizar la versión más reciente del código.
  • Dividir las responsabilidades de codificación entre los programadores – Para grandes proyectos, esta es quizás la principal razón para la separación de código en varios archivos. Sistemas de gestión de configuración y los sistemas de control de versiones como CVS o Git ayudarle con esto.

Ahora que ya estás convencido de que hay beneficios para la división de tu proyecto en varios archivos más pequeños. Así que, ¿cómo hacerlo? Aunque algunas de las decisiones que tomes serán razonablemente arbitrarias, hay algunas reglas básicas que debes seguir.

En primer lugar, mira cómo dividir el código en secciones. A menudo esto es mediante su división en subsistemas separados, o “módulos”, como el sonido, la música, gráficos, manejo de archivos, base de datos, etc.

Crea nuevos archivos con nombres significativos para saber de un vistazo qué tipo de código es el que contienen.

A veces es necesario que un módulo se divida en dos o más archivos, ya que podría tener sentido hacerlo por razones lógicas.

Una vez que haya dividirlo según este criterio los archivos de código fuente, el siguiente paso es considerar lo que va a entrar en los archivos de cabecera. Básicamente consiste en poner el código que suele estar en la parte superior del archivo de código fuente en un archivo de cabecera separado.

EL código que se pone  en un encabezado por lo general incluye algunos o todos de los siguientes:

  • definiciones de clases y struct
  • typedefs
  • prototipos de funciones
  • variables globales
  • constantes
  • macros #defined
  • directivas #pragma

Peligros potenciales

Las reglas dadas arriba son bastante generales y sólo sirven como punto de partida para la organización de su código. En casos sencillos, se puede seguir esas directrices. Sin embargo, hay algunos detalles más que se tienen que considerar.

En mi experiencia, hay cuatro errores básicos que las personas enfrentan cuando entran en el oscuro mundo de los archivos de cabecera definidos por el usuario.

  • Los archivos de código fuente ya no se compilan ya que no pueden encontrar las funciones o variables que necesitan.
  • Definiciones duplicadas en una clase o identificador se incluye dos veces en un archivo de origen.
  • Duplicar instancias de objetos dentro del código que compila bien. Este es un error que une, a menudo difícil de entender

Conclusión

Si se realiza correctamente, la organización de los archivos de esta manera puede acelerar su desarrollo sin perjudicar en absoluto o introducir algún problema adicional. A pesar de que parece que hay mucho que considerar cuando se hace así, con el tiempo se convierte en una práctica habitual.

Sólo recuerde estos puntos clave:

  • Divida el código siguiendo el criterio de identificar los modulos logicos
  • Use los archivos de .cpp para la implementación y los archivos .hpp para la interfaz

En la empresa estábamos trabajando sobre nuestros servidores de VOIP y nos dimos cuenta de que surgía la necesidad de poder conectar los teléfonos de la flota dentro de nuestra red (configurar SIP) y así poder hacer llamadas desde el exterior o simple llamas a internos utilizando datos, ya sea wi-fi o red móvil, buscando en internet no encontramos una página que nos explique bien la operatoria es por eso que preparamos este post.

Fuente: Synergo