Apparently you can no longer legitimately use Twitter with open source clients, Ars has a lot of details around the implications of the way Twitter just rolled out OAuth.
Twitter’s OAuth implementation and open source clients
Requiring third-party developers to embed a consumer secret key in the source code of their Twitter client applications potentially puts free and open source (FOSS) client software at greater risk of key exposure than closed-source client software. The key would be visible as plain text in the source code, where anybody could find it and use it for their own purposes. Indeed, one can already easily find dozens of OAuth consumer secret keys by using Google’s code search engine.
Twitter felt that allowing FOSS Twitter clients to use OAuth posed an unacceptable risk. The company warned that it would invalidate any OAuth keys that it found published in the source code of FOSS client applications. This was deeply troubling to the developers who maintain such software, including me. I am the developer behind Gwibber, a GPL-licensed microblogging client that is used in Ubuntu and other Linux distributions.
This is a damn shame. I just fixed up my little script that talks to twitter, and I’ll be publishing keys out to github later this week because it’s asinine that they would build an interface which makes it overly burdensome to use open source clients. OAuth has some neat ideas in it, but making it fundamentally Free and Open Source hostile seems like a bad direction to go.
CPOSC is now open for registration. It’s in Harrisburg PA on October 16th (a Saturday), which makes it about a 4 hour drive from here in Poughkeepsie, NY. This will be my first year there, but based on the list of talks they’ve got posted I’m sure it’s going to be great, and not just because I’ll be talking  .
If you are in the mid Atlantic area, and are interested in Linux and Open Source, you should check it out.
There is one main reason people in the open source community get so violent over Mono (the open source .NET implementation): the fear that Microsoft could shut everything. There is long standing fear that MS has patents on core parts of the system. People were afraid their investments in software written on top of it would be at risk. Java was always held up as the much safer choice, with a longer legacy, being more open source friendly, with a company behind it that everyone trusted. Of course, companies change hands some times….
Oracle sues Google for patent, copyright infringement
Oracle filed a complaint in federal court in California, alleging the infringement of seven patents and copyrights by Google’s Android mobile operating system software.
I was once told that Sun actually made money off Java, and one of the big sources of revenue was the J2ME market, which is what all those dumb little snake games are written in. Google has undercut that by making a really popular cell phone platform with a version of Java they wrote themselves.
It’s still not a good world to be in, where innovation comes with a 10% patent tax.
Apparently I’m now writing a drupal drush module for patch management, and slowly understanding what that entails. I’ve looked around and surprisingly there really isn’t a good solution for this yet. There are a number of solutions for applying other people’s patches that are posted somewhere, but what I really care about is being able to easily keep, and reapply the dozen or so patches I’ve made to drupal modules to make mhvlug.org work. Some of these were due to bugs that don’t seem to be getting fixed any time soon. Some are due to lost of drupal modules not working with PHP 5.3.
Regardless of the reason, I’ve apparently found a new itch to scratch, which hopefully isn’t going to take me too long, because I really need to get back to android hacking.
The full agenda for the Central PA Open Source Conference is now out there, and I’m on the agenda:
Sean Dague: Solar System in your Pocket – Developing Android Applications
It started with a simple discussion after a local astronomy meeting trying to figure out which moons of Saturn we were looking at. This seemed like the perfect first Android application, building an astronomy simulator that would let me answer that question wherever I was. Little did I know that trying to do this would take me on a Journey through most of the major subsystems and interfaces in the Android SDK.
This talk will take you along on that journey of writing your first Android application. It will touch most of the major concepts involved in mobile development for Android, and many of the interfaces you’ll need to write you first application. Most importantly it will give you a list of things *not* to do when developing for the mobile space.
Sean Dague has been an open source software engineer in the IBM Linux Technology Center for the last 10 years. His spare time is split between the outdoors, amateur astronomy, and random bits of open source hacking.
I’ve been looking through all the talks listed, and I’m quite impressed. I want to attend at least 2/3 of them, which is going to be a problem unless I can clone myself, as it’s a 3 track conference. From an interest density level this looks like it’s going to be a really great conference, so I’m very excited to be going down for it.
This will also add some impetus to getting the 2.0 of Where is Io out there, which I’ve been hung up on building a custom view. Once I get that one custom view finished, I should be back cranking out more regular releases.
I’ve been using Drupal for a number of community websites for the past year. Overall I quite like the system and how customizable it is.
What I’m not really thrilled by is the way the module structure exists on drupal.org. The problem is that drupal core is a very small number of modules. The bulk of useful functionality comes from user contributed modules. So far so good, many projects run the same way.
The real issue is that the drupal project maintains a centralized CVS infrastructure for module developers. There is a pretty formal process to get accepted as a module author, and no real way to get CVS access to just fix bugs. The net result is that after finding 3 bugs in the date and callendaring modules, creating patches for each on my own environment, and submitting them upstream, only 1 has gotten looked at. The fixes were submitted about 8 months ago, and I’ve pinged a few times. I also wrote the author directly on one of the modules.
The root cause of this issue is that drupal has centralized infrastructure, but decentralized decision making. It is a classic community wherein github would be a good solution.
I’ve been an absentee maintainer before, I know that sometimes interests change, and you move on to other things. But at least with something like github, other folks can very easily extend what you’ve got and make the fixes themselves. Hunting out RCS style patches in drupal discussion forums is just really problematic. At this point I’ve got quite a number of local fixes, so module upgrade and maintenance is tricky. The only saving grace is that most of those fixes are on modules that are effectively abandoned so I shouldn’t have to worry about an update coming down the pipe.
The Drupal community is soldiering on even with bad developer infrastructure. I just wonder how much further along they’d be with better developer infrastructure.
The heartfelt tune it plays is CC licensed, and you can get it from my seed on JoinDiaspora.net whenever that project gets going.
Randal, you are awesome, as always.
Last Wednesday, at the kind invitation of the folks from Eclipse, I had the opportunity to sit with more august company – Justin Erenkrantz (Apache), Mårten Mickos (Eucalyptus), and Jason van Zyl (Maven/Sonatype) – on a panel charged with debating the future of open source. Among the questions posed to us was this: is the future of open source going to be based on communities such as Apache and Eclipse or will it be based on companies that sell open source?
My reply? Neither. It’s Github.
Stephen O’Grady does a great job of articulating why github is fundamentally changing the nature of open source development. It meshes well with my own thoughts on the matter.
It’s been 2 years since I got my Proliphix thermostat, and while I did some early hacking on it, largely the whole effort just sat around for the last 2 years. However, with the fun of connecting up my weather sensors, I went back in this weekend and beat the code into a much more sane interface.
Thermostat.rb 1.1.1 was released yesterday. It provides a concise interface to the Proliphix web services API. An example of the usage is something like:
thermostat = Thermostat. new("hostname", "admin", "password")
# get the current temperature
current_temp = thermostat.temp
# get the current setback heat value
current_target_temp = thermostat.heat_to
# set the thermostat to 69F (units are set in the thermostat)
thermostat.heat_to = 69
I’ve got support under the covers for everything in the Proliphix API. I’ve only mapped about 1/2 of it to the user visible interface, starting with all the functions I’ve tended to need or use. I was a good little agile developer and built unit tests for everything here. Using the new module, I added the thermostat to my homegraph code, with some pretty reasonable results:
All this is released under the MIT license.
Over the weekend I was working on revamping a whole set of older ruby projects, some having to do with my Proliphix Thermostat. I had this crufty Rakefile from the icalendar project that I’d been copying and modifying for new projects, and it was slowly degrading. I thought that there had to be a better way. There is, it’s called newgem.
Newgem is like h2xs in the Perl world, something to stub out a new module with all the right files and structures. But, as the Ruby folks tend to do, it ups the ante in the process. In addition to the basic build, packaging, testing, and coverage results you’d expect, you also get a targets for: creating you rubyforge website, publishing your gems to rubyforge and gemcutter, posting release announcements on rubyforge, and even posting blog posts about your release (though I haven’t configured that one yet).
The release cycle is now:
rake release
rake website
rake post_news
The Rakefile created is loading these features from base modules, so it’s only ~ 30 lines, a heck of a lot easier to maintain than the 300 line Rakefiles I had which provided about 1/2 these features inline.
If you are doing Ruby development, you should really check out newgem.
|
|
