Natty Narwhal confirmed my first love for the netbook interface..back in 2009, is the future. Its nice, simple, unintrusive and almost ready for the mass non-geek world. Well some loose ends still remain: VCD/ restricted DVDs and the Sun/Oracle JRE.. or other lil stuff that non-geeks will bump over.. and will need help.

Looks great on a 19″ screen.. Not sure if that is by design.. but 14″ and lower actually reduces the launcher menu appeal tad lower than one a 19″..! Simple n efficient with the dots on left, switch to the window you desire, 4 desktops by default with easy switcher and a search which is for now buggy , sure it will be fixed in a short run from now..

The right upper corner access to cop out, suspend, log out and the System Settings is just right. That top bar has finally worked out just perfect. Cant ask for more simplicity.. overall. Nothing of the zany feeling from Windows 7 , overburdened, artificial pizzazz which many do like.

Corporates.. well Evolution is just a long haul away.. If only Cannonical can do something about that..? or Libre Office takes over to give it the same overhaul as the Libre Impress… that one is real neat.. Unless Outlook can be booted out, Ubuntu will wait on the doorsteps where it ought not to.. Its got all the rest right there, from Samba networking, to Libre Office to Terminal Services Client et als.. Wine too where it matters.. Outlook on Cross Over office/ Wine is ok to talk off.. but that is not Linux pure and simple. That is hacky push to Linux and a workaround. Even a complicated Banking app thick client built for pure windows show.. worked well from Wine.. so there are its usefulness…

Dell needs to push back on its Inspiron Zino and the laptops and the rest..  I love the Lenovo – Linux Mint combo so far.. I guess can move over to core Ubuntu now.. not much that Mint will offer beyond tiding over some minor irritants for a non-geek. Maybe there is something Mint will offer post Natty … to keep its tilt  going..

DVDs of the full stuff, EasyLinux tips blogs , support et als.. have to go up..

What have I done so far over the virgin Narwhal:

1. Medibuntu all restricted stuff..

2. SMPlayer and DragonPlayer ( I love this actually though does not for now play the VCD.. that SMPlayer fulfills..)

3. Sun/Oracle JDK/JRE.. java6-plugin..

4. Chromium Browser

5. Changes in the /etc/default/grub for the GRUB2 changes: quick 3 sec boot, a splash image setup.. lower vm.swappiness to 10

6. On the laptop: use powertop and all tips to reduce battery burn downs..

7. Compiz settings manager and then settings there of for transparency and twiddling thereof.. on the gconf-editor a wee bit

Way Ahead:

1. Back to all tools and stuff I run on including Pharo , Groovy, maybe the others: python/ ruby I dont do much of now.. Tomcat, Spring Eclipse, et als…

2. Evolution.. will keep chugging and trying to use it.. till I find a day when I can throw Outlook away..

3. Use of  Ubuntu One.. 2 GB is way too small for longer term goals.. but nice to experiment my type of use..

4. Ubuntu on the Cloud with Spring+Groovy+Pharo.. here I move on…

Bugs:

Well there are many if I have stumbled on few on the first day.. tiny ones..

* .deb files downloaded dont install all that perfectly.. as it hops to a Software Download screen and then to prompt for Install that does not work well.. but then for geeks dpkg –install always works..

* try some more fancier stuff of multiplexing the Software Center operations.. and you can get a freeze..

* app shell from the compiz settings manager and others disappear.. compatability of stuff not in the virgin install could be moot for many..

* Skype pulse audio has never worked from a get go ever in Ubuntu.. but right now I am having issues with Del Zino back audio outs.. not recognized.. so no mike/ no sound from the back for now..

* Webcam: Iball F2F works ok.. but it aint as good as it might be in Windows.. but then i should use Creative in Linux..

* Wireless USB plugin: will probably have to repeat the old stuff of windows driver wrapper to get it working if I need it.. but dont for now with a wired connect..

Lots of great stuff.. so this is minor change for now..

Caveat: Enterprise integration as in through WebServices though a given in the SOA world is not a trifling to work with and is a non-integrated connection. Major Smalltalks do have it, but neither Pharo/ Squeak have it currently in a stable manner near term.

Smalltalk in general has been the most insular to integrate to the enterprise world of computing, due partly to the arrogance/ perceived superiority of its platform vis-a-vis the enterprise world of Java or .Net computing. Past now the decade of denials, all smalltalkers now should find it relatively easier to accept that there is undeniably large asset built in Java/ JVM / J2EE ( primarily Spring ) that is impossible to ignore any further.

To leverage the best the Smalltalk offers in its productivity, efficiency et als, I firmly believe a tighter and more inclusive integration with the Java/ JVM world is to be forged. Primarily what this means is

