Computers

Good source management

/ hsoi / 2 Comments

Troy Hunt writes on The 10 commandments of good source control management. They are:

  1. Stop right now if you’re using VSS – just stop it!
  2. If it’s not in source control, it doesn’t exist
  3. Commit early, commit often and don’t spare the horses
  4. Always inspect your changes before committing
  5. Remember the axe-murderer when writing commit messages
  6. You must commit your own changes – you can’t delegate it
  7. Versioning your database isn’t optional
  8. Compilation output does not belong in source control
  9. Nobody else cares about your personal user settings
  10. Dependencies need a home too

Read Troy’s article for all the details. I’d like to elaborate on a few.

VSS – stop using it. Totally. “Back in the day” I worked at Metrowerks and they made the Mac version of Visual SourceSafe… or as it was jokingly called, SourceSuck. There were a lot of cool things about it, and sometimes I still think the ability to lock can be useful. But the main repository was constantly down, constantly being rebuilt. It was terrible. Thankfully tools have progressed since then. Subversion is great. I haven’t had the opportunity to try git yet, but that it’s maturing is a good sign.

Commit early and often. Very true. It always gives you a rollback point. A lot of people are afraid of this for whatever reason, especially fearing the merge. Understandable, but it’s just part of life and certainly using version control will help ease the pain — if you use it right. So put your work into a branch, every so often merge in changes from the trunk to keep you building and current, but still doing your thing. When it’s time for you to go back into the trunk, the merge won’t be so painful. If you must reconcile, you must. It happens, but it’s not the end of the world. Maintain that history, give yourself the protection that version control is for.

Going with this, #10. Over time I’ve changed how I lay out my Subversion repository. The basic recommended layout is:

/trunk
/branches
/tags

and while that’s a good start, I expanded upon it:

/branches
/sandbox
/tags
    /builds
    /candidates
    /development
    /releases
/trunk
/vendor
    /archives
    /src

Branches hold branches, labeled in a manner that describes what the branch is about. There’s no need to get too formal about the branch name, so long as it along with the commit message adequately describe what’s going on. Sandbox provides a place to play, perhaps you wanted to write a little testbed application that is relevant to the project, this is where to put it. Why put it into the repository? See #2, along with just all the good reasons for versioning source. Tags is broken down into a little more organization. Development tags are tags defined to ease development, like you’re about to make some big change and want to demarcate a clear rollback point. Build tags are tags made during your build cycle, perhaps by the automated build server, to of course denote a particular build. Candidate tags are tags to say “this is a release candidate”, and these tags are made from a build tag (e.g. “svn copy tags/builds/1.0.0.005 tags/candidates/1.0.0FC1”). Release tags then are the actual public releases, made from the candidate tags (e.g. “svn copy tags/candidates/1.0.0FC2 tags/releases/1.0.0”). This hierarchy of tagging allows a tracking of history. Trunk of course is the main development trunk. The vendor area is for any sort of third party product that is relevant to go in. I like to put the archive, as downloaded, into the vendor/archives/ area (e.g. the .gz or .zip or .dmg or whatever), so the archive as received is maintained. Into vendor/src I then like to put the expanded/opened distribution, but with minor modifications. For instance, they didn’t make a clean distribution and included .svn folders, or build products or other things that are irrelevant or dirty things up, or renaming the top-level folder to something more descriptive (e.g. from “distro” to “boost-1.46.1”) ; it should be as close to the original distribution as possible, just cleaned up. From there, the /vendor/src/whatever/ is svn copied into the /trunk. This allows the original distro to remain clean, but if say it’s necessary to make changes to the local version we can do that without risking dirtying the original distribution.

Of course, this setup may not work for you and your projects, but over the years it’s what has evolved to work for me and my needs.

#8 and especially #9 – yes. Please stop checking in your cruft.

Remember, version control is there to help us write better code. Not directly, but once code is written it will always have to be maintained. History is a part of that maintenance cycle. The more relevant history we can preserve, the better off we can be in the long run.

The Art of Video Games

/ hsoi

I think it’s wonderful when non-traditional art mediums get their due. Just because it’s not an oil painting on a canvas doesn’t mean it’s not art. Or as well, the consideration that some mediums are “childrens” and not to be taken seriously, like cartoons or comic books. To me, that just shows you don’t understand the medium.

