benad

FYI, the RSS Podcast feed: http://www.ipadio.com/phlog_rss.asp?phlogid=8325

As a little break from the series "A Programmer's Journey" (and because I can't push myself to do an audio recording), let me write about my backup plan for my computers. Actually, I was reminded to figure out such a plan for myself before considering upgrading to Mac OS X 10.6 "Snow Leopard" (which I did last weekend).

To figure out what should be your backup plan, you need to ask yourself a few questions. First, what files are really important, classified from "I can re-download" to "critical". Second, how often do you change the files you consider important. A few times a week? Several times per day? Third, security. Should you encrypt everything? Or just what you upload on the Internet?

Based on the answers to those questions, you should start getting an idea of the "value" of what you need to back up. From there, you have a few options that I would recommend even for non-technical users.

First, the local backup. This is some local USB hard drive that you use to make weekly full backups. This is mostly just in case your computer breaks, as this can simplify re-installing your entire computer, or to migrate your files to a new computer. Also, this is a "fail safe" in case that you forgot to add some important files to your more frequent backup mechanism. The question of if you need to encrypt your USB hard drive backup depends on if you expect your hard drive to be stolen (well, that depends on your neighborhood).

Second, an online backup. Because doing a backup online is much slower and expensive than a local hard drive, I suggest that you back up online only your "important" and "critical" files. I suggest to back up online no more than 200MiB. Selecting such files will help you ask yourself the question of what is important on your computer. The standard I use for this is: "What do I want to still have if the house burns down." Of course, you should encrypt everything you back up online, which is a given for most online backup services.

Third, only if you are a bit paranoid about your "critical" files, a backup on you, for example a small USB key that you will add to your keychain. For girls, when I say "on you", I don't mean the purse, I mean you get robbed and you still have it. This is for the "critical" files, the ones you would keep encrypted on you with important passwords and accounts. As such it's pretty small.

So, what tools I recommend? On the Mac, Time Machine is sufficient for full backups. For online backups and full backups on Windows, I highly recommend CrashPlan. It backs up compressed and encrypted, and for online it supports doing a backup securely to a friend's computer for free. For online backups you can also use the free Mozy service. For USB backups, I recommend you to simply copy the files to a USB key encrypted with TrueCrypt.

Let's see if this works... If all works well, this will post something to twitter through ping.fm through twitterfeed within roughly 30 minutes. More details to come soon.

Later... Well, that worked. It also posted into delicious.com here, though since twitterfeed already shortened the link to bit.ly I'll have to edit these after the posting. The big advantage of using ping.fm is that it's going to be much easier for me to post quick links to twitter and manage them later on delicious or wherever.

Before we start looking into my experiences with Java, I learned three important things about learning Perl. That is, there are three different ways you can learn Perl. There's the good, the bad, and the ugly. Let me describe them.

The bad way is to learn from examples, especially examples from the so-called "Camel Book", because most of those examples are pretty much to show off as many features [in] as little amount of lines in the book as possible. Because of that they're pretty much unreadable. There's another book called "Learning Perl". It's much better but most people prefer copy-pasting features from sample code. So what ends up happening is that people with little to no previous experience with programming (or "serious" programming), they would just pick up that book and see how much copy-pasting they can do from the examples until their code does what they want it to do. It's really bad because Perl has a ton, and I mean, really, a ton of hidden features, functionality, weird ways of doing stuff that don't make sense. And if you're just copy-pasting code then you have no idea what it's actually doing except, well, input and output (what it does as a result), and WHY it's doing that you have no idea. And if you have limited programming experience then you'll end up producing code that even you yourself don't know why it's working in the first place. Not because of abstraction, just because you have NO CLUE how to properly write software and at the same time you're using a language that's so complex that beyond the examples you have no idea what it actually does.

So the ugly way of learning Perl is from code examples from people that learned it the bad way. That way it's really bad because you end up not knowing anything about Perl, like me, and taking other people's code, like me, and that code is buggy and your job is to fix it. First of, the programming behind it made an actual bug, and the second this is that the code they were using, they have no idea what it's doing in the first place. So even the original software developer would have no clue about why the bug's happening, and when you're reading the code you don't know if the code is [...], if there's any sense to it. Like, is that line of code there supposed to be doing what it's supposed to do in the programmer's head, or the programmer meant something else, or the code examples he based himself on meant something else altogether. For me this was a really, really harsh experience learning Perl because [I was] learning from examples of other people.

What really saved me was not the "camel book" but really the Perl reference, the "man pages" or the "perldoc" they would call it. That's a big deal because the Perl reference is, well, it's really difficult to read, it's a reference book, and the examples are even more complex, but it covers everything. I mean, litterally, everything. So you're not reading the "camel book" or [the] "Learning Perl" book and you're kind of trusting the author or what the author is saying. No, you actually have what it's supposed to do and all the intricacies of the weird stuff it's not supposed to do and what if that argument is missing or not or if it's undefined, etc. It's really, really, really hard to read, but then when you're trying to figure out somebody else's code and that somebody else didn't understand it in the first place, that kind of saves you because it makes you say: "Hey! Maybe I could just rewrite the damn code in the first place, while keeping compatibility." So that's pretty much what I did. That's pretty much a good habit that I have. Almost all the time that I've seen other people's Perl code, it looked too much like people that don't know what they're doing, so I just end up rewriting the entire code. Of course, if I'm lucky I get Perl code from other developers that is almost pristine. Mine's not as pristine as theirs, but there's a tendency that good Perl developers are very clean in their syntax. There are lots of freedom, lots of optional stuff you can do with the syntax, but you restrict yourself to something that almost looks like C. You don't do Object Oriented Design in Perl, you don't do anything too advanced like function polymorphism, you keep it really, really, really simple. Why? Because the syntax is almost ambiguous.

So the good way of learning Perl is, well, the Perl reference manual. That's what I went through. But also using the Perl debugger. The Perl debugger is command-line based, [and] it's just like my experience in C, it's a life saver. Especially since Perl is a scripting language, so you can interpret Perl code from within the debugger. And you can see nested structures. Sometimes when you're stuck with hash references, scalar references and stuff like that, it really starts making sense.

My overall opinion of Perl, well, I'm a bit biased [since] because of work, It's been pretty much the programming language I use the most. It's a language that's been pretty much "engineered", you know, with features that's been added over time, because it makes sense, because it was useful, not because of some overall design elegance or completeness or [provability] or anything. It's just because "We need that feature, let's cram it in." Perl was inspired by **awk, which was inspired by the regular expression command in **ed. It was just a gradual evolution. So if you followed Perl from its inception phase up to now then everything kind of makes sense and you're used to it. For any new software developer out there, I would tell them: Stay away from Perl. Because the first programming language you should learn is a programming language for which you actually understand what the heck you're doing. And Perl is really not that. Perl is really a language for when you've been programming for 10, 15 years, and you're kind of fed up and you want to do a one-liner on the command-line that does nested hash structures. But otherwise, just stay clear of it until you're mature enough to accept a programming language that has many, many design flaws.

Will transcribe soon on Benad's Blog.
Posted via email from Benoit's posterous

Note: this is just a test post. You can ignore it.

Will transcribe soon on Benad's Blog.
Posted via email from Benoit's posterous

Last week I picked up the PDF version of Sun's free JavaEE 5 tutorial. I saw that it was one thousand pages long, so since then I've been procrastinating about reading it. And I'm writing a blog post about my procrastination.

Not just because it's long (well, for a "tutorial", no one expects 1000 pages), but because I'm not sure I need to. On one hand, apart from hype and pretty bad arguments, it could be tangentially useful for my work. On the other hand, saying you have JavaEE experience at work could, well, exponentially increase your responsibilities without much pay difference.

I know a bit of JavaEE, and that's it. But most of what it offers I already used in other forms. Persistence API? Hibernate. Remote objects and clustering? Spring and Terracotta. JSP? GSP (Groovy Server Pages). Web Services? A servlet that returns a JSON object.

But then, none of my solutions "scale", that is other devs can understand what I'm doing, or be free to run my code on different implementations of the library APIs I use, or have any kind of large-scale commercial support. It's all fine to run some GSPs in Jetty running from a self-expanding JAR file, but then when "the customer" has to run it on their own on hundreds of machines, well, no it's not fine.

Look, I hate code generation. And creating layers of "data access objects" through remote "Enterprise Java Beans" is not fun. But I don't know of anything else that scales as well while being properly supported. You can brag about running a Hadoop cluster on a fiber channel network, but in the "enterprise" world the question is if some poor dev in India can tweak your code five years after you moved on to another job.

So they say that with annotations JavaEE 5 is now easier to use. I'll see. I guess I just convinced myself while writing this post.

For C++, it wasn't a good experience. At the beginning when I learned it I honestly didn't get at first what object-oriented design was. I ended up learning the syntax, the language, but for me it really felt like a kind of hack. The entire language did not represent something in the runtime environment [for features on top of C], that is the compiled code, so it was just a syntax difference, adding some extra language features in the syntax, nothing more. It wasn't exactly true, but still, a lot of things frustrated me when I learned C++.

The standard C++ library, I hated it compared to the C standard library, especially since it was overloading operators, something that disgusted me. Having been used to use the left shift and right shift bit operators seeing that do input and output boggled my mind. Things like the "virtual" keyword, which I would assume would be the normal behavior of overloading a function in derived classes, has to be explicitly written pretty much all the time. And it's a weird word: "virtual"? There's nothing virtual about it... It's function overloading! Templates, again that disgusted me even more, especially since when debugging the code that could lead to massive errors in your bugs and it's difficult to see which version of the compiled "templated" class you're using (because for every different type in the template it would compile a different version of the class). It's really weird. And that, coming from the perspective of someone that already had its own small library of C memory structures (like trees and lists) using opaque pointers, having to use templates I didn't see much the significance of that, except maybe a little bit of performance increase in some operations.

Eventually I bought the Inside Macintosh CD, the documentation of the Macintosh toolkit. What happened is that I tried to further develop my card game, to produce a user interface for that, and I said: "Hey! I could use Object-Oriented Design for that!" I ended up doing so many hacks with the user interface of the Macintosh that it barely worked, and I kind of abandoned it.

In my first workplace, where they heavily used C++, well, kind of, they were using a kind of Aspect-Oriented Programming approach, which I didn't knew what it was back then (and maybe didn't exist as a term back then [correct; the term "aspect" came from AspectJ in 2001]). But they were doing that using preprocessor macros, that is they were using preprocessor macros to generate code. It was, that and combined with bugs in the Visual C++ compiler from Microsoft back then, and the fact that the standard C++ library was a moving target, because it wasn't still finalized, it was a horrible, horrible environment. Since then I pretty much hated C++, especially since the next step was to learn Java, which is closer to a pure (not entirely) object-oriented programming language.

