• KeyRemap4MacBook — awesome way to make sensible keyboard changes.  Recommend the following settings:
• Change Eject Key / Eject to Forward Delete
• Change Fn Key / Fn+letter to Control_L+Letter (note: I use MacOS’s keyboard changes to change Control keys to Command keys)
• Custom Shortcuts / Hold Command+Q to Quit Application
• And my own private.xml file, with Change Cmd+H to Ctrl+H (For Eclipse), and remap Alt-F4 to Command+Q (not that I love windows, but I don’t want quitting to be easy)
• Stay — $15, but worth it if you move between different monitor configurations.
• Airfoil — $25, if you want to use AirPlay with external programs like Pandora or Spotify.
• Jumpcut — clipboard history
• Disk Inventory X — find out where your disk space is going
• Bigger names, all cross-platform: Songbird, Firefox, Chrome, Steam, etc.
• Finally, VirtualBox, so I can use real operating systems when I need them.

• Windows XP: 1..n — You have to hit ctrl-alt-del anyway.  And all keys between CAD and when the prompt shows are lost.
• MacOS X (Snow, Lion): 0..1 — sometimes works, sometimes doesn’t.
• Linux (Ubuntu 6.6 +): 0 keys lost.  Always works just like you want.  You can type your password before your screen powers on.

Fairness

Dr. Danker points out that I’m still looking at the Mac with poorly-tinted glasses.  I apologize for that, I’m trying to be as objective as I can — but I’m still Pat, I guess.

Cutting to the chase

Rather than starting with a tedious blow-by-blow, let’s just jump to the summary: Just as Windows is shackled by its awful technical legacy, MacOS is hamstrung by its legacy UI decisions.  Both products should not be afraid of a complete split from their pasts, but this is unlikely to ever happen.

MacOS has some nice, modern things, like the Dock, Dashboard, and Spotlight, a unix shell, and self-contained applications.  It has some awful nightmares like the menubars, inconsistent installers, and disk images (kinda cool, kinda odd), and exposing the user to at least 3 UI frameworks — Cocoa, Carbon, and X.

Some Detailed Examples

Ever notice Mac’s insane application management scheme?  I, as the user, have to manually close applications, even if said applications have no windows open.  I might have left open five or six applications that are just sitting there, taking up memory.  Now I have to revisit each one just to see if I had any work left in there.  Oddly, some MacOS-supplied apps do this, some don’t.  Consistency FTW.

Same goes for the disk images.  As a programmer I understand what they’re doing, and they are a powerful metaphor.  However, as a user who’s just installing stuff, I have a ton of things on my desktop I don’t understand.

App installers.  If you haven’t noticed the insanity here, you haven’t installed anything yet.

Multiple monitors and the archaic single-menu bar rather sucks.  And heaven forbid you miss your menubar click, as you’ll have to return to your app before you try again.

What is up with the search bar on the help menu?  It definitely doesn’t search that application’s help docs.

“They” told me: MacOS was a rock-solid awesome never-failing always working experience.  I constantly have trouble with resuming, sometimes I can’t even get the login prompt to show, though the mouse cursor moves around.  I’ve had hard lockups, and I’ve had misbehaving software that brings the system to its knees.  Attempting to kill these works eventually, but takes 4-ev-ar to clean up.

One thing that continues to amaze me is how much MacOS fights the keyboard user.  I’ve talked at length about the physical keyboard, but the OS is another layer of frustration.  MacOS provides a ton of customization, but only to a point.  You get a subset of functions that you can turn off, but you can’t reassign or do anything fancy with these.

I think Apple, as often as it is a paragon of keeping the user’s needs in mind, is at the same time a juggernaut that has mutilated its own software market.  For example, try to find an alternate music player for local MP3s.  This ecosystem basically died upon release of iTunes.  You might be able to find some, but they are all 5+ years old, and apparently built for some older version of the UI.  And they are also terrible.

ReSummary

Like I said, MacOS is a decent computer.  It’s not keeping me from doing my work (well, except for the keyboard).  It just isn’t giving me any benefits.  And I’m just not feeling the magic and amazement and simplicity I see when I use Ubuntu.

"Before"

Start of Opening Ceremonies

Now that's a fireball

Lasers and firepuffs

Colored Flames

More lasers, more flames

Greeen

'nuther axplosion

Kaylee and Grandpa

And for your viewing pleasure, a moving picture, starting 10 seconds before the final race.  Here you can see the insane fireballs and what-not.

Overview