The Smithsonian American Art Museum is going to be presenting an exhibition on The Art of Video Games.

The Art of Video Games is one of the first exhibitions to explore the forty-year evolution of video games as an artistic medium, with a focus on striking visual effects and the creative use of new technologies. The exhibition will feature some of the most influential artists and designers during five eras of game technology, from early developers such as David Crane and Warren Robinett to contemporary designers like Kellee Santiago and David Jaffe. It also will explore the many influences on game designers, and the pervasive presence video games have in the broader popular culture, with new relationships to video art, film and television, educational practices, and professional skill training.

Forty years? Geez… that makes me feel old. 😉

What’s cool tho? Look at the winning games. It’s hard to argue with their choices. If I’m in the Washington DC area while this is open, I’d love to go see it. Else, I do hope it tours and comes somewhere near me.

What Monty Python Taught Me About the Software Industry

/ hsoi / 1 Comment

A great blog post by David “Lefty” Schlesinger on what Monty Python can teach us about the software industry.

If you’re not in this industry, you might not get it all… but he nails it pretty well. The part that really struck a chord with me is Mr. Creosote:

“More” is Not the Same As “Better:” For years, the mobile phone industry — as typified by OEMs like Nokia and Motorola — marched along to the beat of the carriers’ collective “standards and requirements,” which essentially amounted to an extremely lengthy checklist of mostly extreme minor features, quibbles, and quid pro quos. In the case of one major carrier, the requirements specifications stretched to some 1,800 pages.

Apple turned that all upside down with its introduction of the iPhone, which failed to implement even such commonplace features as MMS messaging. Predictions of imminent doom for the device and for AT&T (the carrier foolish enough to go for an unproven phone from an inexperienced manufacturer) were rife (and I admit to being among the misguided doomsayers, initially).

It turned out that consumers didn’t care about the carriers’ checklists, and they pretty much didn’t care about niceties like MMS messaging, either. What they did care about was nice design and thoughtfully constructed — both surprising and consistent — user experience.

Adding features aimlessly guarantees that none of those features will be thoughtfully implemented; it reduces the likelihood that any of them are well-integrated. Worse, just-one-more-feature considerably increases the chances of the unexpected happening to your project (see point 1).

Product marketers love to try to squeeze just one more tiny feature — really, it’s wafer thin! — into everything they work on. It’s a bad idea.

Emphasis added… because I’ve dealt with this for so long.

Writing good software is a craft, which most people don’t get. It’s hard to do, it takes time. It takes iterations, revisions, even throwing everything out and starting over. We can add 1800 pages worth of features if you really want it, but the old saying stands: good, fast, or cheap — pick 2. Unfortunately they usually want it fast and cheap… with more features, and oh, can you just add this?

Bad? You keep using that word….

/ hsoi / 5 Comments

…. I do not think it means what you think it means.

Apparently an Apple Store in Chula Vista, California was being broken into. The mall security guard noticed (it was 7 AM, before the mall opened), gunfire was exchanged. Apparently one criminal is dead, two others in custody, one of them also wounded.

And this “journalist” says the holdup went bad?

Uh… no. I think the holdup went pretty good. And actually, this sounds like burglary, not robbery. Furthermore, how do you hold-up a store with no people in it? And to have the crime foiled… to prevent bad people from doing bad things… that’s… “going bad”? that’s “going sour”? Whose side are you on?

In other news…. since when did mall security carry guns?

Another article:

Despite some media reports, there were no AK-47s involved in the incident, police said.

Ah, the media and their love of those Glock ultra-automagic AK-47 semi-assault revolvers with extended high-capacity dethklok clips.

“That’s crazy. That’s so scary. This is supposed to be a really upscale, comfortable neighborhood and for stuff like this to happen is just scary,” said resident Janae Sergio.

Bad things can and do happen anywhere and everywhere. Upscale, comfortable neighborhoods full of rich white people aren’t immune from anything. Welcome to the real world where there aren’t protective bubbles or… since we’re talking Apple here…. reality distortion fields to protect you.

HsoiContextualServices 3.1 now available

/ hsoi

My company, Hsoi Enterprises LLC, just released a 3.1 update to HsoiContextualServices.