Direct call interface with JVM as in:

• JNIPort
• Redline Smalltalk

Integration with the J2EE stack

• Integration with Spring Architecture
  • Callable to and from the bean descriptors transparently
  • Utilize the interface to transparently use the now highly proven frameworks of JDBC, MQSeries, Reports as in Jasper or Cognos or thousands of other frameworks that we do not need to reinvent the wheel of.

The primary argument we have to make is that the business logic, complex enterprise development be doable from the Smalltalk environment while all the interfaces that is stable and proven in the enterprise world can be leveraged transparently.

Also this will give rise to the argument that smalltalk work can be safely integrated as a module in a larger context of existing framework of the enterprise IT architecture and be capable of using and sharing the end points as is required.

Pharo Spring: Post this preamble, to introduce this term, as it clearly suggests is deep integration of the Spring Architecture and Pharo Smalltalk. Spring Architecture greatly simplies the enterprise computing in the Java world for standard GUI interfaces, web world both browser/ non browser or a headless no web world. We may over a period of time see great synergies in our GUI world of morphic, Seaside and headless smalltalk that will offer a great incentive to enterprises to adopt Smalltalk as a module in their larger stack.

All Smalltalkers, despite some inherent dislike for the XML based descriptors and dynamism created by external configuration file, will find a huge common philosophical ground in the invocation patterns and orchestration that it brings in.

To integrate deeper with Spring what is required:

• Be able to have the Spring bean be transparently linkable between Pharo Smalltalk and the other JVM languages of Java, Groovy or Ruby.
  • Callable / reusable as a bean entity. This is currently proposed using the XMLRPC framework to expose a RMI/ Remote proxy mechanism as in a standard distributed world. Both Smalltalk and say the Java/ Groovy end expose their respective Client-Server XMLRPC systems to talk to each bi-directionally. With the two systems proposed to be in the same box/ LAN the inherent intranet latency will not be of huge concern. We can address additional performance concerns much later down the line for servers situated in different distant LANs in a truly distributed environment and even thereof I believe the latency can work towards optimizing it to less than the true EJB style RMI.

This will instantly enable a huge win-win situation for a smalltalk works to quickly plugin to an existing mass base of Spring systems deployed over their favoured App Servers scalably and interact with the existing assets.

• For a web world of interacting webservers, have a filter mechanism that allows the two systems to bi-directionally redirect links to each other. So a call to a link in Seaside though arrives at the Spring Server, it will redirect to Seaside/ AIDA and smalltalk server will configurably prefix the server:port and web app name prefix strings to the outgoing web page for all its links. All of this should be configured in a simple manner and through the use of configuration files in the spring stack.

Planned Work:

Stage I:

Currently Spring supports a horde of features that are extremely useful in the larger enterprise context but the minimum that I would intend to start and complete as a proof of concept and is usable as a start point are:

1. Filter adaptor to redirect calls
2. Bean transparency: bean definition has the extra tag to identify it as Smalltalk bean and have both singleton and prototype capability to begin with.
3. Integrate XMLRPC module as a scalable unit that can be used more pervasively. ( The issue of datatypes limitation and various other critical note not withstanding, it is far more performant, easy to adapt to than WS Stack. The CORBA/ RMI alternative is a complexity challenge not alluring currently. JNIPort/ Redline Smalltalk will need to mature and again will themselves present a complexity challenge, but perhaps the best alternative currently on a longer term. Alternatives will be explored as we move on to ensure the most performant mode to channel the Smalltalk-Java communications transparently for an end developer)
4. Pharo Smalltalk linked to the maven/ ant build script to be startable headless/ with UI as required for runtime deployment/ development. Make it integrated to the environment stack of the spring world
5. Integrate the Smalltalk code management through SVN to have a common code management mechanism
6. Integrate the build, Unit test mechanism through hudson borrowing from the existing work in that respect.

I guess this much with a small change here n there .. as we go ahead shall be adequate to be a usable proof of concept.

What do I have currently: ( Will update this as I go ahead )

• PoC on Filter adaptor
• PoC on XMLRPC
• PoC on the ant script to invoke PharoUsing Groovy primarily for all the PoC works.. to utilize the power of dynamic behaviour on the JVM side to the maximum, this can be easily converted to Java where required.

  Need to take it from this point onwards to a full blooded implementation, I can argue for with an enterprise to adopt.

Comments, suggestions… ?

Technology Directions from this point ahead:

* Cloud Computing: Hosted applications, scalable and change manageable

This depends on virtualization, multi-core computing and remote administration based

*  End device shift:

Enterprises may not reach there very soon, but the tilt to tablet computing is very much on. Tablets, touch screen devices will be the end points of the near term future. Native apps on the tablet is very much required , despite the web browser delivery model being the preffered model in a SaaS model. Better experience period.. despite HTML5 and any other tech..

Spring framework has made the leap from being a rationalized J2EE platform to a platform for the cloud.. How about making Pharo Smalltalk code being an exposed end point in the Spring world.. What does this mean?

* Extension to Spring Filter to redirect to Pharo Seaside… modules in an enterprise app. Simple win.. just makes a Pharo Seaside app as a distinct web module within a pre-existing / or new scalable deployment

* more important make the Pharo class a bean in the Spring world. Two way communication between the Pharo and Spring modules. Make use of Pharo class as a bean that can be ( either to begin with restrictively ) invoked from Java/ Groovy modules transparently and vice-versa. Property bean, as in Java world can easily be integrated to be able to exchange the values between modules. Currently we do have a workable XMLRPC bridge to do the two communication to pass values back n forth. Exploit it further, especially with a compression extension. Look at JNI later.. somehow I have vaguely uncomfortable feeling with JNI… not my cup of tea

* Then later extend this to other major parts of the spring world: Controller/ view/ etc.. that makes it work as if they are transparently fetched from the Pharo module.. plug n play with modules developed independent of each other in any langauge: Pharo or Groovy ( my preference) / Java / Ruby / others Spring integrates..

* Target primarily all of the business logic/ custom code that requires lot of debugging/ change management / complex simulation/ OODBMS connect in Pharo + the plumbing/ back end logic viz: RDBMS through JDBC/ JAX-WS/ Reports etc in Groovy . Also plug n play with pre-existing stuff in Java as many banks/ enterprise co’s would have…

Having plumbed through Spring and Pharo.. I do feel this is a very doable excercise and should have a huge potential to make a quicker win and entry in the enterprise mass computing world.

a) You sell the front end/ infrastructure/ capability of Spring in the advertising of the solution framework..

b) Pharo Smalltalk’s great power in debugging/ simulation/ pure OO / OODBMS is well exploited

c) You get the Java / Groovy world also for combination: JDBC can be substituted but not matched in performance and ten other reasons.. Groovy’s SqlInstance or Spring JDBCTemplate will take us a longer while to reach in Pharo.

JAX-WS and Jasper Reports, Terracotta ad nauseum as Java frameworks go exist heavily in the mind share of many.. and utilizing them is better for Smalltalk.

d) Eventually once Pharo Smalltalk is embedded and the focus/ lights have turned on.. the future possibilities abound about how far one can take onto replacing other modules with a Smalltalk module.. but that is a slow game

Of course for the enterprise world to have it quick Pharo entry, the whole framework will have to be super easy to setup and mix n match.. the way Ruby n Rails knifed through the small-medium web app world..

e) Skyway Builder is an example .. of very quick setup of fairly complex rules engine driven, drag drop world of composing a Spring app. Pharo Smalltalk integrated with Spring should be able to work within this too..

Pharo already has broken a taboo in the Smalltalk world: talk of Java framework integration where it is needed : Hudson, Selenium.. and few others.. how about going the Jasper Reports, JDBC, Spring, JAX-WS route also. Easier selling the story to an enterprise shop..

Let us see.. if Pharo can go in and play this well by the next year.. The baby is going to be a year old coming Jan..!..

-Skrish

Should do it on a regular basis and I guess for 2 hours with a short break. Go through the entire details and enable them to get started right after productively if they so wish.

Coming back, I though it would be great to have two versions or probably more of the smalltalk cd I would want to hand out:

1. Cd containing scratch ( elements, BYOB , Panther too ) , Etoys, plopp , Dr Geo, Magic Words, all that can be used by kids right from age of 4-5 … Onwards to play n develop with. Videos for Etoys , scratch and others with other projects of interest…

2. Pharo n squeak cd with seaside bundled env , groovy with all its package, XMLrpc enabled system, all books relevant, videos to get going with. If I can have this as a DVD inside a live Linux or as installable portable apps even better… Or a VM …

These are a must to get it spread wider to the entire sub continent…

Book on smalltalk covering these would not be out of place now..

Get going… Sooner rather than later..

Had a quick take on the agenda list of presentation, a long one hour open house discussion with surprisingly one tech journalist with interest in Smalltalk : Prashant, a EToys researcher: Subramaniam and long standing Egroup member Sanjay Mini..and a neat presentation from a Scheme/ Erlang enthusiast Vijay Mathews

Presentation covered  Seaside by Pradeep, Intro to Pharo/ Markup Builder by Kaarthiga , Etoys : Subbu and Scheme  by Vijay..

