Uncategorized

I’ve been working through the design course at Hack Design.  I’m about a month behind and decided to try to catch up a bit.  I’m currently working through the whitespace lesson and stumbled across the answer to a vexing issue I’d noticed in some of the websites I’ve been working on.  I’m a relative novice when it comes to CSS and so many of you out there may have already known the answer but it was news to me.

In this article on Scale & Rhythm, Iain Lamb talks about how he adds vertical space between the text and heading blocks on a page.  In the article he points out that he adds padding to get the spacing desired.  He then goes on to say:

At this point, you might be asking: “Why set subhead padding rather than margin?” The answer: vertical margin collapses between two block elements.

That little bit right there stuck with me.  I had never known that and had never come across that little tidbit in my reading about CSS margins and padding.  I had run into this problem of the vertical space collapsing and had never been able to figure out why.  Now I know.

And just so I wouldn’t forget, I jumped over here and recorded it so I could find it later.  Now I need to go back and finish the article.

This post originally appeared on my old Programming Space blog.

When you’ve been working primarily in one environment for nearly two decades, switching to a new one is never painless.

This is the fifth of several articles about my  journey developing an application for NASA’s Fermi Gamma-ray Space Telescope mission.  Earlier articles can be found here:

• My First Mobile App
• Designing the Mobile App
• Building a Prototype
• Going Non-Native

Let me say right from the beginning that I have nothing against OS X.  In fact, there are many nice things about the operating system and it definitely looks nice.  It’s just that I’ve been using some form of Linux (mostly RedHat and it’s derivatives) since 1997 and was using VAX and Solaris before that.  That was for school and work.  At home I run Linux and Windows.  I’ve never owned a Macintosh computer although I’ve occasionally used one here and there through the years.

I knew when I started developing the mobile app, I would eventually find myself on a Mac for development work because of Apple’s restriction that iOS apps can only developed on OS X.  And I knew there were going to be adjustments to be made.  Here are the ones I ran into that caused me the most grief.

Focus follows mouse

The first was the lack of “focus follows mouse” behavior on OS X.  I’ve spent the last 15 years with my windows set up so that when I move the mouse, the window it is over has focus and I can immediately start typing.  Many times I’ll have multiple terminal windows open (sometimes with just a line or two showing) and slide the mouse from window to window and launch programs.

No longer having that as an option definitely caused me several false starts and a bunch of retyping.  It wasn’t so much of an issue for the mobile development and that was mostly being done in a single IDE plus the emulators, but for my other Mac project, which involved a lot of building and compiling and running tools in the terminal windows, it was definitely causing a hassle.

I can understand completely why OS X doesn’t have this as an option.  The windowing system design with the menu bar always at the top of the screen and not attached to the individual windows definitely makes the idea of focus follows mouse undesirable.  It’s just something I’m used to that I miss on the Mac.

Command vs Control Key and Muscle Memory

I think of all the adjustments this one has caused me the most grief.  My hands have been trained, over the past two decades, to know exactly where the Control Key is located for all my keyboard shortcuts and the spacing between that key and the other keys in the command.  All of those same short cuts, on a Mac, use the command key which is one key over and which I still continue to miss for the first hour or two working on the Mac unless I make a conscious effort.  Eventually, I remember that I’m on a Mac and hit the right key, but in the mean time, since my IDE responds differently to Control-C versus Command-C for example, I’m having to hit a lot of extra key strokes to recover form my mistake.

Middle Mouse Button ≠ Paste

This one I use extensively and it’s absence drives me batty.  Instead of doing this:

• highlight selection
• move mouse to target window
• click the middle button

I have to do the following:

• highlight selection
• Command- (not Control-) C to copy
• move to the new window
• click to activate the window (remember, no focus follows mouse)
• Command- (again not Control-) V to paste.

In my Linux windowing environment, this works everywhere, no questions asked.  In fact, I can’t think of a single place where I’ve not been able to use it.

On the Mac, it does work (sort of) in the terminal windows.  But in the Titanium IDE it doesn’t work at all.  Maybe it works in other places but I don’t use much else right now and where I do spend my time, it doesn’t work.

