Programming

Smart guns? Dumb idea.

/ hsoi / 1 Comment

So, Jeremy Shane thinks the solution to the problem is to “make guns smart”: (h/t Shawn)

While the debate rages on, it’s worth thinking out of the box for a moment. What if we could design guns to be smarter and safer — with hardware and software? The right technology could neutralize the killing capability of an assault weapon, even in a madman’s hands.

After reading Mr. Shane’s article, I’m not sure how much he knows about guns or software, but it comes off like he doesn’t know much. I’m a firearms instructor and have been a software developer for over 20 years, so I know a few things about both realms. Given that, while I applaud Mr. Shane’s imagination, I can say his ideas are best left to the imagination, as realization of them will not lead to the end goals he desires.

The root of the problem is that guns are “dumb.” Pull the trigger and they discharge bullets mindlessly, regardless of who is doing the aiming or where they are aimed. Guns should “know” not to fire in schools, churches, hospitals or malls. They should sense when they are being aimed at a child, or at a person when no other guns are nearby.

Most useful tools are dumb. We don’t have “smart” hammers, smart screwdrivers, smart knives, smart binoculars, smart blenders, smart cars… well, granted some things are starting to try to move that way, but most things understand that those “smart” devices can really only operate in dumb environments. No computer can process information as fast and as well as the human brain, can make the “instant” decisions that sometimes are necessary. The “touchier” the environment, the more humans are still needed. Even with all the safety technology being brought into cars, we still haven’t eliminated the driver because there are just some things the car cannot do and only a human can.

Should guns “know” not to fire into schools or churches or hospitals or malls? I don’t know… what if there’s an active shooter in a school or church or mall (since that’s where most such events have happened)? Wouldn’t you want the good guys to have guns that can work in those environments?

They should sense being aimed at a child. How would that work? Define “child”, as some sort of optical device would perceive them? I mean, I know some young teenagers that are larger than adults, some adults that cast child-like silhouettes. Mr. Shane also says “Sensory data can be used by built-in software to disable firing if the gun is pointed at a child or someone holding a child.”. Or someone holding a child… So a gun shouldn’t be functional if pointed at the person kidnapping your child?

You see, these are subjective decisions. How exactly can software make the sort of decision necessary? And even if it can, it takes time, time that may not be present as a horrible event is unfolding.

If you wish to have software attempt to make these subjective decisions, we have to remember that software is imperfect. It’s written by humans — who are imperfect — and software has bugs. It may not be robust enough. It may not be sound enough. It may hold bias of the programmer. I mean, for all my care and concern at writing bug-free code in my decades of programming, it’s impossible to write bug-free code. Do you want YOUR bug to be responsible for someone’s death? That it might not fire when you need it to fire, or that it fires when you don’t want it to fire? And then, who bears the responsibility for such a mistake?

Couldn’t gun software be hacked? Perhaps, but the risk can be reduced by open-sourcing code, requiring software patch downloads, and notifying gun makers or law enforcement if software is disabled. Open-sourcing code is not foolproof, but it will build a community of lawful gun owners and code writers who value safety and Second Amendment rights. Enabling two-way communication between guns and their original makers will help guns to be tracked beyond the initial sale, putting greater long-term responsibility on gun makers.

Nice thought, but open source code is still not bug-free and still can have horrible things happen. And there’s nothing here to address “software hacks”, but boy… what about viruses? what about social engineering? hardware hacks (I mean, why not just disassemble the gun and disable or replace the mechanism)? It’s not like DRM has really stopped piracy. It’s not like iPhone’s don’t keep getting jailbroken. There’s so many other things that can happen and be made to go wrong, to bypass, or to even force malfunctions. Wouldn’t it just be dandy if some virus was let loose that caused all these guns to rapidly empty their magazines at some coordinated time of day… all around the world… *shudder*.