Git is a distribute version control system.  The core concept of DVCSs is that there is no central repository, and that every user has a copy of the entire repository locally.  The second part is a simple truth for all DVCSs.  The first part is kind of a lie.  Yes, you can operate with a bunch of independent nodes, and you’ll get nothing done.

Yes, in the end, you’ll have a central repository, or quite possibly multiple central repositories.  But you’ll have something central.  This is where you will deploy from, how you coordinate with teammates, and generally work, just like you did with CVS and SVN.  So don’t let that freak you out.

Powered by the power of the concept of diff

Git is driven entirely by diffs — sets of relative changes (differences) to files, including new and deleted files.  It is trivial to have git create output very similar to the output produced by Unix’s diff command.

This is a powerful metaphor, though.  You’re now freed from worrying about file dates as a dirty marker.  That is, you can make a change, save it, come back a week later, undo it, save it, and suddenly you don’t have a change to commit any longer.  You don’t even have to do any sort of “revert to repository version” action.

These relative changes can be juggled and reorganized in a variety of ways.  You can

• roll back to a certain change — git just undoes the diffs applied.
• push or pull changes to and from other repositories
• collect a bunch of commits and merge them into one commit — git calls that squashing.
• move a bunch of commits between branches — merging or sometimes rebasing (basing your commits on something else — get it?)
• you can stash a bunch of changes to replay later somewhere else — even if they’ve never been committed anywhere.

Day by day

Git is a bit like an onion, it has layers — lots of them.  Specifically, I’m talking about when and where files and changes are tracked.  You’ll come across these divisions fairly frequently, so it is helpful to be familiar with them.

• Untracked files - these are changes to a branch on the local filesystem.  Git is aware of them, but will take no action unless explicitly acted upon.  Note that you can change branches out from underneath these files, and they will remain as local changes — unless it conflicts with a file changed on the branch.
• Staged files - these are changes ready to commit.  Think of these as a changeset, an atomic diff to apply to the branch.  You can build this up over time, gathering all the changes before the commit.   They will all share the same commit message, as well. These files are in your Git Index, a term you may come across from time to time.
• Changes to your local branch - these are committed, finished changes.  They are stored locally, and can even be “uncommitted” if need be.  But these changes are not shared with anyone.  Since no one else knows about these changes, they are still subject to merges and merge conflicts.
• Changes in the shared repository – these are changes made to a branch remotely.  This is where your changes go to live and be safe, just like CVS, SVN.  While you’re doing work at all the other layers, this layer can and likely will change.  I do recommend you sync with this repo as often as practical, and before you do any commits if you can.

Teach Thyself

The Git Community Book is a great resource for more on git and how to use it.  In fact, it almost goes into too much detail on everything, just like Git does.  But it is a great cookbook — search for anything git and you’ll likely have a hit there in the top 10 results.

In a future article, I’ll describe how to use git in practical, no-nonsense terms.

Start

To those that know me or that read my dislike of the mac keyboard, it may be surprising that I don’t really have a beef with the rest of the hardware.  Touchpad, screen, ports — all are pretty solid, and make for a good development machine.

Touchpad

We’ll start with the touchpad, since that is probably the biggest feature here.  (And I do mean biggest — it is enormous!)  The touchpad has no buttons like you would find on your average PC, but it does have a tactile click action.

In software, you can configure the left and right corners to be left and right click, which proves handy for a codger like me… the alternative is a two-finger click, which I just can’t get working reliably.  In fact, multi-touch is all the rage on this thing, supporting up to four (!) finger swipes and things.

The downside is that you can only turn behaviors on and off, you can’t customize them.  If I wanted to swap a couple of the actions, I just can’t.  Another problem is that a common touchpad idiom for me is to have one hand resting on the bottom left corner and clicking (selecting checkboxes, say) and the other moving the cursor (selecting many rows of checkboxes, say).  Something screws up frequently in this case (maybe hardware, maybe software) and causes the clicks to either misfire or perform an alternate event.

Now, I hate touchpads.  They or overly sensitive, I touch them while I’m typing, and I have to move my fingers off the keyboard to do any mousing.  Trackpoint is just better tech for developers.  Still, this mac touchpad is pretty good as touchpads go — and they’re far and away the majority of pointing devices for laptops, so you don’t have much choice.

Screen

Screen is bright, high-res, and has a very nice auto-dimming feature.  I actually wish it would go further automatically, but it is quite acceptable.

I’ll talk about multi-monitor along with suspend on a future I’m on a Mac segment.

Ports & Thingies

The Mac has a nice magnetic charging port, easy to remove and replace.  In theory, it will pull out before the laptop pulls down, but I’ve still managed to dump the laptop because of the cord.

