Planeta código

• Planeta
• Foros
• Trastienda
• WIKI

• Posicionamiento web
• Ofertas hoteles Barcelona
• Abogados
• Insurance

Meta-Info

¿Que es?

Planeta Código es un agregador de weblogs sobre programación y desarrollo en castellano. Si eres lector te permite seguirlos de modo cómodo en esta misma página o mediante el fichero de subscripción.

subscripción

PlanetaCódigo en inglés

Puedes utilizar las siguientes imagenes para enlazar PlanetaCodigo:

Si tienes un weblog de programación y quieres ser añadido aquí, envíame un email solicitándolo.

Idea: Juanjo Navarro

Diseño: Albin

Pointer to (void)

Integración Diaria, build diario (step back)

Enero 31st, 2005 - [Enlace local]

» Leer más, comentarios, etc...

Pointer to (void)

Integración Diaria, build diario (step back)

Enero 31st, 2005 - [Enlace local]

Recapacitando esta mañana, este post no puede empezar sinó felicitando(me) los recién cumplidos 23 añitos que hago hoy!! Impresiones sobre el próximo año, me siento pequeño todavía.

Volviendo al post anterior, las primera impresión que he recibido es que los desarrolladores españoles no están para nada acostumbrados a los sistemas de build y esas cosas. Si, se que los de java soleis utilizar ant a diario. Si, se que la legión linuxera está empapada de make hasta los codos. Pero los "pobres" desarrolladores de .NET que intentamos sobrevivir a diario todavía nos falta un camino bien grande por recorrer. Por ello, creo que es mejor pegarle un repaso a NAnt, antes de seguir con la integración contínua. No entraremos en temas técnicos, para eso ya hay infinidad de tutoriales.

Un sistema de Build para equipos de desarrollo pequeños.

Vamos por partes. Has decidido ponerte manos a la obra y decides productizar tu aplicación. Cosas que debes tener en cuenta antes de hundirte por intentar hacer las cosas a lo grande:

1. Si tu empresa es pequeña y no puede permitirse lujos de personal, evita caer en la tentación de emplear tres ramas de código (main, qa y release) y cíñete a dos de ellas: main y release. Te recuerdo que seguramente contarás con 3 o 4 desarrolladores, poco tiempo y ningún departamento de calidad. Así pues, establece normas de uso para cada rama: main se utiliza para añadir nuevas características; cuando lo has sometido a pruebas, funciona y no hay más cambios, integra en release. La rama de release utilízala solo para solucionar problemas y fallos. Cada rama ha de mantener su propio número de versión diferente, y una rama puede contener más de una versión logicamente. Típicamente, cuelga tus archivos sobre\\depot\main integra nuevas cosas en \\depot\release y si encuentras un fallo en release, mezcla hacia main. Necesito una traducción de la documentación de perforce ya. (mezclar == merge ?¿?)
   
   
2. He visto en algunos sitios web, que utilizan el número de versión de los ensamblados como número de versión de tu producto. Es una mala elección. Intenta mantener las dos cosas separadas. Así sabrás, cuando realices cambios, qué versión de qué componente es afectada en cada nueva versión de tu producto. Cuando se desarrollan componentes, siempre estas mirando a la reutilización, asi que no los trates como si fueran parte de tu solución (aunque realmente lo sean).
   
   
3. Ejecuta dos builds separados. Uno en main, y otro en release. Obviamente si utilizas NAnt lo lógico sería mantener estos archivos en el propio control de código fuente. Un archivo de ".build" por componente es perfecto. Deberías mantener un archivo fuera del control de código fuente que te permita iniciar el build. Por ejemplo, crea un directorio en c:\build\ que se ejecute con nant release o nant main. Cada uno de estos targets realizará las siguientes acciones:
   
   
1. Obtener el número actual de versión de build.number.release o build.number.main y crear un directorio correspondiente (c:\build\release\1.0.43.456\, por ejemplo).
   
   
2. Crear la estructura base dentro del directorio, a saber, tres directorios: src donde guardaremos los fuentes provenientes de perforce (incluidos archivos de build); setup, donde podemos guardar el instalador de la versión actual (Inno Setup o NSIS funcionan de maravilla y son gratuitos); y web, donde podemos en el caso de que sea una aplicación web, desplegarla y crear un directorio virtual que apunte siempre a la última versión. Útil si necesitas que alguien vea el progreso.
   
   
3. Sincronizar la parte del depot que sea necesario y copiarla al src actual. En NAntContrib existe una tarea para ello, pero no funciona del todo como debería. Mejor utiliza exec y pon la línea de comandos a mano que no es tan costoso.
   
   
4. Copiar de src los archivos .build de los componentes. Lo mejor, que pruebes a construir la aplicación primero y llames en este punto al archivo que coordina ese proceso. <nant etc...
   
   
4. Intenta escribir test para los componentes más críticos de tu aplicación. Si utilizas NUnit, puedes integrar la fase de validación de las pruebas en el proceso de build, fácilmente con NAnt.
   

