Components
Being an XML based language XUL inherits all XML good and bad sides, well-formedness, specifications and can be easily integrated with any language of XML family. Xul application is based on the sets of components defined in 3 main groups:

1. Content – layout and interface
2. Skins – CSS slylesheets  – the appearance of the application
3. Localization Files – definitions for locale setting, languages, time-formates etc.

XUL includes:

• widgets – numerous frameworks for building applications with .NET and java Swing toolkit
• MVC architecture framework
• Rich support for the number of languages -perl, PHP, python, java, c++, javascript and so on.
• Messaging via XML-RPC and SOAP

Elements
Top-Level Containers :
windows, frames, dialogs
Widgets
buttons, labels, several types of boxes, drop-down lists, toolbars, color-pickers
Models
box, grid, stack – etc.
Templates
Templating the application and extending existing templates

XUL Explorer
Xul is becoming very popular, many applications, not only Mozilla ones uses it. For example activestate has released a Komodo IDE which extensively uses it and where it is possible to program it. However xul has its own ide targeted exclusively for it – XUL Explorer. The IDE is fairly simple and provides only the very basic functionality along with independent editor and pop-up windows where you can preview XUL code.

Links used in this post:

http://en.wikipedia.org/wiki/XUL
https://wiki.mozilla.org/XUL:Home_Page
http://articles.sitepoint.com/article/xul-nets-biggest-secret-1#
http://xulblog.de/xul/
http://starkravingfinkle.org/blog/xul-explorer/

At first there was perl and then was the rest. I am not actually sure whether perl is the oldest scripting language but it’s definitely one of the eldest. Being “born” in 1985 perl is still one of the most frequently used languages and one of the
most powerful ones. One of the main differences, I am not sure whether it’s a benefit or not – it’s almost a compiled one. It always had a compiler and written purely in the c programming language. However the compiling is still dynamic and perl behaves as a regular scripting one. This gives a huge benefit of speed, as it is possible to write pure c code and use it in perl programming. Python has emerged later in 1989, however became very popular much later.

Perl is called a Unix biased language – it emerged from unix environment and implements great number of unix utilities such as grep, map, sort. With a great support of regular expressions which work incredibly fast. Python does not have such a great regex support, however it is much more cross-platform oriented and has much better support for windows based systems – perl has 2 main windows distributions – strawberry perl and activestate perl, both have their flaws
and a unix distribution is obviously more natural to use. In fact all unix-based systems comes with pre-installed perl. Python should be installed explicitly.

Perl has 2 main phrases which describe a way perl do things – There are more than 2 ways of doing things in perl and for some reasons half of them does not work That’s true, perl is really diverse, and one tiny bit can be redefined in numerous ways. Perl is also called a “kitchen sink” typing language (particularly I do not really like this one). Perl syntax allows coding with absolutely any style as well as with all possible violations. Python is an “indentation” language, where brackets are dismissed and white spaces become the part of code, hence Python is said to be much better human readable and in fact Python is easier to learn, perl sometimes has odd structures and non-obvious hard-to-read code. On the other hand perl can be much shorter due to the great amount of inbuilt variables which are invoked automatically with no explicit need of typing them.

The main difference and the main point in this debate is Object Orientedness. Python is an OO language, perl is not. In fact you can have an object in perl, but they are very non-obvious, quite difficult to learn and might use totally different syntax on usage and invocation. Python is much more persistent, very little thing is defined and always the same.

OO brings its benefits as modularity, support for global variables, inheritance etc. In my opinion those are negative aspects as well. In perl does not have c pointers – but references. And references are explicitly declared, so if a programmer wants a reference he/she declares it otherwise it is never used. In Python all those is done automatically with a garbage-collector on the background which cleans all the “mess”. I think it’s just the matter of taste which approach to use and certainly with some problems OO is extremely useful as well as sometimes it’s not at all.

So both perl and Python are very powerful mature and very well supported languages. With huge library collections and support. Some things might be done better in perl, some in python but i think that the bottom line here is in programmer;s taste, preferences and the current task which demands certain language ability.

Some browsers, like Mozilla claim to support some new features, some less famous stick to the current standard. However there is no guarantee whatsoever that the HTML 5 specification that is defined now will remain and I still think that it will take a while till all browsers will provide full support. As standards are standards but, html relies on browsers and it does not really matter whether standard is on or not, but whether it is supported by browsers and to what extent.

Some new Features:

