Okay, look. We both said a lot of things that you are going to regret. But I think we can put our differences behind us. For science… you monster

or

Do you know the biggest lesson I learned from what you did? We’re a lot alike, you and I. You tested me, I tested you. You killed me, I – oh no, wait. I guess I haven’t killed you yet. Well … food for thought

1) Download the SDK – that was easy.

2) Add the plugin to Eclipse – also easy

3) Set up the various platforms in the SDK “system”. This was confusing at first. Eventually I realized that one wants (typically) to go for ‘lowest common denominator’ – so Android API 1.5

4) Find a skeletal app to rework. I was writing a soundboard, so it turned out to be incredibly easy to repurpose.

5) Make my app changes – easy, because of the template.

6) Load the emulator and try out my changes. This took a little while to get right, because I didn’t have the target set up properly in my app.
7) Run the emulator and test my code – straightforward
Create a package-able version, and load it directly onto my phone

9) Use Astro file manager to install the app from the phone itself – easy

10) Verify that the app worked on my phone – easy. surprisingly so.

11) Create a signed package for publishing (this took a little while because the wizard was a little confusing, but not horrible)

12) Sign up as an android developer. This cost me $25, but was very easy.

13) Upload my app. This took a little while because I had to rename it (there was a conflict), create screenshots, etc.

14) Publish.

Within minutes, the app was live on the Android Marketplace.

It is  difficult to sufficiently emphasize how similar those two models are.    Think about it:

Read this fascinating article about Dropbox, and how it succeeded where its competitors did not. It should help you down this path.

find . -name \*.jar -exec jar -tf \{\} \; -print > ../alljars.txt

What this does:

1. find every file in or below this directory with an extension of .jar
2. create a listing of every file in that .jar file
3. outputs that listing, including the name of the originating jar file at the bottom into one big text file:  alljars.txt

You can now search for classes/resources you need in the alljars.txt file – and when you find it, simply scroll down to find the name of the jar file the class you are looking for is in.

http://db.cs.berkeley.edu/jmh/calm-cidr-short.pdf

Big Ball of Mud still seems to be the most popular way to design and architect software.

Just because something is ‘common’ doesn’t make it popular.   Your standard everyday cold is pretty common, but it is not popular.   Traffic jams are common, but I doubt anyone involved in them thinks that they are popular.  Wading through bureaucratic red tape is common, not popular.

Primarily, BBoM happens because cost-benefit analysis is time-consuming and difficult.   If programmers, architects and managers could measure and understand the longer-term cost of short-term poor decision making, we would get better decisions.    Remedy?  There’s no one magic bullet, but I suspect that a focus on code coverage and limited code complexity is a great place to start – I don’t know that I’ve ever seen a BBoM project with high code coverage and low complexity.     This may be correlation and not causation, but I think there’s a legitimate story for how forcing unit testing discipline and simplicity pays dividends in terms of architectural strength.

Alas, apparently, they could not find a way to make money off of it.

Which is unfortunate, because I always thought that it would have been a fabulous corporate knowledge-sharing tool – a “private” Bloglines, within a company, that you could add subscriptions that others could use to stay up on important events and thought-leaders in your industry.   Saving and ranking specific posts so that they would potentially become more widespread – identify competitive threats and potential strategic opportunities.

I realize that this model is not without challenges (“We don’t want our employees visiting the web!”), but I’m sure there would have been some organizations with enough strategic vision to see the opportunity inherent in such “corp-sourcing”.    Enough, I would imagine, that they could have made enough money to keep the public site going.  Alas

Also, I see various mentions in the Blogline obituaries that suggest that the day of the RSS reader is done – that we’re replacing it with social link-sharing like Twitter or Facebook.  As someone who generally produces more of these links than I consume, I am puzzled – RSS Readers allowed me to review a wide assortment of feeds at my leisure – Twitter and Facebook are far more ephemeral and constrained to the strategies I use to follow people and to be followed in return.

I’m working a moderate ($300M) Army program through January

Moderate?  That’s a jaw-droppingly large amount of money, and IMO, it explains a lot of the friction between his perspective and a more classical “agile” perspective – agile projects are (in my experience) 100-1000x less expensive, with a corresponding lack of scrutiny/accountability/oversight from management.  Many of the problems/issues that agile was designed to resolve would never happen on a project that large, because that’s way too much money to be sloshing around without high levels of management accountability.

Anyways, I am endlessly fascinated by all the different ways that people can build things.

1. Difficult to integrate into SEO – I didn’t see this directly (because I am not focused on SEO) but apparently all that javascript makes indexing the pages much, much harder
2. Unit Testing – the design of GWT widgets makes it very difficult to write unit tests using anything other than the “built-in” GWTUnitTest, which isn’t helpful for our situation (we need the output in a particular format for tracking purposes).    So essentially we didn’t unit test our GWT widgets much at all
3. Which means our code coverage was very low, and it requires a lot of “jumping through hoops” to get the code coverage to even modest (40%) levels.
4. Most people can’t seem to get used to the programmatic paradigm – horizontalPanel.add( verticalPanel3 );    It’s very hard to debug programmatic panel creation, and it’s easy to get something wrong, and not realize it until you’ve compiled and built everything.   I know they’ve added some XML-based visual building recently, but unfortunately we’re working with legacy code
5. Compilation time – it seems to take a _long_ time to build all the locals and browser variants, and going in and restricting the list of locals and browsers made it harder to track down bugs

This was a large organization, with a lot of resources and fairly smart people, and GWT just simply defeated them – they could not figure out a way to get it to behave in a way that their organization could absorb.    I’m sure all the GWT experts are sneering at our “pathetic lack of skillz” and that’s fine (whatever!), but for me, I don’t plan on recommending GWT to any of my clients.

One thing that I was surprised by (pleasantly) is the “JSNI” – the way that the GWT allows the user to “drop in” javascript in situations where the GWT widgets just won’t do.

Here’s the first blog post I found about JSNI .  I love the first comment.

JavaScript is king in the browser and GWT is for cowards.

Hee hee.  Go back 20 years or so, and you’d see the exact same argument, only with different names:

Assembly is king in graphics, and C is for cowards

Pretty much the same situation – a certain group of people have made their living from being experts at something cryptic and difficult.  Along comes something (in the older case, DirectX) that attempts to simplify that difficult thing, and those experts begin flinging poo at it.

This was back in 07, of course, I wonder if those people still hate GWT and the leaky abstractions it represents.

There are other uses for Hadoop, but I think this is one of the most strategic.

Let me know  your thoughts!