Via channels I can’t now remember, I came across this presentation about the very unsolved issue of how Computer Science as a field of study relates in any way to creating software.
With so many colleges in the area, and having a number of friends that are CS professors, and other IT staff at colleges, it continues to amaze me how disconnected these worlds are. All made the stranger by coming into the field sideways from a physics degree.
Software companies would do well to learn this lesson: anything with the phrase “users love our product” in it isn’t a strategy, it’s wishful thinking. Your users do not “love” your software. Your users are temporarily tolerating your software because it’s the least horrible option they have — for now — to meet some need. Developers have an emotional connection to the project; users don’t.
All software sucks. Users would be a lot happier if they had to use a lot less of it. They may be putting up with yours for now, but assume they will ditch you the moment something 1% better comes along — or the moment you make your product 1% worse.
I gave up Firefox as my main browser when Chrome decided to support WebGL on Linux, and Firefox kept back burnering it. Mozilla is now deprecating Thunderbird, which is the only product of theirs that I still use regularly. Guess that means I’m going to have to get used to GMail’s web interface eventually.
Sad to see something as critical as Mozilla, the beast that cracked the IE hegemony, become an also ran.
I hate data entry. I find entering the same data twice into a computer one of the most soul sucking things I could do. So having both events on our website, and on meetup, meant I needed to automate things.
Meetup events was thus born. The model is simple, your Drupal site is considered the authoritative resource. You select which node types (which have date fields) you want to sync to meetup, and whenever you create or update an event of that type a meetup entry is made (or updated) accordingly. The body content that is synced is tokenized (and I added a few tokens for getting nodereference content). Venues are a little hokey right now, but I just provide a selector for a numeric field either on the main type or on a nodereference which maps to it.
Once you set up the module, including your API key and group url, you pretty much forget it is there. Then you just edit as per normal. Any time you save a type that you are syncing you’ll notice this:
Which includes a link to the meetup event that was just saved.
One of the more recent things I worked on was integration with views so that there is now a Meetup Events: Meetup Link view field for nodes. If you add that to a node listing (and you’ve registered for an oauth key) you’ll get the meetup dynamic RSVP button for your event.
There is plenty of work remaining here, ways this could be nicer, but I’m pretty pleased with the results so far. It’s made me learn a bunch about Drupal’s ctools module, more than I ever wanted to know about the drupal settings system, and how to pull in incompatible versions of jquery in custom tools.
I’ve also been really happy with my experience with the Meetup team. They’ve added multiple API calls for me to make my life easier. Thanks guys. If every developer facing team acted like that, the world would be a much better place.
The meetup platform is turning out to be a really great way for our Astronomy club to draw in new people, and I’ve started using it for MHVLUG now as well. Now that I’ve got meetup_events, I can do that seamlessly without data duplication, or degrading our native experience. If you are interested in doing the same, check out the module. Bugs and patches welcomed.
One of the things that happened once getting to Ubuntu 12.04 was that gnome-do started acting up on me. Given that it’s a very minimally maintained project, I decided it was time to move on. Ubuntu’s dash provides a lot of the same functionality, so I finally started using it. But, I missed a few things.
Gnome-do isn’t just a launcher for programs, it’s an actions engine. It has support for Pidgin buddy lists, an I even wrote an NX launcher for it. I didn’t really want to give either of those up, so I started trying to figure out how to add those to Unity’s launcher itself.
Unity lenses, the plugins that support results, are written in either vala or python. Given that I’m trying to reflex my python muscles now, I decided that was my way in. After a few false starts I found the One Hundred Scopes project, which is an attempt to build a whole set of Unity lenses to add functions and examples for the world.
The wikipedia example is a good starting point. It gives you an idea of how to build a custom search and return results. That enabled me to build a basic launcher that fed up file urls for launching nx sessions, and I created an pushed unity-lens-nx that implements that.
But, pidgin is a little harder. There is no file to open for pidgin, this is about communicating with another program over dbus, and catching the action to do something else with dbus. Fortuntately through the help of David Callé I figured it out. Also, once I had it I found some good tricks (and a couple of undocumented dbus methods) here – https://github.com/gregorl/Unity-Pidgin-Lens which I used as inspiration.
Super + b and search you buddy list. It only displays currently online buddies, and available buddies are preferred over unavailable ones. You can get it via ppa here.
There is plenty more to do. The search results should be smarter, especially taking into account most recently contacted buddies, which means integrating with zeitgeist or something equivalent. Ideas floating around there. I’d like to do some overlays with status icons, just to give a visual clue on either protocol or current status state.
If anyone else wants to help, or has their own ideas, I’d encourage you to join in on the conversation. The One Hundred Scopes community is pretty cool, and I’m happy to make their vision a little closer to reality.
The first week of 2012 was pretty jam packed for me, which is a good thing. One of the many things that made this week busy was my talk, entitled “Getting Involved in Open Source” at MHVLUG.
This presentation was one of the hardest I’ve had to pull together, as well as one of the most fun to give. I had 3 entirely different slidedecks, each with their own narratives, each with their own dry runs, before I found something I felt would keep everyone engaged, not be too abstract, and time in at 1 hour. (The final dry run was 1:03, the live presentation came in at 1:05). That left plenty of time for questions, and still the ability to end the meeting by the advertised 8pm.
The focus on this talk wasn’t building your own open source project, but really about interacting with various communities. I told stories about reporting bugs, fixing small features in projects, getting into flame wars, getting ignored, and becoming the accidental maintainer of projects. The core center of the talk was a tale of 3 projects: 3 drupal modules that I’ve submitted issues and code to, that have gone in completely different directions. This was to make the most important point of the talk:
Open Source, it’s made of people!
When folks get involved in Open Source, they think that it’s all about code. My experience has been that while the code is very important, the people are just as important. Understanding how to interact with a wide range of personality types is one of the most important skills for an open source developer. How do you get conversations rolling? How do you get your ideas listened to? When do you know it’s not going to work, and a new approach is required? When do you just walk away from an idea, because it won’t fit in this community?
With 37 folks in attendance, this was one of the larger MHVLUG meetings. The fact that it was also in our new location, made me really happy with those numbers. A very good way to kick off the new year.
Steve Yegge is one of the most insightful people on the internet. I was really bummed when he stopped blogging, because his posts were always well thought out, funny, and really got to the heart of some key issues in software development.
Last night he posted publicly, by accident, Google’s current biggest issue, a complete lack of a platform. He’s really dead on.
I hope Google internalizes that post and does something about it.
Etherpad was a great idea, online simultaneous editing. After the team was acquired into Google Wave they dumped what they had in open source, and moved on. A few brave souls tried to improve it, but it was a beast, and seems to have died on the vine.
Fortunately a few new brave souls have decided to try to build a conceptual fork from the ashes of etherpad. The new version is written in node.js (all the hipness now), and called etherpad-lite. The install isn’t too bad, and I’ve gotten a couple instances up and running so far.
Etherpad has become a critical tool to me for coordinating distributed teams. We use etherpads as part of remote planning sessions. While it’s not quite the same as a whiteboard, it’s closer than you’d imagine, and the fact that everyone has a cursor makes it easy for anyone to speak up and make changes. The most important part of a plan is that everyone that’s part of it buys into it, and participation is one of the best ways to ensure that happens.