Engineering

Efficiency

/ hsoi / 9 Comments

Every Friday we pick up our veggie box from Johnson’s Backyard Garden. Yes, still going strong, still enjoying it. But that’s a topic for another post.

Maybe it’s the engineer in me….

The veggies come in a thick, sturdy, wax-coated box. Makes good sense, and given their durability (and cost to produce), JBG likes to keep the boxes to reuse them. No problems there. We pick up our box, take it home, and bring the empty box back next week. Works fine.

We see many of the other people who come to pick up their veggies bringing bags (reusable cloth type). They stay at the pick-up place, move all the veggies from the box to their bag, then take the bag home (leaving the box). I guess that works but…

Box –> Fridge

Box –> Bag –> Fridge

The extra step doesn’t make sense to me. Doesn’t seem very efficient. More work. More time.

Sometimes I think too much about stuff…. 🙂

Outlook 2011 – resource hog

/ hsoi / 8 Comments

Geez….

My MacBook Pro hasn’t felt this sluggish… well… ever. But I install Microsoft Office for Mac 2011 and start using Outlook and geez…

I’m guessing it’s got some serious memory and resource management issues. I have so much slowdown in part because there seems to be tons of VM swapping going on. The longer the app is running, the worse things get. I’ll use the Activity Monitor and see the amount of memory that Outlook consumes just growing and growing and growing. What’s worse, the WindowServer process also grows huge. So put those two together and the machine just gets consumed. Thinking about it, the nature of the app makes you open and close windows all day long (I’m not using the preview pane / all-in-one-window mechanism… I open each email in its own window… maybe that’s not the codepath used much by the developers), and they are probably leaking windows (amongst other things).

Quit Outlook (which takes numerous minutes, which is crazy) and then not only do I reclaim all the memory from Outlook itself, but I saw my WindowServer process go from taking like 500 MB of real memory down to about 53 MB.

And Outlook is just slow. Slow to open a mail message. Slow to do a major context switch (making Outlook the front process). I’m floored at how sluggish things are.

I really hope that the MacBU is aware of this and working on it. I’ll drop them a line, don’t know what good it will do. But man… instead of seeing any more features, bug fixes, or bringing back Entourage 2008 features that we lost (more of which I’ve found, like I can’t cmd-shift-return to save as a draft)… I’d love for them to just spend time in Instruments, fix leaks, optimize, and so on.

I’m very tempted to move back to Entourage 2008…. but unfortunately I just accepted that Outlook wouldn’t suck and didn’t set myself up to keep things in sync, so I’d lose a bunch of mail. *sigh*

 

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.

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?

How did we manage before Google?

/ hsoi / 3 Comments

I’ve been working on a new programming project that’s new in every way. It’s a new project, it involves new API’s, new platforms, new paradigms, new things to explore… just about everything with this project is new.

When I get stuck and wonder how to get something done, first I turn to documentation. The docs are useful but generally are straight API docs. I need more conceptual docs, I need more HOWTO docs. So I look for sample code, and while some code is linked to from the docs, it many times hasn’t been enough to satisfy my question. So I do what has become natural in this day and age: turn to Google. Within a few keystrokes and clicks, I tend to find what I’ve been looking for. I can implement a solution in my code, get back to work and get on with things. Progress is quite rapid, all things considered.

What did we used to do?

I recall having to walk down the hallway to talk to other engineers at the company and ask for their help. Working from home for the day job and then having my own side gig, I just don’t have that luxury any more. Oh sure there are people I can turn to when I need it via IM or email or phone, but the world is growing so diverse in languages, technologies, platforms, APIs, and then the depth of what’s within those areas that often I ask someone a question and their response is “never used that before… never did that before… I don’t know”. 😦   While that isn’t solely a problem of today, in the old days we’d then turn to things like Usenet newsgroups or ad-hoc mailing lists; today we’d use web forums and official mailing lists But no matter whether we walked down the hallway or posted online, those all took one thing: time. If you walked down the hall you had to keep asking until you found someone who had a clue about the problem set, then you’d talk at great length, you’d get sidetracked, and eventually get back to your desk and work. If you posted online, you had to wait for a response with netiquette saying you should give it at least a day or two for people to respond. That sort of lag time isn’t always acceptable.