Two USB ports.  Not enough.  I’m not a fan of wireless mouses and keyboards, which is what Apple is pushing folks toward.

DisplayPort.  Not bad, slightly annoying that there’s no straight VGA, but in an all-Apple shop, who cares?

SD slot.  Sadly, the SD card sticks out even when put in fully.  I can’t leave a big card in there to store my stuff and keep it separate.

Power monitor thingy.  This is a series of green LEDs along the left side, and a unlabeled button.  There was no information on what this was, I had to go online to find out.  Once I did, though, it’s a nice battery gauge.

Value

It’s hard to put a dollar amount here, but I would have to say that the things this MacBook have lend themselves to a good developer machine.  I would not pick lesser specs in looking at any brand full-size laptop, though I’m still tempted by netbooks for light dev.  So, based on that, those pieces are worth more than a $250 netbook.  How much more?  Hard to say, we’ll have have to keep digging into the Mac.

Level Ground

First, where I was coming from:  I came in as a long-time Windows user, and a mid-time Ubuntu user.  I did my best to have an open mind, recognizing that I’d have a big adjustment.  My coworkers raved about multi-monitor handling, closing and opening the lid for instant on, and a top-notch keyboard and touchpad.

Keyboard

The keyboard hardware is pretty well-constructed, and looks quite easy to clean.  Keys are full-size or nearly so.  It is surprisingly austere, with what I’d bet is the smallest key-count in the laptop industry.  Fits in with the look, though, and leaves ample space for speakers and the touchpad.

I was cautioned to use the command key in place of just about every control-key combination I was used to.  Imagine my surprise when I found there was still a control key on the mac! And that not all of my key combinations carried over.  Sure, cut-copy-paste moved from ctrl-xcv to command-xcv, but IDE staples like ctrl-space (or my other eclipse buddies, ctrl-h search or ctrl-q last edit) sure don’t: they’re still on the control key.

In fact, the Mac keyboard manages to have five different shiftkeys on this already limited keyboard:  shift, fn, control, option (alt), and command.  That’s two more shiftkeys than a DOS/Unix keyboard and one more than a Windows keyboard.  Add in the duplicates from the other side along with caps lock and you have a whopping nine shiftkeys on here.

Really?  You kept caps lock, which has no earthly (well, computerly) use, but couldn’t find the need for a del key?  There is a key that I can only assume ejects the disc, but no home or end keys?  Honestly, the lack of those three keys would stop me dead from considering this a programmer’s paradise.

In software, some of the pains can be eased.  A person can disable or re-purpose the caps lock key.  The function keys can be made function keys without shifting.  Command-space can be removed as a system function and given back to applications.  IDEs, too, are extra customizable to fix a lot of things, like home/end behavior.

There is no good way to remap the keyboard though.  There’s a lot of documentation out there on how to do it, but it seems like Apple is so quick to change UI frameworks that a lot of the documentation out there is incorrect.  Also, programs can simply opt to ignore the remappings if they like, making global configuration… difficult.  Home and end are a frequent target of such remappings.  I can’t get them to work yet, but I’m still following some leads.  They have inexplicably been neutered to only move the viewport, not the cursor, and much work has been done in the community to reverse this.

Thankfully, one can plug in a USB keyboard of any stripe into the mac, and it will start working with minimal configuration.  Better have a full 104-key, though, since the command key (windows key) is absolutely required.  It and the context-menu key were completely optional under windows or unix.  Anyway, it makes things a little bit better at the risk of getting your fingers used to yet another key mapping.

Value

The value of a mac to a developer based on its keyboard alone: $0.  Yep.  Don’t buy it to develop on.  Don’t worry, the mac has a lot of other features, I recognize that.  But this keyboard has no place on a developer’s desk.

My last post was a bit terse, so I thought I’d spruce things up a bit.  With real words, anyway.  I’ve started to settle in a bit.  I rode the Muni subway train home all by myself.  I squashed 1.75 software bugs today, too, a new high in my three-day career.

What’s Square like?  A little surreal, for a Midwestern boy, but that may be a bit of San Francisco showing.  A day begins with a silent office, just like anywhere else.  Over the next two to three hours, people filter in slowly.  At some point breakfast shows up.  (I had bagels and lox today.  Or, some kind of fish.  Another day I had something made out of walnuts and lingonberries.)  All the while, folks are working through their tasks.  There is a lot to do for a product with so much focus.

Lunch arrives at around 11:30, 11:45, or so, and often folks will gather in clumps and take a break.  Today we had a guest speaker (Abdur Chowdhury) from Twitter come in and give some perspective on how abusers think and work.  A cool part of the day was when Jack Dorsey gave a quick shout of “Hey, Square!” to announce the presentation.  The room went silent.  He’s trained us well.