<Doctype html> – one of the declared changes is in the declaration of document, for now html 5 documents will need only this very short and convenient type, on the contrast to html 4, which I, for example was never able to memorise, but rather copy over and over again.

From now on (or not really, that’s W3C to decide) tags similar to <input>, which are not really closed ones, should not be necessarily closed, for example <input type=”button”/> or <input type=button> will be of the same effect. That’s a little bit weird, I would think that strictness should be enforced, rather than dismissed, anyway <input> is an absolutely valid tag

Of course, html5 introduces a bunch of new tags abandon support of a fairly impressive amount of old ones. One of new features is the article-type template that is to be made with brand new tags:
- Top: <header>
- Bottom : <header>
- Sides : <nav>
- Inside : <article>
Of course this structure can be nested in many ways, and none of those tags are really compulsory. For better navigation new tag <section> is introduced for the reasons of division new document template into appropriate sections:

Some other tags:
<figure> – group of media content
<datalist> – drop down menu
<command> – command button
<embed> – embedded into page media content
<source> – media resources
<time> – date/time definitions
<video> – video content
<audio> – audio content
<canvas> – graphics

Deprecated and not supported tags:
<applet>
<basefont>
<font>
<big>
<center>
<frame> and <frameset>
<strike>

I still ask myself a simple question why these tags are really deprecated ones, in my experience some of them are not that “evil” and might be quite useful, even though that’s a “bad” style to use them. For example I totally agree with definition of everything in CSS, however we can not get rid of cross-browser issues where <center> tag is sometimes a panacea. On the other hand, why, oh why <blink> is a supported. And what to to with all resources with frames that already exist and are based on framesets, javadocs, as an example.

One of the main features in future is multimedia support, when there would not be necessary to bring an external players, but audio and video would be simple embedded into pages, as well as drag and drop support, based exclusively on html in contrast to slow and complex javascript functions.

New Html is claimed to have a great javascript support, embedded into it. I am not sure how that will be done, but in fact sounds impressive.

In my opinion html 5 owuld be a great step towards new Web technologies. However I do not think that this change will happen any time soon. Additionally it is not that clear what browsers would do in that situation, clearly tags that are claimed to be non-supported would not be as there are too many legacy projects that rely on that. I believe the best way is to leave all the existing functionality in place, but add some new features, that would give much more freedom to the developers and the resources to produce things in a way they want and not depend too much on new technologies

Sources used in this post:
http://www.w3.org/TR/html5-diff/
http://www.w3schools.com/html5/html5_reference.asp
http://www.smashingmagazine.com/2009/07/16/html5-and-the-future-of-the-web/
http://diveintohtml5.org/semantics.html
http://www.readwriteweb.com/archives/google_dumps_gears_for_html5.php

Groovy and Java Differences:

• As Groovy is a dynamically typed and compiled language it can be executed with no compilation as pure source code on the contrast to Java which should be compiled;
• Groovy does not demand import statements at the very top as Java, and the libraries are uploaded automatically when used;
• Weird syntactical difference between ‘==’ and ‘equals’ is not used in Groovy and all objects can be compared only with ‘==’;
• Groovy does not support a classic ‘for’ loop, and used more sophisticated and more recently introduced for (each) one;
• Groovy consider semicolons optional as long as line is terminate with ‘\n’ character;
• Native support for maps and lists (these data types are not included as external libraries but are the features of the language);
• Native support for regular expressions, unlike java which has 3(!) classes for handling the very basic one;
• Return keyword is optional as well as unchecked cast, it is just skipped if not used, in contrast to java which would not even consider compiling unless method that has a return type does not have a return statement;
• No need for thorough exception declaration, methods that would throw the exceptions would throw them however there is no need to declare them;
• easier string operations and much more powerful switch statement, which can handle strings as well. Java consider only integers or character as suitable input for ‘case’;
• Groovy uses both ‘ and ” quotes for strings;
• Method and variable declarations are optional, however are still the element of a good style;
• Short and very nice print and instead of System.out.print

Hello World In Groovy:
println(“Hello World!”);

Technologies

• dynamic scripting java run-time environment that facilitate usage of the Groovy scripting language and PhP
• optimizatin of applications and information exchange via SOA and REST based web services
• heavy use of AJAX
• integration of mash-ups and feeds with ATOM, JSON and RSS technologies on top

