December 16, 2011

This Blog is Moving

This blog is moving, or more specifically has moved, and split up. I've opened up two posterous spaces for my posts, and will be starting a special purpose blog in January on blogspot.com.
  • "...and they shall know me by my speling errors" has moved to http://shemnon.posterous.com/ [RSS]. This is my random stuff blog.
  • The blog for insubstantial has moved to http://insubstantial.posterous.com/ [RSS]. Don't expect much except quarterly release anouncements.
  • My crazy idea is going to be at http://12fizz4buzz.blogspot.com [Atom]. I intend to post a FizzBuzz solution twice a week for about 50 weeks starting in January of 2012. I have a point to make, but first I have to build a base. In February or March I am also looking at running a kindle giveaway, but first I have to set the tone.

Also, I've written a silly little e-book that is available on Kindle. Emphasis on silly and little. The eBook costs US$0.99 and the only reason it costs that much is because Amazon won't let me charge any less. Some candy bars cost more and some are even more satisfying (particularly the ones from Europe with a rich chocolaty taste and a smooth caramel filling). It is what it is, and if I find the time to write more I may make a 5 or 15 chapter version, but this constitutes the minimum viable product.

July 3, 2011

Insubstantial 6.3 Release

Since this is a long weekend in the US I am taking the opportunity to spin out the next quarterly release of Insubstantial, the 6.3 or "Defender" release.

What is Insubstantial?

Insubstantial is a maintenance fork of some of Kirill Grouchnikov's swing based projects. Specifically Substance, Trident, Flamingo, and some supporting project. These are not Kirill's 'official' releases but he has expressed that he is unlikely to do any more official releases.

How do I get it?

The best way is to use them directly from the maven repository (via Gradle, Maven, Ant+Ivy, or other maven repository aware build tool). The group id is com.github.insubstantial. The artifacts are as follows:

trident [ jar | sources |javadoc ]
Trident Animation Library.
laf-plugin [ jar | sources | javadoc ]
A swing component enhancement framework.
laf-widget [ jar | sources | javadoc ]
Swing component enhancements.
substance [ jar | lite | tools | sources | javadoc ]
A custom look and feel for Swing.
flamingo [ jar | sources | javadoc ]
A Ribbon component and other supporting components.
substance-flamingo [ jar | sources | javadoc ]
Substance customizations to some Flamingo components.
substance-swingx [ jar | sources | javadoc ]
Substance customizations to some SwingX components.

What's Different?

A full bug list can be found at the github page. Some of the more interesting bugs:

  • #18: Trident Animation Threads - If left alone long enough with nothing to do (about 60 seconds) the animation threads will shut down. This will allow for OSGi class unloading.
  • #15: Inactive Title Captions - Some Skins now have a different coloring when frames are inactive or not focused.
  • #14: Dialog Icons - JDialogs now have title pane icons (and an icon menu).
  • #5: JRibbonFrame Captions - When the Quick Action Toolbar and Context Tab Header don't leave enought space, the title caption will move to the right of the context tab header if it helps.

Can I see it do stuff?

Soon. I'll add some demo links once I mess with the GitHub Pages.

What about me?

What about you? Well, being open source patches are always welcome! The code is being hosted at Github so forking, soing your own thing, and posting a pull request should be very easy. There's giant tasks to do, such as updating the look to match Office 2010 and Windows 7. Administrative tasks, such as making the existing web content work on github. And creative tasks, sush as creating new color schemes and skins.

What's on the horizon?

I am bumping the next version number to 7.0 and it's code name is 'Unconquered.' I will track any bugs that make things break in Java 7. Right now I don't know of any breakage (know any? Tell Me). I also plan on looking into supporting some JDK7 features, such as translucent windows (rounded corners anyone?) and re-jiggering some of the jars contents (such as not bundling laf-widget and laf-plugin). I've also seen some early work from Erich Schroeter on a fluent builder for the Ribbon. that should hopefully make it in. The tenative date is early October 2011.

Until later [insert witty postscript here]

April 4, 2011

Insubstantial 6.2 Release