Now with so much content being online and Google’s amazing search capabilities, it takes almost no time. Chances are your problem isn’t unique, thus someone has asked about it before. And if you’re lucky, someone has responded with a useful solution… and Google was there to index it. Just craft your search string well and hopefully you’ll dig up what you need and be back on track within a few minutes of typing, clicking, and reading. The only thing we need is for people to keep their data online: websites can’t go away, blogs can’t close up, else that knowledge and information goes with it.

I’m quite impressed with how much I’ve gotten done this past week. With everything so new and having to wrap my head around so many things it’d normally take me a few weeks to get done what I’ve accomplished this week. The immediacy of the giant collaborative network that is The Internet is becoming a more awesome thing and powerful tool each day.

Further Android impressions

/ hsoi

Been reading the official Android developer documentation. The Notepad Tutorial is the most complex introductory step-by-step tutorial they offer. Going through it I can say a few things that I find pretty cool, mostly about Eclipse.

  • The “Organize Imports” command is awesome.
  • I like to type things out manually and format code my own way. So that the Eclipse IDE wants to format things its way, wants to code-complete, and keyboard shortcuts aren’t fully the same as true Mac editing? Well… it’s getting on my nerves. But I’m trying to remember that “ok, when I open a brace/bracket/parenthesis, it’ll close it automatically and also indent to the next level”. So I just have to try to stop typing so much.
  • When you get a compiler error, that it attempts to suggest fixes and you can just pick from the list? That’s kinda cool.
  • Bring up a contextual menu in source code, Source, Override/Implement Methods…and then you can just pick inherited methods to override and a template is inserted? That’s cool.
  • I don’t like how not-seemless all the work is. This is certainly where Apple has things down. You see, in the Apple world all parts of the toolchain work together. The language makes things go. To help the language make things go, the library provides a base NSObject that (almost) everything descends from, and also provides design patterns for everyone to follow. These patterns then are implemented by the tools, so things like Interface Builder allow you to just click and connect everything. The entire toolchain is integrated and supports the greater developer paradigm, so things are smooth. But here in this Android world? Not so much. There’s still a lot of manual hooking of things together, from the layout XML to the code to make everything go. But I will say, the trick with the generated “R” class is a pretty slick way to try to blend this all together. I just wish the editing process was a little more smooth.
  • I’m curious why Eclipse is sooooo slow with things like opening files. I mean, I’ve got an 8-core Intel Mac Pro with 10 GB of RAM. There shouldn’t be such pauses just to do simple operations like opening and closing files.

All in all, it seems that Eclipse strives to help you out as much as possible. I like that. Sometimes I wish it wasn’t so helpful, but I reckon that’s probably because I’m not used to it. The real test will be spending a long time in this world then switching back to say Xcode and seeing what I miss and then hate about Xcode lacking. 🙂

I went to the bookstore and got the Pro Android 2 book. Of the various “How to program Android” books out there right now, this seems like it has potential to be the best one, not only in terms of how the book itself is put together, but the breadth and depth of topics covered.

The more I work in this, the cooler it is. Yeah, I also see more of the rough and painful edges, but yeah.. this is neat.

I did realize one thing tho. I don’t like looking at Android. There’s a grace and elegance that Apple brings to everything it does. They care about the design down to the last pixel. Looking at Android GUI? It feels like I’m thrown back to 8-bit Atari games. Not really, but that’s the only analogue I can think of to describe it. It just doesn’t look as graceful nor sexy as iOS or anything Apple does.

Android – next steps

/ hsoi

Now that I’ve gotten some introductory Android programming stuff done, the next step is diving deep into the developer documentation.

Still working my way through it all, but just reading through the Android Application Fundamentals and gosh… what a bunch of neat stuff. Or at least, so it seems here on paper.

How applications aren’t these monolithic things, but instead a collection of components. There is no main(). The notion of Activities, Services, Broadcast Receivers, and Content Providers. That’s pretty neat. Then how those Activities group together in a Task, how components across the system can work together, pushing and popping off the task stack. That level of modularity and integration is pretty cool. It’s like the whole system is a giant plug-in architecture of sorts.

iOS vs. Android – programmer first impressions

/ hsoi

I did my first “Hello World” style Android app yesterday, and while it’s only a first impression I wanted to share my first impressions.

My background is that I’ve been a professional Mac software developer for about 15 years and a hobbiest Mac and Apple developer since I was a wee lad. I used to work at Metrowerks, makers of CodeWarrior, back in the day when CodeWarrior was “the thing” for Mac software development. So I’ve not only used developer tools, I’ve made them. That all said, I don’t have a lot of iOS experience from a developer perspective because I’ve only so much time in a day and just didn’t have time nor a job that required it. But that’s changing and so into the abyss I go. I say this because yes, my initial Android experience is going to be tainted by the world I’m coming from. I’m not saying the new world is bad, just different.