Mac users, check it out! Download and use. It’s free, it’s functional, it’s useful!

Spread the word!

Is your iPhone data fully encrypted?

/ hsoi

I subscribe to TidBITS, and in issue #1068 (21-Mar-2011) was an article about ensuring your iOS device is really encrypted.

I fell into that situation. iPhone 3GS, started with iOS 3, upgraded to iOS 4, but while I used a passcode my data wasn’t fully encrypted. Or at least, as encrypted as it can be.

Apple has an article that explains it all.

It was time-consuming to perform on my part because I have a lot of data and almost full iPhone. But it’s a one-time operation. I just started things before I went to bed and let it roll.

If you have a recent iOS-device, you’d do well to check to ensure your data is fully encrypted (the articles explain how to check), and if not, take the time and trouble to remedy it.

Certificate of Destruction

/ hsoi / 7 Comments

Just say that a few times: “Certificate of Destruction”

Sounds cool. Or at least, me and my kids think so. 🙂

I have (well, had) a bunch of old computers lying around: an old PowerMac 850/150 (that was the shiznit back in the day), a IIvx with a Daystar 040 upgrade card in it, and a few other things. I kept them around because I thought I could repurpose them somehow, like install NetBSD and have a little server or something. But the reality is they are so old, may not work, or to bring them into serviceable condition would be more expensive than just building a cheap Unix box or even buying a MacMini. So, then it became a matter of overcoming inertia to get rid of them, mostly because I was worried about data on the hard drive and was just not in the mood to dismantle everything and deal with it myself.

But worry no more.

I found a place in Austin called Electronic Recycling and Trading. They took my stuff, they will ensure the drives are either truly wiped or shredded, and they’ll resell things then either in whole or in part. Easiest solution for me.

And for my troubles? I was given a “Certificate of Destruction” which is their guarantee that it was done. So of course, if any information gets out that was on those drives, I’ll get to have happy fun suing them (good luck with that).

In the end, I’m just glad to be free of the clutter and that it was disposed of in a responsible manner. I did love that 8500… oh it was so cool. And the IIvx was my (personally) first Mac… should have gotten the Centris 650, but live and learn.

Authentication in an Xcode Run Script

/ hsoi

Time to put on my programmer beanie for a moment.

One of the most useful features in Xcode is the ability to add “Run Script” build phases anywhere in a target’s build process. A little shell scripting and there isn’t a whole lot you can’t do to customize your build process.

One of my co-workers asked me if I knew of a way to perform privileged operations during that phase. I didn’t, but figured osascript might come into play. I finally had an opportunity yesterday to investigate this and sure enough, there’s a way.


osascript <<ENDSCRIPT
set shellScript to "rm -Rf /Users/hsoi/Desktop/TheTarget"
do shell script shellScript with administrator privileges
ENDSCRIPT

In an Xcode “Run Script” build phase, you have to use shell scripting (sh, bash, Python, etc.). I know of no simple way within a shell script to invoke Authorization/Authentication Services and pass that along. I do know you can do it with AppleScript, but via the do shell script command with the with administrator privileges option. So what do you end up doing? Creating a shell script (or simple command line instruction), embedding that into an AppleScript, which is executed via a /bin/sh script within the Run Script build phase.

I know. Convoluted. But it works, at least in the light cases that I needed.

Of course, you could go the pure AppleScript route:


osascript <<ENDSCRIPT
tell application "Finder"
set targetFile to "/Users/hsoi/Desktop/TheTarget" as POSIX file
move targetFile to the Trash
end tell
ENDSCRIPT

and if the Finder needs you to authenticate, it will prompt, just like it would if you directly manipulated “TheTarget” yourself in the Finder.

The bottom line is AppleScript will get the job done for you since it’s savvy to the OS and OS services like the Finder and Authentication. If your scripting needs are a little more complex you may have to do more work to get things working as you want them, but at least this provides a foundation.

Happy Scripting.

Learning to program

/ hsoi / 17 Comments

When I posted about “What To Teach The Kids“, I desired to write this side-bar on learning how to program.