After much hoop jumping, I am pleased to announce that Substance 6.2 (codename Invincible) has been pushed to the Maven Central repositories. This is a maven only release (meaning I am not spinning any other distro jars).

What is Insubstantial?

Insubstantial is a maintenance fork of some of Kirill Grouchnikov's swing based projects. Specifically Substance, Trident, Flamingo, and some supporting project. These are not Kirill's 'official' releases but he has expressed that he is unlikely to do any more official releases.

How do I get it?

The best way is to use them directly from the maven repository (via Gradle, Maven, Ant+Ivy, or other maven repository aware build tool). The group id is com.github.insubstantial. For all of the released projects the version is 6.2. This is a bit of office 6.0 version bumping, but it makes it easier to determine which jars are meant to run with each other.

The artifact names are the same as the original project. I had contemplated renaming them, but after messing with numerous JNLPs decided it was better for compatibility if the jar names were as close as possible to the original jars. The artifacts are as follows:

trident [ jar | sources |javadoc ]
Trident Animation Library.
laf-plugin [ jar | sources | javadoc ]
A swing component enhancement framework.
laf-widget [ jar | sources | javadoc ]
Swing component enhancements.
substance [ jar | lite | tools | sources | javadoc ]
A custom look and feel for Swing.
flamingo [ jar | sources | javadoc ]
A Ribbon component and other supporting components.
substance-flamingo [ jar | sources | javadoc ]
Substance customizations to some Flamingo components.
substance-swingx [ jar | sources | javadoc ]
Substance customizations to some SwingX components.

What's Different?

Not a whole lot code wise or feature wise was added in this release.

  • Gradle - the codebase has been adjusted to use Gradle as the build system. This has allowed for seampless deployment into the maven repositories. For Trident, laf-plugin, and substance-swingx this represents the entirity of the changes
  • Maven Distribution - this deserves it's own bullet point. The jars are available from day one in the maven repositories.
  • NPE Bugs - most of the code changes are to deal with possible null pointer exceptions. No one in their right mind would use a JTable as a table cell renderer, but it does happen in the wild.
  • Flamingo API addition - a patch from Jonathan Gileswas applied to allow commands to be removed from the ribbon.
  • Java 7 fixes - there is a bug fix in Java's Color Choosers that broke substance 6.1. This is fixed in Substance 6.2, so it should run on Java 7 now!

Can I see it do stuff?

Yes you can, there are several JNLP demos that I have managed to stand up over at github.

What about me?

What about you? Well, being open source patches are always welcome! The code is being hosted at Github so forking, soing your own thing, and posting a pull request should be very easy. There's giant tasks to do, such as updating the look to match Office 2010 and Windows 7. Administrative tasks, such as making the existing web content work on github. And creative tasks, sush as creating new color schemes and skins. In a couple weeks I'll figure out what I intend to do, and also some ideas for those who might want to congribute but don't know where to start.

Until later [insert witty postscript here]

March 26, 2011

On Preparing for Releasing Insubstantial (Codename Invincible)

Just a quick post here. Been busy at work transitoning to a new role, so the time away from work has become more precious.

I intend on starting the release train for my first maven central release of Insubstantial on or about 31 March. There's not too much beyond some bug fixes (one needed for JDK 7 support). I intend to call it 6.2 across all of the related projects. So if you are sitting on any bug reports or patches, go to github and submit those now, or it will have to wait for the next release.

Kirill liked to name his releases off of cities, however I have a different plan. The codename for this release is "Invincible." And I didn't pick that entirely out of the air. The future releases will have a specific pattern of code names that will last about 10 releases. Post a comment if you think you know what it is, but it will take a few release to become obvious.

As for future releases, I plan to do a release roughly quarterly. So look for new releases in late March, June, September, and December of each year. I will release what is in the codebase and bump the version numbers as needed. Either the major, minor, or patch number. This release would usually merit a patch number (6.1.1) but I am upping it to a minor to distance it from Kirill's line.

The first release after Java 7 hits the free world will receive a major version bump. This will likely be the Q3 release (unless something needs to be fixed from the Q2 release) and that is when Java 7 will be officially supported (meaning I will look into bugs against that version of Java). In that time frame I also may look into new frills like supporting rounded corners in the windows and other such silliness.

