Porkchop sent me a link to this comic and I loved it, especially after having a “sensors” conversation about a year ago. Click on the image to get to the site.
Internet Relay Chat (IRC) has been around for just about ever. In the 90s it was used for chat rooms and warez sites mostly. For the past decade it’s become one of the key pillars of communication for the Open Source Community. It has the advantage that the client and server are free and open, and there is an inherent redundancy system built in.
One of the challenges of IRC, over say email, is that you need to be online to see the discussion. On a really global project this is a problem, because of the pesky fact that daytime is determined by facing the Sun, and living on an orb, only 1/2 the earth gets to do that at a time. Life would be so much simpler if the flat earthers were actually right. But there is a way to stay connected, even when you are not, which is using an IRC proxy.
Using an IRC Proxy
The get started you will need a Linux machine, that you can run code on, that is always on. It doesn’t need to be on your network, but you need shell access. If you are a Linux geek level 4 or higher, this is probably not an issue. You probably either have a Linode or a home server that’s always on. If not… well sorry… your journey ends here. There is not, as of yet, a cloud service to provide this for you. Please come back once you level up.
The next step is the actual IRC proxy. IRC is a simple enough protocol, which goes over clear text, that many people have written a man in the middle server for it. You connect the proxy to the IRC server as you, then you point your IRC client at the proxy. When you are connected to the proxy, everything works as normal. Your messages are sent back and forth in real time. When you disconnect from the proxy, the proxy keeps you logged into irc and logs everything that goes on. The moment you reconnect to the proxy all those messages are replayed to your client. You now have a full offline ability.
My favorite IRC Proxy
There are many out there. A few years back I spent some time trying to get one that I didn’t hate, and I landed on miau. I’ve even packaged it for ubuntu, so if you are on that platform, it should be easy to install. Once installed, read the same miaurc on configuration, it’s really well documented, and should be easy enough to get rolling.
Although miau supports a password to connect to it, I don’t really trust running another service connected to the internet that just has a password in clear text. My solution here is to have miau only listen to localhost (127.0.0.1), and ssh proxy to the machine. Pick a port (like 4098) on your local machine and have that forwarded whenever you connect to that server. In linux this would look like the following in you .ssh/config.
LocalForward 4098 localhost:4098
The have your IRC client (like XChat) connect to localhost:4098. This will mean that you will only be connect to IRC when you have an ssh link to your proxy server. It works quite well, and is about as secure as you’ll get.
If you made it this far, you probably already know why. When development conversations happen at 4am your time on IRC, you are probably never going to participate directly. But, having access to the conversation when you connect in the morning is a very good thing, and I’ve walked people through this setup enough times in the past, writing it down for posterity seemed like a good thing.
The book is an episode by episode look at Star Trek The Next Generation, wherein Wil provides a 6 – 8 page synopsis of the episode in the way that the Mystery Science 3000 folks would do one. It’s incredibly funny, and has lines like “well as long as we’re not advancing the plot, why don’t we do a pod race?”. For anyone that watched ST:TNG growing up, this book is a really amusing look back, especially on all the uneveness of the first season. Each episode also then has Wil’s favorite quote from it, the obligatory technobabble, and his personal memories of shooting the episode.
Vol 1 covers up through Datalore (the first 1/2 of season 1), and is constantly making comments about the disaster which is Angel One. I can’t wait for Vol 2 which is going to start us there take us to the end of season 1.
Wil is really an incredible writer, and his great sense of humor comes through in this book in spades. After reading Just a Geek in the spring, I was happy to pick this book up. Honestly, I found it hard to put down. It’s just too damn funny. If you had any opinion at all on ST:TNG (loved or hated), do yourself a favor and get this book. You will not be disappointed.
After our android hack-a-thon, Frank put a page in the MHVLUG wiki to start to stub out Android information that we’re all finding useful. It’s small, and largely a stub, but it’s a start. When I went back to shift a couple things around, I started to really wish this whole things was Drupal instead.
Drupal gets a lot of hate in the tech world, so I’m sure that I’ll get complaints or at least scoffs. I’ll get into why I wish this was drupal in a bit, but first, some theories on why people hate drupal.
It’s popular. There are over a million drupal sites out there, and you’d loose your tech street cred if you didn’t scoff at that which is popular. I suspect that our high school experiences dealing with being unpopular probably shape that point of view.
It’s a big php application. PHP has a low barrier of entry. This is a double edge sword, because your average php developer is probably less skilled than your average developer in another language (Visual Basic has this even worse, as some time with the daily wtf will show.) Being both php and big means that drupal security issues come up relatively regularly. Like with wordpress, you need to keep on top of updates. A 2 year old drupal install, like a 2 year old wordpress install, is basically a rusty door waiting to fall off.
People learn one tool, then try to make the world out of it. I’ll brush off the first 2 complaints, as I think they are both addressable. When talking to O’Connor recently, I found a much more reasonable complaint, which he was in the middle of. Drupal is a content management system, and if you use it for semi structured content storage and display (i.e. a ghetto database), it’s great. But because it has a module structure, a lot of people turn Drupal into a web application development framework…. which it really is not. If you want that, check out rails, django, cake-php or something that actually gives you that level of control. This is a standard issue – if you have a hammer, everything looks like nails.
If I was doing mhvlug.org over from scratch, it would be with Drupal.
What I’ve found over the last almost 7 years with MHVLUG is that being a wiki was better than being a static website, but that the number of edittors for the site is still in the single digits. We’re a group of 150 people on the mailing list, 20 – 30 at a monthly meeting, 10 – 12 at our monthly lunch. It’s a solid community, but it’s one with a pretty well defined reach, that’s been more or less constant now for at least the last 4 years. People are fading in at basically exactly the same rate as people are moving away or fading out.
The bulk of what gets updated is information around the meetings. If that was stored in a semi-structured way, it would be a whole lot easier to update in one place, and have it viewed different ways in different places. If I didn’t have a project list queued out the door, around the block, down the hill, and… well you get the point, I’d seriously think about this one.
I’m pretty happy with how things are coming together in exactly this way when it comes to the farm website build on drupal. Now that I understand what the right “types” structure is for the farm, the rest of it is just falling into place.
So for people looking to put up a website for a community in this day and age, I’d highly suggest that drupal is a good place to start. Yes, you’ll catch grief from your other tech friends, but such is life. Long term, I think it’s a pretty good call.
Update: I ended up redoing the MHVLUG website as a drupal site, with an extensive writeup on how.
Last night we did the first, of what I hope will be many, MHV Android Hack-a-thons. The basic idea was to get folks together that are interested in doing android mobile development, and having others around they could bounce questions off of. We did it at Panera because they have food and wireless, though future sessions probably have to move elsewhere, like Barnes & Noble, because the 9pm closing time came a bit too early.
Turnout was promissing. Frank, Kershaw, and Muller all showed with their android phones and laptops, plus we got 3 other folks that just wanted to see what an android phone looks like. Frank and Kershaw both had the Droid, Muller has a google issued G1, and I’ve got my Hero. It was definitely interesting to see the differences across all of them, and supports my theory that there isn’t a straight road when it comes to android base platforms. The Droid did some things the Hero didn’t, the Hero did some things the Droid didn’t. A big reason for these differences is how modular Android is. You legitimately can replace any part of the core interface with your own code. HTC Sense, for instance, is a Home replacement. You can write your own. HTC also replaced the default mail, sms, contacts, and a few other things. Some for good (mail, contacts), some for worse (messaging power bug). But as a user you are empowered to replace the SMS system with a 3rd party app, which I did.
The evening started off with “oh, have you seen this yet?” which got a lot of knowledge cross shared. Frank’s starting a wiki page to try to keep track of that. I got out my laptop early and started working through the Sudoku example application in Hello Android. It’s a pretty good example that includes many of the widget systems as well as the 2D graphics API. I’m pretty impressed with the book so far. Frank and Kershaw spent some time getting the SDK installed and poking it, and Muller was focused on the Android Scripting Environment to do some python on the phone.
All of use except Muller are still a bit in the “ooo shiney” stage, as I’ve had my phone for a whole month now, and Frank and Kershaw have had theirs for less than a week. I suspect that future hack-a-thons will actually start generating a bit more code. I continue to be impressed by the API model for Android, and really look forward to working on applications on it. Yes, Java is not as nice and terse as Ruby, but at least I won’t have to write widget packing code. And that makes me a happy camper.
I was listening to Fresh Air last night on the author of new book on google. It started with a nice lay person description of a lot of what Google has been working on, and how the company evolved into the worlds biggest advertising firm. When the laundry list of Google properties got to Google News, the interviewy made the following statement:
On the other hand, there is evidence that it can be done, and
Apple’s iTunes is a classic piece of evidence in this regard. I mean,
the idea that music – I mean, just think about five years ago, the
music companies were suing their customers on college campuses for what
they called illegally downloading their music. And it was illegal, by
the way. You know, they were breaking the law to do that, but it was so
commonplace that no one thought it was against the law to do it.
Apple comes along and they said we’ll charge you only $.99 and you can
pick the music you want. You could listen to a little segment of it
before you buy it, and you could buy individual songs. You don’t have
to get stuck with buying an entire CD for X many more dollars. And it
took off like gangbusters, and it’s been a great success for Apple and
something the customers who were used to free music have accepted. So
there are some models that suggest it can be done, but it won’t be
When looking for a general purpose solution to the fall off of newspapers, there are 3 models that are always put out there which “prove” that paywalls will work: The Wall Street Journal, NPR, and iTunes. And they are all wrong, and present an over simplification. The issue is, none of these things apply generally to the local newspaper model. Clay Shirky does a better job of explaining why than I, but I will take a stab at the iTunes front.
When you buy (if you buy) music, you are buying a durable good. It’s something that in 2 years, you’ll still probably be listening to, and yes, in this disposable age, that’s considered durable :). It’s something you listen to dozens if not hundreds of times. For this pattern, $0.99 seems like a fair trade off. But even for that low low price, studies show that the people that buy the most music, as the ones that download the most first. You can charge for music because it’s not ephemeral. News paper articles aren’t like this. When was the last time you reread a news article from your local paper 10 times.
I heard a great statement recently when listening to The Media Project, which looked at the Titanic. This issue with the Titanic wasn’t that it was too big, or going too fast, or not enough life boats. The issue was that 15 years prior the wright brothers invented the airplane. Even if the Titanic hadn’t sunk, the company would have gone out of business in a decade anyway, because they were in the wrong line of business.
What this means for local news is sort of scary, but as Clay Shirky is found of saying: “A revolution doesn’t go from point A to B… it goes from point A to chaos, then after a long time someone figures out what B is.”