http://tech.groups.yahoo.com/group/smalltalkindia/files/techmeets/dynamictechmeet301010/

are the list of presentations currently available..

Quite efficient and neat stuff..

modified from: http://www.javaworld.com/community/node/3881

The need to stop in a particular method is served by using self halt. but that is a little kludgy going and putting in this stmt through the code sections and cleaning it up. The standard debugger capability as in VW or VA with breakpoints is what is needed.

To be able to get started in a simple manner, i just hacked into the OBCommand hierarchy and put in this two cmds that help me insert a self halt. and remove it.. at the top of the method. but it is not good beyond a point..

* It creates history of method changes each time you put in the self halt and remove it.. I could not figure out an easy way to switch off the method changes log for such changes

* It is not currently supporting the right click insertion at the cursor point.. and removal by again the cursor point near/ before or after the self halt.

* Better still just simply a debugger point with capabilities of VA/ VW.

But for what it is worth I put this piece of code for anyone to tinker further with..

http://www.squeaksource.com/PharoGoodies/AddRemoveHalt-Skrish.2.mcz

Ok, I did have the push / or the shove coming in for the use of Pharo XMLRPC code with a colleague Vibhu M. putting in the effort to try out the old existing code, getting the tests to run on the first cut.

I have modified the XMLRPCTest and XMLRPCServerEchoTest to complete the loop.

Two issues that are from Komanche Server package:

BlockClosure >> processHttp

uses fixTemps message that is deprecated in Pharo, causes the server to freeze. Either run the server in a fork / or remove the call to fixTemps or override fixTemps to doNothing rather than the modal warning dialog.

This one I need nail it down, comes from some basic package one off: from:to: .. has the trailing colon missing.. probably in KomServices package, which I override by loading KomHttpServer later, This also helps in having HttpService available in order.

Prereqs:

* KomService

* KomHttpServer

* XMLParser

* DynamicBindings

all in this order works fine.. guess should have it in ConfigurationOfXMLRPCClientServer created to have dependencies marked.

http://www.squeaksource.com/PharoGoodies/Spy-Vm-Skrish.Pharo.5.mcz

http://www.squeaksource.com/PharoGoodies/XMLRPC-Server-vm-Skrish.15.mcz

Action items are:

* make it work in a performant manner against Groovy with a seaside front end picking values through Groovy to various DBMS using JDBC DB2/ Oracle/ SQLServer and others..

* Make it complete with respect to prereq/ dependency loading, all corrections as reqd even for fixTemp etc..

Per se it is ready to roll out for my enterprisy stuff.. all trials/ POCs can role out with this to the extent required.

* convert to VisualAge..? or is it already available there..?

* compare performance time against direct DB connection for RPC fetches localhost

* compress the server sends to achieve some performance improvements with both client/ server fixes to do compress/decompress.

Thanks to Vibhu to get it going.. I was prevaricating on getting on this for a while now..

* New TabOrCsvStreamReader class

* Table now handles different text types per column

* scrubbing the code.. infact that is the major effort to ensure the base framework gets to be flexible , clean and easy to extend..

many small things I have been doing, adding unit tests, cleaning existing ones, etc.. that I have not tracked changes per se.. but sure that this should be free from any known bugs/ issues I have noticed so far..

* need to clean up on few more things though: trim any other text that gets through viz: css etc.

* xmlPreProcessor needs to be better.. to include the already existing api for encoding etc..

generally review the XMLBuilder more intensively to ensure perfect adherence to complete spec of W3C org..

Updated with a bug fix to 2.2:

MarkupBuilder-Skrish.alpha.2.2.mcz

* indenting: clean from grounds up through a single method call that also controls dumping the string without indents if you so wish..

* HtmlBuilderTableWidget: component that should now have sufficient basic capability to play with.. including reading csv files/ PropertiesBean/ plain collections and all marshalled internally as PropertiesBean.. easier now for further extension to use it in Forms etc..

* More exact matching tests and confirmation of XHTML conformance for all tags emitted

Still there are I believe some more minor stuff to iron out to make it perfect as in 100% perfect compliance in every minutae I can pick on..hopefully target it through the nights every week to complete by weekend.

For now I will link it up here and post a copy on squeaksource/PharoGoodies too.. but need to control the versions I dump..

MarkupBuilder-Skrish.alpha.2.0.mcz

Working on this bug:

Needs a small patch on WACallback>>evaluateWithAllFields:

evaluateWithFieldValues: anOrderedCollection

self evaluateWithArgument: (self valueForField: ((anOrderedCollection select: [ :ea | ea notNil]) at: 1 ifAbsent: [ nil ]))