February 21, 2011

On Forking Substance

Most people think of fun things to do on their three day weekends. Things like getting a babysitter and seeing a movie with your spouse, going to a birthday party, getting some car maintenance done, or taking the kids to the playgrond. Me? I spent this weekend forking an existing open source project.

The particular project I forked was six different code bases from Kirill Grouchnikov relating to the Flamingo Widget Library and the Substance Look and Feel. However, there was no drama like what went on with Hudson and Jenkins. Kirill (the principal and basically sole developer) instead has decided to end his support for the project. Something about Android having a better growth potential and that his work on the Android Market paying his rent/mortgage I’m sure. He seems pretty determined about this, because he has even rejected some pull requests for some very specific null pointer checks. In his response he has practically asked that the project be forked, so I am testing the waters.

There are a few things to consider when one is forking a project. The first is the the license terms. Kirill licensed his projects under the 3-clause BSD license . This license allows forking with basically two restrictions (my understanding in layman’s terms, I am not a lawyer though I play one when reading GrokLaw): (a) credit where credit is due and (b) pick a new name. So I’ve come up with some names for my forks of the projects.

Trident
Halberd – another middle ages weapon with three sharp points, just configured differently.
Substance
Insubstantial – A play on substance. Really the UI widgets should be insubstantial and fall away leaving only the data and user interaction.
Flamigno
Peacock – Another colorful bird.
laf-(widget|plugin)
plaf-(widget|plugin) – I’m just being lazy here. (Pluggable) Look and Feel.

The next question is releases and maintenance plan. For now I am synchronizing all of the release numbers to 6.2. There are some null pointer fixes in the forks for substance, flamingo, and plaf-widget. I intend to only do bug fixes and minor alterations for this release. Any new features will wind up in a 7.0 release. At my day job we have code for rounded window pane corners. If that winds up in a public repository it will be in the 7.0 release, these are the sorts of feature adds that are not going into bug fix releases.

Next this fork gives me a chance to do other tweaks that match my whims. For my day job we have a need to see these libraries in a Maven repo, so to that end I have migrated the build system to Gradle, am building the git repo on a CloudBees instance, and I have a Sonatype account to post the libs on their OSS repository. Details and experiences will be in another blog post.

The other tweak has to do with the infamous EDT checks Kirill installed into Substance. I have decided to add system properties to control the logging of the errors and the throwing of exceptions separately. By default violations will be logged to System.err, but no exception will be thrown. You’re free toggle either one of them (insubstantial.checkEDT and insubstantial.logEDT as Booleans). I was going to leave them both turned on, until I discovered that Kirill’s own unit tests for Flamingo violate the rules. The whole EDT issue is worthy of its own blog post/diatribe.

For those who are interested, the maven repository groupId is com.github.insubstantial. The code is at https://github.com/Insubstantial. I have this set up as a group at github. So patches are welcome, and so are collaborators.

January 27, 2011

On Going Dark

One of my favorite songs by Pearl Jam has got to be "In Hiding." It’s a song inspired by a poet/writer who was known for disappearing into his room for days on end, with no contact with the outer world. It's not my favorite because of the lyrics or meaning of the song. The melodics just rock. But the meaning of the song is pretty cool too. Sometimes you just need to check out. And when you are ready to check back in things really haven’t changed, but on the other hand it really has changed a lot because your perspective has changed.

For me, 2010 was a year of checking out of contributing to open source software and participating in 'the scene' so to say. It wasn’t so much that I intended to check out, it just kind of slowly happened and when I realized where I was I just went with the flow for a while. And again, it wasn’t that I conciously checked out, it’s that other things filled the space and time I used to set aside for OSS hacking.

Family was the first to intrude on the space. The beginning of the decline started around November, when the major family focused holidays occur here in the USA. If I was Canadian, the decline may have started in October. And if I was in Europe... I don’t even know what the Christmas season would be like without a precursor holiday like American Thanksgiving. But I had more things I needed to do. More places to be on weekends. There were more weekday evenings that I had tasks to accomplish. And since Groovy and Griffon wasn’t my paying day job I couldn’t exactly work on those on the clock.