There have been groups that have attempted such “smart guns”, and all have failed. Not only because the system itself doesn’t really work out, but because no one is willing to buy said “smart” systems. There’s no police nor military group that would want to buy such a thing, because they operate in environments where you may need to shoot multiple rounds in a school at a person holding a child. They understand these “smart” systems are anything but, and are too risky and prone to failure, and not worth risking their lives over. So you may say, only sell “dumb guns” to police and military. Realize then that still means such guns would be in circulation, and thus bad people will still get a hold of them. Of course, if you know anything about weapons fashioned and found in prisons, bad people will get weapons without your “smart restrictions” if they really want them. Even if somehow that’s all there is, there are going to be other “dumb” ways to cause mass destruction; look at Timothy McVeigh. So all these “smart” weapons would do is abridge and hamper law-abiding good citizens. Why do you want to do that?

You see, a well-made gun is actually a very simple mechanical system; it’s a simple machine. Once you start to add all of these things on it, start trying to add GPS, sensory data, target discernment, you start making for a massively complex system. And with any complex system, it starts to become… well… complex. Difficult. And prone to mistakes.

If truly you value life, should it be held to a system that can be massively complex and prone to mistakes? For all your attribution to car technology, Mr. Shane, consider how many recalls happen every year. A car is a massively complex system, and while it may work most of the time, you know all too well that cars break down and fail us. Thankfully most of the time car breakdowns don’t have life hanging in the balance. But when good guys need their guns, for certain lives are hanging in the balance — do we really want the risk of breakdown when preserving life is most critical?

It’s a nice thought, but technology cannot save us. Fixing our cultural and social norms and behaviors is at the root of solving this problem.

Thanx, Mom & Dad

/ hsoi / 2 Comments

The other morning I was thinking that being a programmer was probably where I was headed all along in my life…. and thankfully Apple has remained around that whole time too, since that’s where it started.

I remember being sent to a week-long “computer camp” one summer at Brownell-Talbot. We learned BASIC on Apple II+’s. I kept the 4 books as my “reference bibles” for many years of my youth… carrying them around with me all the time, reading them. I recall being befuddled by GOSUB routines. 🙂

I remember when we got an Apple IIe for Christmas, with 2 5.25″ disk drives, and a 64K expansion card! Top of the line stuff there… and of course, I pulled out my BASIC books. One day Dad took us to a software sales “convention” in some hotel conference room where they sold this “shareware” stuff. I recall pulling out my BASIC knowledge and hacking the games. I didn’t know how to write a full game myself, but I did like modifying the existing ones. Heck, I recall kids at school giving me obviously pirated/hacked versions of games — I didn’t understand what it was I was getting, but I thought it was cool to see how someone had inserted their own name into the game’s intro screens.

I remember going to my Dad’s office and while he worked he sent me over to this one desk to occupy my time. This desk had a Mac on it. I was so fascinated by this MacPaint thing.

I remember needing my own computer in college, being tired and frustrated by the limitations put on me from sharing or borrowing. Dad bought me a Mac IIvx (I should have gotten the Centris 650!). I found a copy of THINK C for sale at the college bookstore, and with a Dave Mark book in hand I started down the road in earnest.

So I was looking back at just how much my parents supported and enabled my efforts… and well….

Thanx, Mom & Dad. 🙂

What we (programmers) want

/ hsoi

I’ve poked at computers for decades… yes, I’m dating and aging myself.

And programming always appealed to me. I guess it’s been my craft, my calling. I’ve had opportunities to move into management, but I refuse because I know what I’m good at and what I love (and that I don’t like being a paper-pusher). For example, right now I’m working on one of the more challenging programming tasks I’ve dealt with in a very long time. It’s very complex, very complicated, very frustrating. But because it’s such a huge challenge (and will be a HUGE win when I pull it off), I’m happy to let it engulf me. Part of my poor sleep this past week has been due to Daylight Saving Time throwing me off, but also because the moment I wake up my brain churns on this problem because well… it’s just what I find exciting. Geek that I am.

Over my years, over my jobs, my bosses, my companies, the projects and groups… I’ve learned what I want and don’t want. Geeks do tick differently, and we aren’t satisfied by the same things a lot of other officer workers are. It’s welcome when the company and bosses get it, and frustrating when those that “run you” don’t get it. I don’t expect people to bend to my way of being, but I can say if you can understand folks better, you tend to get further.

This article by Michael O’Church about “What Programmers Want” is insightful and pretty spot-on about us.

If you have to manage geeks or interact with them, take the time to read it and gain some insight into us.

