Agregador de canales de noticias

Se soluciona un bug que al listar las tablas creadas
provocaba un fallo de segmentación.

Commiter:
José María Caballero Alba
caballeroalba@gmail.com
Added:

Modified:
src/main.c
src/screen_work_flow.h

Deleted:

Hoy día 21 de Marzo, el equipo al completo de Open Tiny Crazy World está de enhorabuena: Esta mañana hemos puesto en práctica nuestra primera actividad-tipo para educación en nuevas tecnologías con una divertida jornada con l@s niñ@s del Grupo Scout San Rafael de Elche, que nos han visitado en la Universidad Miguel Hernández.

En este evento hemos desarrollado nuestra ficha educativa “Conociendo las redes sociales”, que ya podéis descargar en la página de “Actividades” de nuestro sitio web. Además de esto, hemos aprovechado para introducirles en el mundo de la impresión 3D a través de Wynona, la Impresora 3D que utiliza el equipo de la rama de estudiantes IEEE SB UMH, amablemente cedida por el SIATDI (Servicio de investigación y apoyo técnico a la docencia y a la investigación de la UMH).

En la actividad queríamos queríamos tener una primera toma de contacto con el principal segmento de mercado al que irá destinado nuestro producto y realizar un intercambio de conocimientos. También queríamos dar uso a nuestro propio material educativo y sacar conclusiones haciendo una evaluación posterior.

Como principal aspecto a trabajar, hemos considerado que es muy importante el modo en que los jóvenes ven las redes sociales hoy en día. Es por ello que hemos realizado un experimento en el que simulábamos una red social en la que los niños tenían que “publicar” dibujos de sus juguetes (Cada uno ha dibujado su juguete favorito y su juguete más “olvidado”). A continuación, comentaban e interactuaban a través de ellos como si fuera una auténtica red social. Al final del taller, hemos conducido a una situación en la que tres monitores defendían la autoría de tres de las creaciones de los niños, con un tira y afloja en el que ambas partes defendían haber creado el mural, y concluyendo con una moraleja clara: Cualquier cosa publicada en internet está al alcance de cualquiera, y puede ser utilizada sin que nosotros lo sepamos. Nuestros datos en internet nos restan privacidad, y es necesario medir la necesidad de tener perfil en cada red social. Las RRSS son una increíble herramienta para la sociedad, pero es imprescindible hacer un uso correcto de ellas y siempre pensar antes de postear.

Al final el sabor de boca que ha quedado ha sido muy bueno: L@s niñ@s se lo han pasado “¡pipa!” y nosotros hemos aprovechado para, por un lado cerciorarnos de la importancia de la educación en nuevas tecnologías, siempre con base al respeto y a la utilidad, y por otro conocer las tendencias y gustos de l@s niñ@s cuando llega la hora de coger sus juguetes y jugar con ellos; tendencias y gustos que tendremos en cuenta a la hora de desarrollar nuestros productos y servicios. Próximamente publicaremos conclusiones y valoraciones sobre los resultados obtenidos.

Agradecemos al Grupo Scout San Rafael por darnos esta oportunidad para trabajar con sus lobatos y esperamos que la actividad haya sido para ellos tan provechosa y divertida como para nosotros lo ha sido. Hoy somos un poco más felices que ayer, y consideramos que nuestro trabajo definitivamente comienza a dar sus frutos.

Muchas gracias por leer este artículo y un saludo de parte del equipo de OTCW. ¡Hasta la próxima!

Se añade el fichero principal main.c con los métodos de inicio.

main(): Llama a las apis de tabla, que a su vez llama a las de
chain y rule. También llama a la api de ncurses para recrear
el menu principal de la aplicación.

Commiter:
José María Caballero Alba
caballeroalba@gmail.com
Added:
src/main.c

Modified:

Deleted:

Se modifica las apis de table,chain y rule para reservar la
memoria con calloc en vez de con malloc para inicializar
a 0 la memoria para las estructuras y así eliminar fallos
en valgrind.

