Friday, January 15, 2010

developerworks on git

Git changes the game of distributed Web development

Git was designed to facilitate distributed development among thousands of developers working at many different locations with different degrees of Internet connectivity without introducing significant performance or access bottlenecks. The most important aspects supporting these fundamental requirements in Git are:

  • Using a central repository but providing each developer on a project with a complete copy of the source code for that project. This guarantees that all developers can get work done regardless of their current connectivity.
  • Providing fast and reliable support for creating different working sets, known as branches, within a software project and sharing changes across them, known as merges. Branches make it easy to support different versions of a software package, regardless of whether those versions are permanent or were created for experimentation. Merges are a key aspect of a source code control system in general and are especially common in a branch-oriented VCS.
  • Making it easy to share in-progress branches and code changes between subsets of developers without requiring that those changes first be checked in to the central repository.
Conclusion?
Git is more than a VCS

Hack to Hacker: Rise of the Journalist-Programmer - journalismism - Gawker

Hack to Hacker: Rise of the Journalist-Programmer - journalismism - Gawker

Friday, December 11, 2009

web sockets almost working .... - Erlang Programming | Google Groups

Sounds obscure at first, but this offers amazing speed and moves erlang closer to the mainstream. Nice.

web sockets almost working .... - Erlang Programming | Google Groups: "Thanks now it works beautifully, I've enclosed listings below.

First reflection - this is amazing - the overhead is tiny and there is
no parsing
headers etc. The erlang just had to send

[0] ... bytes .. [255] and it ended up in the browser.

This will kill Ajax, keep-alive connections etc, now all google has to
do is ship
the parse trees of HTML pages instead of *text* and browsers can skip parsing
and concentrate on rendering and stuff will go fast ...

Now somebody just has to be the first to implement
http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-65
in Erlang"

Tuesday, October 27, 2009

Open file dialog

Spirit of Web vs. Open File

Below are a few notes on getting a file dialog to work in GWT. The assumption really violates the spirit of web applications as they are currenly understood because of reasonable browser security issues. One approach to making things work fairly easily is to have the browser based application always look at a web server, even if it is local. Then the file resources are easily accessable to the browser based application. Consider an application which needs to digest textual output from complex image processing tools: the output files need to be deposited into the server's content area. Then everything is simple. Even more important, thearchiecture of the system remains unchanged if and when the image server provides a richer interface than text files because one will always want the giant image files to be managed by the server.

EXT-JS
Like most programming languages, Javascript has libraries. One of the most powerful is ext-js, which is supported directly by the GWT. Read all about it here. The widgets of ext-js are also directly supported by Instantiations GWT Designer. There may be better libraries, Dojo certainly has a great reputation, but  GWT's support makes it a sensible first choice.
Still, I was disappointed that I could not find direct support for an open file dialog easily. Eventually I noticed a BrowseButton, which seems to to the right thing. In google code I found documentation for gwt-ext-ux (GWT-Ex User Extensions) which has documentation on BrowseButton. It looks like the right thing, although I'm not sure it allows one to read the contents of the file. I hope it will not be necessary to send the file to the server and then get its contents back, but that could work.
Its also possible that a web-oriented Python library/framework would do the job more directly without having to look at libraries like ext-js directly.
If it is a complex as it appears in the BrowserButton docs to do this, I'm disappointed. I think all this appears more complext than needed because I don't have much experience with Javascript (exactly why I want a library to hide the details).