In the terminal windows, it works like on Linux but with one exception.  When you middle click, it doesn’t count that as clicking to activate the window.  A lot of times I’m pasting in a command and I then want to hit Enter and have it execute.  On the Mac, the Enter key keystroke is captured by the window you copied from, not the one you just middle clicked in.  You have to middle click and then left click to activate the window you just pasted to.  Maybe Linux does the same with click to focus window behavior but with focus follows mouse enabled, the window I’m in is the active one so it’s not an issue.

Fuzzy Screen

I’ve seen flame wars and huge discussions on the font rendering engine on the Mac vs. Windows vs. Linux and I don’t intend to reignite those, but for me, the Mac screen is fuzzy.  I should say that I’m using an external 24″ 1920×1200 monitor on the Mac (it’s an HP LA2405wg)  and it is being driven by the Mac at it’s native resolution (the Mac is a MacBook with a 1440×900 LCD screen that is just way too small for a guy that uses dual 1920×1200 screens on all his other systems).  I get used to it after a bit but whenever I have to be switching back and forth between systems, its definitely an irritant.

Slow Response

I don’t think this really has anything to do with the fact that the computer is a Mac, per se, other than the fact that the machine has an old Core 2 Duo processor where my other systems are a Intel i7 and an AMD Phenom which are both quad-core and much faster.  I’m running Mountain Lion on a system that originally shipped with Leopard and I can feel it.  Luckily, this is soon to be rectified and I’m getting a new MacBook in a month or two with a faster processor and more RAM.

The other area of slow response is when I do switch between systems.  I have all my computers hooked up to a pair of monitors, keyboard, and mouse via a KVM switch.  For some reason the Mac has issues with the switch.  Many times it doesn’t connect the keyboard and mouse and sometimes just doesn’t grab the keyboard.  It also doesn’t seem to respond very well to the video switch when the screen saver is on.  Again, I think these are mainly issues of the old hardware and are only an issue when I switch to the Mac for the first time any given day.

Final Thoughts

Overall, the experience of working on the Mac has been fine.  I don’t have adapters to do the dual screen setup like I do with my other computers (only one video out on the MacBook) but that typically isn’t an issue since my work on the Mac is fairly focused.

Would I ever switch to a Mac as my primary system?  Probably not, although it’s not out of the question.  If I was doing mobile development full time and had to target iOS, then I might just out of necessity.  But while that’s only a side project, I think I’ll stick with what I’ve been using longer and am more familiar with.

I think the biggest thing I learned by starting to do development on the Mac is how ingrained some habits are and what I took for granted in my usual environment.  It has helped me to realize what is core to my workflow and what is extras provided by the environment I’m working on.

This post originally appeared on my old Programming Space blog.

This is the second of several articles about the journey of developing a mobile application for the Fermi Gamma-ray Space Telescope mission.  Part one was entitled My First Mobile App.

The idea for the application came about due to a request we had from a couple of scientists at the American Astronomical Society meeting in January 2011.  They asked if we had a mobile application that would allow easy access to some of the public data that we were already releasing on the mission website but which would be nice to be able to quickly access on their phones.

At the time we didn’t have such an app or plans to create one so the answer we had to give was no.  However, the requests started us thinking about what it would take to create such an application.

While at the meeting I sat down with one of the mission scientists and she and I went over what such an application should provide, both in terms of functionality and data.  Over the course of a couple hours we worked out the initial design of the app.   This was by no means a continuous process as we both were on duty staffing the mission booth and answering questions about the mission to those who stopped by and so were continuously being distracted from the design process to talk with others about the Fermi mission.

However, out of that process came a fairly straightforward design of what the application should do.  In all, the final design was barely over one page of hand written (by me) notes that included the basic functionality of the the app, the various user interactions it should support, and basic sketched out screens for the various parts of the app.

The initial design we came up with in those few hours at the AAS meeting has served remarkably well to guide the development of the application through its initial release.  Although I should say that the application is fairly simple.  It is serving up basic plotting data and then a lot of textual data and as such didn’t need a complicated design.  Even so, having the design provided good guidance throughout the later development process and kept me on track of what to do and what to leave out.