Before going to college I still wasn't sure what to do as a living, so I convinced my parents and used my allowance to buy Metrowerks CodeWarrior for Macintosh, Educational Edition. It came with a C compiler, as I was trying to push myself to learn C on my own, and if I liked it then maybe make a living out of programming. What was surprising was that I was expecting as a second step to buy a book for learning C, but the documentation CD came with a PDF book, for free, called "Learn C on the Macintosh" by Dave Mark on Addison-Wesley Publishing. While it wasn't necessarily a great book and not necessarily programming of the Macintosh per se, it was a good introduction to the language. I used that to learn C on my own. The book was big enough so that I could start, for exercise, coding my own C library for data structures, and eventually I wanted to write some small "card-playing" game.

The best way for me to learn was really to use the C debugger (the CodeWarrior C debugger), because it lets me catch the bugs and null pointer exceptions before they actually crash the machine. That's because back then on the Macintosh, if you had a null pointer or anything that's "bad memory" it would crash the entire machine. And since the compiler was running from the CD-ROM drive, rebooting the machine and running the compiler again and running the program again would typically take about 5 minutes. So that's a very good way of learning how to not have null pointers in your code.

From there I was ready to embark on learning C++ with an additional free book as a PDF on the documentation CD.

Here it is: benad.me.

Well, it's a start. Next step is to add more content about the "making of" the site, and a few other things like an RSS feed, an easy way to force access the static HTML pages, and some kind of GPG signature of the source XML pages.