» Leer más, comentarios, etc...

niko's mini factory

Integración continua para .NET

Enero 29th, 2005 - [Enlace local]

¿Integración continua para .NET? ¿Realmente? Pues si, es posible con NAnt por ejemplo, un producto opensource. Vean este ejemplo de Luis.

» Leer más, comentarios, etc...

Comienzo del libro Java & XML 2nd Edition

Enero 25th, 2005 - [Enlace local]

» Leer más, comentarios, etc...

Anjuta 2.0

Enero 25th, 2005 - [Enlace local]

Parece que la versión 2.0 de mi IDE preferido, Anjuta, para C/C++, va a salir en una o dos semanas con un montón de novedades entre las que destacan:

• *Navegación sobre Devhelp integrada
• *Integración de un diseñador GLADE
• *Task manager
• *Quizás un plugin para Subversion

Y más novedades…

Ya estoy deseando probarlo, aunque de momento no me voy a bajar la versión del CVS por una cuestión de salud “codigal”

» Leer más, comentarios, etc...

Mi coeficiente Nerd…

Enero 24th, 2005 - [Enlace local]

Wow, no estoy seguro de querer publicar esto, pero según este test soy un 80% mas nerd que la mayoría.

Respecto a no “postear” tan a menudo, tengo para decir en mi defensa que estoy cambiando de compañía para la que trabajo, por lo que el entrenamiento de la gente que me reemplazará me deja poco tiempo disponible.

Cuando podáis, mirad este pequeño ejemplo de Debu Panda sobre EJBs 3.0: Using EJB 3.0: Lean and Thin HelloWorld, y este logging “anti-framework”: simple-log.

» Leer más, comentarios, etc...

Null Pointer Exception

Niños Prodigio

Enero 21st, 2005 - [Enlace local]

Hacía tiempo que no visitaba MobileRobotics y me he llevado una gran sorpresa. Este portal va a patrocinar al equipo Team Prodigies en su intento de conseguir ganar la competición DARPA Grand Challenge, ya sabéis, la carrera del millón de dólares (bueno, a partir de este año será la carrera de los dos millones de pavos) que consiste en una carrera de vehículos autónomos por el desierto.

Lo que llama la atención de este equipo es que está formado por dos chavales de 15 y 20 años que han conseguido despertar la atención de todo el mundo, de hecho, su principal patrocinador para la GC2005 será Via Technologies. Aunque en su página web se pueden encontrar algunos detalles de su trabajo, lo más interesante es su blog, donde van contando su trabajo diario y como van preparando su vehículo. Resulta curioso y divertido ver como compran las piezas en eBay y como tienen que compaginar la construcción del robot con la escuela (y con los deberes !!). Espero que su eXpeditor se comporte en el desierto ...

Ahora una pregunta, ¿qué hacías tú a los 15 años?

P.D.: por cierto, parece que roller no se lleva excesivamente bien con las eñes, así que para acceder a la página de comentarios hay que ir a esta dirección: http://weblogs.javahispano.org/comments/mondelo/Weblog/ninos_prodigio#comments. Al visitante que lo hizo antes que yo descubriera este bug (¿feature?) para decir que a los quince años se la machacaba le borré el comentario no porque me pareciera ofensivo (todo lo contrario, según los últimos estudios es un hábito muy sano) sino porque al menos podía haber puesto su nombre