Commiter:
José María Caballero Alba
caballeroalba@gmail.com
Added:

Modified:
src/chain.c
src/rule.c

Deleted:

Se sanea el contenido de src para su mejor uso eliminando
ficheros antiguos o inválidos.

Commiter:
Jose Maria Caballero Alba
caballeroalba@gmail.com
Added:

Modified:

Deleted:
screen_Utilites.h
src/main.c
src/main1.c
src/main3.c
src/screen_maker.c
src/screen_maker.h
src/test.c

Se sanea el repositorio de archivos inválidos o antiguos en
la carpeta principal para que la facilidad de uso sea mejor.

Commiter:
Jose Maria Caballero Alba
caballeroalba@gmail.com
Added:

Modified:

Deleted:
database_util.h
main.c
nftables
pegados de lyx/documento de requisitos.lyx
pegados de lyx/documento de requisitos.lyx~
pegados de lyx/documento de requisitos.pdf
pegados de lyx/manual iptables nuevo (copia).lyx
pegados de lyx/manual iptables nuevo (copia).lyx~
pegados de lyx/manual iptables nuevo.lyx
pegados de lyx/manual iptables nuevo.lyx~
pegados de lyx/manual iptables nuevo.pdf
pegados de lyx/pegado1.png
pegados de lyx/pegado10.png
pegados de lyx/pegado11.png
pegados de lyx/pegado12.png
pegados de lyx/pegado13.png
pegados de lyx/pegado14.png
pegados de lyx/pegado15.png
pegados de lyx/pegado16.png
pegados de lyx/pegado17.png
pegados de lyx/pegado18.png
pegados de lyx/pegado19.png
pegados de lyx/pegado2.png
pegados de lyx/pegado20.png
pegados de lyx/pegado21.png
pegados de lyx/pegado22.png
pegados de lyx/pegado23.png
pegados de lyx/pegado24.png
pegados de lyx/pegado25.png
pegados de lyx/pegado26.png
pegados de lyx/pegado27.png
pegados de lyx/pegado28.png
pegados de lyx/pegado29.png
pegados de lyx/pegado3.png
pegados de lyx/pegado4.png
pegados de lyx/pegado5.png
pegados de lyx/pegado6.png
pegados de lyx/pegado7.png
pegados de lyx/pegado8.png
pegados de lyx/pegado9.png
pegados de lyx/uml.asta
test.txt

Se ha corregido un fallo en las opciones para las tablas aceptadas

Antes se aceptaban ip,inet,arp,nat. Estas se han cambiado para
aceptar la correción por parte del profesor Pablo Neira para ser
ip,ip6,arp,brigde:

Commiter:
Jose Maria Caballero Alba
caballeroalba@gmail.com
Added:

Modified:
src/rule.c
src/table.c
src/table.h
src/testwork.c

Deleted:

Mar 17, 2015 NumberDance pushed to master at NumberDance/InformaT

• a413b97 Raiz funcionando, lista para meter componentes.

Mar 16, 2015 NumberDance pushed to master at NumberDance/InformaT

• 5e7e185 Definida la Raiz

Teniendo la forma básica procedimos a diseñar la pestaña que entraría en la pieza nexo produciendo el “clic”. Queríamos que el proceso de creación de las piezas fuera lo más simple posible, y el hecho de que estuvieran divididas en dos partes ya era de por sí bastante complicado. La pestaña nos presentaba un problema que no habíamos tenido en cuenta: Debido al saliente, hacía imposible que ese lado de la pieza fuera la base a la hora de imprimir la pieza en 3D.

Nuestra solución fue colocar un pequeño alargamiento en la parte más baja de la pestaña que conectara con el resto de la pieza para que la impresora pudiera imprimirlo como puente. En un principio el tope iba a ser de un milímetro de altura, pero tras imprimir un primer prototipo nos dimos cuenta de que era induficiente para bloquear la pieza ante una fuerza de tensión. Yendo un poco más lejos, y pensando en un futuro en el que tuviéramos que utilizar inyección de plásticos para crear las piezas, hicimos un nuevo diseño (Incluyendo en éste una altura del tope de 2 mm). La nueva versión (También dividida en dos partes) no tenía cerramientos, ahorraba plástico y parecía más apta para nuestro cometido. Además, dispusimos una ranura para que la conexión de metal de los extremos de la pieza reposara fija y no bailara. El resultado fue algo así:

Al imprimir el nuevo prototipo, nos dimos cuenta de varias cosas: En primer lugar, el sistema de agujereado que habíamos diseñado para unir las dos partes de la pieza se llevaba mal con la impresión 3D si no variábamos el tamaño de las partes. En segundo lugar, el sistema de la pestaña con tope no era todo lo eficiente que pensabamos que sería. Esto lo supimos, por supuesto, cuando dimos forma al nexo.

El nexo e4s (4 salidas) fue nuestro primer intento de pieza nexo. En principio quisimos que fuer una cruz, pero finalmente decidimos darle forma de hexágono para darle robustez a la pieza. Teníamos que hacer que la arista e50 encajase y tuviera suficiente juego para no desgastar pero suficientemente poco como para que la pieza se mantuviera firme. Nuestro primer e4s fue el siguiente:

El nexo e4s está preparado para disponer dos muelles perpendiculares en el centro, de forma que sobresalgan por las paredes y hagan contacto con los extremos de metal de las piezas arista. Cuando el diseño del juego avance,  necesitaremos aristas puramente estructurales, que no posean conducciones eléctricas internas, pero dada su facilidad, decidimos dejar éstas para más tarde. Al imprimir el nexo e4s vimos que, aunque el diseño era correcto, no ofrecía la rebustez que pretendíamos darle al juego, de modo que reconsideramos nuestro sistema. En la parte 3 llegaremos al estado actual de las piezas e4s y e50, todas las consideraciones y conclusiones del proceso de creación del enganche básico.

¡Un saludo!

We have released a new enhancement that improves the tagging of the ViSH resources and the catalogue service as well.
Now its possible to search/filter by tags in a non-case-sensitive way and taking into account internationalization.

The catalogue service of ViSH can work now using the enhanced ‘matchtag’ mode.
The wiki has been updated with instructions to set up the catalogue to work in this mode: https://github.com/ging/vish/wiki/Setting-up-a-ViSH-instance:-The-application_config.yml-file .

En esta entrada se van a exponer los problemas que se han tenido que resolver para poder añadir circuitos al juego. Se explicará la situación al empezar a estudiar el problema y después se mostrará el proceso que se ha segudio para crear nuevos circuitos.

click to read the rest of the article

