“The time has come…to talk of many [technologies].” –Lewis Carroll(‘The Walrus and the Carpenter’)
General
WordPress Plugin and Theme Cheatsheets
4If you are a plugin or a theme developer for the WordPress software, then you probably are going to love these two cheatsheets – created as JPG images so that they can be set as a desktop wallpaper! Screenshots for the Plugin cheatsheet and the Theme cheatsheet are available at the headzoo.com website. Send suggestions or any other feedback to the author.
More cheatsheets related to programming technologies are available here.
Official google cheatsheet is here but I think you will like this google cheatsheet more.
For more such cheatsheets, there is always Google Search :)
Movable Type 3.3 Beta To Be Released On May 31
1Its close to one year now since the 3.2 version of the Movable Type blog publishing software was released last year. Jay Allen, Product Manager at Six Apart, has announced yesterday that the first beta of the next version of the software, Movable Type 3.3, will be released on May 31.
Good news: We’ve got a new version of Movable Type on the way, and we wanted to let you know that the beta is coming soon. We plan to start the Movable Type 3.3 beta test on Wednesday, May 31.
The highlight this time around about the beta development stage is that a separate blog will be serving as a common place for everyone to keep informed(and get technical support) about the latest developments with the beta product. There is also a tight 3-week deadline for beta testing this time, informs Jay Allen. So whoever is a Movable Type fan and would like to get their hands dirty by test driving its multiple beta versions that would be released in the coming next few weeks, get ready and be prepared for the D-day.
You can read the announcement here:
Coming soon: Movable Type 3.3 (beta)
Update: More details about the new features of the Beta version to be released are here: What’s new in Movable Type 3.3?
Should I Be Developing Ajax Applications using Google Web Toolkit(GWT)?
0So why should an Ajax developer be interested in the recently released Google Web Toolkit(GWT)? One possible reason could be to overcome the shortcomings of the typical Ajax web development model as noted in my earlier post. Firstly, a framework always provides a head start to a project, allowing the developers to worry only about writing the application logic; user interface elements, the plumbing work needed for the communication between the client and the server are provided by the framework itself. The more specific benefits of using the Google Web Toolkit are:
- The developer is relieved from the thankless job of understanding every single way in which the browsers differ from one another in handling the same web page, allowing them to create websites such that all these web browsers handle a page in (roughly) the same way.
- GWT allows the developers to interact with the browser’s history stack which means that the Ajax applications created using GWT can allow the users to use the ‘Back’ and ‘Forward’ buttons of the web browser and to bookmark the various pages of the website.
Refer to points 2 & 3 in my earlier post.
- Developers can use a more modular and statically typed programming language in Java to create the interface and other components instead of hacking their way out with Javascript. Ultimately, its still the JavaScript code that is generated and served to the web browser, but GWT provides an abstraction layer that shields the developers from having to do much with the JavaScript language. The flip side of this is that for pure interface code, Javascript might offer a more natural solution than Java language when it comes to creating web pages; see the discussion below.
Refer to point 1 in my earlier post.
Being able to use Java to create Ajax applications also means better integration with the rest of the Java web development technologies like JSP, JSF, etc(note that code written using GWT uses the Java Web UI class library which is not related to any of the Java standard libraries and this code is statically translated to Javascript and HTML code before making available to the server. Integration would be limited to sharing something like a Java component between a JSP page and the code written using GWT). This may not appeal to those who are using other server-side technologies like PHP and ASP.NET.
Java language also boasts of better programmer IDEs and tools with good support for Unit Testing and Refactoring. In fact, GWT itself has good JUnit integration through easy to use class libraries in the package com.google.gwt.junit.
Javascript code can still be embedded within the Java code if only the services of the Javascript language are going to solve a particular problem, by using the Javascript Native Interface(JSNI)(on the lines of JNI). See this for more information.
- The biggest advantage of using GWT for creating Ajax applications is the relative ease with which the data can be communicated between the server and the client by just creating serializable Java objects.
- Good support for debugging. Eclipse IDE and GWT host mode form a good combination for convenient debugging of the GWT applications.
Having said all this, I am not a big fan of static translation of one programming language to the other. If it were as unified as in ASP.NET(see ASP.NET WebParts; all the translation happens at run-time), I would have welcomed it whole-heartedly. But different programming languages are created to solve different problems, and they are optimized to that specific job. I hate Javascript language for many reasons(as I do in case of Java) but still believe that Javascript is better oriented towards creating client-side code for the web browsers than Java language is(when the intention is to create a web interface). Are we going to use Java idioms here or are we going to try to imitate the Javascript idioms in the Java code? How many Java libraries are supported by the GWT SDK tools? What about the unsupported libraries whose functionality is needed for the application?
Secondly, the entire translation process is lengthy and inefficient: create an empty GWT application using the GWT SDK, fire up your favourite Java editor(eg: Eclipse) and create the Java source files in it, translate these Java files to Javascript + HTML files and finally integrate them with the rest of the server-side code(PHP, JSP etc). But there are advantages we get out of this investment as noted in the above mentioned points.
Not all the standard Java libraries are supported by GWT. For example, only java.lang and a part of java.util are supported by the GWT tools, which means the code written using Java libraries not supported by GWT cannot be translated by the GWT tools. The developer needs to make a call whether to achieve the desired functionality by writing custom Java code or by writing the code in Javascript.(I would be tempted to go the second way as that would allow me to use the same code in other applications that don’t make use of GWT).
By the way, why don’t we have the access to the GWT source code? Isn’t Google a big supporter of the Free Software community?
For developer centric GWT related discussion, go to the GWT Support Forums.
Related Post: A Case Against Ajax Web Development Model
My Favourite Note-Taking Applications
3Earlier, it used to be sufficient to have a sticky note-taking application hanging around a corner of the screen(or on a different [virtual] desktop) ready to take any text you want to paste in it for future reference. While browsing various technology related websites, I would just copy and paste the important text, along with the URL of the page, in the sticky notes. The data thus collected could then be perused later, organised, blogged about, sent as email to the friends etc. Stickies are easy to create, easy to manage and the data persists even across system reboots. A text editor in contrast has to be started from a menu or a command line, and the user also needs to remember to save the contents every once in a while lest it may be lost due to an unexpected system failure. Every time the system reboots, the text editor needs to be started and the scratch file needs to be re-opened, unless you have the habit of saving your work session before rebooting(I never do it).
Nevertheless, there are some shortcomings of a sticky note-taking application too.They are as follows:
- Its available in only one operating system. I can’t save the notes in Gentoo and later access them from Ubuntu or Windows operating systems. Accessing the notes from another machine is out of question.
- It doesn’t save the formatted text(bold, italic etc), images, hyperlinks and similar stuff – only pure text is supported.
Three applications that I have evaluated in the past few weeks proved to be excellent replacements for the traditional way of taking notes. These modern note taking applications that I grew really fond of are:
- Google Notebook: This application allows formatted text to be saved including images, and also includes a link to the source of the text in case you want to go back to it to collect some more info. Multiple notebooks can be created for different categories of notes, some of them can be shared with the general public, it has got features like expanding and collapsing the notes etc. Most significant benefit is that it is accessible from any machine, any operating system that has got an Internet connection. It pops up in the bottom left corner of the web browser for easy note taking while surfing the web; a full page view is also available to better organise and share the collected notes.
- EverNote: You are sure to fall in love with the interface of this application if you give it but one chance. The feature rich, basic version(no time limit) of this product is freely downloadable from the website, and the paid version, EverNote Plus, that boasts of some additional impressive features like handwriting recognition, is currently priced at $35. A one month trial version of it is available for download at their website.
Its the best note-taking application I have ever used; be it the interface of the application, the features that it supports(copy content from anywhere and paste it in the application and it appears just like it was in the original place) or even the help manual that comes with the product, everything leaves a strong impression upon the user. If you are used to taking notes heavily while you surf the web, read the emails, chat with friends, read the documents etc then you must give this application a try. The only limitation of the product is that its available only for Windows users. - Tomboy: Its a desktop application created in Mono for the GNU/Linux operating system. So unlike Google Notebook, the data cannot be shared across operating systems or among different machines. It allows the text to be formatted after the text has been copied into it(it does not retain the formatting from the original page as does Google Notebook and EverNote) and also allows links to be created to the other notes created in the same application(sort of cross-linking).
It’s still in early stages of the development, so lets give it some time before it can completely replace our old note-taking applications.
A Case Against Ajax Web Development Model
2Ajax is the hottest buzzword today on the web development scene. Everyone is trying to port their existing websites to now make use of the Ajax technologies or just including the name ‘Ajax’ somewhere on the website to claim that they too are in the loop too. I am not totally impressed by the Ajax technologies though.
My primary reservations are with the complete diversion of the path that web development is currently taking towards the Ajax based development style. I have the following concerns:
- Creating websites using a heavy dose of HTML and Javascript is not the most intuitive way of creating complex web applications. After taking all the steps to build convenient abstractions(objects and events) for web development, hence bringing it closer to the desktop development model, its foolish to take one big step back now.
- Not being able to bookmark most of the pages of a website is not going to make anyone, the customer or the website owner, feel happy about it. We come across the same concern with the ‘POST’ data too, but POST method is either used:
- when submitting sensitive information to the server; or
- when sending large amounts of data to the server
No bookmarking should be needed in either of these cases. The same is not the case with the Ajax based websites.
- It breaks the ‘Back’ button of the web browser. Once again, this is not a new restriction; many websites break at many places if the ‘Back’ button of the browser is used, but the problem is compounded to the extreme level when using Ajax.
- I can’t right click on a link to open the target page in a new window. This point may look silly but this in fact is my biggest irritation when using the otherwise excellent Google Mail interface.
- Web developers need to be taught to learn new interface design guidelines. With the liberty of being able to create and destroy any part of a web page dynamically, a bad design can easily leave the user clueless and confused if enough indications are not left regarding what each part of the page tries to accomplish(Flickr demonstrates an example of a good interface). Easy to navigate interfaces are critical for any kind of applications, but the issue gains more importance with Ajax based interfaces.
Its not that I see only drawbacks of using the Ajax technology – with so many great application interfaces being created using this technology every day and so many Ajax applications gaining such widespread adoption, it cannot be without its virtues. It allows some cool effects to be achieved(game website) without having to invest a lot of effort in it – just a basic knowledge of HTML, DOM and Javascript(a skill set that every web developer should be comfortable with) is sufficient. Ajax is not just coolness though; it also helps in creating better interfaces than possible with the traditional web development model, for similar kind of functionality; improves response times giving a more interactive feel to the users; it saves bandwidth, saving time and money in turn.
So when would I use Ajax and when would I prefer to stick to the traditional web development style? For simple web tools(eg: a file uploader/manager, a simple online game, a calculator etc), I would go all the way to use the Ajax technology as it would enable the user to experience the same convenience as that of a desktop application. For complex/moderately complex applications, it should be a tough call based upon the following question: what is most critical for the application, the interface and responsiveness, or the development and the maintenance of the application? Let us admit the simple fact that its not a much pleasurable activity to implement feature after feature using heaps of Javascript code, then writing just enough php code to merely pull the data from the database to return it to the client in some obscure data structuring format.
I would still use Ajax based techniques to pepper up certain parts of the interface though, if I feel like none of the above mentioned disadvantages weigh heavily over the gains that the application can make with them. For example, I wouldn’t use Ajax technologies heavily if I were creating a website like Amazon, though I would still use Ajax to pop up the balloons whenever a user holds the mouse over a product, providing the user with fresh and useful information about it(how many in stock, latest discounts etc).
All the Ajax frameworks that are propping up on the Internet in recent times should help the web developers escape from having to write large amounts of Javascript code, test them, debug them and also from having to maintain them. Such frameworks also use the best practices, thus removing the scope of many design errors that the web developers might commit if they write the Javascript code manually. The Ajax framework that Google has released recently is definitely worth trying out, and I will try to write about it in a future post.
Recent Comments