» Leer más, comentarios, etc...

Fuckowski: Memorias de un programador

Enero 19th, 2005 - [Enlace local]

Relatos imprescindibles de leer para los programadores, en www.fuckowski.com

Un extracto:

…
El “brainstorming” o “tormenta de cerebros” es (o debería ser) la reunión en la que todos aportan su talento y experiencia para encontrar soluciones óptimas a problemas. La realidad es que en la tormenta de cerebros, el manager suele poner la tormenta y tu tienes que poner el cerebro. Y en la tormenta, como en el río revuelto, la ganancia es para los pescadores. Tu piensas, diseñas y solucionas, que para algo querías ser ingeniero. El se apunta el gol, que para algo hizo un master en “strategy business janderklander”.

Así que uno llega a la sala de reuniones con la mosca detrás de la oreja. Ahí está él, con el portátil, la taza de café, y un montón de papeles (normalmente emails de los clientes con sus requisitos, es decir el problema en sí mismo, y ni un solo folio extra que indique que se ha dedicado algo de tiempo a solucionar nada).

Ya sabes a lo que te expones una vez más. Te van a preguntar el consabido “y ahora que hago” pero sin que se note. De soslayo. Como si tu fueras imbécil. Pero no queda ahí la cosa: vas a ser el conejillo de indias con el que poner a prueba los últimos discursitos aprendidos en los foros o “cookbooks”, para que los valides o rechaces, los corrijas, y en definitiva ayudes a perfilar esa superficial sabiduría, ese “arte de aparentar tener razón” (véase Schopenhauer) con la que estos individuos justifican sus desorbitados salarios ante la directiva (que normalmente no suele saber distinguir una churra de una merina).

Así que te lo tomas como algo personal. Se trata de dejar claro que A) una churra es una churra y una merina es una merina, es decir, una idea es una idea y una gilipollez es una gilipollez, y uno sabe distinguirlas; B) se puede hacer demagogia hablando del sexo de los ángeles o quizás de pintura abstracta, no de software; C) no se aprende en un foro en una hora lo que le ha costado a uno varios añitos de carrera, otros cuantos de trabajo, mucho café y muchas horas extras; D) un inútil con un libro no es un ingeniero; E) Un master, una corbata y una PDA hacen juego, pero no proporcionan sentido común al que carece de él.

Total, que empieza el circo. Abróchense los cinturones. Aférrese uno con fuerza a sus principios, porque le van a aplicar el método Ludovico (véase La Naranja Mecánica). Le van a inmovilizar en una silla, a administrar una droga, a colocar unos soportes en los párpados, y le van a obligar a visionar dos horas de Power Point. Le van a someter a uno a espantosas torturas psicológicas con el doble objetivo de sacarle información, y a la vez convencerle de realidades alternativas.
A continuación reproduzco fragmentos reales (doy mi palabra de honor) de reuniones con mi actual IT manager acerca de varios proyectos Java y VB en los que “hemos” trabajado.

Perla 1: Hibernate
[manager] ¿Qué utilizamos para la capa de datos?
[yo] Usemos Hibernate
[manager] Es mejor usar Entity Beans
[yo] ¿Por qué?
[manager] Entity Beans son J2EE estándar, y además están en un pool, Hibernate no tiene pool así que va mas lento.

Cuando quise explicarle la burrada que había soltado, eran tantas las ideas que se me vinieron a la cabeza de golpe que sufrí un shock y tuve que ir a por un vaso de agua. Creo que esto es una técnica deliberada de argumentación, que debería denominarse “tan gorda es la burrada que no se puede rebatir”. Si alguien dice que “dos y dos son cinco”, se puede argumentar que son cuatro. Pero si alguien dice que “dos y dos son una constelación cercana a Alfa-Centauri”, sólo se puede rebatir “¿pero de qué estás hablando?”, y te pueden replicar “Cómo se nota que no has hecho un Master Janderklander”.
…