I'll resume posting the series "A Programmer's Journey" soon.

  
Download now or listen on posterous

APJ 3 - C++.m4a (2256 KB)

Will transcribe soon on Benad's Blog.
Posted via email from Benoit's posterous

  
Download now or listen on posterous

APJ 2 - C.m4a (1480 KB)

Will transcribe soon on Benad's Blog.
Posted via email from Benoit's posterous

My first programming experiences were with HyperTalk, the scripting language of HyperCard. If you're not familiar with HyperCard, it was a program made for the Macintosh in the end of the 80's that was a kind of precursor Macromedia Flash, HTML and FileMaker, all in one easy-to-program format. The HyperTalk scripts could be attached to buttons or any other elements of an HyperCard "stack". "Scoping" for shared functions could be done by attaching the scripts to a particular "background" of a series of "cards", or to the whole "stack" itself. A kind of object-oriented design could be done by placing values in hidden text fields.

A special note should be given to the language itself. It was a bit similar to Pascal, the programming language of choice for the Macintosh, and made a strange distinction between functions and procedures. But more importantly, it's syntax was so simple, even compared to Basic, that for most non-programmers it looked like a simple form of English.

I mainly used HyperCard and HyperTalk for some highly interactive teaching tools for Chemistry and French grammar, at a time when "multimedia" was all the buzz.