Or if you just want to understand us geeks a little better, it’s worth your time too.

Senior Engineer

/ hsoi

John Allspaw writes “On Being a Senior Engineer“.

In my long career, I’ve met lots of people with the title “senior engineer”. We’d joke and call them “señior engineer” because it was all too often thrown around as some title of arrogance or tenure, but was about as meaningful as a “perfect attendance” award  — sure it’s great that you showed up and have been here a while, but that didn’t mean you knew anything.

Or were mature enough.

So with that, I’ve often cast off the title because it’s tended to be meaningless, maybe useful for business cards or at most on your résumé. But John’s article gives a perspective that the title is meaningful, if applied to someone who actually fits the role.

Of course for it to truly be meaningful, the title needs to be properly applied over the course of a career, not just because you’re the lone coder at some startup you and your other 20-something-year-old friends put together over beers one evening fresh out of college.

In the end, it’s just a title. It doesn’t really matter. But the merits and qualities of a senior engineer, as John lays out, are what really matters and what are worth striving to be.

We don’t need no stinkin’ comments – yes you do

/ hsoi / 2 Comments

If you haven’t guessed, I like to write.

Some think I like to talk. No, not necessarily. But get me on the right topic, and I can go on.

Programmers are a funny bunch. They’ll write pages and pages of code, but they won’t say a whole lot. It tends to happen frequently with regards to comments.

Comments are blubs of text within code that don’t have much to do directly with the code, but tell us something about the code.

Comments help us understand.

Comments are also the subject of religious wars.

Some believe comments are evil and shouldn’t exist. I’ve seen a lot of course code that is devoid of comments. I generally assume the programmer is lazy or in a hurry when this happens. They might come back to say code should be self-documenting, but then I see the quality of their code is such that it doesn’t document much of anything.

To me, the trouble with self-documenting code is… what if the code is wrong? Comments (and perhaps design or API documentation written prior to the writing of code) provide a level of redundancy, because they provide the general overview, the abstract notion, the description of the promise of what is to happen. If the code jives, great. If it doesn’t, then we know there’s a problem. Can comments be wrong? Sure. But we tend to grok wrong comments better than wrong code, because it might be possible the code is right even if it looks wrong to us. What helps us determine that? You guessed it, comments.

See, comments are about the “why” of the code. We cannot tell WHY the code from the code; we cannot derive the reasons for the way the code is from the code itself. Once you write code, it will forever have to be maintained, so you need to think of the future maintainers — likely yourself 6 months from now, and yes you will have forgotten more than you expected. Do yourself a favor and comment your code.

I worked on a large software project many years ago. It was a huge beast of a mess of code. One day I went digging around after a memory problem and found a complete mess. See, every bit of memory you allocate, every resource you create, it must have a distinct owner. We have to know who made this mess so it can be cleaned up when we’re done. As I dug through the code, it became evident whomever wrote the original code played fast and loose with the ownership and numerous people assumed ownership over the memory but never rightly transferred that ownership. It created a massive mess, and in the end I determined there was no real safe way to properly clean things up. It was horrible.

Consequently, I wrote a lengthy diatribe in the code (comments) explaining the mess. It was pages long, because it was that ugly of a mess. I figured after all the crazy I went through, future folks ought to know about it so they could beware.  Well… I left the company some months later, and then later on the product was sold to another company. I was at Apple’s WWDC (back in the old days) and came across a representative of the new company. When he saw my name his eyes got really wide and he said “YOU!!”. He started laughing. Seems they had come across my epic comment block and had a great laugh reading it, calling over everyone in the office to see it. He said I was a legend in their office for having written it. It was most amusing. 🙂

What spurred this walk down memory lane?

Over at AltDev is an article The Elements of Comment Style. It talks about the value of comments and the different types of comments. I never gave much thought to the types of comments — it’s just comments, there to explain what code itself cannot explain. But the article provides good reason for comments, and links to writings of others, like Knuth and Raskin, as to why comments are good (and wouldn’t those guys know).