Para partirse de risa, jajajaja.

Gracias a Vaijira por el enlace.

» Leer más, comentarios, etc...

Null Pointer Exception

Programacion Orientada a Comportamientos

Enero 17th, 2005 - [Enlace local]

No os dejéis engañar por el título, aunque me he permitido un pequeño juego de palabras (POO,AOP), este post no es de ningún nuevo paradigma de la programación, todo lo contrario, es una arquitectura de los años 80 empleada para el control de robots que en su momento supuso un avance sobre el control reactivo y con el que yo estoy practicando con mi Lego Mindstorms. Lo primero que hice fue recuperar mis apuntes de "Robótica Perceptual" (¿quién dijo que no se puede aprender jugando?) y bajarme el paper en el que Rodney Brooks expone su teoría. Además el tutorial de leJOS incluye una sección dedicada al API Behavior, que es la implementación de la "subsumption architecture" (como es conocido el modelo de Brooks) que este Sistema Operativo incluye para el control de robots Lego.

¿Qué son comportamientos? un comportamiento se entiende como una tarea o conjunto de tareas simples que se encargan de tratar un aspecto específico de nuestro robot (por ejemplo evitar colisiones). Así, la subsumption architecture pretende dividir nuestro programa en estas tareas o comportamientos. Estos comportamientos competirán por hacerse con los recursos del robot (como los motores) por lo que deberán estar priorizados, de tal manera que un comportamiento con alta prioridad puede "robarle" el recurso compartido a otro comportamiento con menor prioridad. Esta es una de las características del modelo de Brooks, frente a la división vertical del control que se hace en el modelo deliberativo (Percibe -> Planifica -> Actua), Brooks propone una división horizontal, en capas ordenadas según su prioridad, de manera que las capas superiores pueden cancelar la salida de las inferiores. Para hacer mis pruebas he implementado un ejemplo muy sencillo para un robot que sigue la linea negra: solo tiene dos comportamientos, uno que le hace andar hacia adelante, y otro, más prioritario, que cuando detecta (mediante el sensor de luz) que se ha salido de la línea negra se pone a girar para recuperar la posicion. Este sería el esquema:

¿Cómo se hace esto en Java? Aqui viene lo mejor, leJOS permite utilizar esta arquitectura en un robot Lego mediante el API Behavior, que consta de un interface que todas las clases que pretendan ser un Comportamiento deben implementar y de una clase que actuará como árbitro, determinando qué comportamiento tomará el control de los recursos. El mecanismo es muy sencillo y a la vez elegante: tus comportamientos implementan el interfaz Behavior por lo que tienen que definir tres métodos, takeControl() que devuelve un valor booleano cuando el comportamiento tenga que tomar el control, suppress() que se ejecuta cuando el comportamiento pierde el control, y action() en que se incluye el código del comportamiento propiamente dicho, es decir, lo que se va a ejecutar cuando este comportamiento tenga el control. Una vez que estén definidos los comportamientos, solo hay que crearlos, pasarlos a la clase arbitro como un array (teniendo en cuenta que los primeros elementos del array son lo que menos prioridad tienen) y poner en marcha al árbitro:

¿Para qué sirve esto? En lugar de programar el robot mediante los típicos if ... then que acaban degenerando en un código spagheti imposible de mantener, los comportamientos encapsulan un determinado aspecto del robot, con lo que hacen el código mas claro (y mantenible), además facilitan mucho la evolución del robot, ya que es muy sencillo añadir o quitar comportamientos. Por ejemplo si queremos dotar a nuestro robot con un sensor de tacto para que además de seguir la línea negra esquive obstáculos, solo tendríamos que programar el comportamiento y añadirlo al array (bArray) según la prioridad que le queramos dar.