My second programming language (more a scripting language too) was AppleScript. To explain what is AppleScript, let me put it in context. For the Macintosh System 7, Apple introduced a new technology called Apple events. In the typical application GUI event loop, Apple events are special events that can be sent between processes, making it possible for the first time on the Macintosh to have some kind of inter-process communication. Those Apple events can describe function calls, with arguments and some basic types and data structures (strings, lists, etc.), and also get and set operations of object attributes identified by ID and type. By generating Apple events to yourself for every GUI events, it became possible for another application to record and replay GUI actions.

An application could additionally provide a dictionary that provides a name and textual description of externally available Apple events functions and objects, making it possible to present them in a scripting language of some kind. Of course, that language is AppleScript.

AppleScript was heavily influenced in style by HyperTalk, though it has more functionality. Since it internally compiles the script into some bytecode format, it had the unique ability to present itself not only in its original scripting form, but also in different human languages (French, Spanish, German, etc.) Now that feature doesn't exist anymore and only the English form remains, but at the time it was quite fun for me to use a programming language in French, my mother tongue.

At the time I used it mostly to automate complex file system operations and to scripts operations in a web browser, a feature I haven't found an equivalent for until I discovered Selenium IDE for Firefox.

Today, with its tight integration with Objective C, AppleScript is still in use in Mac OS X.

I'll skip the audio post for now, as it won't record well in the metro...