In all my years of programming I’ve gone back and forth and refined my approach to comments. Do I think we need to have copious levels of documentation? Well, sure that’d be nice and ideal, but it’s tough to do that because comments and documentation also have to be maintained. There isn’t always time. And that, depends upon the scope of the project. I’m sure if I was writing some system for the .gov I’d be documenting everything to the Nth degree. But working in the mobile app space, sometimes you have to move faster than is healthy and there isn’t always time for formal comments. Maybe the best I can do is a couple lines at the start of a function to give the basics of what it does then “self-document” what are legal parameters by having a lot of asserts of the parameters at the start of the function, which do provide documentation and also a level of code robustness. But that approach only works when we have full access to the code; writing an opaque library/SDK would require a different approach. So there’s always trade-offs and balances to be found, depending upon context.

I haven’t written a multi-page comment since that one.

And if nothing else?

A little humor buried in code can always brighten your day. 🙂

A year since we’ve said goodbye

/ hsoi

A friend pointed me to the Apple website, because 1 year ago today, Steve Jobs passed away. Apple changed their home page today to post a video (linked here, but no idea how long this link will remain, or if it’ll move to a more permanent home eventually), a tribute and remembrance of Steve Jobs.

Yeah… it choked me up a bit.

I didn’t know Steve at all, but my first computer was an Apple //e, and the day I saw a Mac… it changed my life. I’ve spent over 20 years writing Mac and now iOS software professionally, so yeah… Apple has a place in my life.

At the end of the video you hear Steve say:

It’s technology married with liberal arts, married with the humanities, that yields us the result that makes our heart sing.

That’s what people tend to not get.

Sure, iPhone is behind Android in a lot of respects. In fact, in many respects Mac has been behind the PC/Windows. But in many other respects, Apple has completely lead the way in both the desktop Mac and mobile iPhone world (and let’s not forget the music iPod world either). And the biggest leader is Apple make products people want to have, that people yearn to have. Who lines up for the midnight release of any product? What other customers find opening the box to be a religious experience? that a product, a service, a brand creates such intense devotion… to plastic and silicon?

There’s an aesthetic.

I see Android devices all day at my day job, and I just can’t like them. Same with Windows vs. Mac. Oh sure, I can totally appreciate the technology going into them, both the hardware and the OS. I think there’s actually a lot of cool stuff about Android as an OS. But it just doesn’t sing to me. It doesn’t move me. I don’t look at it as a joy that I like to look at for hours every day, which is what I have to do. If I have to stare at something for a long time, I like it to be pleasing to the eyes (like my wife), and somehow stir my soul (like my wife).

To some people, they don’t care. These things don’t matter to them. And that’s OK. To some it’s pure utilitarian, or they don’t know any different or don’t care. And that’s fine. That’s them.

Me?

Well, speaking of Steve… if you consider his background with typography and how that influenced the development of Mac. Just the other day I read about a new programmer’s font, the article mentioned a few, I downloaded and tried them out, and settled on Source Code Pro. It’s a beautiful font. It’s a lot nicer on the eyes, and when you’re staring at code all day long well… the shape and placement and count of pixels really starts to matter. And you probably don’t realize it, until you start to care and do something about it… like change it. But there’s the joy of Apple. They spend so much time fussing and caring about every little pixel, every little detail. The intent? To just work. In some respects, it should be remarkable; “Any sufficiently advanced technology is indistinguishable from magic.” But really in most respects it should be unremarkable. It should just work, it should not get in our way, it should not impede the flow of our work, it should enable and empower us… and we don’t really notice nor understand why. And even something as simple as a font can do this. Does that matter? Yes it does. And Steve knew that. Many people don’t know, don’t care, or aren’t aware… and that’s fine for them.

Not me.

Think different.

Happy Programmer’s Day

/ hsoi / 1 Comment

Happy Programmer’s Day to my fellow programmers!

Oh wait… you mean it was yesterday? Ah that’s right… leap year. So that means this is an “off-by-one” error. How appropriate. 🙂

More things I’ve learned about Jenkins

/ hsoi / 1 Comment

At the day job, I’m still working with Jenkins and our build system. I’ve written about some things I learned at the onset, and now I’d like to add some things I’ve learned since then.

Plugins