Java

Android uses the Java programming language. I haven’t touched Java in over a decade, and I know the language has evolved. First thing I did was pick up a book on the language. I bought Learn Java for Android Development by Jeff Friesen. The book has NOTHING to do with Android itself, it’s a pure language book. But I choose this book because the book is geared towards Android so it doesn’t waste time talking about matters irrelevant to Android, like AWT. I didn’t give the book a hard-read, nor did I bother with doing much of the exercises because I don’t feel I need it (famous last words?). I’ve used Java in the past, I’ve been programming for quite a while, and the book is geared towards someone who is starting from scratch. So talking about Generics? It’s akin to C++ templates so I just needed to get the details and differences. Container classes? Just give me an overview of what’s there, I don’t need to read 10 pages about all the various methods and what they do (that may come later for reference).

That all said, there’s a lot that’s changed in Java since I last really used it and I think a lot of the changes are good. Being able to “inline” a lot of things, nest classes, anonymous classes… it’s nice to just define your “callback” right there as you go along. It’s nice to have a language that’s more pure OO than C++ (Objective-C is pretty good at being true OO). It’s nice to see the library expanded, and things like Generics added. Yes there’s a lot of syntax I’ll have to get used to, but that’s how it is when you switch from one language you’ve used for years to one you haven’t. I should be alright.

But while the language is fine, the IDE is another story.

Eclipse

Oh…. I don’t like.

You see, every platform does things they way they do it because they believe they have something different and better. Mac OS X is one thing, Windows is another, Linux another… and everyone does their thing differently. Sure most of the core concepts are the same, but little details of interactions and how widgets work and the parts mesh vary. And Java apps seem to like to do things their own way, perhaps with a Windows-bias since many Java developers are Windows-based. Coming from the elegant world of the Mac user experience? Using Eclipse feels bizarre and klunky. I’m sure I’ll get used to it, but it still feels strange and like a step backwards in terms of human-computer interaction and experience.

One thing that really bugs me is I don’t like being forced into a tabbed single-window-only interface. I’m not that into tabbed interfaces, but I have come to appreciate when tabs are good and when they are not — for me. Apple’s really pushed a single-window mode of being on Mac OS X, and for the most part that’s alright. What I find I like is the ability to exist how I want to exist. Sometimes I want two windows because I need to arrange the content as I need to to do my work. Other times I want these “windows” to be grouped together and thus having the content in multiple tabs within the same window makes the most sense. I like options. If Eclipse allows me to escape this tabbed world, I haven’t found it yet.

Tools Install

You want to develop for the Mac? These days it’s pretty much Xcode. You download, you install, and off you go. All the apps you need, compilers, libraries, documentation, everything. It’s simple and rather painless.

To develop for Android? I had Eclipse installed from a prior thing I was working on, but now I had to get another version. So download that. Then I have to download the Android SDK and put that somewhere and tell Eclipse about it. Then I have to actually download and install all the API’s and tools for developing Android apps. Then more configuring. Finally, I can get going. What a pain. I don’t really blame anyone for this because the nature of the beast is so open, requires things from different vendors, and there’s a lot of flexible options. I do think options are good, but I also think there’s something to be said for providing a setup to get new folks started. It’s a high bar of entry, and I can only wonder how a total programming newbie would handle this. If Google could provide a “one click download and install” that gets you going, that’d be awesome. Sure it may provide more than is needed, it may bias towards one product or SDK or something, but get the n00b going, then once they grok the world they can sort things out and streamline later.

Nevertheless, things are going.

First App

A friend sent me this blog posting on writing your first Android app. I figured I’d give it a try before I went through all the Getting Started stuff at the Android Developer website. First, this blog posting was great because it gave better instructions on how to get the tools downloaded, installed, and configured. Thank you for that!

But as I worked through this, it helped me see how spoiled I am in the MacOSX/iOS world, especially with how integrated the developer toolchain is.

Designing the user interface. So, I have to hand-write XML? Holy crap… I thought we were in the 21st century! Oh sure there’s a little tool to work it, but it sounds like no one uses it and it’s very rudimentary. That everyone just prefers to edit the XML by hand. Man, that’s…. unacceptable in this day and age.