It’s a pretty good place to be a developer.  If you set aside the noise, by will or by headphone, you can concentrate on your task and get a lot done.  Meetings are short and direct, more often than not only involving two or three folks for a minute.  Longer tasks may involve two people from different teams pairing up to solve a problem.

I’m also glad to be back in a strong code review regime.  Every piece of code is reviewed and approved.  This may be while pairing, or by working on an issue branch and sending out to the team for a look.  Very nice.  A good way to learn the standards and conventions, and a whole lot of git.

I’m slowly learning the ropes on the mac, finding things, turning things on or off, figuring out the keyboard, etc.  But that’s another post for another day.  I brought along another Dresden Files novel…

I love apple.  You?  Apple very Square, yet not square!  Tasty, and not tasty.

And so on.  Here are some very quick impressions from almost two days.

• Square
  • Fun, fast-paced.
  • Cramped in the current SF office, moving soon.
  • Growing very fast.
  • Very awesome food.
• Macbook
  • (I’ll have to do a detailed post on this…)
  • Missing lots of keys
  • Unintelligible key combo hints in menu
  • Edges are a bit sharp
  • OS is so-so, very stuck on WIMP,I’m surprised there’s not more innovation here
  • Touchpad is enormous.  And borderline non-functional.
  • I’ve got Ubuntu in a VirtualBox and I’m loving it.
• Intellij Idea
  • In one singular case (extract method), it actually seemed smarter than Eclipse.
  • The rest, surprisingly so-so.
  • Missing flyovers of, well, everything.  Sometimes a man likes to hover without touching anything.
  • Wildly misleading web documents for Mac users.
  • Manages to have more property pages than Eclipse.
  • Is getting replaced by Eclipse soon, perhaps this evening.

First, a quick note:  Yes, I still use Firefox as my default browser.  It works, it is extensible, and I’ve never had performance problems with it.  Yes, Chrome is out there, but every time I’ve tried it, it is broken in various ways (spellchecking, for one) and the UI decisions in it are perplexing.

And to my dearly departed extensions:  you may still be installed, but you got left behind and I can’t use you:

• Google Notebook
• InstantAction Game Launcher
• Quick Preference Button
• Reveal
• TagSifter
• UrlParams
• WebDAV Launcher

Maven 102: Advanced Basics

Alternate title:  What you need to do to be a good Maven citizen

Java module layout

Here is the default layout for a java/jar maven module.  You can reconfigure source and output directories, but you may not want to, as I’ll discuss in a second.

source/input directories:

src/main/java
src/main/resources
src/test/java
src/test/resources

output directories:

target
target/classes
target/test-classes

Build Flow

A general flow for Maven in such a project would be to:

1. compile src/main/java to target/classes
2. copy src/main/resources to target/classes
3. compile src/test/java to target/test-classes
4. copy src/test/resources to target/test-classes
5. run unit tests, output to target/surefire-reports
6. build jar, source jar, and test jars, place in target

Again, you can change much of this, but with Maven, the more you fight with it, the more you will have to fight with it.  It kind of snowballs and will cause annoyances down the line, during releases and documentation and site generation and such.

Repositories

It is not terrible to set up a repository, but the holy grail (for the users, anyway) is to get your libraries uploaded to Maven Central — this will make the process quite seamless for adding a new compiler to a project because access to Maven Central is basically required for Maven operation.

Custom Language Compilation

Another important task for easy maven integration is compilation.  This will generally require a special maven plugin that can essentially execute  the custom language compiler and conform to something similar to the input and output directories above.  This is not too tricky, especially if there is a java entry point to do the work.

Modularity

Related to this is a topic of modularity:  how do you break up a project?  How do you resolve circular references across multiple langugaes? For example, you will generally get yourself into trouble if you have:

src/main/java
src/main/netrexx
src/main/javafx

all in the same module, and are trying to compile them all at once.  Unless you have a single compiler that can process all your source at once, this won’t work.  You will be far happier to make multiple modules, use maven to describe the dependencies, and do one language at a time.

Swing, James Bond, interface design, Dresden, an Elizibethan England children’s novel, and more — it’s all good.

We have lots of technologies and practices for remote communication.  Some examples from Java: RPC, home-grown sockets, serialization, RMI, CORBA, XML, REST, DTOs, SOAP, and many more.

What’s the one thing consistent about all of those?  99% of the time, I DON’T CARE! I want to be able to send data to and from a server quickly and consistently.  How the data gets de-rezzed and rezzed in the meantime matters to the end product only a tiny bit.  (sorry, only good video I could find, watch :10 through :45 for what I mean — and hope you like Depeche Mode)

