Technology Sufficiently Advanced

Eclipse Indigo on OS X 10.6.8: Tuning eclipse.ini

2011-10-16T13:01:00.000-07:00

Based on information from a lot of places (on stackoverflow here, here and here; and various other parts of the Internet) I've cobbled together an eclipse.ini that doesn't hose my system. Note that I'm on a 4GB MacBook Pro from early 2011.

-startup
../../../plugins/org.eclipse.equinox.launcher_1.2.0.v20110502.jar
--launcher.library
../../../plugins/org.eclipse.equinox.launcher.cocoa.macosx.x86_64_1.1.100.v20110502
-product
org.eclipse.epp.package.java.product
--launcher.defaultAction
openFile
-showsplash
org.eclipse.platform
--launcher.XXMaxPermSize
384m
--launcher.defaultAction
openFile
-vmargs
-Dosgi.requiredJavaVersion=1.6
-Declipse.p2.unsignedPolicy=allow
-XX:MaxGCPauseMillis=1000
-XX:MaxHeapFreeRatio=70
-XX:+CMSIncrementalPacing
-XX:+UnlockExperimentalVMOptions
-XX:+UseFastAccessorMethods
-XX:+UseCompressedOops
-Dide.gc=true
-XstartOnFirstThread
-Dorg.eclipse.swt.internal.carbon.smallFonts
-XX:MaxPermSize=384m
-Xms512m
-Xmx2048m
-Xdock:icon=../Resources/Eclipse.icns
-XstartOnFirstThread
-Dorg.eclipse.swt.internal.carbon.smallFonts

I'm running the 64-bit Cocoa version of Eclipse. You'll find the eclipse.ini in

Eclipse.app/Contents/MacOS/eclipse.ini

.
I'd also highly recommend turning on "Show heap status" in the "General" preferences section; this shows how much heap space you're using and lets you request garbage collection.

Aside from settings, I've also found that being diligent about keeping only the projects you need open is a big deal.

thefacebook/WHARRGARBL

2011-09-21T12:12:00.000-07:00

I joined thefacebook in early 2005. Since then, new features have been released, always met with a storm of criticism for "changing things." Yet in retrospect, almost all of these features have been widely embraced because they make the site better.

Like Apple, the people at Facebook spend time thinking about their users' problems; they know what their users want better than their users do. The primary difference: Apple has managed to convince their customers this is true, whereas Facebook has not.

Have some Oatmeal.

Snowmageddon 2010

2010-12-27T05:26:00.000-08:00

I woke up this morning around 5am and decided to brave the snow to take some photographs of the aftermath of the blizzard. Despite having given my ankle a mild sprain while walking across the park on Christmas, I was able to trudge through the snow for about an hour.

