Tiling a Polygon

One of the most challenging problems I came across working on a .NET PDF Annotator and Editor application was to tile a 2-D polygon and also accurately determine the number of tiles that fill the surface of the polygon.  The tiling part was not as much of a challenge as the counting part. The tiled polygon was to be rendered on a PDF document since the application in question is a PDF Annotating and Editing tool. We looked for anything the third party .NET PDF rendering/manipulation API that was used could provide for the tile rendering but there was nothing unfortunately.

So we set out to use C#'s native GDI+ library to render the tiles for the polygon.  After trying out different approaches to accomplish the rendering of the tiles, we discovered the one that would work best. The idea was simple. Every 2-D shape on the drawing surface has a bounding rectangle that encloses the shape. Starting from the top left bounding point of the rectangle, iteratively render a rectangle (tile with whatever length and width) across the X axis until the right most edge of the rectangle and this iteration needs to happen over the Y-axis (not sure if I explained clearly enough .  So now we have rectangular tiles laid out across the bounding rectangle for the polygon. GDI+ gives us a clip method that allows us to clip the rendering surface to a specific graphics path or region. Using the clip method, clip the drawing surface to be the graphics path for just the Polygon so that only tiles within the polygon's graphics path get rendered on the screen. We could apply other transformations to the rendered tiles like offseting, rotation or a gap between each tile.

Coming up with the most efficient way to count the number of tiles (including partial tiles) was a little trickier than rendering the tiles.  It turned out that the ideal approach was to essentially count each tile as it was drawn and checking whether the tile was partially or fully part of the polygon's graphics path/region. So, there is this method Region.IsVisible that lets you test whether a rectangle is partially or fully contained within a graphics region. During the rendering of each rectangular tile, the method was used to check whether the tile was going to be part of the region associated with the polygon and was counted if it was going to be. Even though, this was the most efficient solution for the problem, we did nt see 100% accuracy sometimes when rotation transformation was applied to the tiles. Still havent found an answer to this anomaly.

Related posts:

1. Eyespot – AJAX App for Video Editing
2. LINQ to My Domain
3. How to REALLY do Page Preview in Java with Embedded HTML Rendering

photo credit: B Rosen

I remember my first real grownup and serious web project outside of the university environment. It was 1994 and SSL was a novelty. People were making insane predictions that one day up to $600 million (think Dr. Evil) worth of consumer goods would be sold on the web worldwide. In 2007, just Canadian B2C sales were US$12.9 Billion.

Some folks, especially startups and smaller companies, saw the web as an opportunity to shake up the established order and establish a new sales channel or an entirely new business model. They invested what they could in building the first of what became known as e-commerce sites. Among established players, and some more conservative smaller players, there was initial hostility toward the new medium. When in 1994 I proposed to Ameritech (now part of SBC/AT&T) that they bring their lucrative print yellowpages online, I was run out of Hoffman Estates on a rail.

The con arguments ran as follows:

1. Investing in the web will increase our IT costs and require us to support lots of new and different technologies.
2. It will spoil our existing business model.
3. The platform is unproven. We have a proven client/server (desktop, etc., etc.) solution which is far better than some primitive web site.

These were all valid points. And if the web was just the idea of some crazed developer, then it could have been safely ignored.

But the web was being rapidly adopted by both consumers and businesses, knocking down barriers to entry wherever it went. The network effect was about to slap the entrenched players upside the head.

Now we're seeing much the same thing in the world of mobile, which right now means mostly iPhone but will at some point include more players such as Android and perhaps Blackberry devices. The same objections are being raised towards the iPhone -- more IT costs, spoils our business, unproven/not capable -- and the answer is still the same: if you ignore iPhone/mobile, then the network effect is going to knock you upside the head.

Related posts:

1. Ajax and Browsers: Recapitulating the Early Days of Personal Computers
2. Will Q4 iPhone Sales Surpass Expectations?
3. Apple’s Earnings Call: Enterprise iPhone Adoption Growth

photo credit: suki_fotografiert