These are really cool technologies, and fascinating to dive into for their own sake.  But when I’m trying to deliver software, I don’t want to worship at a particular altar, it just doesn’t matter.  You can typically accomplish any requirements using any of the technologies, but we so often just start waving techs around as a panacea instead of looking closely at the problem.

Example: We just had a client-server app using RMI with Spring Remoting‘s HttpInvoker.  Were we having troubles with too much data being sent from the server, and being tied to the same version of domain objects on client and server, having trouble with releasing.  (A Detailed analysis here, from a former architect on the team.)  We solved this by switching to RESTful web services all over.  We have specific data being sent down, and no longer depend upon the same module for domain objects.

Now, take a look at the problem and the solution.  We weren’t having a problem of how we sent the data over, we were having a problem of what we were sending.  We could have fixed that in place, using RMI, using a common module, with a couple of tweaks (managing serialization and not releasing domain, client, and server simultaneously).  Instead, we spent several man-months (I might dare to say close to a year of time) converting our modules, dealing with any RESTEasy quirks, and arguing over URIs.  And now we have 2-3 extra copies of objects in client, server, and web modules.

In the end, things are improved, and these problems are solved.  In fact, following REST patterns basically forced us to confront the problems.  I am glad we are where we are, we’ve gone to something more text- and test-friendly, all with just a browser.  But it wasn’t REST that fixed our problems — we did.

Documentation and Tutorials

What is Android? — Quick start on architecture .

Application Fundamentals — Terminology and Components

Hello, World tutorial — very basic tutorial

Notepad tutorial — nice tutorial with “problems” to work though, as well as a clear goal.  Demonstrates different parts of an app’s lifecycle.

Development Set-Up

You’ll have to go through several steps to get a fully working development environment.  Start with the Android SDK.  Download to somewhere reasonable, then cd into {android’s home}/tools and run android.  This brings up the SDK/AVD manager, which can pull down samples, documentation, and runtime environments for the different Android versions.  It also is where you set up and launch the device emulators.

Get the Eclipse plug-in for Android next, if you like that sort of thing.  Be sure to configure the SDK location in your preferences.  Note that you can launch the SDK/AVD manager right out of Eclipse, if you like.  If you don’t want to use the plug in, be sure to check the documentation for the command-line tools, which can do many (if not all) of the Eclipse plugin’s functions.

There’s a little agile in there, relating to software design minimalism.  That’s not what I’m getting at.  Whether you are developing something new, or fixing something broken, deliver the very least you must for the desired outcome.

I did not say to do the least amount of work required, I said deliver the very least required; go quickly and completely in the direction you must move.  Destroy that bug, hack that web page, do something terrible and glorious.  After getting it working, though, take that next step, and wash all the mud off what you just did.  That is, minimize the actual changes you’re about to apply.  Make sure every change makes sense and is required.  Don’t lump another change or some code reformatting in just for “because it needs to be done eventually”.  Focus on only what you are doing.

It is a massive accomplishment to delete code from a working system and still have a working system.  It is thrilling, and you’ve saved yourself and “the next guy” a lot of trouble in the future.  This applies whether you are fixing a bug or making something completely new.

A quick search revealed several hacky things, but when I read Rakesh Menon’s Always On Top post to the end, I found the tidbit I needed:  java.awt.Frame.getFrames().  It’s a static method that lists all AWT frames in use by the system.  So, for as long as JavaFX uses AWT/Swing (not too much longer, apparently), we can use that.  Here’s the code to get your Stage as a Frame, all above-board.  What you do with it is up to you.

function getFrame(frameName:String):java.awt.Frame {
    var frames = java.awt.Frame.getFrames();
    for(frame in frames) {
        if (frameName == frame.getTitle()) {
            return frame
        }
    }
    return null;
}

I’ve spent a lot of time on the boxes, and unfortunately, the time I spent fixing seems to have eclipsed the time I spent playing.

The thing I’ve found most fascinating about the process is that, while buggy, the 360 hardware is quite resilient.  With enough twiddling of screws, I can get a box up and running quite consistently.

The Company was pleased with our performance last year.  So they went against everything we’ve been teaching our kids, and gave us candy pills.

That’s Jelly beans on the left, mints on the right.  Or so I hope.

One bad thing about Buzz: Those replies are on the Buzz server, not here.

I’ll try to scale back the user requirements for posting, as I have gotten complaints about that.  But if spam gets too high, I’ll have to turn it back on.