In my six months in New York, I've learned a lot about how people move around in the city. New Yorkers jaywalk; if they didn't, nobody would ever get anywhere (traffic lights aren't timed for pedestrians). But while walking across the street is normal, walking in the street is not. With the snow mounds covering the sidewalks, the only viable route for pedestrians is to walk alongside motorists on the plowed streets.

On every street you could see evidence of drivers who had attempted to move their vehicles and failed. Cars with their hazard lights on, pulled a few feet off the curb and then left behind a mound of snow. I watched as a limousine driver attempted to pull onto Lexington Avenue, stuck in the pile of snow created by the plows. I spoke to him briefly, offering half in jest to give him a push. He was confident he'd be able to get through if he let the car rest for a minute. He finally dislodged his car after ten or fifteen minutes.

The flickr set:
http://www.flickr.com/photos/55192998@N06/sets/72157625683038786/

Videos from the snow last night:
http://vimeo.com/18196656
http://vimeo.com/18201205
http://vimeo.com/18201358

The Open Internet

2010-12-22T13:21:00.000-08:00

In the wake of the recent FCC action on net neutrality, we're starting to see more mainstream coverage of the issues around the open Internet. But most people don't understand how a failure to guarantee an open Internet directly affects their lives. theopeninter.net provides a simple, visual to-the-point rundown of why we need net neutrality.

While spending time with your family this holiday season, take a few minutes to share the importance of net neutrality with them -- so they won't be paying per holiday Facebook post next year.

Herding Firesheep: Addendum

2010-11-04T18:08:00.000-07:00

Following my previous post I found that out of brevity I'd omitted some information. This serves as an addendum to my previous post. This has been editorialized as little as possible.

The original message sent to the patrons was as follows:

Because you are using Facebook at a Starbucks without encryption, your account has been compromised. I'm just a friendly fellow Starbucks patron who felt you should know about the vulnerability.

You can learn more by searching for "Firesheep". There aren't readily available ways to protect your Facebook account while on a public network, so I'd recommend just staying off it at Starbucks. This exploit also affects Twitter, Amazon.com, Google (not Gmail), and several other services.

Your password has not been compromised; logging out of Facebook is all you need to do.

As for the significance of why leaving one's Facebook account unprotected: a compromised Facebook account doesn't just mean someone can view your photos, likes, wall posts. A compromised Facebook account gives someone access to an identity, to perform social engineering attacks, and to potentially ruin relationships (both out of boredom and for gain). While much of this can be corrected, the time and energy it takes to do so is significant, especially when someone has a large number of friends. Someone sending a fake message to one of your friends may not seem like a big deal, but someone sending a fake message to 500 of them is - especially when that 500 may include colleagues, family, and clients.

As for the legality of my actions: such was not the point of the article. While you're welcome to speculate as to whether or not I'll be thrown in jail, it's irrelevant to the threat that unprotected websites like Facebook and Twitter pose to their users. I'd much rather you channel your energy into spreading the word rather than trolling the comments on my blog wishing for my incarceration.

As for what users can do, the best answer right now is nothing. Stay off unprotected networks when using these websites, or use an application that does not use unprotected authorization cookies (from what I've heard, the Facebook for iPhone app does not). Make sure your home network uses WPA or WPA2 encryption (WEP is trivially crackable). If you use Facebook at work on a wireless connection, verify that the network uses WPA or WPA2 encryption. The threat does not just come from Firesheep, it comes from the lack of protection of the connection. The larger threat is from automated tools that have already existed for years.

I've disabled comments for this post as it is intended as an addendum; if you'd like to leave comments, please do so on the original article.

Herding Firesheep in New York City

2010-10-27T18:50:00.000-07:00

There's been a lot of talk about Firesheep over the last few days. The free Firefox extension collects cookies that have been broadcast over an unprotected WiFi network without using SSL. You turn it on, it collects cookies for Facebook, Twitter, and 24 other sites (by default). Then, you can sidejack the account and gain access under the acquired identity.

This extension isn't shocking. If you're worth your weight as a developer, you've known this flaw has existed for a long time, right? But what about the rest of the world? What about the people who haven't heard about the newly accessible threat through their friends, through Engadget, through Slashdot, or through ABC ProNews7 in Amarillo?

I thought I'd spread the word and help some laymen out after work since there's a large Starbucks near my apartment. I dropped in, bought some unhealthy food, opened my laptop and turned on Firesheep. Less than one minute later, there were five or six identities sitting in the sidebar. Three of them were from Facebook.

This wasn't at all surprising; Firesheep is not magical, and anyone that's been to a Starbucks knows that a lot of people mindlessly refresh Facebook while sipping on their lattes. I thought I'd give it more time, so I listened to some music, talked to a few friends, and most importantly (and difficultly) did not navigate to anything sent over vanilla HTTP (including, of course, Facebook).

Around half an hour later, I'd collected somewhere between 20 and 40 identities. Since Facebook was by far the most prevalent (and contains more personal information than Twitter) I decided to send the users messages from their own accounts to warn them of their accounts' exposure. I drafted a friendly, generic message that stated the location of the Starbucks, what the vulnerability was, and how to avoid it. I sent messages to around 20 people.

I cleared the sidebar, took off my headphones, and waited. I heard one expletive muttered a few feet away, and wondered if my message was the cause. Over the next 15 minutes, I didn't hear anyone talk about what had happened (and folks at Starbucks are usually not ones to keep their conversations private). However, what I did see happen was a sharp decline in the number of identities I was collecting when I restarted Firesheep.

This was relieving -- these people got the message. Hopefully they'll tell their friends, hide their kids, hide their wives. I cleared the sidebar once again, and after another twenty minutes of mindless conversation I saw five familiar names had returned to my herd.

This was somewhat puzzling. Did they receive the first message? I logged into their accounts, and surely enough, they had. One of them was even on Amazon.com, which I had warned about in my first message. I targeted him first: I opened up his Amazon homepage, identified something he had recently looked at, and then sent him a "no, seriously" message on Facebook from his account including the fun fact about his music choices.

I cleared again, waited for ten minutes, and after resuming Firesheep's collection it appeared that he was gone. Yet the other four remained persistent. Perhaps, I thought, they thought the message was automatically generated and randomly targeted (despite mentioning their location within 100 feet). So, one last message was in order.

I drafted a very short message (perhaps the first was too long?) and sent it to the four, once again from their own accounts:

Really wasn't kidding about the insecurity thing. I won't send another message after this -- it's up to you to take your security seriously. You're at the [XYZ Street] Starbucks on an insecure connection, and absolutely anyone here can access your account with the right (free) tool.

Twenty minutes passed, and all four were still actively using Facebook. Again, I considered that they may not have received the second message, but after viewing their accounts it was clear that they had.

This is the most shocking thing about Internet security: not that we are all on a worldwide system held together with duct tape that has appalling security vulnerabilities; not that a freely available tool could collect authentication cookies; and certainly not that there are people unaware of either. What's absolutely incomprehensible is that after someone has been alerted to the danger (from their own account!) that they would casually ignore the warning, and continue about their day.

But, I kept my word and did not send another message. I packed my things, I walked around the store, and recognized several of the people I'd just introduced to their own vulnerability. I included no clues as to my identity, less because of fear of retribution, and more because invasion of privacy is all the more frightening when it is committed by an absolute stranger with no chance of discovering their identity.

On my way home, I considered what the experience meant about our society. No matter how many security measures we provide to the world, there will always be people who leave the door open, even after they've had an intruder. The weakest link in security has been, and always will be, the user's judgement.

Back at my apartment, I began to settle in -- only to realize that throughout the entire night, my fly had been wide open. Just another demonstration: we're all walking around with vulnerabilities we have yet to discover.

UPDATE: I've posted an addendum to this entry containing the first Facebook message, why leaving your Facebook account unprotected is a serious thing, and some guidance for users that aren't sure what to do to avoid the threat.

Parallel Structure: Programming Edition

2010-04-21T15:27:00.000-07:00

I was reflecting on some of the code that I've read over the last two years, and thinking about how unreadable a lot of it was. I couldn't put my finger on the reason until I looked at it in the same way I look at (English) writing.

What Parallel Structure Is

Parallel structure makes writing easy to read. You can read about parallel structure all over teh interwebs, but the gist is that a series of sentences that express similar ideas of equal importance should have the same (parallel) structure. It helps readers tie the sentences together. In the West Wing, Toby Ziegler brushes the topic (although not by name):

Food is cheaper, clothes are cheaper, steel is cheaper, cars are cheaper, phone service is cheaper. You feel me building a rhythm here? That's 'cause I'm a speechwriter and I know how to make a point... It lowers prices, it raises income. You see what I did with 'lowers' and 'raises' there? It's called the science of listener attention. We did repetition, we did floating opposites and now you end with the one that's not like the others. Ready? Free trade stops wars. And that's it. Free trade stops wars!

Parallel structure introduces a rhythm, and breaking that rhythm signals something important. The practice expands beyond writing -- in interior design, accent walls serve the same purpose. Accent walls are typically a single wall in a room with a vibrant color that frames the focal point of the room. They can also be used to delineate a separate space -- for example, painting two inset walls a different color where the dining table is placed to make it feel like a separate room.

And Software

So what about software? How can parallel structure be applied to programming? I found myself writing some simple code today to update a model object from a user interface component. I later scrapped the code for something more object-oriented (just constructing a new Filter and returning it), but I thought it was a great illustration of the issue (the utility functions do exactly what you'd think they'd do):

 Date newStartDate = Util.parseDate(startDate.getText());
 Date newEndDate = Util.parseDate(endDate.getText());
 String newApplication = application.getText();
 boolean updated = false;
 updated |= !Util.equals(newStartDate, filter.getStartDate());
 updated |= !Util.equals(newEndDate, filter.getEndDate());
 updated |= !Util.equals(newApplication, filter.getApplication());
 filter.setStartDate(newStartDate);
 filter.setEndDate(newEndDate);
 filter.setApplication(newApplication);
 return updated;

I think this is pretty easy to understand. The code is too short to be split into separate methods, so it's organized into logical section, each of which contains statements with parallel structure.

This could have been written another way, the likes of which I have seem many times. In the same number of lines, with identical statements, it looks like this:

 boolean updated = false;
 Date newStartDate = Util.parseDate(startDate.getText());
 updated |= !Util.equals(newStartDate, filter.getStartDate());
 filter.setStartDate(newStartDate);
 Date newEndDate = Util.parseDate(endDate.getText());
 updated |= !Util.equals(newEndDate, filter.getEndDate());
 filter.setEndDate(newEndDate);
 String newApplication = application.getText();
 updated |= !Util.equals(newApplication, filter.getApplication());
 filter.setApplication(newApplication);
 return updated;

We can increase line count by inserting some spacing, which makes it a little more readable:

 boolean updated = false;
 
 Date newStartDate = Util.parseDate(startDate.getText());
 updated |= !Util.equals(newStartDate, filter.getStartDate());
 filter.setStartDate(newStartDate);
 
 Date newEndDate = Util.parseDate(endDate.getText());
 updated |= !Util.equals(newEndDate, filter.getEndDate());
 filter.setEndDate(newEndDate);
 
 String newApplication = application.getText();
 updated |= !Util.equals(newApplication, filter.getApplication());
 filter.setApplication(newApplication);
 
 return updated;

I don't like this for several reasons. While you can tell that each chunk performs a similar purpose, the chunks aren't short enough to make an obvious parallel structure. In reading, you can easily pick up on parallel structure when the parallel elements are less than 10 words long. That two 500-word passages are written in the same structure is not as obvious.

It's also not immediately obvious that each corresponding statement is identical. A different statement could be an important functional difference, or it could be a defect.

A Defect

Spot the defect, first in the chunky code:

 boolean updated = false;
 
 Date newStartDate = Util.parseDate(startDate.getText());
 updated |= !Util.equals(newStartDate, filter.getStartDate());
 filter.setStartDate(newStartDate);
 
 Date newEndDate = Util.parseDate(endDate.getText());
 updated &= !Util.equals(newEndDate, filter.getEndDate());
 filter.setEndDate(newEndDate);
 
 String newApplication = application.getText();
 updated |= !Util.equals(newApplication, filter.getApplication());
 filter.setApplication(newApplication);
 
 return updated;

And then in the more streamlined code:

 Date newStartDate = Util.parseDate(startDate.getText());
 Date newEndDate = Util.parseDate(endDate.getText());
 String newApplication = application.getText();
 boolean updated = false;
 updated |= !Util.equals(newStartDate, filter.getStartDate());
 updated &= !Util.equals(newEndDate, filter.getEndDate());
 updated |= !Util.equals(newApplication, filter.getApplication());
 filter.setStartDate(newStartDate);
 filter.setEndDate(newEndDate);
 filter.setApplication(newApplication);
 return updated;

And again, if we add the same newlines to the streamlined code:

 Date newStartDate = Util.parseDate(startDate.getText());
 Date newEndDate = Util.parseDate(endDate.getText());
 String newApplication = application.getText();
 
 boolean updated = false;
 
 updated |= !Util.equals(newStartDate, filter.getStartDate());
 updated &= !Util.equals(newEndDate, filter.getEndDate());
 updated |= !Util.equals(newApplication, filter.getApplication());
 
 filter.setStartDate(newStartDate);
 filter.setEndDate(newEndDate);
 filter.setApplication(newApplication);
 
 return updated;

And Gestalt Psychology

The law of Prägnanz illustrates why it's easier to spot the defect in the second excerpt: similar elements are grouped into a single entity. The line prior to the defect forms a single entity with the lines above and below it, which makes the ampersand stick out. Without this defect, the similarity extends to the first parameter of the utility method invocation.

The takeaway: group similar lines together. If you have to break lines for a control statement, the control statement should probably be in a separate method.

PS: The above is the reason I prefer long line lengths. Lines longer than 80 characters are perfectly reasonable (especially if variables are properly named, i.e. "customerAccountNumber" instead of "a" or "can" or "acct"), and almost every developer uses an IDE or text editor that supports at least 100 columns of text. When a line wraps, you lose the parallelism and it's more difficult to understand code at a glance.