I am finally getting around to building some useful tools in Pharo. I will try to capture more of my learnings as I go along. However, I was struck by something today that really warrants commentary.
One of the really great things about Smalltalk (and Gemstone - when I get to use that), is that one stops thinking about data storage. I have become so used to reading and writing to my objects - without the normal data marshalling - that I hadn't realised just how much easier it has made my life.
22/09/2009
No, seriously, XMPP really does rock!
As you can see from Peter's comment on my previous post, the XMPP integration is really cool. However, it is also something that one has to experience to really understand.
I added the app to the chat window in my gmail account. The app instantly appeared as being online. I typed in a few messages and they either controlled windows, or wrote to the transcript.
Now, clearly this is not some huge theoretical breakthrough in computer science, but for end users this is amazing. I could build a simple web site for e.g. brainstorming ideas, and ask people to add the app to their buddy list. I could broadcast a message from the app, asking for ideas about xyz, and moments later their responses would come straight back into the app. From there it would be trivially simple to split them off, write them to a google spreadsheet etc.etc.
What this is doing is putting some really powerful collaboration tools in the hands of people who really don't need to know much about programming at all. Fantastic :-)
I added the app to the chat window in my gmail account. The app instantly appeared as being online. I typed in a few messages and they either controlled windows, or wrote to the transcript.
Now, clearly this is not some huge theoretical breakthrough in computer science, but for end users this is amazing. I could build a simple web site for e.g. brainstorming ideas, and ask people to add the app to their buddy list. I could broadcast a message from the app, asking for ideas about xyz, and moments later their responses would come straight back into the app. From there it would be trivially simple to split them off, write them to a google spreadsheet etc.etc.
What this is doing is putting some really powerful collaboration tools in the hands of people who really don't need to know much about programming at all. Fantastic :-)
XMPP Rocks
While I was playing with the GWT system, the contents of one of the windows suddenly changed to 'XMPP rocks!'. I assume that Peter had sent a jabber message to the server, and the client has - almost - instantly updated that respective window.
I think this is hugely exciting. It makes me think of all sorts of new ways of working with web apps.
I think this is hugely exciting. It makes me think of all sorts of new ways of working with web apps.
Undeclared variables are global in GWT
Yes, I know this is a statement of the obvious - particularly given that it is really javascript that is executing, but I found it interesting nonetheless.
I was looking at the startup method Object >> helloWorld, when I suddenly realised that a number of the variables - that were holding windows - were not declared in the method. I opened a workspace and tried sending them messages. Sure enough, it worked.
I am gradually beginning to work out how to play with the system :-)
I was looking at the startup method Object >> helloWorld, when I suddenly realised that a number of the variables - that were holding windows - were not declared in the method. I opened a workspace and tried sending them messages. Sure enough, it worked.
I am gradually beginning to work out how to play with the system :-)
GWT Smalltalk becomes colourful
GWT Smalltalk is moving along in leaps and bounds. It now supports the user creation of multiple class browser windows - pretty useful for coding! - and also setting the css for elements.
At the moment one can't save code between browser refreshes, but that is coming soon. The bits I am really waiting for are:
Couple that with the ability to define the startup method, and we have the beginnings of a really interesting tool
At the moment one can't save code between browser refreshes, but that is coming soon. The bits I am really waiting for are:
- the ability to define HTML form and input elements e.g. text boxes
- The link to BigTable, so that I can read and write data
Couple that with the ability to define the startup method, and we have the beginnings of a really interesting tool
21/09/2009
GWT Smalltalk
And, all of a sudden, I am back :-)
Peter Fisk, who some of you may remember developed the Vista Smalltalk system, is also back. This time he has created a version of Smalltalk that runs in the browser. It looks very promising, particularly because it is designed to integrate with Google Wave.
If you are interested, please visit the demo site, which is here
Peter Fisk, who some of you may remember developed the Vista Smalltalk system, is also back. This time he has created a version of Smalltalk that runs in the browser. It looks very promising, particularly because it is designed to integrate with Google Wave.
If you are interested, please visit the demo site, which is here
28/12/2008
Objective-j versus Seaside
I have just spent the last few hours learning about objective-j and the cappuccino framework. In essence, the guys at 280 North have implemented the OS X Cocoa frameworks, in Javascript. The whole thing is very impressive indeed.
However, it has got me thinking about different ways of developing web applications. In the Cappuccino model, the client programming is done in objective-j, and is - essentially - totally separate from the backend system. The client application has no connection with the server language. All that is required is the appropriate set of REST services. This is obviously very different from the Seaside model in which the client application is, almost, a by-product of the Squeak code.
But which approach is better? Cappuccino looks like an excellent development framework. A lot of basic OS X code (written in Objective-c) can be run, almost completely unchanged, in objective-j. And, perhaps best of all, the documentation is very good. This is achieved partly through the efforts of 280 North, but also because the Cocoa docs match up very well.
On the other hand, Seaside offers much better development tools and a very different way of working. I don't know enough about each approach to really form a conclusion, yet. But, it is nice to be spoilt for choice :-)
However, it has got me thinking about different ways of developing web applications. In the Cappuccino model, the client programming is done in objective-j, and is - essentially - totally separate from the backend system. The client application has no connection with the server language. All that is required is the appropriate set of REST services. This is obviously very different from the Seaside model in which the client application is, almost, a by-product of the Squeak code.
But which approach is better? Cappuccino looks like an excellent development framework. A lot of basic OS X code (written in Objective-c) can be run, almost completely unchanged, in objective-j. And, perhaps best of all, the documentation is very good. This is achieved partly through the efforts of 280 North, but also because the Cocoa docs match up very well.
On the other hand, Seaside offers much better development tools and a very different way of working. I don't know enough about each approach to really form a conclusion, yet. But, it is nice to be spoilt for choice :-)
Subscribe to:
Posts (Atom)