A few weeks ago, I read a post made by Kragen Sitaker on his mailing list about his journey as a programmer. Well, his experience and lessons about them were unoriginal at best (I'll write more about this later). In comparison, mine's quite unique, and might even explain a bit why I tend to focus on programming from a software designer's perspective.

So, for the following few posts, I'll present "A Programmer's Journey", starting from my beginnings on the Macintosh to the present.

So, what is this? About two, three weeks ago the Intetnet radio host Leo Laporte started preparations to go to a trip to China. What he did is try some iPhone software called AudioBoo, which is basically an application for the iPhone where you record your voice, attach a photo, a title and/or your GPS location and it automatically gets uploaded to their web site. So it's kind of like an audio blog posting tool for dummies, meaning that there's is no set up (by default it's an anonymous account). What's interesting though is that you don't need to sit down and type on a computer or the iPhone to be able to send another post, which is closer to some kind of audio-based Twitter, meaning that the posts are short compared to big blogging articles and you can basically download all the audio posts from a lot of people you subscribe to, and listen to them on your iPod, your iPhone, an MP3 player in your car or wherever. So it's pretty practical.

When I listened to that I realized that this was a potential solution to my blog post procrastination problem (sitting down in front of a computer and typing it up, and not only that but also spell-checking, putting all the links in there...). It's a good excuse to just "speak it out", mainly because it's instant.

Eventually what I should do once the audio is "up", later on, is write down below the post an actual transcription of the audio data, plus with the links that (of course) with my voice I can't say, and removing all the "uh" sounds, pauses like that, mistakes, whatever. But if you don't want to wait for the text version then you can right away listen to the audio version, and subscribe to it as some kind of podcast. So this becomes a kind of podcast of my own, or a really cheap version of it.

I didn't want to use the AudioBoo software because it's instant. The moment you press send it's sent and that's it. There's no editing, no "offline" mode (so it has to be done on 3G or WiFi). There's not a lot of other options. Now the iPhone software has some audio recorder software built-in that let's you send the audio by email. There's only a very few services that let's you host audio messages by email. There's drop.io, that I talked about in an earlier post, that for every drop has an email address to where you can send the audio file as an attachment. That would work, and it even has an RSS feed for podcasting and 100MB account storage. The downside is that the audio file stays in your drop. I'm saying that because there's another service called Posterous, which not only lets you make a blog post by email (you don't need to create an account: you just post to their email address "post@posterous.com" and you'll now have a blog), but also they do the hosting for you for up to around 1GB, audio posts become a kind of podcast, and it's kind of the opposite of tumblr. Whereas tumblr aggregates information from other web sites about you, posterous "autoposts" your posts, attachment, text, whatever to all your other social services, including Twitter, Facebook, Livejournal (which is what I'm using). That was pretty much the "instant posting" I was looking for. Because one way or another I'll have to do the transcription, so if the service doesn't let me post instantly from my phone (when I'm online) to my blog and on top of that to twitter (which has a link to my posterous account which eventually gets forwarded to my Livejournal account), what's the point? You'd get all of that instantly with posterous, as soon as you want to listen to it (or within a minute or two). So it has the instant posting effect of AudioBoo but without having to install any software of any kind: you just send the attachment by email, which is one of the features of the built-in audio recorder of the iPhone. Which by the way has multiple options to name your recording, including "Podcast", so I guess they predicted that.

It's easy to set up. You still need to set up an account on posterous, to be able to put your account information for your other blogging sites and Twitter and Facebook, but once that's done it's all automatic. And there's still a lot of options on how you can post. The one thing I don't like about posterous is the lack of encryption or SSL. It's based on email, and email is not that secure. They say they have a way of detecting when someone is faking a post. Authentication is based on the sender and some properties of what is now used to detect spam. One way of another what I'm posting is open to the public, so in a way I don't care that much about encryption. But it's something I'll have to think about because I really insist on using encrypted connections to email services (for example MobileMe), yet the contents is still not encrypted... I don't know of any service that supports decrypting the email contents, so I'm pretty much stuck with that for now.

I'll have to figure out what I'll have to do in the future about transcription. I could use Dragon NaturallySpeaking (which I get for free for work, because I work at Nuance), but for now I'll just type it up. If I play the audio file in QuickTime or the iPhone there are options to play at half speed the audio file without changing the pitch, which is what I'm going to use to listen and transcribe fast enough. I'll see if that's OK. Or maybe I'll just want to change the pitch, because, damn, my voice is really high-pitched... That, and if there's any kind of software on the iPhone that let's you edit the audio file. I don't even think that's even possible... If there's any crazy noise or something interrupting me I could just pause the recording, but not remove the noise. So it's very "live" and "raw". You know, what you would expect from an instant-audio-live-blogging-thing... See, that's the kind of stuff I can edit easily when I transcribe later on, that is not knowing what word to say... And of course I wouldn't g get that at all with automatic transcription (with Dragon). For now I'll manually transcribe it myself. I suspect it's still going to take more time than actually sitting down in front of a computer and doing a text post in the first place, but then it's one less excuse for procrastination.

So that's it for now. Hopefully, I should be able to come up with audio posts faster than I can transcribe them, and faster than the procrastination I've done for the past 6 months.

Post recording notes:

Well, I just noticed that the recording app doesn't let you send by email an audio note longer than 8 minutes. Weird. Weirder is the fact that I didn't noticed that I recorded 9 minutes in one shot. Well, at least the application lets me send a section of a note without changing the original recording, hence the "part x of y" thing you see in the post titles. I still missed the last minute or so for the second part...

Oh, and it's "posterous", not "posterious".

Also, I'll need to find a way to have some notes displayed on screen while I record. Right now, it's all memory-based, so surely I forgot to say some things.

Finally, the audio is not great, but acceptable. The headphone microphone picks up too much noise, and there are not many places downtown that are quiet.

  
Download now or listen on posterous

First Audio Post.m4a (1192 KB)

Will transcribe soon on Benad's Blog.
Posted via email from Benoit's posterous

  
Download now or listen on posterous

First Audio Post.m4a (3597 KB)

Will transcribe soon on Benad's Blog.
Posted via email from Benoit's posterous

  
Download now or listen on posterous

Memo.m4a (33 KB)

Background: I'm using http://posterous.com/ to post an audio message through email.