In the last days there has been few work here at NodeOS, but that's because [we has been worked on a side open source project](https://github.com/NodeOS/NodeOS/issues/105): thanks to the awesome work of @formula1, now GitBlog is a reality :-D [GitBlog](https://github.com/NodeOS/GitBlog) is a blogging system that use GitHub issues as engine, so it integrate directly with our current work flow based on them :-) We'll store the content of the legacy blog for historical purposses and reference. In the next days maybe there would be some updates, but at this moment is production ready, and in fact this will be the first post there :-D But GitBlog hasn't been the only thing we have been working on... the most important one has been a re-design of the overlay layers inspired by [this IBM article](http://www.ibm.com/developerworks/linux/library/l-mount-namespaces/index.html) that have bring us trhee important things: * root home folder moved to the users filesystem * users has their own local filesystem hierarchy... * ...and root filesystem now it's read-only :-D This has the great advantage that will be easier to generate ISO disk images and to port to other platforms, since the root filesystem is minimal. So minimal, that now it only host the ```resolv.conf``` and terminfo files, so in a future iteration we'll remove them at all. No root filesystem, only the initramfs to boot the system and everything stored in the users home! :-D A too drastical design? Yes, but we are not willing to create a POSIX system here, but instead only the required parts to create an environment were Node.js apps could feel like at home :-) This give us more flexibility to optimize CPU & memory resources (specially disk space) and increase security by having less components in the system. It needs still some work to clean-up the final users filesystem and about automatically assign a filesystem namespace to new process (at this moment they are all mount on boot...), but seems promising :-) In other things, some people think that a graphical interface is important for an OS. I don't think so, and in fact it complicate the overall system so we decided to [split NodeOS and have several flavours](https://github.com/NodeOS/NodeOS/issues/106), but it's true that would be cool to be able to use NodeOS to play some games... :-P and that's why [there has been some progress towards FbDev support](https://github.com/NodeOS/NodeOS/issues/39#issuecomment-76904769). We have it by default thanks to Linux kernel default configuration, so why not use it? We were thinking about writting a wrapper library and use it as basis to implement the [Canvas API](https://developer.mozilla.org/en-US/docs/Web/API/Canvas_API) on top of it, but the fact is that [node-canvas](https://github.com/Automattic/node-canvas) (the most popular Canvas API library for Node.js) has surpassed us and now [it start to support FbDev natively](https://github.com/Automattic/node-canvas/issues/533) thanks to our comments :-D It's cool when your work can help to move forward other projects... :-) And last but no least... now we have a [Facebook page](https://www.facebook.com/NodeOperatingSystem) :-P It's not active yet but we'll try to fill it soon :-)

Buenas.

Desde hace unas dos semanas no ha habido demasiado movimiento en el desarrollo de ColorSharp. Sin embargo han sucedido suficientes cosas como para que valga la pena escribir sobre ello.

En la entrada anterior comenté como había realizado algunos esfuerzos para ponérselo fácil a la comunidad y que alguien se animara a contribuir al proyecto. A lo que comenté, debo añadir que también creé una lista de correo para quien quiera discutir sobre lo que sea más pausada y organizadamente de lo que permite un chat tipo IRC.

De momento, tanto la sala de chat como la lista de correo están completamente muertas. Es normal, el proyecto sigue sin ser conocido y es de nicho, además de estar relativamente verde todavía. Considero que la estructura y el plan de desarrollo permitirán que la biblioteca supere en flexibilidad y funcionalidad a las otras bibliotecas de conversión de color que existen para .NET (de hecho ya las supera en algunos puntos), pero de momento lo conseguido sigue siendo insuficiente.

Continuando con el asunto de la actividad, por suerte no ha sido todo malo. Añadí mi proyecto a la página de Up for Grabs, y, oh casualidad, al día siguiente tenía un “pull request” pendiente de revisión para ColorSharp :) . Debo decir que aun no lo he integrado porque tengo que hacer más pruebas, pero debería darme brío para no desanimar al colaborador recién llegado. Además, me sorprendí viendo en mi buzón dos emails de dudas relativas a ColorSharp, aunque fueron enviados a titulo particular y no a la lista de correo. El asunto de los canales de comunicación debe ser tratado.

Otro punto que tenía pendiente hasta hace nada era la documentación. Finalmente he rellenado la wiki con explicaciones sobre la estructura de ColorSharp y como usar el proyecto.

Si nos fijamos en los artículos anteriores, podemos ver que mucho de lo que he comentado y me he propuesto sigue en el limbo. La creación de comunidad y asegurar que la experiencia “out of the box” es buena han sido los puntos que más han centrado mi atención la mayor parte del tiempo.

Parece mentira, pero pequeñas sutilezas pueden marcar una diferencia enorme en la actividad del proyecto y en la percepción que se tiene de él. Por ejemplo, actualmente tengo una lista TODO en un fichero dentro del repositorio, desde luego eso es mejor que nada, pero por muchos motivos es subóptimo.

Mi próximo movimiento, antes de tocar una sola línea de código, será mover toda esa información al bugtracker de Github. Esto servirá no solo para visibilizar la necesidad de “mano de obra” sino también para obtener una mejor visión sobre el progreso del proyecto.

Saludos!