A while back I looked at the Vaadin Plugin and tried to make it work with the Multiton PureMVC. Back then I proposed the following code:

 
public static ApplicationFacade getInstance() {
   if (instance == null) {
     // nuke the multiton so we can do the grails recompile
     if (ApplicationFacade.hasCore(CORE)) {
       ApplicationFacade.removeCore(CORE);
     }
     instance = new ApplicationFacade(CORE);
   }
   return instance;
 }
 

A little more noodling and you'll see that doesn't work. In a multi-session environment, each user will need his own core. Furthermore, inactive cores should be harvested, otherwise we will have a memory leak.

A little repair work and we have the following code, which does half the job:

 
public static ApplicationFacade getInstance(HttpSession session) {
   String id = session.getId();
   if (instance == null) {
     // nuke the multiton so we can do the grails recompile
     if (ApplicationFacade.hasCore(CORE + "_" + id)) {
       ApplicationFacade.removeCore(CORE + "_" + id));
     }
     instance = new ApplicationFacade(CORE + "_" + id));
   }
   return instance;
 }
 

We get the session through the Vaadin ApplicationContext object. So, now we get a fresh core per session. But we still have the problem of leaking memory every time a session or Vaadin application is invalidated. Neither PureMVC nor Vaadin have any lifecycle methods to hook into for cleanup. In PureMVC that is understandable, since it isn't really designed for a web application context, but this seems a more serious oversight in Vaadin.

We can hook some PureMVC cleanup by storing the key as a session attribute and using a HttpSessionListener to clean it up. I'll test that out and blog about it in the future.

Related posts:

1. Making Vaadin, PureMVC and Grails Work Together
2. Notification Testing with PureMVC and FlexUnit
3. Griffon and a PureMVC Plugin: Some Initial Thoughts

As January 26th, the rumored date for Apple's rumored tablet unveiling draws near, the hype and anti-hype keeps getting more and more over the top:

Five Ways Apple's Tablet May Change the World

The world doesn't need an Apple tablet, or any other

and the inevitable

3 Reasons A Microsoft-HP Tablet PC Would Trump Apple

If you want to keep up to date on the rumors, Gizmodo has a regularly updated run-down here.

There are a couple of places that have more informed speculation and insightful commentary - I'd recommend these three in particular:

Antacid Tablet by ars technica's John Siracusa:

... There's also the popular notion that Apple has to do something entirely new or totally amazing in order for the tablet to succeed. After all, tablets have been tried before, with dismal results. It seems absurd to some people that Apple can succeed simply by using existing technologies and software techniques in the right combination. And yet that's exactly what Apple has done with all of its most recent hit products—and what I predict Apple will do with the tablet. ...

So how will an Apple tablet distinguish itself without any headline technological marvels? It'll do so by leveraging all of Apple's strategic strengths. Now you're expecting me to say something about tight hardware/software integration, user experience, or "design," but I'm talking about even more obvious factors:

• Customers - Apple has over 100 million credit-card-bearing customer accounts thanks to the success of iTunes.
• Developers - Over 125,000 developers have put over 100,000 iPhone OS applications up for sale on the App Store. Then there are the Mac OS X developers (though of course there's some overlap). Apple's got developers ready and able to come at the tablet from both directions.
• Relationships - Apple has lucrative and successful relationships with the most important content owners in the music and movie businesses.

These are Apple's most important assets when it comes to the tablet, and you can bet your bottom dollar that Apple will lean heavily on them. This, combined with Apple's traditional strength in design and user experience, is what will distinguish Apple's tablet in the market. It will provide an easy way for people to find, purchase, and consume all kinds of media and applications right from the device. It's that simple.

Thoughts on what an Apple tablet should be – or not by Andy Ihnatko

Apple always asks themselves simple and stupid questions like “How will this device be used?” and “Will this be used by human beings with, I mean, arms and hands and fingers?” and stuff like that.

The iPhone UI isn’t a desktop user interface where a pen takes the place of a mouse ... which is the model that previous smartphones followed. It was designed to be held in one hand and tapped with your thumb. Occasionally you’d use the index finger of the right hand to key things in.

You want to try to figure out the UI of the RAT? Go get yourself a comic book, or any other rectangle that measures roughly 10” on the diagonal. Hold it as though you’re reading what’s on the surface.

You see the problem? Your fingers get in the way. Think about how big that surface is, too. That’s a lot of acreage to scan, looking for the right buttons to push.

While you’ve got it in your hands, imagine that it’s a sheet of thin steel. That’s heavy, isn’t it? Hard to hold up for long periods of time.

Think about how a user interface would have to incorporate those observations. Now imagine that you’ve been doing this experiment for four years and not four minutes.

That’s a very long list of observations. If you didn’t come up with a workable solution, don’t worry: I think Apple has.

and

The Tablet by Daring Fireball's John Gruber.

... The way Apple made one device [the iPhone] that did a credible job of all these widely-varying features was by making it a general-purpose computer with minimal specificity in the hardware and maximal specificity in the software. And, now, through the App Store and third-party developers, it does much more: serving as everything from a game player to a medical device.

Do I think The Tablet is an e-reader? A video player? A web browser? A document viewer? It’s not a matter of or but rather and. I say it is all of these things. It’s a computer.

And so in answer to my central question, regarding why buy The Tablet if you already have an iPhone and a MacBook, my best guess is that ultimately, The Tablet is something you’ll buy instead of a MacBook.

Gruber's a bit more gung ho than Ihnatko or Siracusa, but they both make a pretty compelling case that something very interesting is about to happen over the next year.

Related posts:

1. iPad: Instant Reaction to Apple’s Tablet Event
2. iPad: How big is the space between laptops and iPhones?
3. Where the iPad will take over: 15 examples

photo credit: matsuyuki

I've made my fair share of predictions, and this may seem to be a layup, but I think it's a prediction worth making anyway: mobile devices and applications will transform business and every day life in the next decade.

Why does this seem like such a layup? Well, look at the iPhone and the ecosystem of applications and companies springing up around it. Android and Blackberry are trying to jump in on the business and everybody and their brother is cooking up a connected mobile device. And yes, that's obvious. Mobile devices are going to increase in importance in 2010 and if you don't already have an iPhone app cooking to complement your other online channels, you're behind the times.

But if you're just thinking that more iPhone applications are going to be the end of it, you're in for a rude awakening. Businesses have just started consolidating after the disruptive years of the 90's and aught's, with the transformative effects of the web largely digested by the marketplace (the newspaper industry is still thrashing but will soon succumb). A new disruptive decade is dawning that may see the passing or fundamental transformation of industries as varied as telecom, credit card and broadcast television/cable. Prepare to take your business through a roller coaster ride every bit as challenging as the web revolution.

What Will Change First? Telecom.

The introduction of the wifi chips into the iPhone broke the charge-by-minute mold. More and more carriers are moving to a flat rate and hybrid connection types will be standard on all mobile devices within a few years. Bandwidth will be purchased in bulk as it is between Amazon and carriers, leaving the consumer (in this case Kindle users) out of the transaction. Connectivity will be sold by the device vendors, not the telecoms, as a part of their offering. The customer relationship will be with the device vendor (much as you relationship with the iPhone is through Apple, not AT&T).

What will change next, or as a result of this enabling transformation? Lots of things:

1. Larger screens, always on solid-state mobile devices with long battery life, and higher bandwidth means that content distribution is moving away from the airwaves and cable and coming to a handheld device near you. What iTunes did to Tower Record will happen towards the end of the next decade to cable and broadcast. Like my friend who gets most of his content through Netflix and Hulu, they'll be saying "I have a TV, but I never turn it on."
2. Somewhere in the next few years, someone will invent a reliable and secure way to make payments through mobile devices. It will get broad adoption, and after a few hiccups and scares (Remember "Is it really safe to give my credit card information via SSL?"), they'll be acquired by Paypal and we'll be paying for all of our Xmas presents, in stores, with our iPhone Ultras. The banks and credit card companies will fight this, but before too long you'll be getting lines of credit and debit mechanism through your mobile devices. Time to cut up those credit cards, because they'll be useless.
3. Secure mobile devices will enter into every corner of the workplace and cause another productivity boom among those workers who are not tied to the cubicle. Since they use mobile devices in all other aspects of their lives, these will not be expensive new devices with steep learning curves. They will be based on widely existing technology (maybe Android?) and their use as natural to the workers as breathing or browsing Facebook.
4. Flexible, foldable displays will make an entrance late in the decade to make the size of mobile devices irrelevant.

These four fundamental shifts along with the change in the telecom will drive a whole new set of businesses, both products and services. New artforms will spring up, new ways of presenting information, new ways of social and political interaction.

As a Business, Take Nothing for Granted

Those sound like plenty of transformative changes to keep most businesses, large and small, either plotting to take advantage of them or worrying about their future. If you're the sort to embrace change, then there are a few steps you can take to prepare.

1. As a business, don't assume you know what your customers want. Your customers may have selected your product, for example, because it was a safe choice, not because it had the best features. Your competitors (or new, mobile entrant into the market) may have better, more informed customers and may be getting better feedback and developing a better product that will crush you in a few years time. The risk of this happening is greatly elevated when a new technology is destabilizing existing business models.
2. Do user research. The ways in which people are consuming products and services is expanding. Making naive assumptions about your customers will leave you delivering new software that behaves just like your old software, a sure recipe for obsolescence.
3. Invest in User Experience Design (UXD). UXD can help you with context. Why is context important? Because your customers aren't going to be just sitting in a cubicle or at home. They're going to be in stores, shopping, or out on the road, deciding where to stop to eat, or on the sidewalk, trying to find a cool coffee shop. Their context is going to be different as are their goals. The most successful businesses are going to deploy software that understand the importance of context and optimizes how they can achieve their goals in the environment (context) they are in.

Yes, definitely, the bar has been raised to be successful in business. If you're already uncomfortable with your web channels, then this is another headache you're going to have to handle. But if you think of it in the same way that you think of your web presence, you'll miss the boat.

Related posts:

1. 6 Tips for Designing Mobile Interfaces
2. Apple’s Earnings Call: Enterprise iPhone Adoption Growth
3. Single Purpose Devices vs. Flexible Platforms and Functional Cases

For instance, I always have Action Script Language Reference, Wikipedia, some library API site(s), Gmail and a dozen other ones open + the debug version of the app at hand.

So what used to happen when you but a breakpoint in Flex Builder with all these tabs? They would be unavailable and any process happening inside of them could not be relied on. Since not all code runs well on first attempt, if the app crashed while testing ( think 3D, data intensive apps, etc.) the browser and all the tabs went down with it.

My solution so far was to use Firefox as a development browser and Safari ( since I'm Mac based ) as a browser for references and everything else. For crashing resolution, Firefox has a nice "Restore" option but it's not fun waiting for 15 tabs to reload.

So Google Chrome recently came out for Mac. It didn't impress me on Vista so I didn't care much. I guess I was in between of curious and bored so I decided to give it a spin.

What a pleasant surprise to see every tab running in a different process. My workflow feels so much better now that I'm not afraid that a bad line of code is going to take down my whole browser.

I've heard that IE8 also runs tabs as different processes but I'm not crazy about returning to development on Windows. I did try out Chrome on Windows 7 as a result of the Mac test and all the issues I've seen the first time around have been addressed. Kudos to Chrome development team.

Let's not forget to mention all the features that are missing on Google Chrome for Mac, primarily the lack of Bookmark Management, but Google Bookmarks or any online bookmarking service will do for now.

I can not wait to see more development being done on Google Chrome for Mac and it getting out of beta. I will not uninstall Firefox anytime soon but as a Flex developer I give Google Chrome for Mac high scores for beta.

Related posts:

1. Why Chrome OS is the Future of Netbooks
2. How much Excel can we get in Flex?
3. Using Adobe Flex Builder 3 on a Mac

You've probably heard about the finding that in children, shoe sizes and handwriting quality are highly correlated. It would be wrong to conclude, however, that one causes the other. In fact, as children mature, their shoe size increases, as does their cognitive ability and their motor skills. They are all dependent on age.

That may seem obvious when we talk about shoes, but it may be less obvious when talking about sales or marketing figures. It may seem obvious to graph income versus purchases or conversions versus sales leads, but you may be visualizing the sales and marketing equivalents of shoe size and handwriting quality.

I suggest approaching the problem of data visualization in a more open minding fashion, like a scientist. Ask yourselves what questions you are trying to answer, and if you're measuring or collecting the right information in your software system to answer those questions. Only when you have determined these two things will you be able to pick the right way or ways to visualize the correct relationships.

Let me give an example from my own experience. I used to work for an economist named Robert Fogel. His particular area of study was Economic History, or Cliometrics. When I worked with him in the early 90's, his focus was on the economics of morbidity and mortality, i.e. sickness and death. A big part of this study revolved around nutrition. One of the challenges was how best to study nutrition, especially when all that one had in historical records were weight and height.

The key insight, as expressed in Fogel's 1993 Nobel Prize lecture was that:

Height and BMI measure different aspects of malnutrition and health. Height is a net rather than a gross measure of nutrition. Moreover, al- though changes in height during the growing years are sensitive to current levels of nutrition, mean final height reflects the accumulated past nutritional experience of individuals throughout their growing years, including the fetal period. It follows that when final heights are used to explain differences in adult mortality rates, they reveal the effect, not of adult levels of nutrition on adult mortality rates, but of nutritional levels during infan- cy, childhood, and adolescence on adult mortality rates. A weight-for-height index, on the other hand, reflects primarily the current nutritional status. It is also a net measure in the sense that BMI reflects the balance between current intakes and the claims on those intakes.

(BMI stands for Body Mass Index, expressed as kg/m^2. Or weight normalized by height.)

Armed with this insight, Fogel could develop a method of data visualization (dubbed the Waaler Surface) that mapped height and weight versus risks of morbidity and mortality. This method was crucial to expressing many of the concepts and findings of this groundbreaking research.

Without careful thought about the relationships to be analyzed, however, this data visualization method would not have been developed, and discussions and writings about the topic would have been awkward and severely hampered.

So, the next time you are specifying reports and charts for your system, spare some thought on the nature and type of relationships you want to map.

Related posts:

1. Nice List of Data Visualization Tools
2. DUX2007 – Data Visualization
3. 3D Data Visualization in Adobe Air

If we're honest about it, these aren't really "data visualization" tools. They're some decent graphing and charting libraries. Data visualization is more than just pretty pictures. Providing the user with direct manipulations and other interactions is also a key ingredient to making the data understandable to system users. As such, these 28 tools only provide one piece of the puzzle.

Related posts:

1. Information Visualization tools
2. Data visualization and the art of conveying information
3. DUX2007 – Data Visualization

I'm especially eager to use UiBinder to do declarative UI creation. Just specify how your interface should look in XML:

<!-- UserDashboard.ui.xml -->
<ui:UiBinder xmlns:ui='urn:ui:com.google.gwt.uibinder'
    xmlns:g='urn:import:com.google.gwt.user.client.ui'
    xmlns:my='urn:import:com.my.app.widgets' >
 
  <g:HTMLPanel>
    <my:WeatherReport ui:field='weather'/>
    <my:Stocks ui:field='stocks'/>
    <my:CricketScores ui:field='scores' />
  </g:HTMLPanel>
</ui:UiBinder>
 

and write some Java to instantiate it:

public class UserDashboard extends Composite {
  interface MyUiBinder extends UiBinder<Widget, UserDashboard>;
  private static final MyUiBinder uiBinder = GWT.create(MyUiBinder.class);
 
  private final String[] teamNames;
 
  public UserDashboard(String... teamNames) {
    this.teamNames = teamNames;
    initWidget(uiBinder.createAndBindUi(this));
  }
 
  /** Used by MyUiBinder to instantiate CricketScores */
  @UiFactory CricketScores makeCricketScores() { // method name is insignificant
    return new CricketScores(teamNames);
  }
}
 

Obviously there's a little more to it than this. I'll try to post a little howto over the weekend. There's already a few examples out there, but when it comes to a new feature like this, the more explanations, the better.

Related posts:

1. GWT, Gadgets and OpenSocial
2. Released: QxWT-0.8.2-RC1 – GWT Wrapper for qooxdoo
3. GWT and XUL

It's taken them long enough, but they've finally released a wrapper for GWT, named QxWT. Best of all, they have a commercial-friendly open source license. If you're put off by GXT and it's license, you owe yourself a look.

Related posts:

1. QWT: Qooxdoo Web Toolkit
2. GWT Libraries Released – XML, SOAP, Crypto, Amazon, etc.
3. GWT Wrapper for Rialto

Dabble->Scribble has a nice blog entry on including log4j logging in Griffon. My favorite part? One of his goals for logging is to "Filter out the cruft from Groovy's massive stacktraces." Amen.

Related posts:

1. Questions About Griffon
2. Griffon and a PureMVC Plugin: Some Initial Thoughts
3. Griffon Plugin Development: Some Nitty Gritty

Never get involved in a land war in Asia.

.

Also, never get involved in a religious war about statically versus dynamically typed languages. Well, maybe just this once.

Periodically, an angry Javascript developer will let loose and flame GWT as a misbegotten spawn of evil. Then all the GWT developers point and chuckle and move on to developing more cool applications. Every so often, though, someone will make a thoughtful comment about GWT, and then we have a fruitful discussion that helps clarify what GWT is and what it does and doesn't do well.

William Shields has either posted such a thoughtful comment or a very high end version of a flame, entitled Lost in Translation or Why GWT Isn’t the Future of Web Development. It is well worth reading, along with Google's Joel's somewhat heated response.

What I want to take issue with is Shields' statement that "Between Javascript, PHP, Python, Perl, Ruby and other languages over the last decade (and yes some have a history going far earlier than that) have clearly demonstrated that indeed the sky hasn’t fallen with loose and dynamic typing."

I'm very much a right tool for the job kind of guy. I love my Groovy and my Ruby, but I also like C# and Java for some things. So, has the sky fallen? I would say yes.

Over the last decade, I've run a software development company that practices agile development. One crucial aspect of our practice is Test Driven Development (TDD). We strive for a high level of code coverage, typically over 85%.  With this approach we deliver software where the number of bugs post-release converges rapidly toward zero, even with enhancements and new features being added.

Now while TDD is great for all software development projects, it is absolutely essential of projects developed with dynamically typed languages. Where statically typed source code without unit tests is like a toxic wasted dump, dynamically typed source code without unit tests is like a nuclear holocaust. Those types of projects just throw off new bugs like a frat house in summer.

Given that many JavaScript and PHP (and Rails, for that matter) projects are developed without unit tests, either because the practice of TDD wasn't common in the organization, or because dynamically typed languages are often the choice of amateurs and, well, "what's a unit test?"

We often take over code developed by other development shops. Sometimes that code has no tests and the client is predictably upset about the bugginess and fragility of the code. I'm usually calm when we take over a statically typed code base, but I'm extremely nervous when the code base is dynamically typed. That's not religious, that's just pragmatic.

Related posts:

1. Josh Bloch Intro Q&A
2. Remain Static or Go Dynamic?
3. Static Typing and the Paranoid Style of Programming

Related posts:

1. Open Laszlo DHTML Milestone
2. Agile Development for Product Managers: Why Agile Testing Rocks
3. Dojo 0.9 M2 Released

1. A compiler which is a "JavaScript optimizer that compiles web apps down into compact, high-performance JavaScript code. The compiler removes dead code, then rewrites and minimizes what's left so that it will run fast on browsers' JavaScript engines. The compiler also checks syntax, variable references, and types, and warns about other common JavaScript pitfalls. These checks and optimizations help you write apps that are less buggy and easier to maintain. You can use the compiler with Closure Inspector, a Firebug extension that makes debugging the obfuscated code almost as easy as debugging the human-readable source."

   So it compiles JavaScript into JavaScript and makes it behave more like a statically typed language.

2. A library which contains both widgets and datastructures and algorithms. Sort of the standard library that JavaScript was always missing.
3. A templating system you can use to assemble a user interface.

Since this system has been in use at Google to develop real applications over a long period of time, I expect it to be a fairly robust system. In many ways it solves some of the same problems that GWT is trying to solve, but in a different way.

I'll see if I can kick the tires over the weekend and post about it next week. So many cool tools and frameworks, so little time...

Related posts:

1. The Difference Between a Compiler and a Compressor
2. The awesome state of JavaScript development tools
3. Eight Javascript Code Generators

I've been working on a grails app recently that uses the grails App Engine Plugin. Along with the GORM-JPA Plugin, which gives you some  of the usual grails GORM goodness, you can write some reasonably interesting grails apps.

There are still a few flies in the ointment. Some of them are grails issues, and are due to the immature state of the plugins. Those are forgivable and will clearly be addressed given time. Some of them, however, are App Engine Java SDK issues. Those are really more problematic given the 1.2.6 version number on the SDK. f I had to boil it down to it's essentials, then I would say that the SDK doesn't barf in consistent ways. Up until 1.2.5, the SDK in development mode wouldn't even complain if you were doing privileged operations. With 1.2.6 you at least got some complaints. For example, with 1.2.6 you now see the following exception on grails startup:

[java] Unable to use direct char[] access of java.lang.String. Disabling this method.
[java] java.lang.IllegalAccessException: Private fields can not be set on JRE classes.

That's because Groovy is trying to modify the String class. But still, there are any number of things that behave differently in the actual App Engine container than the local environment. One solution is to frequently deploy the app the the App Engine container. That's a pretty expensive step, however, and can't be a part of your development and test cycle. Also, even if something does blow up in the App Engine environment, you don't always get a log message. I've been trying to track down a "404 NOT FOUND" problem for a couple of weeks now that doesn't happen at all in the local SDK environment and leaves no log file traces in the App Engine environment.

I have my fingers crossed that version 1.2.7 of the SDK will solve all of those problems.

Related posts:

1. Grails: Delegating to GORM Persistence in Java
2. Grails and JSONP: How Easy is That?
3. Making Vaadin, PureMVC and Grails Work Together

I should have a full review of it up in a week or two.

Related posts:

1. From the Grassy Knoll: Google Android Undermining Java ME
2. Book Review: Core Animation for Mac OS X and the iPhone
3. ZK on Android

I finally have some small amount of spare time to start working on my Griffon PureMVC plugin. One of the first things to think about is where to we make the marriage between the two frameworks?

Griffon has Models, Views and Controllers, as does PureMVC (actually, it has Commands, Mediators and Proxies, which essentially perform the tasks under MVC). My initial thought is that Griffon's MVC triads really perform the tasks of a complex view, and PureMVC wires these complex views together via it's message bus. So, my thinking is to wrap each MVC triad into a Mediator, with the Mediator mostly talking to the Griffon controller and perhaps the Griffon model.

I'll make some more posts here as my thinking and experimenting evolves.

Related posts:

1. Griffon Plugin Development: Some Nitty Gritty
2. Griffon: Convention over Configuration for the Desktop
3. Questions About Griffon

I have a short list of things that I don't like about GWT. They are:

1. You have to use a special browser to debug in Java. That browser doesn't always behave the way IE or Firefox or Safari does. And you need OS specific distributions which can make it a little tricky to share a project between developers with different OS platforms.
2. GWT apps download as a massive hunk of code. There's no way to dynamically load code as you need it.
3. Building UI's dynamically, through a sort of XUL mechanism is a pain in the ass for non-standard components. Just talk to the Vaadin folks about the hoops they had to jump through.
4. The annoying dependency on SWT for tests.

So, what does 2.0 promise? To resolve these four things, and a few more. Check out the GWT 2.0 Milestone 1 release announcement:

In-Browser Development Mode: Prior to 2.0, GWT hosted mode provided a special-purpose "hosted browser" to debug your GWT code. In 2.0, the web page being debugged is viewed within a regular-old browser. Development mode is supported through the use of a native-code plugin for each browser. In other words, you can use development mode directly from Safari, Firefox, IE, and Chrome.

Code Splitting: Developer-guided code splitting allows you to chunk your GWT code into multiple fragments for faster startup. Imagine having to download a whole movie before being able to watch it. Well, that's what you have to do with most Ajax apps these days -- download the whole thing before using it. With code splitting, you can arrange
to load just the minimum script needed to get the application running and the user interacting, while the rest of the app is downloaded as needed.

Declarative User Interface: GWT's UiBinder now allows you to create user interfaces mostly declaratively. Previously, widgets had to be created and assembled programmatically, requiring lots of code. Now, you can use XML to declare your UI, making the code more readable, easier to maintain, and faster to develop. The Mail sample has been updated to use the new declarative UI.

Bundling of resources (ClientBundle): GWT has shipped with ImageBundles since GWT v1.4, giving developers automatic spriting of images. ClientBundle generalizes this technique, bringing the power of combining and optimizing resources into one download to things like text files, CSS, and XML. This means fewer network round trips, which in turn can decrease application latency -- especially on mobile applications.

Using HtmlUnit for running GWT tests: GWT 2.0 no longer uses SWT or the old mozilla code (on linux) to run GWT tests. Instead, it uses HtmlUnit as the built-in browser. HtmlUnit is 100% Java. This means there is a single GWT distribution for linux, mac, and windows, and debugging GWT Tests in development mode can be done entirely in a Java debugger.

Looks like Xmas has come early. I've been working with the browser plugin for a little bit and it is just a joy to use. One down side, of course, is that Intellij 9.0 will be out of date re: GWT the day it is released.

Related posts:

1. Plugging Some Cool Tools
2. Grails and Google App Engine: Birthing Pains
3. Don’t be lazy, download a good browser

Time to answer some questions about Griffon:

1. What is the size of the jar that gets generated for a Griffon jar?
   If you package it all up ('griffon package'), then a vanilla Griffon jar weighs in at 4.7M. That's mostly the Groovy runtime (4.4M) and the Griffon runtime (204k). If you're concerned about download size for Java Web Start, then you won't want to bundle it as a single jar, but rather let your users download the Groovy and Griffon runtimes once, then your app specific jar as it is updated.
2. Can Griffon apps be distributed via Java Web Start?
   Yes. When you run 'griffon package', you get an executable jar, an applet, a JWS app and a 'zip' that is structured as a directory with bin and lib subdirs and batch and shell files to run the application. In short, most ways that you may want to deploy the application.

There is even an installer plugin that allows you to package your app as an izPack (platform independent), RPM (Linux) or DMG (Mac) distribution. It will also create app (Mac) or exe (via JSmooth) launchers for Mac and Windows. Pretty sweet.

Related posts:

1. Griffon Tutorials: Adding Useful Logging
2. Griffon Plugin Development: Some Nitty Gritty
3. Griffon and a PureMVC Plugin: Some Initial Thoughts

In the past, one of the nice things about web application development versus desktop development has been the proliferation of application development frameworks. Where desktop development pretty much gave you a set of GUI components and a few concepts like event driven programming and MVC, web frameworks, in particular the more recent ones such as Rails and Grails, gave you an application architecture into which you could implement your domain specific logic.

Lots of benefits accrued from this predefined structure, not the least of which was the ability to quickly understand the application based on a shared understanding of how applications using this framework were put together. In my experience of looking at desktop and web applications over the years, the web applications were better and more consistently designed than their desktop counterparts. Similar tries at desktop frameworks just never seemed to gain any traction (recall Scope, an app framework based on the HMVC pattern that died of neglect).

Now along comes Griffon, a desktop application framework modeled on (and sharing an architecture) with Grails. Griffon has a very similar controller, view and model breakdown as Grails, and support for plugins. I'd like to see similar frameworks for .NET and Cocoa (yes, yes, Cocoa has some of it's own framework goodness, but could use some higher level application abstractions to make application development more consistent).

Finally, even Griffon applications, while a vast improvement over bare GUI development, still wrestles with complex, hierarchical interfaces. That's where integrating something like PureMVC with it's message bus can lead to even greater elegance and productivity.

I'm in the process of developing a PureMVC plugin for Griffon. Stay tuned.

Related posts:

1. Griffon and a PureMVC Plugin: Some Initial Thoughts
2. Griffon Tutorials: Adding Useful Logging
3. Questions About Griffon