And then there was work. Work actually stopped sucking. When I started devoting time on the weekends and evenings to Groovy and Griffon it was mostly as a release for daytime assignments that were absolute crap. I knew it and the powers that be knew it as well, but we both realized that someone had to do it and the most appropriate (available?) person wound up being me. Writing beautiful code and being able to reach into the compiler and make it behave in ways I saw fit was a wonderful salve to the psychic pain that was endured by domesticating the beast I had been bequeathed. It kept my hand to the plow long enough so that someone else could take control. And if I still had that task today, I’m sure I would have tried to quit sometime in the past year.

So in the world of good-fast-cheap (pick two), I chose family and work. You needn’t presume any medical, family, or emotional crisis. There weren’t any dramatic work meetings involving lawyers and contracts. And I sure didn’t win the lottery and buy myself an island off of the Florida Keys. I just needed to go dark because my light only goes so far.

January 14, 2011

Predictions for the Rest of 2011

Well, it’s been over a year since I’ve posted a blog entry, and to those who say you should never excuse yourself for long absences, I extend my apologies. And to those who say you should never apologize on your blogs, I must excuse myself for this indescression.

I am writing this blog post in my hotel room after one of the best conferences I have ever been to: CodeMash. Next year do yourself a favor and go. A word of warning though, they increased the conference by 200 seats this year and sold out in under four days. I expect it to not last even a day next year with open ticket sales. I personally intend to avoid that hassle altogether and speak again. Wish me luck.

This year I presented a talk entitled “Pry it from My Cold, Dead Hands: A Survival Guide for Swing Development in the Twenty Teens.” I’ll post the slides on slideshare when I retire the talk. This is, indeed, a prediction for the next year: that I will give this talk again.

Since it is only 15 days into the New Year I will take the liberty of also making a few more predictions. My first 2011 prediction is that Verizon will get the iPhone before apple fixes their problems with the white iPhone. Well, one down four to go.

Next I have a 1 year prediction, related to the content of my talk. Oracle will ship JavaFX 2.0 on time. Or heads will roll. One might give them until Halloween, but since Oracle OpenWorld/JavaOne is earlier that month then it will have to ship before Wal-Mart puts Christmas Trees up for sale. Wait, that’s too aggressive a schedule for anyone to make, so I give them until the JavaOne closing keynote.

Looking out into the 5 year timeframe, I see desktop computing as past its zenith. It is likely there now, but we won’t know because the first little while after the zenith of an arc feels like a steady state. You really cannot call it until things start really crashing down. The prediction to prove it? 2015 is the last year that NetBeans, IntelliJ, or JDeveloper will release an IDE based principally on Swing components. They will either switch to some other toolkit before then (like JavaFX, or HTML) or they will go into the bit bucket and cease being a product as we recognize them today. Swing development will die like COBOL died, living a long and fruitful life in business internal applications. And I’ll probably still be drawing a salary developing Swing UIs long after that.

Next for a 10 year prediction, I look to what is causing the desktop to be at its zenith. For that, it is handheld computing: specifically iPhones, iPads, and their non-apple counterparts. What differentiates desktop computing from handheld computing? The desk or lap, and the keyboard with tactile keys, and the single monitor attached to it and the CPU. Handheld computing does not require a keyboard or a lap/desk. The handheld space looks a lot to be like the desktop space was in the 1990s. Apple is playing the role of, well, Apple and Android is playing the role of the IBM PC Compatible. Apple’s previous incarnation was basically peaking around 1990 with perhaps a little more up to go. But the PC, even though more fragmented, uglier, and full of fighting vendors, wound up eating their lunch. Apple had a total near death experience because even though the walled garden they played in was a true paradise it resulted in inbreeding and stagnation. The PC land was survival of the fittest because of its diversity and was forced to evolve, rather than the sheer force of will that accompanies the birth of successful Apple products. Before 2020 Apple will experience another one of these near death experiences as competitors catch up and change the game. But Apple will survive. Half credit if they actually die.