Be mindful of them. There’s a great many out there that can help you solve things, but they seem to also bring much risk. For example, Jenkins was going belly-up at least a couple of times a day. I’d look in the system console and see some plugin that I wasn’t even using (just had installed) was somehow causing memory failures, throwing an exception, and Jenkins went stupid and had to be restarted. Once you figure out what plugins you need, uninstall every other plugin. Keep your system as minimal and tight as possible to avoid introducing risk or uncertainty.

Backups

I had to write a lot of custom scripts (some bash, a lot of ruby). These files I can keep in our version control system. But Jenkins files themselves are harder to do. Make sure you have a backup strategy. Make sure you run it often while you work. Working on a Mac and using Time Machine is useful… make a change, screw up, easy to revert.

Updates

Don’t apply an update unless the changelog shows it directly affects you. For example, the git plugin was just updated to fix a regression that prevented using env parameters in the branch name — I need that, so I upgraded that plugin. This goes back to the plugin issues I mentioned above… and if you screw up, it goes back to my backup issue I mention above. 🙂

Planning

Do your best to plan your jobs and pipeline. Figure out the abstract ideal that you want. Then figure what Jenkins can offer to get you there. You might find plugins, but you might also have to write your own scripts and other management.

Then, don’t be afraid to revise and revise again, even starting over if you have to.

DIY

I wanted to use a lot of plugins, because they’re supposed to make it easy, right? Well, it depends. The Xcode plugin is supposed to make it easier to do xcodebuild-based, builds. And in theory it does, but our needs are different and so I just have to get dirty with our own scripts.

The email-ext plugin is really cool, but I couldn’t get it to understand and bring in a bunch of env vars and do other bits of logic processing that we needed. So again, scripting to the rescue. Net::SMTP to the rescue.

CodeSign problems

I noticed from time to time that I’d start a build and eventually xcodebuild or ‘xcrun PackageApplication’ would fail:

“There are no valid public/private key pairs in the default keychain”

It seems this would happen after rebooting the machine (and Jenkins started up via the launchd stuff). I could manually use launchctl to unload then (re)load and things might be back to normal, but that’s annoying.

I found this post at stackoverflow.com, and adding the “SessionCreate = true” key/value to the launchd plist seems to do the trick.

But then further down things failed out. Despite the codesign command line tool being granted special Keychain access, it still hated life:

<path to build output app>: User interaction is not allowed.

Uh…

So I found this and added a:

security unlock-keychain -p "" login.keychain

in the custom ruby script before invoking xcodebuild and PackageApplication.

BTW, I don’t have the passwords encoded into the script. Remember the use of the .netrc file? Use that.

Speaking of .netrc… it seems curl doesn’t like a .netrc where newlines separate entries… it wants everything on one line.

Passing Data to Downstream Jobs

Using Jenkins’ parameterized build mechanism, I was able to pass parameters around. I’d have the main build job, which would then use the promoted builds plugin to allow me to move the build through a pipeline, like to promote to QA, then promote to the App Store, or whatever. But there’s a lot of information from the main build job that I want the downstream jobs to have so the jobs can be properly named, emails can be properly formatted, version control tags set up, whatever. I found the easist way to do this was at the end of the main build job to use a little ruby scripting, create a Hash with all the things I cared to preserve, use YAML to preserve it to file, make sure the build job archived and fingerprinted that .yml file, and moved that “config.yml” file along with the rest of my archives and promotions. Then it’s simple enough to load and look up key/values out of the config.yml file in the later job scripts.

Tagging Git

One of the downstream jobs is a “deploy to the Apple app store” job. Certainly when we do that we want to tag our github-hosted repository with info about the build so we can know what was deployed. Trouble is, at that phase of the build pipeline we don’t have source code. So we can’t just “git tag” then “git push”. What to do? Use the github v3 API. In that config.yml file I was able to preserve the SHA hash of the code we used, so that’s all we need.

At first I thought to use the Tags API, but as I played with that it didn’t work. Even if I could create a tag, it wouldn’t show up in the Tags area of my git GUI app SourceTree. In fact, it started to give errors about refs. So I started to play with the References API and tried things like:

$ curl -XPOST --netrc https://api.github.com/repos/:user/:repos/git/refs \
-d '{"ref":"refs/tags/MyTestTag","sha":"be43262431c7a4b9db67a23d37f51e7901b9845c"}'

and lo… that seemed to work.