Aunque el proyecto final se  implementará en un ATMega328 para el desarrollo del firmware estoy utilizando una placa de desarrollo de ST, la STM32F4-Discovery. Esto se debe principalmente a que incluye el depurador, que va a facilitar enormemente el desarrollo.

Todo el código se va a modularizar mucho, separando sobre todo las partes dependientes del hardware. Así, cuando se termine de desarrollar y depurar el firmware en la Discovery, la migración al ATMega solo supondrá implementar unas pocas funciones relacionadas con la configuración y uso del SPI, GPIOs, Timers, etc


¿Por qué el ATMega328 y no la Discovery?Pues por tres factores:

• Consumo: El µC de la Discovery es un ARM Cortex-M4 de 32bits y el ATMega328 es un micro de 8 bits más sencillito, con menos periférico, menos frecuencia de reloj y menos consumo. Como no se necesita más de lo que nos proporciona el ATMega328, nos quedamos con él.
• Tamaño: La Discovery es una placa relativamente grande y crear la nuestra propia y soldar el ARM es bastante complejo. El ATMega328 tiene un encapsulado de pocos pines y la circuitería para echarlo a andar es muy simple (como vimos en el esquemático propuesto)
• Bibliotecas: Las bibliotecas para la configuración y el control de los periféricos del ARM son privativas y demasiado complejas para perder el tiempo replicándolas. Las del ATMega son libres, así que el firmware que desarrolle cumplirá con las normas del concurso.

Mar 10, 2015 NumberDance pushed to master at NumberDance/InformaT

• c474840 Definida la Raiz

Mar 10, 2015 NumberDance pushed to master at NumberDance/InformaT

• 62302b1 Definida la Raiz

¡Hola a todos!

Desde hoy quedarán visibles todos nuestros avances en el desarrollo de la app, tanto documentación como programación.

Esperamos que este espacio sirva de ayuda para todos aquellos, que como nosotros, se introducen en el mundo de la programación Android y podamos compartir experiencias.

¡Mucha suerte!

Hi! Today I’d like to show you how the jQuery.dpm library works and how it communicates with the user interface.

The library is responsible af all communication between DPMbox and the DPM server through its WebDAV interface. So basically it acts as an API exposing the needed WebDAV methods, lying on the JavaScript XMLHttpRequest object through the jQuery Ajax method.

Besides taking care of global data as XML headers or defining some additional functions, what the library offers is (method with correspoding WebDAV call in brackets):

Main methods

• get (GET)
• post (POST)
• head (HEAD)
• mkcol, createFolder (MKCOL)
• put, createFile (PUT)
• remove (DELETE)
• report (REPORT)
• getVersionTreeReport (REPORT)
• checkout (CHECKOUT)
• uncheckout (UNCHEKCOUT)
• checkin (CHECKIN)
• versionControl (VERSION-CONTROL)
• lock (LOCK)
• unlock (UNLOCK)
• propfind, getProperty (PROPFIND)
• proppatch, setProperty, removeProperty (PROPPATCH)

And here’s a diagram represeting how a jquery.dpm method works. As you see by the prepare function we configurate accordingly an XHR that then is sent to the server:

Additional methods

• isCollection: Returns whether an element is a collection or not by looking for a collection XML tag inside a resourcetype property. For a DPM server there’s no need to use it since a DPM response includes a specific property iscollection to check this, but the method is needed for standard WebDAV server support.

• getNodesByTag: Works exactly like the standard getElementsByTagName, however introduces the ability to filter those results by namespace, which is important for handling WebDAV results.

• seekToNode: Sets resource variable to first node matched via getNodesByTag, and returns this, allowing further processing.

• eachNode: Executes a function on each element.

• nodeText: Get the text contained by a node.

• nodeName: Returns the name of a node (the tag name, essentially).

• extendbeforesend: jQuery ajax option beforeSend may be set to a function reference, and this function will fire prior to the request being sent. It gets the XHR object, so this is the point you will want to do things like set headers, for example.