Si antes comentaba la elegancia de Java con el uso de los interfaces, no lo es menos la posibilidad de gestionar los eventos mediante "event listener", lo que me permite por ejemplo, en lugar de preocuparme de tener que leer periódicamente el valor de los sensores mediante el API Sensor, que un listener esté encargado de comprobar el estado del sensor y avisar cuando éste haya cambiado. En mi caso he definido una clase que implementa el interfaz SensorListener, y que mediante el método stateChanged mantiene actualizado en todo momento el valor de lo que está leyendo el sensor de luz en una variable accesible mediante un método get. Así, el método takeControl() del comportamiento Girar sólo tiene que comprobar si ese valor no corresponde al color negro (de la pista) para tomar el control. Tan sencillo y tan eficaz !!

» Leer más, comentarios, etc...

El arte de programar

¿Buscas un código fuente?

Enero 16th, 2005 - [Enlace local]

Pues en www.koders.com seguramente encuentres algo parecido a lo que estés buscando. Se trata de un buscador de código fuente donde como criterios de busqueda puedes filtrar por lenguaje de programación o licencia de uso del mismo. La única pega es que para encontrar lo que andabas buscando tengas que leer un chorro de codigo de otra persona que tenga una forma curiosa (horrible) de hacer las cosas, cosa por la cual ya he tenido que pasar en algún que otro trabajo donde he estado :).

» Leer más, comentarios, etc...

Pointer to (void)

Integración Contínua

Enero 14th, 2005 - [Enlace local]

<?xml version="1.0"?>
<project name="Hello World" default="build" basedir=".">
<description>Hello World</description>

<property name="debug" value="true" />

<target name="clean" description="remove old files">
<delete file="Hello.exe" failonerror="false" />
<delete file="Hello.pdb" failonerror="false" />
</target>

<target name="build" description="compile src">
<csc target="exe" output="Hello.exe" debug="${debug}">
<sources><includes name="hello.cs" /></sources>
</csc>
</target>

</project>

» Leer más, comentarios, etc...

Pointer to (void)

Integración Contínua

Enero 14th, 2005 - [Enlace local]

Hoy toca considerar una de las practicas de moda en la industria de fabricación del software: la integración continua o continuous integration. No, no estamos hablando de matemáticas, estamos hablando de una forma de producir software, de forma continua.

Breves apuntes para situarse. Hoy en día, ninguna empresa seria habla de aplicaciones "sueltas", habla de productos. Un producto de software, y habrán mejores definiciones que esta, lo podríamos considerar como un conjunto formado por la aplicación, la documentación de esa aplicación y un montón más de elementos dependientes de la configuración. Por lo tanto, es claro que no basta con distribuir el ejecutable y esperar que el usuario funcione a su aire. Primer problema, necesitas productizar tu solución.

Por otra parte, cierto es que alrededor de todo producto de software trabaja un conjunto de profesionales, desde programadores a documentalistas pasando por analistas, gestores de la configuración, QA, ejecutivos y la señora de la limpieza, que su tarea hace. Toda esa gente realiza su labor en pro del producto por lo que los esfuerzos se centran, como en el remolino de tu bañera, en un solo punto. Si no coordinas bien toda esa energía, simplemente colisiona. Segundo problema, tienes veinte o treinta alfareros trabajando a dos manos sobre el mismo jarrón, y has de conseguir que acabe pareciendo un jarrón.

Así que llegamos al primer concepto de moda, que surgió creo recordar por los 90, cuando yo todavía apenas existía: Daily Build and Smoke Test. (para muestra, IEEE Software Best Practices, Steve McConnell). El concepto es simple. Invierte tiempo en construir un sistema que te permita compilar los fuentes, generar la documentación, empaquetar el producto, etc. de forma diaria y automática. Fijate que si lo haces diariamente, produces diariamente un producto. Y si es automático, reduces los errores y el tiempo que tus ingenieros invierten en la integración. La gente de Perforce, por ejemplo, recomienda mantener tres ramas: la principal, donde se añaden nuevas características diariamente, la rama de mantenimiento, que afianza las características ya añadidas, y la rama release, donde reside el código estable. Por lo tanto, dentro de este workflow se puede establecer un ciclo continuo de producción de la solución final que te permita evaluar la calidad, determinar el estado del proyecto y ayudar a que tus ingenieros y la señora de la limpieza puedan ir integrando nuevas características o correcciones, entre ramas y de forma ordenada, a la solución.