Is that enough? Is that correct? I don’t know. I’m not an expert on the low-level plumbing of git. I have contacted github support, but as of this writing have yet to hear back.

The Journey Continues

That’s all that I have for now.

It’s a lot of work to set up a build system, but it’s rather satisfying to do it. I still have a long ways to go. Right now we just have the basics for building and deploying to help our general workflow. It still needs lots of work for validations, testing, continuous integration, and other good stuff like that. One step at a time.

Setting up Jenkins… things I’ve learned so far

/ hsoi / 3 Comments

At the day job I’ve been tasked with setting up an automated build system. This is a Good Thing™ and I actually volunteered to do this task. I’m interested in doing what can help us make our code better, deliver our products faster, and make our lives easier in terms of automating things we don’t necessarily need to be involved in. So a Mac Mini was obtained to be a build machine, and I’ve been working to set things up.

I should note that I’m not a dedicated buildmeister. I know at larger companies they can have a person (or persons) whose full-time job is dealing with builds, but I’ve never been one of those people. I’ve done some build hacking in the past, but it was always homebrewed scripts and systems. This time around, let’s use an established system instead of homebrew.

It seems the modern hotness is Jenkins. Yes there are other options, but all signs via Google searching point to it. As well, it seemed (note the verb tense) like the more Mac-friendly solution. If nothing else, it had a nice Mac OS X installer. 🙂

I’m still far from having our complete build system, and I reckon as I learn more things on this list will change. But I’ve already learned a few useful things and I felt like sharing and adding to the greater knowledge-base out there that, through Google-Fu, helped me get this far. Maybe with my additions, someone else can be helped and maybe with a little less frustration and time sink.

The Project

A little context about the project being built.

Working on Mac OS X, developing iOS apps. Thus we’re using Mac OS X 10.7 Lion as our dev runtime environment. We’re using Xcode 4.3.3. Jenkins is version 1.474. We use git and a mix of private and public repositories on github.com.

First Time Problems

Started with a brand new, fresh from the box Mac Mini. Of course, before attempting any of this CI-specific work, the box was brought up to date with OS updates, Mac App Store updates, and so on. Note! Jenkins is a Java app and Java is NOT installed by default. So after you run the Jenkins installer and it tries to start Jenkins, things will probably fail. The OS will prompt you to install Java, so you’ll have to do that, but then Jenkins should end up running. Not a big hurdle, but it’s there.

Make sure to launch Xcode.app (the GUI app) and get it properly happy. This is mostly ensuring the various downloadable components get downloaded and installed, like command line tools and such.

You will be using command line tools, thus you will have to run xcode-select. But being as this is Xcode 4, things are different.

$ sudo /usr/bin/xcode-select -switch /Applications/Xcode.app/Contents/Developer

This will ensure xcodebuild can be found. And note, the first time you run xcodebuild, it won’t run! While you agreed to the license agreement when you first launched the GUI Xcode.app, that’s not good enough for xcodebuild; you have to agree to it all over again via the command line. Just be aware. It’s not a big deal, it’s a first-time-only occurrence, but it’s there to deal with.

The User (login) Matters

This was the source of much fun and frustration for me.

The first time I installed Jenkins I had no idea what to expect. That it had a proper Mac OS X Installer .pkg was cool, but it was also hiding a secret. Any time there’s a “Customize” button I like to click it and see what options there are. I noticed it provided two options:

  • Start at boot as “daemon”
  • Start at boot as “jenkins”

I had no idea what the relevance of these two options were. The default was “daemon” and “jenkins” was unchecked. I just figured to trust the default installer settings. Ha ha ha…  This actually caused me the most trouble and pain. I won’t recount the many hours spent dealing with this, but I will explain the issues.

I opted to go with the installer’s default of “daemon” but that creates a problem because “daemon” is a special user. When Jenkins needs to do things, it’s going to look in non-typical places, like /var/root for ssh keys or the like. Basically, it’s going to cause you a lot of headache.