You see, the trouble with getting started in programming is it’s difficult. Usually you want to learn to program because you want to do something, but there’s a lot of things you have to get straight before you can do something. It’s frustrating. You have to learn programming concepts, like loops, if-decisions, storage, subroutines and the like. You’ll have to learn higher concepts like factoring and organization. If you’re doing object-oriented programming you have to learn that whole paradigm and perhaps start to understand design patterns. Then you have to learn some language and all the quirks that come with it. You’ll have to learn some sort of library or framework. Depending what you want to do, there may be other specialty frameworks or concepts you have to pick up on, like for games work. I mean, it’s hard to get started because there’s so much you must have in order to just get started.

So how can you get started?

It so happens some other folks are presently discussing this, here and here. I think they’re headed in the right direction but haven’t quite gotten there. But the direction really is nothing new.

Karel

Back in undergrad I took this “abstract” computer programming class that used something called Karel the Robot. I remember in grade school learning to program in LOGO, which was kinda neat but looking back I see it was poorly taught and taught without direction… what’s the point of making this turtle draw a star on screen? But that started the ball rolling. BASIC was cool and very functional. But Karel was different.

Karel wasn’t out to teach you a programming language or other hard skills. Karel was out to teach you the basic theory of programming. Karel’s a robot that lives in a grid world. He can do a few simple things like advance, turn left, detect a beeper, pick up a beeper and put it in his beeper bag (I always thought “beeper bag” was a cute concept), detect walls. Very simple things, but from those simple building blocks you were able to learn concepts. For instance, you learned about the notion of subroutines when you wrote the “turn right” routine implemented as 3 turn left commands. And so it would grow from there. Karel was deliberately simplified so you didn’t have to worry about all the gory details that programming truly involves, so all you had to focus on was concepts of programming that apply anywhere regardless of programming paradigm.

Karel’s been around for 30 years, and truly I think this is the way to start programming because once you understand the concepts — and can do so free of all the other complex dreck — you’ll “get it” and be able to progress a lot faster. Karel’s been ported to numerous environments and languages, with an attempt to keep the essence of Karel but also give a gentle introduction to the language. I’m of mixed feeling about that because it removes a basic tenet of Karel: the simplicity of worrying about other stuff. But for those eager to get going, it may not be so bad.

Still, the trouble with the Karel is you can’t do anything useful, but that’s the tradeoff: ease of learning vs. usefulness. Again, when people get interested in programming it’s typically because they want to do something. So how can we get them to do something?

Useful

I’ve looked around for ways to teach kids to program, that honors the real tenants of programming — perhaps simplifying but not dumbing down nor misrepresenting — but still lets them do something useful.

I found this product called Stagecast. I’ve only evaluated it, but it looks pretty neat. It’s visual programming. It’s very simplified, a lot of click and drag and so on, but it still is true to real programming. The real bonus is the feedback and results are immediate. The kids can see what’s happening and how it all works. There’s no need to edit 500 lines of code across 20 files, wait for it to build, fix compiler errors, build again, then try to debug it. It’s like my “fishing vs. catching” analogy: there’s fishing, then there’s catching… you can fish all day, catch nothing, and it’s still a good day fishing. But if you’re trying to introduce a kid to fishing, they want to catch and catch soon else they will lose interest. So for kids, you have to start out with “catching” and as they start to enjoy “catching”, inevitably they’ll discover what “fishing” is. So I feel the same can happen here with Stagecast… let them “catch” and immediately create things in a simplified way. If they truly love programming then they’ll start to see the restrictions and limitations of Stagecast and want to explore further (“I want to write an iPhone game!”) and so, then you can start to introduce them along the path to other languages and other things.

If I picked a more generic path, I’d say the next step might be to teach them HTML. No it’s not a programming language, but it’s still simple, teaches formal constructs and organization, how to look things up in references, and again you get results but still have to debug those results. If they want to do more, JavaScript could be a simpler language to learn. I’d also say a modern scripting language like Python or Ruby would make a good “next step”. But exactly where to go from here really all depends upon their interest and direction.

Of course, something like LEGO Mindstorms would be wicked cool too, if you can afford it. 🙂

Make it Fun

Getting started with programming is a daunting task because you have to lay so much foundation before you can do anything useful. I believe laying the core foundation of principles, through something like Karel the Robot, is a good approach to take. Then moving to simplified but immediately productive environments such as Stagecast makes for a good transition. After that, you just have to determine your goals and where you want to go. There are ways to get there in steps, you just have to be patient. 🙂