Basta de palabrería, para aquellos cuyas mentes pertenezcan a .NET, literalmente, NO es buena solución utilizar un archivo de solución de VisualStudio.NET, aglutinar un montón de proyectos dentro y compilar conforme te vayan dando, plus copypaste docs and stuff... No!! La respuesta viene de Java, es para .Net, es opensource y se llama... NAnt!! Es simple. Creas un directorio, escribes un documento XML con extension .build siguiendo unas pautas, ejecutas nant en la línea de comandos y pasados unos segundos, tienes tu producto. Cierto, podrías usar un script, pero es un verdadero rollo tener que escribir la línea entera de csc.exe y demás. Un ejemplo sacado de la documentación:

<?xml version="1.0"?>

<project name="Hello World" default="build" basedir=".">

<description>Hello World</description>



<property name="debug" value="true" />



<target name="clean" description="remove old files">

<delete file="Hello.exe" failonerror="false" />

<delete file="Hello.pdb" failonerror="false" />

</target>



<target name="build" description="compile src">

<csc target="exe" output="Hello.exe" debug="${debug}">

<sources><includes name="hello.cs" /></sources>

</csc>

</target>



</project>

» Leer más, comentarios, etc...

Bloggingg

Inauguración del Bloggingg

Enero 8th, 2005 - [Enlace local]

» Leer más, comentarios, etc...

Bloggingg

Inauguración del Bloggingg

Enero 8th, 2005 - [Enlace local]

Sábado 8 de enero de 2005.

» Leer más, comentarios, etc...

Pointer to (void)

Microsoft Windows AntiSpyware

Enero 8th, 2005 - [Enlace local]

» Leer más, comentarios, etc...

Pointer to (void)

Microsoft Windows AntiSpyware

Enero 8th, 2005 - [Enlace local]

Microsoft acaba de comenzar una lucha contra el spyware. Recientemente acaba de publicar una beta de su software anti-spyware, lo que podría sumarse a la ya larga lista compañias que aportan medios a la lucha. Personalmente creo que es una gran idea que un gigante con medios se encarge de temas tan serios como este. Los virus, el spam y el spyware son la lacra de internet, todavia no entiendo como pueden existir empresas que hagan dinero con ello. ¿Quien compra sus servicios? No creo en esta clase de mercado agresivo. No son formas.

Microsoft Windows AntiSpyware (beta)
Microsoft's strategy for addressing spyware
Video: Protecting your computer from spyware

La tecnología de protección a sido adquirida por Microsoft a Giant Company
Microsoft Acquires Anti-Spyware Leader GIANT Company

» Leer más, comentarios, etc...

Pointer to (void)

Prediciendo lo sobradamente visible

Enero 8th, 2005 - [Enlace local]

» Leer más, comentarios, etc...

Pointer to (void)

Prediciendo lo sobradamente visible

Enero 8th, 2005 - [Enlace local]

Sabéis la sensación esa de cuando eres niño, en la que hinchas un globo hasta que parece explotar y apuntas a la otra punta de la habitación, con la sola ingenua idea de que el globo impactará rápidamente contra el objetivo. Decides soltarlo "para ver si das" y volila, obtienes una respuesta contundente de unas rígidas y ordenadamente caóticas leyes físicas. Ese, sin duda, es mi 2004. Soltar el globo. Volar erráticamente por toda la habitación. Perder la orientación entre el ruido. Pero como el vuelo es en la habitación, y es fulgurantemente rápido, vale la pena. Que el globo no vaya en línea recta, me asombra y me hace ver como el resultado es mucho mejor de lo esperado. Señores, mi 2004 ha sido todo lo categóricamente imperfecto que puede representar un año cualitativamente perfecto. Me gusta ser yo.

Y de ahí que haya sido uno de los pocos años que no he planteado objetivos para el año próximo, lo que representa un cambio fundamental en mi vida. Ahora prevalece una sola sentencia: hazlo ahora. Y esta rige la mayoría de mi pensamiento. Tomar el control de la vida. Liderar el cambio. Provocar el cambio. De ahí pues, que mis objetivos estén sobradamente establecidos. Lo hice entonces, no he de esperar al comienzo del año. Estoy en camino, solo espero no olvidarlo.