When you search around for information about this, everyone starts to talk about using the “dscl” command line tool to create a hidden secret “jenkins” user and run Jenkins that way. This makes sense because it creates a user of restricted ability so it helps to keep the system secure and minimize chance of damage should someone gain access to the system via the Jenkins system or login. But in practice, this turned out to be a big pain in the ass because of what we’re doing. I’m sure there are some projects where this won’t be that problematic. But writing iOS apps brings issues. Apple makes great products, but you find they are great as long as you color within the lines; the lines might be really wide and vast, but still you must color within them. Trying to deal with this secret “jenkins” user created various issues.

For Xcode (or xcodebuild) to do code signing, it needs access to private keys and certificates and other such things. Thus the Keychain is involved, but this hidden “jenkins” user doesn’t have one. Again, more searching will turn up possible solutions, but they are not ideal solutions. In fact, one solution of putting these into the “system” keychain really defeats the purpose doesn’t it? Then there are the .mobileprovision files needed during the signing process, and those must exist somewhere in the “jenkins” user structure. In my case, the provisioning files may be updated fairly often due to the addition of device UDID’s, and setting up the initial .mobileprovision files by downloading to the logged in user then copying it all into the hidden jenkins user locations… it was just turning into a massive pain in the ass. And you’ll have to do this at least once a year, when you renew your iOS account with Apple.

So I fumbled with various permutations of these user setups and it was all just frustrating to me.

In the end, I backed everything out and started over (for the umpteenth time). I created a “jenkins” user via the System Preferences. That is a full-on login-able user named “jenkins”, admin user. I then logged in as the “jenkins” user. I ran the Jenkins installer, customize, and selected the “start at boot as ‘jenkins'” option (and deselected the “start at boot as ‘daemon'” option). I ran the installer. That did not immediately succeed, but the resolution was simple. Stop the daemon (using launchctl). Edit the .plist for the Jenkins launchd job and changed the location of JENKINS_HOME to /Users/Jenkins. Then restarted the machine. Life was good.

I think today I’m going to try doing it “yet again” tho… deleting the Jenkins user and creating it again, then installing again, and this time making a subfolder, like /Users/Jenkins/Jenkins_CI or something like that. That’ll contain all the stuff in one folder and not litter the actual home directory.

Is this the right thing to do? Well, from a pure security standpoint, no. It’s now an admin user that can log in and have all sorts of fun. But my feeling is this machine will be behind our firewall. If this box gets compromised, we have bigger problems anyways.  Could it mean bigger problems for me down the line with Jenkins-CI itself? Maybe. We’ll see. I’m not necessarily advocating taking this approach, but it’s just the one I’ve presently taken. It appears that it will create less long-term hell for me, especially in dealing with Xcode and the OS.

Authentication

Another source of pain was dealing with authentication issues.

Since we use private repositories on github, we need to authenticate. This proved to be more difficult than it should have been.

When I first tried a basic build of our project, I installed the various git plugins within Jenkins, created the new job, set it to obtain the source via the http protocol, and off we go. Well, that failed. The job just hung forever, I reckon waiting for authentication. So how can we authenticate? I saw no configuration options for it. So I started playing with ssh.

ssh would actually be a good thing in many ways, but with all the aforementioned user/login issues, it was becoming a massive pain. The way Mac OS X seems to handle ssh is by launching the ssh-agent on demand. Well… it can’t do that for the secret jenkins user. I tried all sorts of things, but I just could NOT get it working. *sigh*   Another vote for making a fully-realized jenkins users instead of this secret hacked one.

The one thing I had to then do was edit my ssh keys to not have a passphrase, and that would work (no need for ssh-agent, no need for interactive issues). But lacking a passphrase ain’t so hot. But it seemed to work… well, at first.

The next problem? Our git project has submodules. In the .gitmodules list, the “url” for each submodule used http as the protocol. And so, when the Jenkins-CI git plugin tried to obtain the submodules, we were back to the original problem. FML.

I tried fiddling with the repository URL as specified in the “git” section of the Jenkins-CI job to be something like:

https://:@github.com/path/to/repo.git

and while that worked for the top-level repository, the submodules still tripped me up. Plus, I did not like the idea of storing a password in plain text and sight like that.

I was able to solve it tho… through the magic of the .netrc file.

I created the following file in /Users/jenkins/.netrc

machine github.com
login <github username>
password <github password>

Saved it. Did a “chmod 600” on it. And lo…. everything worked. Huzzah!

