Back in August when Google acquired Instantiations, the speculation was that Google would possibly provide Instantiations GWT Designer as a free tool for all to use. Today, Google has made my day, because not only is GWT Designer relaunched as a free tool, but so are their three other core products. This is a huge day for Java developers, particularly those focussed on the desktop, as these tools are among the best of breed: as commercial tools they were worth the cost as they boosted productivity, but as free tools they are now an indispensible part of your software development workflow. The importance of this announcement can not be overstated. Firstly, Java developers now have a production quality UI builder for fast prototyping of their desktop application using either Swing, SWT or RCP, as well as GWT and XWT. I've used WindowBuilder in the past, and it's a great way to get started quickly. The code generated is very usable. There has been no convincing free solution available for this range of UI frameworks in the past: today that all changes. High quality static analysis of code is important for Java developers. Before you walk into a code review, it's always worth taking a scan over your code. Typically developers skip this, or else they use a free static analysis tool (e.g. FindBugs). Working CodePro AnalytiX into your development process, or just your nightly build, will help you identify bugs, and possible security issues, with your codebase earlier. Finally, automated UI testing is one of the most difficult areas to get right. While there are free solutions available, the commercial products have always seemed one step better. WindowTesterPro will allow you to automated tests for your Swing, SWT or RCP applications. It includes record and playback functionality to get you started with an automation test suite quickly. Here's a quick overview of the tools, now relaunched as Google products GWT Designer Powerful Eclipse-based development tools that enable Java developers to quickly create Ajax user interfaces using Google Web Toolkit (GWT) CodePro AnalytiX Comprehensive automated software code quality and security analysis tools to improve software quality, reliability, and maintainability WindowBuilder Pro Java graphical user interface designer for Swing, SWT, GWT, RCP, and XWT UI frameworks WindowTester Pro Test GUI interactions within Java client rich applications for the SWT and Swing UI frameworks Google plans to unify the products into the Google Plugin for Eclipse. You can download any of the tools from the GWT download page. Check out Google's announcement to find out more.
You can use a language, and not care how it works; or you can use a language, learn how and why it works, and then go on to improve it yourself. You can, of course, improve a language without knowing how it works -- just providing feedback is often plenty. But if you really understand a language, including why each of its formal features is structured exactly as it is, then you can contribute as a master, almost as an engineer. So what's the purpose of HTML? Let's say: providing user experience over the web in a browser. Okay, fine: then to become master, learn about the inner workings of the web (which moves you closer to network engineer) or learn about the inner workings of the browser (probably more useful for web developers than network engineering, especially since browser change a lot faster than the architecture of the web itself). So then what's the purpose of HTML5? and how does HTML5 get there? Paul Irish answered these questions in a great 37-minute presentation at W3Conf2011 last month. He explains how browsers work now as opposed to ten years ago, how browsers drove previous standards and how standards drive browsers now. Eacfeature of HTML5 is given a history (which often explains some otherwise unintelligible bizarrities) and a reason (often hard to summarize, because the reasons are often quite varied, and sometimes deal with e.g. security issues developers don't always worry about). Paul's a smart guy (he's Modernizr's lead developer!), and an excellent speaker. Definitely worth the time. Watch the video below.
Last week I wrote a brief introduction to Kristof Degrave's ongoing, multi-stage IndexedDB tutorial. Judging by the number of reads, it looks like quite a few of you are interested in learning more about HTML5's IndexedDB. I'm following Kristof's tutorial anyway, so I might as well keep posting about it here. Today Kristof has posted his next IndexedDB tutorial -- Transactions -- and here's where IndexedDB begins to get exciting, where the work of creation and definition begins to pay off. We're preparing for actual data retrieval and manipulation, so we'll be creating a READ_WRITE transaction. At this point, if you're trying to understand IndexedDB formally as well as use it pragmatically, you might want to get more comfortable with W3C's conceptual treatment of transactions along with the formal object description, and maybe the IDBTransaction interface too. (For me, it especially helps to understand emerging tech like HTML5 a little more abstractly, just in case the standard takes a different turn than previously expected.) If you prefer learning by doing, here's how Kristof explains transactions: Today, I’ll handle the transaction subject. As said in previous posts, every request made to the database needs to be done in a transaction. So for every read or write request we need to create a new transaction. There for we need a database connection and 2 argument that we will pass to the transaction method. The post is, like his previous tutorials, quite straightforward -- painlessly showing you how to use what is potentially one of the most powerful features of HTML5. Take a look, create an IndexedDB transaction, and get ready to retrieve and manipulate data.
Well, after hubbub, including some here at DZone, the HTML5 element has returned. Paul Cotton, on behalf of the chairs of the working group, issued a revert request -- and his explanation is interesting: The Chairs have received multiple requests to revert change r6783. This change is related to bug 13240  which was never sent to the HTML WG since it used a possibly incorrect Bugzilla component. Since WG members were NOT notified of the creation of this bug the Chairs have decided that this change should be subject to the Enhanced Change Control rules in the WG Decision Policy : "Therefore during a pre-LC review, or during a Last Call, feature additions or removals should only be done with sufficient prior notice to the group, in the form of a bug, a WG decision, or an on-list discussion. This applies only to LC-track drafts and does not apply to drafts that may include material for future versions of HTML." We therefore ask for a revert of this change to be completed no later than the end of day on Tuesday 8th of November. If this revert is not complete by that time, we will instruct W3C staff to make this change. In other words: people don't like it, and we never really meant to approve, and we're not really sure how it got through in the first place. Now, the decision policy quoted sounds as though it would not invalidate the change, since the 'bug' was listed (and discussed) since July. I don't know what 'possibly incorrect Bugzilla component' means -- did they actually find something misconfigured in Bugzilla? -- but the vague hedging on 'possibly incorrect' raises my suspicions a bit. The meeting minutes don't help much (though it's neat to glimpse at how these conversations go). After the decision, a proposal to modify the reverted element was posted on the W3C wiki. This might map the near future of , so it's worth checking out for that reason alone -- though also, again, to help understand how HTML5-spec decisions are made. But however it happened, is back. So: did the W3C WG actually bow to popular outcry? or was there really just a bug in their bug-review system? I don't know, but I'm curious. What do you think? Update: Discussion has re-opened in the original bugpost since the revert command came through -- some deductive, some inductive. Results from the blekko web grep mentioned in the last comment might be very interesting...