Ajax
WebSphere sMash uses an open source Dojo Toolkit for ajax interactions. IBM also incorporates it to the range of other products. Another ajax tool used is Open Ajax Alliance that allows WebSphere sMash components work with third party Ajax widget libraries that uses the same technology. These libraries are included by default, however their is not compulsory, a web application can be built with sMash without any Ajax interactions, in fact, although Ajax provide an excellent connectivity with a range of web services used. IBM has also inbuilt a range of security features into it, as ajax applications from different libraries can have multiple vulnerabilities when used. For example the OpenAjax Hub 1.1 implementation which facilitates securing the contents of HTML pages.

Aglie Development and speed
End-to-end development and runtime environment – applications and components can be biult in the number of ways, which involve less coding and has increased speed of execution. End-to-end browser-based tooling facilitate concurrent development of both client and server side easily, in addition to it WebSpere is able to integrate and coexist with components that do not belong to a framework. WebSphere sMash enforces the usage of reusable code, content, templates, and patterns which results in less work and bugs that might occur during development process.

Event-driven model
WebSphere sMash uses an event-driven programming model. Applications are referred to as modules – blocks of functionality that communicate with each other in eficient manner. These blocks are used for bunding other callback functions that are suppose to catch incoming events and execute when event is fired. This model allows usage of mixed tools and technologies, such as PHP, Java, Groovy or the Flow language.

Some people still prefer keep everything as simple as possible and use many small tools rather than one enormous one. Tne main reason is probably manual configuration – it is definitely easier to let the tool to build a project for you, but on the other hand it’s much more fun to write your own make file, keep it small and maintain along with the growth of the project.

There are many more plain text editors than IDEs which peacefully coexist and used by developers, but there are 2 major UNIX ones – the reason and a souce of the “Editor War” vi and emacs.

I believe many windows users might ask a reasonable question on why a eprson would ever use any of those. Similarly to my first reaction on vi when i just could not figure out how to close that thing.

Both editors are quite sophisticated and ancient pieces of software and it takes a long time to learn how to use it and a much longer time to feel comfortable with it. Programming using vi or emacs is much more fighting the editor at the beginnig. In fact bothe editors were designed to be used without a mouse. Simply there was not one at that time

vi
vi was written in 1976 by Bill joy in Unix system. Later it has been redeveloped into vim, and then a separate version with GUI has emerged. However an original version is still avaialble. vi is a modal editor – it operates in 2 modes – a command and insertion. In command mode the buttons that are usually used for entering the text are used to perform commands, such as save, copy paste and many many more, vi has more than a hundred.

emacs
emacs was developed later and it is a modeless editor. The current version is Xemacs22. Emacs is more sophisticated than vi, is heavier and functionality commands are defined via key combinations.

Benefits
emacs

• emacs has a greater number of plugins and addons which might include almost everything
• emacs can be programmed, as it is the variant of LISP
• emacs can be used as vi in fact, there’s a special mode for that as well as a special mode for windows like shortcuts
• emacs is modeless
• emacs supports typing in more than 20 languages
• emacs supports many types of calculations, for example calendar calculations
• emacs can perform plain-text into PostScript

vi

• vi is smaller and faster, though emacs has much more embedded functionality, but it takes a considerably longer time to launch it
• vi is usually used within the command line and the shell commands are typed in the shell directly, emacs uses a pipe
• vi is embedded in all unix systems by default
• vi does not 2-3 key shortcuts as emacs, commands are often defined by one button
• vi does not need a lot of customization and keeps its settings in the simle plain text file

Editor Wars
*nix programming community sometimes treat their favourite piece of software with almost religious fanatism and the non-stopping debate on which editor is actually better are called “Editor Wars” similarly to Browser or Platform ones.
Emacs fans has even created therir own Church of Emacs formed by Richard Stallman, as a joke though. It refers to vi vi vi (which is 666 in roman numerals) as the “editor of the beast”. In anser to that vi lovers has established the Cult of vi.

Go (do not confuse with GO!) programming language is a brand new programming language developed and introduced by Google about a month ago (Novermber 2009). It is described as compiled, structured, concurrent and imperative programming language of a ‘c’ language family (it’s syntax is very similar to original c). The distributions so far are for Linux and Mac operating systems (not for windows, so far, but I am sure there will be one soon enough).

The new language was bor out of frustration and with the purpose of making things faster,simplier,shorter and less mistake prone (as usual though). One of the main principles was to make language shorter, and in order to do that several approaches were followed:

• everything is declared only once (No Forward Declaration and common C header files)
• use of := declare-and-initialize construct instead of heavy and verbose java like declarations: Foo foo = new Foo();
• inproved type heirarchy – types just are, but no need to declare relationships between them, therefore methods are implemented for any type
• despite teh language is similar to see the pointer arythmetic is not being used (as there’s no way then to get non-existing memory address)
• for the same reasons prefix notation is not used
• language has a garbage collection – mainly for the matter of simplification of memory management
• the space of identifiers was extended to Unicode, not just ASCII
• More interestingly Go does not have neither assertions nor exceptions. Generic types are not used as well. However Generic types and exceptions are still an open question and might be added in the later release
• there’s no type inheritance in Go. The language  automatically satisfies any interface that specifies a subset of its methods
• Go implements maps, (similar to perl hash data type)

Hello World! in Go
package main
import fmt “fmt”
func main() { fmt.Printf(“Hello, world;\n”); }

Go currently has 2 compilers
6g are in C, using yacc/Bison and Gccgo with a C++ front-end with a recursive descent parser.

Currently there are 2 versions of YUI – YUI 2 (2006) and YUI 3 (2009). The latter was almost rebuild from scratch to be faster and more reliable.

YUI includes 3 additional subprojects:

Also in the YUI Project:
YUI Compressor – way of minifying of scripts
YUI Doc – self-documenting Python-based framework
YUI PHP Loader – managing back-end functionality issued.

YUI Core
YUI object – main object in the library, the rest of functionality and plugins are accessed through it, similar to Jquery object. Benefits from the use of ‘use’ function which allows to load a necessary modules. Unlike Query YUI is not divided into 2 libraries and contain everything in one. Jquery facilitates usage of different internal objects, (such as “.modal”, for example) YUI refer to those objects through a use function.

Additionally YUI Core includes “Node” and “Event” object that facilitates modification of DOM nodes and browser events. Events are organised similar to jQuery, however a “Node” object is a totally different one. jQuery accesses nodes through CSS selectors, YUI does almost the same job however “Node” functionality in YUI is slightly different and more extended.

Utilities

• Animation – definition of css properties of an element in one declaration. Similar to jQuery css function. the major difference here is that jQuery css processes one property at a time, with YUI a properties can be given as a set
• Browser History Manager  – facilitates use and refering to browser “Go Back” button and bookmarks – no direct analogue in Jquery
• AsyncQueue – a YUI ajax interface intended to create a series callback functions with sequential order of execution. Jquery provides similar functionality with .ajax object, where functions can be binded to events, based on the result of the query.
• Cookie – inetrface for managing cookies in the browser. No direct analogue in jQuery
• DataSource – API for data retrieval with variety of protocols (including XHR request)
• DataType, DataSchema – data conversion and validating – no direct analogue in jquery
• IO – managing ajax requests
• Selector – element selection through CSS properties, almost exactly the same as selectors in jQuery
• JSON – verfifcation and conversion of JSON data
• Get – the asynchronous loading  – similar so .GET function in jQuery
• StyleSheet – dynamic modification of CSS properties, similar to jQuery css function

Widgets and Effects:

Similar to jQuery UI YUI provides a wide range of effects:

• Draggable
• Droppable
• Resizable
• Selectable
• Modal Windows, etc.

YUI is considered to have more visual effects, for example “File Tree”, which Jquery has as a plugin.  jQuery and YUI are similar libraries which were created with the similar purpose – make the work of a Javascript developer easier and forget of cross browser issues.

Initially libraries have some differences in the API, however given the countless amount of plugins for both have similar functionality.

Google Apps environment supports a range of computer languages – the first introduced ones were Java (JSP and servlets) and Python. Later a feature of using other languages that support java based interpretor was introduced (languages like Ruby or JavaScript).

Google Apps is not completely free of charge, the resources web application uses are measured in megabytes and should be paid for. However for small application (less than 500 Mb Google Apps is completely free). The measurements are performed in terms of Emails sent/received, Bandwidth in/out, CPU time, HTTP Requests, Datastore API calls, Data stored, Data Fetching calls

Google Apps engine uses an approach called “cloud computing” – applications developed with this language could be distributed all over the internet or distributed in a particular network with no access for non-authorised users. Here Google apps benefites from the overall infrastructure – Google accounts can be used to access the resource.

Runtime anvironments
The run time environments supported by Google Apps Engine are already mentioned Java and Python ones:

• Java – interaction with Java Servlet standards and the use of JSP (Java Server Pages). Engine primarily supports version 6 of java and includes support for application written for Java 5. Google apps include Java SE Runtime Environment (JRE) 6 platform and libraries.
• Applications written in Python use interpreter version 2.52. Future releases are claimed to use Python 3 instead. For the matter of compliance to Python Programming standards Google Apps supports such development environment as Django and includes common Python packages and libraries.

Datastore
Google Apps provide a powerful database storage facility called a DataStore. This tool is a bit different to common relational SQL based databases. Data units are have a kind and a set of properties attached to it – for the matter
of retrieving an object by a kind and sort and filter via property. The retrieval Mechanism is called GQL – similar to SQL, however it is different to the latter one – for example there is no ‘join’ statement, select statement is able to retrieve not more than 1000 rows in one call and several more. In general sense it is not a relational database.

Google provides a set of restrictions, such as:
Read-only access to the filesystem, HTTP only code execution, Pure Modules (Python c based modules are not allowed)

Comparison to Ruby on Rails:
It’s very hard, in fact, to compare Google Apps Engine and ROR, even though they both are used for creation of web applications.
In my opinion, they serve a little different purposes and uses quite different tools.

- Ruby On rails is more a framework for fascilitating development, in order not to reinvernt the wheel and concentrate of design, rather than on implementation. everything that can be done with ROR can be also done and integrated manually, however this environment brings everything together – things like webserver, language tools, databases are in all large piece. However this iis not the only feature. For me it looks like and IDE comparing to a simple text Editor. However the major differences might be described as following:

• ROR used Ruby as a major language, Google Apps are More python and Java base, however there is a support for Ruby
• With ROR it is neede to maintain your own server, Google provides its own and its own infrustructure
• In ROR many things are brought together, and they all are quite settable – for example the use of a relational database on your choice – MySQL, SQLite, Google Apps provides its own non-relational in a broad sense database engine
• Google Apps provide a range of services, and therefore developers are mainly limited to the ways in which Google Apps work, in ROR it is up to a developer what tools to use, how to make calls, execute code, etc.

Personally, I would probaly use neither of those or any other large and sophisticated development framework. I prefer do and combine everything manually with a simple text editor as a major tool. These frameworks enforces a range of principles and perform a lot of work automatically. I think custom build is always better. However this is just a personal preference

However despite a large number of previously mentioned editors – programming plain text editors with syntax highlight are quite rare. One of the most popular ones is EditArea code editor written by Christophe Dolivet – http://www.cdolivet.com/.

It’s a very powerful tool and by his own words that is “That is no way a WYSIWYG editor”.

The core idea is quite similar to the WYSIWYG one, however there is no need to insert tags any more, in fact highlight can be performed through External CSS properties and the text is returned as is – therefore it can easily be a code that might be executed.

The main features of EditAera are:

• Syntax highlight
• Search/replace text
• Key bindings
• Line numbering
• Multilanguage support
• Easily integrated with such libraries as prototype, jquery, mootools
• Plugin integration
• Undo/Redo buffers

Syntax Highlight
Edit Area provides syntax highlight for a number of languages (PHP, CSS, Javascript, Python, HTML, XML, VB, C, CPP and many more). The switch between different highlighting schemes could be located on the editor as a select box

Search/replace
Editor provides a search/replace modal box. Additionally search can be performed via a regular expression and easily replaced – this is an incredibly useful feature especially when it is needed to replace one pattern (like variable name) that occurs in the large text multiple times

Key bindings  and Line numbering
Editor provides line numbering a number of inbuilt shortcuts common to a regular system editor – the main feature is in indenting blocks
of text with tab key.

Multi language support
A large number of language schemes is provided – everything (including tool tips) can be easily translated into one of many language packs provided – Croatian, Czech, Danish, Dutch, English, Esperanto, French, German, Italian, Japanese, Macedonian, Polish, Portuguese, Russian and more
.
Integration
Editor easily works ion the environments built on top of common JavaScript libraries, such as Jquery or prototype

Plugins
Additional buttons or select fields can be easily created with a plugin framework provided by editor  interface. A framework includes a number of ready-to-use functions.

Undo/Redo
EditArea has a very well implemented settable undo and redo buffers – the number of “undo” and “redo” actions can be set by s user.

Additionally EditArea is very easy to use, provide a large number of functions for accessing and setting the editor, almost everything can be set including an interface for executing internal functions. Editor is very light and well documented. And in my opinion it should be the choice number one for online-coding purpose.