I think the git plugin should have a way of doing authentication, but I’m still too much of a Jenkins n00b to know really where the fault lies.

More Ahead

At this point, I’m able to clone our git repository and build the app. It’s very basic at this point, with much configuration and fiddling yet to come. But I spent a good deal of time on these matters this past week and tried to sift through a bunch of search engine results to wind up here. So much of the information out there is Linux or Windows based, which is fine for the general but some of the little details aren’t there. And I can’t imagine we’re the first people to need to build in such a way, but I just couldn’t find anything specific to the particulars of our setup. So here’s hoping this helps contribute back.

As well, if you the reader have any information, insight, comment, etc. please share. I’m still learning, and constructive contribution is appreciated.

Trying Trello

/ hsoi / 3 Comments

The new hotness in software development is “agile“. At my prior day job, it was waterfall. Sure they tried to adopt agile processes, but it really wasn’t going to happen. Due to the nature of the products and process, it just can’t be agile, tho they could try to adopt a few things and make some improvements. But at my new day job? Agile can make a LOT of sense. Take home: you can’t impart the process merely because it’s the new hotness or you think if you just adopt X process it’ll solve problems. Like any problem to be solved, you have to understand your problem fully and then apply the right tools to solve it, and that includes what processes you use.

However, it’s tough getting folks on board, so I’ve desire to try to sneak in agile stuff as we can. It’s nothing more than a commentary on human condition — we tend to resist change. If all this change is dropped on folks all at once, we’ll balk. I would too. Massive sudden change, especially when you’ve still got daily chaos and stress to manage, well… the change will be rejected. But if we can make little changes here, little changes there, over time we get there.

One thing I can tell is we all need a way to see the whole picture. We’ve got so many things going on at once, and it changes on a daily and sometimes sub-daily basis. I find myself often making lists and (re)telling my todo lists to my teammates merely to help ensure 1. I know what I’m doing and am on track, 2. that we’re all on the same page. By sharing with them I hope that if there’s a mismatch, they’ll speak up and correct. I’d rather be perceived as over-communicating than under-communicating.

But all this talk doesn’t solve the problem for everyone. The dev team is one thing, testing another, production another, sales another, marketing another… there’s so many things. Sure, we could use our issue tracking system, and there’s a lot of sense in that approach. But the issue tracker doesn’t work as well for non-dev folk PLUS it’s harder to get a 1000′ view. Yes, pictures/diagrams can make a big difference.

One thing from the agile/scrum world is having the daily stand-up meetings at “the wall”. Let’s set aside the meeting for now (again, baby steps), and just focus on the wall. I’ve suggested the wall, because I think that would be useful. Pick a wall in the office, divide it up in whatever way makes sense for us, then start populating it with sticky notes to represent all the tasks to be done. I think that’ll be useful at keeping a somewhat permanent record of the state of things (unlike a whiteboard, which will be erased eventually). Plus it allows anyone to just look at the wall at any time of the day to see where things are. CEO wants to know what’s up with Customer X? Just look at the wall. Did we ship Product Y yet? Just look at the wall.

Alas, one shortcoming is 1. we don’t have a lot of free wall space left in the office, 2. the wall is restricted to the physical. I’ve been searching for a digital wall solution and haven’t found much that thrills me. Something that we could access from any computer via a web browser (or even a platform-based app), and it would look good. But then we could also access from iOS or Android devices. In the office. Out of the office. At 3 AM, during office hours. From my desk, in a meeting on the shared screen. Whatever. Something with power to do what we need, but flexibility to work for anyone, not just the geeks.

So… I recently read this article from Joel Spolsky about “Software Inventory”. While I read it, it sounded like it was talking directly to me and our situation. I went looking at their solution:

Trello

I’ve only just started to play with it, but it seems like it could be the answer to my problems. I could see using this in my personal life, for Hsoi Enterprises, and for the day job stuff. Even if the rest of the office doesn’t buy into it, it could be useful for my own management of my tasks and issues to deal with. Being able to SEE everything instead of sorting through a bunch of text notes and to-do lists is sometimes much more useful, even if it ends up being redundant and a little more maintenance to keep 2 data stores in sync.

It’s still preliminary, but it’s promising.