And I close with a prediction with no timeframe. For this I look to the application market for handheld devices. It truly is a developers dream now. But don’t move into independent apps, it is a fleeting space that will assuredly disappear. The app market will look a lot like the record market of the mid to late 20th century. Publishers will become the pimps, err, I mean professional services managers, of the modern app store. The same techniques, legal and otherwise, that record companies used to get their songs on your radios and in your home stereo systems will be brought to bear on your smart phones and tablets. Individual acts like Rovio will quickly become the pawns that musicians and recording artists are now to the recording industry. While iTunes is helping break those shackles the App Store is starting to make new ones. It will appear to be good at first, but it will eventually suck the life out of the market like manufactured acts have killed CD sales. The good news is that producers and studio musicians still have steady work if they are really good at what they do.

Remember, fame has a price that quiet professionals never have to pay.

September 10, 2009

Taking Flight: A Year of Griffon

Whenever I fly I like to get the window seat. Sitting on the aisle may get you out quicker, and it may get you quicker access to the overhead bins. But I like the window, for the 15 minutes at the beginning and end of the flight when you must turn of your laptop and take out your earphones. I like to peer out the window and see if I can see the places I came from: my car in the long term parking lot, my house, my office, or the hotel I stayed at. It helps me realize that I've come a long way, but with a lot of help.

I still remember the moment I got serious about my contributions to Griffon. I was sitting at Chinese restaurant for lunch just after JavaOne 2008. While I was reflecting on my SwingBuilder session I did with Andres Almiray I was thinking about where things should go with Swing and groovy and the germ of an idea we had recently named Griffon. I opened my fortune cookie and I can't remember what it said exactly, but it was something along the lines of "They are waiting for you to act." A couple months later I had ported over most of Grails to do a build framework for the JavaOne demo I wrote. I still remember practially dancing down the halls of work the first time I got a full loop working. After some fit and finish time Griffon 0.0 was released, but the array indexing joke was ruined by a crippling mac bug and I had to release 0.0.1 (I've since bought a mac just to rectify that issue).

But as far as I've come with Griffon, I can't forget the help I've received to get things as far as they have come. From the beginning it was a team effort with Andres, James Williams and I. And once it was released community interest was more than I anticipated. Geertjan Wielenga blogged for a solid week or two on a daily basis. Our committer ranks have doubled (although GParallelizer has far outstripped our growth rate). Andres has been amazing with the number of plugins he has written, and James has done more blogging and speaking engagements than I have the time to commit to. But that is what makes a good open source project: a community.

We haven't yet reached cruising altitude, there is still more coming out. Griffon has just release it's 0.2 beta. There are also conferences that will feature Griffon content. Two big ones are SpringOne2GX in New Orleans from October 19-22 (use the code SpringOne2GX75 to save $75 when registering) and StrangeLoop on October 22-23 in St. Louis (sorry, no discount code). So sit back and relax. Beverage service will begin shortly.

February 17, 2009

Groovy Console Bling-Bling

Groovy 1.6 is about to hit the inter-webs, so I thought it was an appropriate time for me to emerge from a twitter induced blogging hiatus. But what to blog about? How about one of the funner items I added to the new release. AST Transformation have changed the way I think of annotations, the bind node in SwingBuilder has brought my GUIs closer to MVC nirvana, and Grapes have been a tasty experiment. But when it comes to plain old gratuitous fun, output visualizations in the Groovy Console will help you see your results in a new light.

GroovyConsoleViz.png

Yes, you probably have seen something like this before, but it's such a neat Idea we had to copy re-implement it.

How does it work? Well, first and formost you have to turn it on. By default it is disabled, so it is less astonishing that way. It's in the menu in View->Visualize Script Results, and we remember what the last seting was when you exit as well. The built in transforms are fairly benign, if the script returns a java.awt.Image, a javax.swing.Icon, or a java.awt.Component that has no parent we display the object instead of the text. Everything else is still text. But that's not really interesting. It is also user extensible! If you have a file ~/.groovy/OutputTransforms.groovy the Groovy Console will insert an empty list named transforms, and you just need to add an appropriate closure into that variable and GroovyConsole will take the results and process those first.

