Warning: This is a (very) delayed announcement! ;-)
oEmbed is an open standard for embedded content. It allows users to embed some resource, like a picture or a video, in a web page using only the resource URL, without knowing the details of how to embed the resource in a web page.
oEmbed isn't new stuff. It was created around 2008, and despite not being widely supported by content providers, it is supported by some big players, like YouTube, Vimeo, Flickr and Instagram, making its usage highly viable.
To support the oEmbed standard, the content provider just needs to provide a simple API endpoint, that receives an URL and a few other parameters, like the maximum allowed height/width, and returns a JSON or XML object, with ready-to-use embeddable code.
The content provider API endpoint can be previously known by the oEmbed client, or auto-discovered using some meta tags added to the resource's HTML page. This is the point where the standard isn't precise enough: not all of the providers support auto-discovering of the API endpoint, neither all of the providers are properly listed on the oEmbed specification. Proper oEmbed clients should try both approaches, looking for known providers first, falling back to auto-discovered endpoints, if possible.
Each of the Python libraries for oEmbed decided to follow one of the mentioned approaches, without caring about the other one, failing to support relevant providers. And this is the reason why I decided to start writing pyoembed!
Some weeks ago I decided to restart working with PIC microcontrollers, just for fun, and bought some electronic components, tools, etc. After having everything in hands, I started looking at the state of the PIC development tools in Gentoo, and found some outdated packages. I updated the packages I wanted to use (dev-embedded/gputils and dev-embedded/gpsim; dev-embedded/sdcc still needs some work), and added some other packages (dev-embedded/cpik, a C compiler for PIC 18F, and re-added dev-embedded/pikdev, a simple graphic IDE for the development of PIC-based applications, that was previously removed due to the usage of kdelibs3, and now is a Qt4-only application).
I'll be putting some effort on packaging the MPLAB X IDE and the XC8 compiler in the next weeks, if permitted by their licenses. I'm not sure yet.
That's all for now.
This year I helped the Gentoo GSoC project as a mentor for the first time! I mentored Jauhien Piatlicki, that worked on the g-sorcery project, that is a framework for automated ebuild generators. It is meant to replace g-octave and some of the other Gentoo automated ebuild generators in the future.
For those who don't know, Google Summer of Code is a Google program that pays a student to work during 3 months on an open source project.
I have been using Scrum at work for some time already, and asked Jauhien about trying to use it in our project. We agreed on using it wherever it made sense for our workflow. In other words, we adapted Scrum to our workflow, instead of adapt our workflow to Scrum. That's because none of us was a Scrum expert, and because we needed to follow Gentoo/Google guidelines and timeline during all the project, making it hard to apply some aspects of the Scrum methodologies.
We had sprints of 2 weeks, starting on monday, after a quick planning on IRC. We had a private IRC channel at Freenode, where we discussed stuff, had meetings, etc.
Tumblelogs are old stuff, but services like Tumblr popularized them a lot recently. Thumblelogs are a quick and simple way to share random content with readers. They can be used to share a link, a photo, a video, a quote, a chat log, etc.
blohg is a good blogging engine, we know, but what about tumblelogs?!
You can already share videos from Youtube and Vimeo, and can share most of the other stuff manually, but it is boring, and diverges from the main objective of the tumblelogs: simplicity.
- ← Newer
- Older →