Then to hook your GUI into your code, you have to do all this manual labor in code to make it happen. Yes, I’m spoiled by the actions and outlets paradigms in Cocoa, where in my code I can just declare an IBAction or IBOutlet, then in Interface Builder just click and drag to hook everything up. It’s a small thing, but it’s there.

I do like Android Virtual Devices thing, where you can simulate any sort of device. That’s of course necessary, but it seemed to run a little smoother than the iPhone/iPad simulator.

As an aside, I got to learn about a cool prototyping/wireframing tool called balsamiq.  That app is way cool.

From here?

The first impression I’m left with? Android as a technology might be really advanced, but the developer experience is archaic. The toolset just feels really klunky, and I can see how spoiled I am with Apple’s tools.

That said, that’s the toolset and I will work with it. I’m sure I’ll get used to it and come to find things I love and things I hate. I’m still looking forward to delving deeper into the world of Android development. I’ve only begun and I’m sure my impressions will change, but first impressions are important and the impression I’ve been left with is one that desires more. Here’s hoping for the best.

Don’t assume; assert.

/ hsoi

For the love of Knuth…

If you write code that makes assumptions, assert on those assumptions and assert in a manner that the developer stuck with maintaining your code will see them.

Doing so would save much hair loss, and cut down on the number of times the original author of the code gets damned to hell by the maintainer.

Thank you.

Simplicity

/ hsoi / 2 Comments

I am an engineer by trade, and Wife points out that I have an engineer mind.

While I spend much of my time working with complex systems, I understand that simplicity is king. Simplicity is actually quite difficult to achieve because it takes work. You start off doing what you need to do, over time things grow and it will become more complex and kinda messy. You must take the time to stop, step back, and reengineer and rearchitect things to regain that simplicity. Typically this will mean you must discard and cast off.

Antoine de Saint-Exupery said:

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.

Tao Te Ching #48:

In the practice of the Tao,
every day something is dropped.
Less and less do you need to force things,
until finally you arrive at non-action.

Simple is not easy, but it is best.

I’ve seen a few things in the past couple days that reinforce this.

I stumbled across this blog posting on “What is good code?”

Good code is simple. Even complex good code is comprised of simple building blocks. Good code hides or cuts through the complexity in the problem, to provide a simple solution – the sign of a true coding genius is that he makes hard problems look easy, and solves them in such a way that anyone can understand how it was done (after the fact). Simplicity is not really a goal in its own right, though; it’s just that by means of being simple, code is more readable, discoverable, testable, and maintainable, as well as being more likely to be robust, secure and correct! So if you keep your code simple (as simple as possible, but no simpler), it is more likely to be good code – but that is by no means sufficient in and of itself.

And all of this talk of simplicity isn’t just something for the world of engineering…. I think it applies to all things in life, and I think it’d do well to be applied to government.

Witness the mess there is in classifying sensitive information: (h/t Slashdot)

Protecting and classifying sensitive information such as social security numbers shouldn’t be that hard, but perhaps not surprisingly the US government has taken complicating that task to an art form.

It seems that designating, safeguarding, and disseminating such important information involves over 100 unique markings and at least 130 different labeling or handling routines, reflecting a disjointed, inconsistent, and unpredictable system for protecting, sharing, and disclosing sensitive information, according to the watchdogs at the Government Accountability Office.

Read the full article (it’s short) to see just how messy the problem is. This is not simplicity, this is about the furthest thing from simplicity. How does this make life easier?

Then I see this flowchart on Department of Defense acquisitions:

The Integrated Defense Acquisition, Technology, and Logistics Life Cycle Management System -- MY BRAIN HURTS!

Wow. Even the name (The Integrated Defense Acquisition, Technology, and Logistics Life Cycle Management System) is a complex beast.

I truly hope no one considers that to be a simple, streamlined process.

Have you ever noticed, any time the government talks about streamlining or improving their process, they always create some new group to do so? Nothing ever gets shut down or shed or cast off… it’s always grows.

If people are tired at how inefficient government is, at how bloated and slow it is, how complex, how confusing… why aren’t we working to truly simplify things? Why does no one believe in casting off? Why do we call them “law-makers”, as that seems to imply all they can do is make more laws instead of refining or repealing what we already have?

Why don’t we have any politicians that run on a platform of repealing, stripping down, and simplifying? Why is a discussion of “loss of government jobs” considered a bad thing? closing of government agency a bad thing?

Consider how truly simple things are better in life (or at least, consider how those ugly complex things make life difficult). Work towards the ideal.