The closure itself is fairly simple. The result of the script is passed in. If you want to transform it you return a non-null transformation. If you don't want to transform it you return null. And the output doesn't need to be a visual component either. You could make all numbers register as percentages:

transforms << { it -> if (it instanceof Number) "${it / 100}%" }

But visual results are much more fun. Here is a simple transform that will make all maps render in tables (it is also the transform that is displayed in this post):

transforms << {it ->
  if (it instanceof Map) {
    def jt = new javax.swing.JTable(
        it.collect{k, v->[k, v?.inspect()] as Object[]} as Object[][], 
        ['Key', 'Value'] as Object[])
    jt.preferredViewportSize = jt.preferredSize
    return new javax.swing.JScrollPane(jt)
  }
}

Don't forget to have fun!

January 2, 2009

Griffon <3's Java

When I first started poking around the Groovy project one of the things I didn't get was the whole MOP thing. Why did every method have to go through the MOP? I thought it was the boat anchor that was going to sink the ship. However, the more I dug into Builders, method injection, closures and delegates, properties, and in general all of the other neat stuff that Groovy does the more I saw that to some extent all of them were enabled by the MOP. Even closures use the MOP, mundane things like trying to figure out where a method call should be dispatched to (the declaring class or some delegate that has been assigned?) uses the MOP. In a sense the MOP is the boat anchor that steadies the language in unpredictable waters.

About the same time I came to my senses about the MOP something wonderful was donated to the Groovy project from the people over at IntelliJ (the IDE that eclipsed my 7 year love affair with NetBeans). They donated a joint Java/Groovy compiler. The Groovy/Java interop story was always very simple. In fact it is so simple an intern could do it. Well, not just any intern. Er... Umm... actually... well... any intern that could fire up two different compilers from the command line could do it. The new joint compiler fixed that, so that any intern who could fire up one compiler could do the interop. The compiler part was really the only hard part because the code looked the same in Groovy and Java, as if you are calling another object of the same language. And at the JVM level the code was the same, following the same naming semantics as Java. However, if any of your interns get a little too excited when you mention a joint compiler and you are thinking of hiring them after the internship, you may want to check with HR to see if there are any policies that they may be concerned about. Some HR departments may be OK with that intern. But be sure to check, you know, for the intern's sake.

So how do those two different threads tie into Griffon? When I first started laying down code for Griffon I intentionally merged the Java and Groovy source trees in the griffon-app. Grails has seperate directory forks in some places for Java and Groovy, of course those decisions were made before the joint compiler was integrated into Groovy. But since I was starting with joint compilation being available, there was every reason to turn it on. And it's turned on everywhere. You could write your controller and models in Java if you wanted to (sounds like a blog post there..) and place the code in the same directories, and it will just magically work.

So when would you want to write code in Java in a Griffon project? First, you would never need to write it to interop with an external java library. Groovy integrates seamlessly with them. In fact, all those snazzy plugins Andres has been chugging out are (for the most part) wrappers for existing Java libraries, packaged into groovy bits for easy use by Griffon. But back to the original question, you would want to write Java (a) if you are more comfortable with it, but it won't take you long to see how easy coding in Groovy is; or (b) if you observe performance issues relating to processor load.

There are two key caveats in the (b) case, (i) observe and (ii) processor load. Why wait until you observe a problem? It has been said that premature optimization the root of all evil. I like to think of it instead in terms of time, it takes you time to optimize code that really isn't causing a problem. When you observe performance problems then you know your work will add value. But before then you are just guessing. Since Griffon aims to improve developer productivity for Swing apps working on unsure optimizations defeats that goal. The other key caveat is processor load. There are many performance issues that really are threading and EDT issues. If you are doing a long calculations you should move it to a SwingWorker or other thread off of the GUI thread. If you are locking on objects... don't. Dropping down to Java won't fix lock contention. Re-think what you are doing and leave data that can be read without locking. And if you are doing database calls in the EDT... let me check with HR before I write up any job offers.