Y toca un año y medio de estudio, ahora que puedo permitírmelo. Adoro trabajar y realmente me siento como un marinero en tierra, leyendo libros de navegación sin poderse hacerse a la mar. Es una decisión personal que poco a poco esta revelándome una sensación ya conocida, pero no instanciada. Necesito trabajar, necesito crecer. Así pues, desde aquí y a todo el que me lea: quizá mi cabeza este empezando a decidir pedir trabajo. Busco trabajo, ea.

Una de las mejores sensaciones del 2004 es, sin duda ni pausa, la siguiente: Trabajas en algo durante mucho tiempo. Al principio te embriaga la emoción, más tarde empiezas a caer en el trabajo duro, y conforme vas acercándote al final eres más y más critico con tu trabajo. Empiezas a dudar de lo que haces, te esfuerzas a diario, te llevas a niveles que no creías poder llegar, y un buen día terminas. Dejas pasar un día, compruebas lo que has hecho y no te lo puedes creer, la emoción vuelve a embriagarte. Es, simplemente, perfecto. Es como construir una pirámide gigante con los ojos vendados. Quitarse la venda y ver lo que realmente ha valido tu trabajo, eso no tiene precio.

De corazón, feliz 2005.

» Leer más, comentarios, etc...

Mejor no usar NULL en C++

Enero 7th, 2005 - [Enlace local]

Esta mañana me decía un compañero de faenas que era conveniente no usar NULL en C++, y mi curiosidad me llevó a preguntarle el porqué sin una respuesta convincente .

Me puse a buscar una razón, la encontré y se la dije sin decirle que lo había leído en Internet, jejeje.

The pointer is initialised to 0, and not “NULL”. There is no such thing as “NULL” in C++, so the number 0 is what we have, and use. The reason is, oddly as it may seem, that C++ is much pickier than C about type correctness. Typically in C, “NULL” is defined as “(void*)0.” C++ never allows implicit conversion of a “void*” to any other pointer type, so this definition is not good enough. The integer 0, however, is implicitly convertible to any pointer type.

Como pone aquí, en C, NULL está definido como (void *)0 y C++ nunca permite una conversión implícita de un (void *) a cualquier otro tipo de puntero, por lo que no es bueno del todo usar NULLs cuando se programa en C++. Sin embargo, el entero 0 se puede convertir a cualquier tipo de puntero de forma implícita por lo que es más correcto.

Curiosidades de la vida que uno desconoce y conviene apuntarlas en un weblog

» Leer más, comentarios, etc...

Null Pointer Exception

Lo que no me trajeron los Reyes …

Enero 6th, 2005 - [Enlace local]

Pese a que estos últimos días intenté portarme mejor de lo que lo había hecho durante el resto del año y que además había dejado turrón y sidra en cantidades industriales para que sus majestades repusieran fuerzas en tan ajetreada noche, no hubo manera, y de la lista de regalos que les había pedido, esta mañana en mi zapato no había nada.

En fin, que no tengo ni el robosapien...

... ni el modulo gsm nokia 12 con el que poder conectar mi lego con el mundo ...

(supongo que los reyes no se pudieron hacer con él porque creo que no se vende a particulares y su precio no me lo quiero ni imaginar. Mas información en esta presentacion en pdf. Las imagenes estan tomadas de este post en el blog de Angela Caicedo)

... ni siquiera un robot-aspirador que haga las tareas domésticas mientras yo me dedico a otras cosas mas productivas ...

(foto tomada en el Media-Markt de Oviedo, el cacharrito costaba una pasta)

Pero bueno, también me han dejado otras cosas, espero que con vosotros hayan sido espléndidos

Y de paso aprovecho para felicitaros el nuevo año y advertiros que he retomado con mas fuerza mi afición por la robótica y espero también retomar también con fuerza este blog (ya se sabe, estamos en época de buenas intenciones). Y que el 2005 sea todavía mejor que el 2004 !!

» Leer más, comentarios, etc...