Posts Tagged ‘ OpenSource ’
Remember a few weeks back I announced resisto.rs, a no-frills resistor color code calculator?
Welllll, if you happen to be a user of DuckDuckGo, it’s now even easier. See the resistor colors directly in your search results!
Try it out at DuckDuckGo.
And thanks to DuckDuckGo for making it so easy to extend your search engine.
Here’s the code.
[Update: discuss on Hacker News]
This is the Pi Crust:
It lives at http://picru.st/.
It’s a little PCB I designed to make it easier to experiment with electronics and the Raspberry Pi.
You stick it on a Raspberry Pi, like this:
Some features:
There are lots of other boards out there, but this is unique in that it fits nice and snugly against the Pi, keeping your projects compact.
Now you can easily find all those pins:
Find out how to make one for only a few $ at http://picru.st/
[Update: discuss on Hacker News]
Smoothie Charts has a new website. Rather than add to it, I ended up taking stuff out. It’s simple and to the point. It also works well on mobile / tablets.
I like the Texas Instrument MSP430 microcontroller. It’s cheap, low-powered and has tons of features. You can get a complete development board, with embedded debugger, software and 2 controllers for $4.30!
I also like the macetech ShiftBrite RGB LED modules. Makes it easy to add a bit of color to electronics projects.
So here’s a library that makes it easy to control a ShiftBrite from an MSP430:
SiteMesh is now available for Webbit Server:
Tutorial here: https://github.com/joewalnes/webbit-sitemesh
There’s tons of great JavaScript charting libraries out there. Too many to choose from. I’ve just made it worse by adding yet another to the mix.
Before I go on, I want to balance karma a little – if you’re looking for a JavaScript charting library, just use Flot. I don’t know anything about your requirements, but I like my chances – everyone loves Flot (including me). It’s small, simple, great looking and flexible.
So why another library? Well, I had a very specific problem… I want to show real time streaming data pushed over a WebSocket. Although many of the charting libraries allow you to dynamically update data, none have really been optimized for a constant stream of data. I tried many (seriously, at least 40 libraries) and the constant updates just looked too jerky.
So Smoothie Charts was born. It’s not big, and it’s not clever. And it only works on Chrome and Safari. And it doesn’t support legends. Or pie-charts. In fact, it’s inferior in virtually every way to a library like Flot. But, it’s very good at displaying streaming data.
I use it for building web dashboards monitoring active system load (that look something like this).
Use it, hack on it, and contribute back.
I’d like to announce the new lead for QDox, Robert Scholte.
Anyone who’s been following the project for the past year would have seen that Robert has made a tremendous number of contributions to all areas of QDox, including bug fixes, build, docs/website, releasing, user support and admin. If you follow the project further back, you’ll see that Robert has actually done more on the project in the past year than was done for the combined 6 years before that…. impressive.
I originally wrote QDox back in 2002, as a stop gap until annotations were added to the Java language. It was quickly picked up tools such as XDoclet. I always thought (and hoped) that once annotations made it into the language, it would be redundant. Yet it lived on. Unlike the JDK Annotation Processing Tool (APT), it could process source code rather than byte code in a simpler and faster manner. And it provided access to information that the JDK didn’t make available (e.g. parameter names). And it was useful where annotations still did not exist, like in JavaME. So, even in 2010, it still lives on and is used in tools such as Maven and Eclipse. But I cannot invest the time into it that I once could.
Given Robert’s commitment to the project, I can think of no better person to lead the project. He’s done an astounding job. Robert has kindly accepted this role and I’m delighted to hand it over to him.
I’d also like to use this opportunity to thank Paul Hammant, Mauro Talevi and Dennis Lundberg for their ongoing efforts on the project.
Does SiteMesh work on Google AppEngine (Java preview)?
Short answer: Yes.
Longer answer: Yes. It does. So long as you check 2 things…
You need SiteMesh version 2.4.2 or greater. Earlier versions do not support AppEngine.
If you want decorators to be applied to static content (e.g. to .html files), the following needs to be added to WEB-INF/appengine-web.xml:
<static-files> <exclude path="**"/> </static-files>
This forces the static resources to be served by the Servlet engine, rather than a separate static web-server. Without this, the files served by the static web server will not be decorated.
Happy AppEngining.
After a long wait, SiteMesh 2.4 has just been released.
This mostly consists of minor bug fixes and improvements.
Today it was announced that Qt would be made available under the LGPL license. Qt is well known in the Linux community thanks to KDE, but Qt based applications run very well on Windows and OS X, as well as many embedded platforms such as WinCE and S60.
I’m a closet Qt fan, because:
Of course, on each of those points alone there are other frameworks that can beat Qt – it’s the combination of all of these that makes it so compelling.
Oh yeah, Java…
Jambi is the Qt binding layer for Java. It’s actually been very well thought out, allowing you to use pretty much any of the functionality in the C++ layer, with a simple Java API and set of conventions. It also includes bindings allowing Qt and Swing components to seamlessly co-exist in the same UI.
There are parts of the Qt Java API that make me cringe slightly (namely using reflection for event callbacks), but overall the benefits outweigh these – I’ll just have to get over the cringey bits and live with them.
I’ve used Swing and SWT extensively on some big (and small) projects. I’ve only dabbled with Qt, but from that I’ve been productive very quickly and built some solid UIs in little time. The reason why I’ve previously chosen not to use it on ‘real projects’ was due to licensing. Now that it’s LGPL, that changes everything.
If I were to start a new project tomorrow and needed a serious Java UI, Qt would be my first choice.
Ok, that wasn’t really a convincing argument. How about checking out:
Me, Elsewhere
Joe Walnes 