• prepare: Prepares the WebDAV call. Here we want to ensure integrity of call object, verify WebDAV method requested, set any authorization information (if necesssary), and return the modified call object. WebDAV servers usually respond in XML but some WebDAV methods will not return anything at all, or return an empty response. This matters to jQuery in that the success method of a jQuery.ajax options object won’t fire if the reponse could not be parsed (although the complete method will). Is needed to be aware of what dataType of your ajax response will be, and set it appropriately.

An XML response of the DPM server looks like this:

<D:multistatus xmlns:D="DAV:" xmlns:ns0="DAV:"> <D:response xmlns:lcgdm="LCGDM:" xmlns:lp3="LCGDM:" xmlns:lp1="DAV:" xmlns:lp2="http://apache.org/dav/props/"> <D:href>/dpm/cern.ch/home/dteam/aalvarez/public/test_collection/</D:href> <D:propstat> <D:prop> <lcgdm:type>0</lcgdm:type> <lp1:resourcetype> <D:collection></D:collection> </lp1:resourcetype> <lp1:creationdate>2015-04-04T09:51:59Z</lp1:creationdate> <lp1:getlastmodified>Fri, 27 Feb 2015 18:57:50 GMT</lp1:getlastmodified> <lp3:lastaccessed>Sat, 04 Apr 2015 09:51:59 GMT</lp3:lastaccessed> <lp1:getetag>5c317-54f0be2e</lp1:getetag> <lp1:getcontentlength>0</lp1:getcontentlength> <lp1:displayname>test_collection</lp1:displayname> <lp1:iscollection>1</lp1:iscollection> <lp3:guid></lp3:guid> <lp3:mode>040775</lp3:mode> <lp3:sumtype></lp3:sumtype> <lp3:sumvalue></lp3:sumvalue> <lp3:fileid>377623</lp3:fileid> <lp3:status>-</lp3:status> <lp3:xattr>{"type": 0, "normPath": "\/dpm\/cern.ch\/home\/dteam\/aalvarez\/public\/test_collection"}</lp3:xattr> <lp1:owner>3</lp1:owner> <lp1:group>102</lp1:group> </D:prop> <D:status>HTTP/1.1 200 OK</D:status> </D:propstat> </D:response> </D:multistatus>

Depending on the context in the interface and the w2ui library, the XML data is parsed in JSON format and adapted with a specific dpmFilters method. And considering that is a petition on the network, the way to use it is by taking advantage of jQuery ajax callbacks, like for example success.

/* * A function to refresh the grid content */ function refreshContent(directory_route){ $.dpm(server + directory_route).readFolder({ success: function(dat) { w2ui.grid.clear(); w2ui.grid.add(dat); }, dataFilter: $.dpmFilters.filesDPM }); }

And that’s all. I hope that with this post you have now a clear vision of how DPMbox communicates with a DPM server.

¿Qué son los Minus?

Para un dibujante, la pregunta cambia a ¿Cómo son los Minus?

Lo primero que imaginé fueron bolitas diminutas volando de un lado a otro tan rápido que casi ni se veían. Pero los Minus tenían que dejarse ver, porque son ni más ni menos que los personajes principales de este curioso y diminuto mundo…

El problema que tiene una bolita es que poco puede hacer aparte de poner caras, así que, naturalmente, la siguiente idea fue una bolita con patas, algo más expresiva. Para no limitarme a una sola idea, empecé a diseñar personajes variados: redondos, alargados, con gafas, en patines, e incluso con forma de animalito. Y después de todo, el que acabó llamando más mi atención fue….sí, exactamente: una bolita con patas.

Con la aprobación del resto del equipo, me centré en ese diseño, y le di movimiento y color. En un principio, los Minus iban a ser amarillos, porque es el color que más me recuerda a la electricidad. Pero al final decidimos que fueran azules, por votación popular de amigos y familiares.

¡Por fin nuestros diminutos protagonistas han hecho aparición! Ahora observémoslos, sigámoslos por su pequeño mundo y hagámonos preguntas, porque hay muchísimas cosas que podemos aprender de ellos.

Bienvenidos a Open Tiny Crazy World.