One of the best things you can do when designing any software, is sit down with potential users and find out how they expect the app to function.  While I knew this already, the process of designing this application reminded me of that truth.  Working with the scientist on the design was very helpful.  While I have a Ph.D. in Astronomy myself, we were working with data that I didn’t use and had no experience with.  She was someone who would actually be using the application and the data it provided and so was invaluable in providing insight into how the app should behave and how the data should be presented.

This post originally appeared on my old Programming Space blog.

I’ll admit I’m a big fan of Jeff Attwood and Joel Spolsky’s family of question and answer sites.  I was an early, although not strongly active, user (#116) of their original StackOverflow site and have at least registered with many of the other sites that have come out as part of the StackExchange network of sites.  I even proposed a site (Role-playing) that is currently in public beta.

Anyway, this short post is to announce a new StackExchange site that I’m really excited about, namely the Astronomy StackExchange. This is a great site where you can get answers to any questions you have about astronomy.  But to make it really great we need more people participating on the site, both asking questions and answering them.

So if you have an interest in astronomy jump over and check it out.

This post originally appeared on my old Programming Space blog.

If you haven’t seen it yet, check out the March 15 Astronomy Picture of the Day.  Its actually a movie this time and not a picture.  Part of of an upcoming IMAX movie called Outside In, the video clip is a flyby of some of Saturn’s moons and a pass through the ring system.  The thing is, there is not a scrap of CGI or computer animation in the entire clip.  It is all real images and data take by NASA’s Cassini spacecraft that has been exploring the Saturn system since 2004.  (You can find out more about the mission and science at the link above and also at the JPL Cassini site.)

So if you haven’t watched the video yet, go ahead and jump over and watch it.  It’s only 2.5 mintues long.  I’ll wait.

…

Welcome back.

Watching this video reminded me of all the nights I’ve spent doing public outreach with small to moderate sized telescopes (in the 4 to 14 inch diameter range).  Scott Hanselman’s (@shanseman) tweet yesterday evening (“Unbelivable when ACTUAL VIDEO OF SATURN looks like CGI.”) was a perfect capture of all the many comments I’d hear from people who would look at Saturn for the first time through the the telescope.

“That’s not real.”

“Is that a picture?”

“What are we really looking at?”

“Is that really Saturn?”

All said in tones of either amazment or incredulity.  And we’d patiently answer that yes it was Saturn and no, that’s not an image, it’s the real thing.  And people would always go away with a sense of wonder and amazement.  Showing Saturn has always been one of my favorite targets on nights like that because it really is a wonderful sight.

Jupiter is neat, you can see the banding from the storm clouds and if the air is still and you’ve got a good telescope (say 8 inches or better), you can see the Red Spot if it is facing towards you.  Plus you have the Gallilean sattelites that are visible as well.

But there is just something special about Saturn and it’s rings that captures the public’s imagination.  With a good telescope you can see the rings sharply defined around the planet and even see the Cassini division (named after the astronomer who first discovered it), the large gap in the rings that is prominent on any image of the planet.  It’s always a crowd pleaser.

That’s one of the wonderful things about astronomy, the images and views can be quite breathtaking and it’s fun to share that with others.  And it’s funny, that despite being spoiled by all the beautiful full color images produced by NASA, the ESO, and other agencies, the simple images available through a moderate sized telescope (which are mostly black and white since there usually isn’t enough light to trigger the color sensors in your eyes), always elicit amazed responses from those viewing them.  It’s still pretty amazing what is visible to the Mark I eyeball with just a bit of glass to assist.

So if you want to sample the wonders of the universe first hand, check out your local planetarium, univeristy astronomy department, or astronomy club and find out when their next public viewing session will be.  There are bound to be many people willing to share the amazing sights and take you on a guided tour of the night sky.  And if you want to see Saturn, it’s rising late right now (~10-11pm) but will be up sooner and sooner in the coming months.

This post originally appeared on my old Programming Space blog.