Claudio Campos began to develop professionally in 1989 (at age 17), and independently since 1995. In 1997 he made ​​his first contact with Smalltalk (SUGAR), and from there began a journey with object technology, working with Smalltalk in various domains: class 3D library, smalltalk on mobile devices with reduced resources, R & D in computational linguistics and semantic processing, GIS and logistics.
Note: SUGAR "Smalltalk User Group of Argentina" was an organization that joined all the Smalltalk programmers in Argentina and the first site in Internet related to Smalltalk in Spanish. 1992-1997.

Could you tell us a little about your experiences with S8. The use I have given to S8 is very broad. Maybe I can talk about the latest developments I'm doing in Android (using A8). Some of them are internal, parts of a commercial project. I have not really much in production running S8. Instead, what I am doing is an evaluation of costs associated with platform migration/upgrade. As everyone knows, this kind of tasks take time. Times to find the way to innovations, time to prove that underlying products really work as it is supposed to work. Because there are things that have nothing to do with Smalltalk but with the execution platform that's underneath.
For example if we talk about NodeJS while there is some stability in the project, there are constant changes. Also in case of HTML5 on the desktop level as Mobile at times there were things that were not supported in the Mobile and other times yes. So some tests you are doing are quickly invalidated. Specifically in support for HTML5. This means that today, in my case, all this is by way of assessment. Not in a mature and functional development.

What problems you see in HTML5 support? I see no problems in particular in S8. There are times that are required to spend to see whether a particular feature works or not. At first time began with future plan of using PhoneGap to make a hybrid application, but after that the PhoneGap library entered in a phase of instability. Anyway were projections. In my activity, I try to search the most practical. I am one-man so I do not have a research staff to delegate work. I try to find what works for me and give me some projection in time. It should not be too much marginal and must look modern.

...more close to standard. Yes ... I was always a kind of marginal. More than ten years working with Smalltalk, that's marginal. But to live with Smalltalk I can't go to the other end. So I have to evaluate where I'm going to move while continue development with Smalltalk.

and what were the problematic issues you saw in PhoneGap? There are things that were working with PhoneGap and actually do not work ... I did not invest more time to see how many and which things do not work anymore (broken inside PhoneGap). Probably trivial changes need to be made in code to update. But even if one is experiencing and evaluating, that makes us generate some stinging and leads to think that there would have to wait the PhoneGap API to mature a bit ... This is always in case you need to access native features of a device, in multiple targets, if we are talking about PhoneGap in particular.
Last time I did several cycles there. I developed a geolocation application. It is an application that has to do with the activity of the company to which I am developing, which is the same that was presented in Smalltlak 2007 where you can access the device's position and makes a geolocation of places where people can go, which are the collection points that the company has.
At that time, I had thought to face it with PhoneGap and S8 to have something working on iPhone and Android but later... we are moving forward with an application for Android only. With the possible use of PhoneGap in the future, to include iPhone if it starts gain more stability as time passes. So, actually I implemented all (including geolocation) with S8 alone.
On the other hand, we have an application for internal use which is Android but we depend on the availability of some industrial devices.
Note: the PhoneGap framework has been updated to a complete support of Cordova targeting more devices.

What is that? Industrial devices are devices that are prepared to survive in harsh environments. They have anti-shock shells, secure access, etc. They are not standard consumption devices. For example in this context we are talking about people who drive trucks, they can drop the device, there is dust, rain, etc.. For that, we actually use Windows devices. Now there are some new devices (Android). At the time we had evaluated put protection to common Android devices. This is a larger application, no matter if it is not an iPhone application. In this case A8 is perfect, because it is well made, it has a very good integration with the Android SDK and Java layer, at least of the possibilities offered, and what can be done. It is very well resolved how to access local resources within the same application, packaged within the same application and also access remote resources. You can do cross domain request where you can access local and remote resources. In the geolocation application case you have some assets that are images, pages and S8 files that are loaded by the installation of the application. In addition, there is a Smalltalk system that serves news and information.

what about map issues? The map is done with the Google Maps, it's all HTML5. This is a web application running S8.

Coltex system: planning and route optimization

so, it would be enrich the map with all assets and S8 generated info. That's right, it's a local application (installed) running a WebView on the device. But Web, in the local and remote sense. That is, the application interacts with a remote system that serves Smalltalk application pieces. From the server I am accesing information, objects and pieces of chunk to update, if I need to update/customize the application.
On the other hand, I have other things done in other Smalltalks; I'm working on the migration of the entire development platform. I worked at the NodeJS server integration. For eight years we are working in an own application framework. It is completely dialect independent, so migration to S8 would be quite possible. I have to define some infrastructure changes. The applications we have today are things that work on a server and in case of migrating to S8, it would work on the client. This will change the way of working, is a major change. The server will lose relevance.
It is not my intent to port these frameworks on S8. The idea is doing a cycle on these frameworks, and do a complete rewriting to S8.

...but some of that has been migrated. Of course, I hooked the domain model in a S8 image and I have done persistence through the browser. It works fine.

At this point ... that was an evaluation. Yes, I agree. If we were to formalize a more structured speech I would say my specific tests taking the domain model of the system -which is quite large, is a logistics system, with planning, with management, etc.- are positive. This is not only the geolocation system. The latter is a system utility. I am referring to the mainframe, the system of the company. According to my evaluations is perfectly possible a migration. It will require changes because instead of running on the server, it will run on the client. So there is adaptation work to do. I'm not going to do only adaptive work, I'm going to start a new implementation cycle with this new model.
Currently our applications are Web, working on Smalltalk -I mean the central enterprise application- this application has a model of complex information management of how to carry out all logistical planning of the company. The application won an award in 2010, came second in a logistics competition and first in coke , so the application has some notoriety. It has management optimization tools with optimization over 30-40 places to visit in Europe, knowing which are the shorter trips, coordination of time, a lot of things. It has a mobile module to record all the information offline.

so, all this is implemented in Smalltalk Web. All we have is implemented in Smalltalk and there is a web and a desktop interface. The entire application is Smalltalk and the UI is a bit "negligible" in the sense that application is not influenced by interface part. We actually have a web interface, a Windows Mobile interface, a Windows desktop interface, and now we have an Android interface, always using the same application from behind.

This new development cycle on S8 you name, how to direct this? S8 has so many ways to run... S8 is as wide as Smalltalk is, but broader because it is modern. Why I want to move to S8?, because I have a modern execution platform, more varied, more places to run my objects. Today I can implement, with S8, 64bit NodeJS servers, as well as mobile application running on Android, or iPhone, or iPad, as chome extension, or any browser that supports HTML5 and ECMAScript5.

What is the benefit would you see in this new implementation cycle? Access to new execution environments. The cost of migrating the whole system is the same to other smalltalks. But why should I migrate if I'll have the same? Before I used to work in the browser with javascript. Now I have the opportunity to work in Smalltalk. I have Smalltalk on the server and in the browser, with all implications. To be more specific, if you build web page, or any UI, or even any test you do in a browser, you will have to deal with browser tools, the firebug, etc, very limited tools, in addition to all validations, calls made to the server, using ajax, etc... With Smalltalk it is interactive, you got a full environment in the browser. This gives the opportunity to experience things not previously thought because I did not want to waste my time. While javascript is dynamic it does not give odds that Smalltalk does while you work in the same way. So is the same underlying execution platform (homogeneous and modern, all is anObject). S8 raises an opening of something that previously we did not have, because javascript tools are rudimentary (low level). At server level, raises me an opening to an execution model that, seems to me, much more modern than common Smalltalk virtual machines for server.
If you want to put in terms of gain, it opens up possibilities, it opens the game in a way that was not possible before.

whenever we talk about migration, we talk about cost... I never migrate. Migration is to take what is written and slap it a bit to run in elsewhere. As smalltalker, you always do things again. Sometimes commitments force to us to do a raw migration but later, you realize the system evolved.
Over time we build a web application layer independent of dialect, so I could put whole thing in S8 and continue working in the same way, but ... if I work in the same way I lose or leave advantage of all the possibilities that S8 opens. I could put everything on the server with NodeJS and continue to work the same way in the browser. Now I will work both ways. With Smalltalk on server and on client. And if I can work with Smalltalk on the client, I can connect two clients without the server in the middle...

At this point it is opened a range of possibilities than anyone expected... I think that's the key to what is interesting to raise, at least is what I think from my point of view. I am more active than thoughtful about these things. I tend to do, instead of theorizing why I do it. In the case of Smalltalk you go flowing in the doing. You see, all I can tell you has to do with the perception with working in smalltalk.-

Sergio Garcia Canto has a long way as a teacher of OOP (UBA, UNLaM, UB), as well a solid Smalltalk developer experience in industry. In recent years he had the opportunity to approach the world of entertainment, specifically in events and games area. Some of their experiences back to the beginning of S8, where he could go different ways of working, down to shape their own development environment.

Could you tell us how is your experience with S8? I find S8 very interesting. I have quite a few things done in Smalltalk, on the other hand I note Smalltalk support was declining fairly. In addition, there is also the fact that some Smalltalks became very unstable, too many versions, etc. In my opinion, today, Google is leading the technology way. Things are developed with similar characteristics to I develop in Smalltalk. For the most, simple and very concrete things. These are the kind of issues that I usually investigate in Google and I try to capitalize on my work.

For example? The Goolge Maps, is very large and works very fast. No flash, just HTML5 and javascript. I was already guiding using HTML5 + Javascript. In many ways help me to simplify my working way. In meeting S8, I thought it was very good because it is a way to follow the footsteps of Google, using all the experience that I have done in Smalltalk. This allow me the facility to move many code already I have.
I had a work around August 2012, a business meeting (Movistar & Telefonica) whither leaders to evaluate how to improve things. And I asked for two things for that event: a game, which was played on a multitouch devices, a trivia. And second, I was asked to do the assistance of group dynamics. Each 8 people had a computer. That is usually done on paper now I have to virtualize on computers.

Could you talk a bit about group dynamics? These meetings are about thousand people, which makes it very difficult a pooling, or can read everyone says to draw conclusions. So there is a machine every certain number of people (in this case were eight hundred people and was a notebook every eight people, with about hundred tables). Then a topic presentation is made, and then asked people to write on three points a short, or whatever caught his eye, or whatever is usefull to their daily work of what was previously discussed. There are many group dynamics techniques, but in this case it was used to record the closures. The person guiding the dynamics could say, "Well, lets look what certain table said".
To make this from scratch, I had less than a week. And the soft had to work well. So I decided to try S8.
I was already doing things in this style. I mean I've done things like that for other events and it has been doing on javascript on the client and Squeak on the server. My idea with S8 was to have NodeJS as a server and S8 client.
I have become a day without sleep, less than a week to do something and besides all these marketing things spent a lot of money. It can not fail. A lot of pressure. But, I know this is the best way to test something. Under pressure with little time is the best way to test something.
I did it with S8, the game went well! I only had trouble with accents and 'ñ', an issue of character encoding that I could not resolve properly. What I did was something very simple, the server will change these characters for three ASCII characters and sent the questions in this way from the server to the client.

What was the game about? questions and answers? It was trivia. They put ten questions with a variable number of answers to choose from, and had to take the time it took to respond and a way to grade the questions. At the end the person entered their identification, and the time and the score was shown. Then the highest score was the winner.
What I had it was a configured approach, it was a text file on the server with questions and answers. Here was the problem, I was carrying it through ajax and when info arrived, it had changed characters. In addition, I decided to try the local storage on the client. It worked very well.

So in this case the the local storage was used as a distributed storage and then you caught everything that was recorded on the clients? The issue was very critical, I had to take several precautions. What people wrote, traveled to the server at the same time tucking into a file on the server (I did not use database), but also was kept on each client. If I had a problem, I could take up all results of a particular client.
At that time I came to some conclusions regarding the S8. If I had done the same thing directly in javascript using a graphic library like ExtJS (although use S8, also use ExtJS ) I think I would have taken longer to achieve what I did.
Using the S8, I built a mechanism that whenever open a browser (Chrome in this case) I open another browser next. So in latter I had two text panels. When I wrote Smalltalk code, it is evaluated on first browser. I used a browser as an area of development and another one as space where things ran. I was creating and working in that way, working a little in one, and started to take shape on the other, testing on the other. If I had working on javascript I should have written ASCII and run all at once and see what happened.

...there was the usual Smalltalk whiff. The S8 that I used, did not have tools like Hierachy Class Browser (Note. At the time of this experience was not yet WI8 + UI8). It was a workspace and nothing else. Even so I could work faster. Working like you work in Smalltalk, building in-place with "hands" and editing at the time. Suddenly when I had a problem with any method I wrote the name of class #methodDictionary #at: the method name and the source appeared to me. In that sense, it was done through sheer grit but I think I made much faster than if I had done directly in javascript. I missed a lot of tools. The debugger is vital (Note. At the time of this experience was not yet U8 Debugger)

Very impressive. How trivia was resolved? The trivia was installed locally. That was a mistake. Squeak was installed as server on each computer, and Chrome as a client calling the loopback address.
If you installed the server in a single place and centralized the results, it was easier. That would have been much better. But there was no time and did the best I could, I could not coordinate with people support.

What about group dynamics? At certain moment someone said "first conclusion". So from server I sent a message, something like, "first dynamic enabled". And automatically on the client screen appeared a blank sheet where people can respond. Eventually response was sent to the server. So again someone said "let's turn to the second dynamic" and I empowered the second dynamic and so on.
That worked well. I had only one stumble -we must take into account all pressure this experience mean- in a moment someone reports me that trivia did not record the answers. I went to the machine that was marked as "problematic" and through the console started opening codes smalltalk methods and started to put "console.log" to see where was the problem. And there on the same client, which showed the error, I found the problem and fixed it.
So far overall I thought it was very good. But at the same time I was a little disappointed not having the development tools. Furthermore we have all the limitations of sandbox, the security scheme. Although with local storage you could simulate a file, etc.
In other time I was called for another promotion of a product. This time was required interaction with a tablet. For this I implemented a slot machine. This is where I had animation needs.
At that moment U8 already had CHB (Class Hierarchy Browser) and Workspace. So I mix U8 tools in my S8, to have a "standalone" development kit. In addition I kept the philosophy I comment before. On one hand I have a browser with development tools and other blank browser to capture and evaluate what is developed. In this enviroment I built a remote CHB and a remote Workspace. When development begins by entering the url, it opens a blank Chrome and Chrome side with another toolbar. To begin my development I open a remote CHB and just adding stuff.
The first thing I did was add an image moving. For this I used what is called, in DHTML5, the 'Canvas'. Later I added complexity in shaping movement speed and acceleration, to achieve mechanisms that allow me to do things like move an image with such speed, and then moving an object at a specified acceleration up to a certain speed. And that would enrich the animation to go it closer to what I needed in the slot machine animation, the "jackspot".

This process was very Smalltalk style. It is like modeling plasticine. As a child learning. You play something and see what happens. If it falls then you have to modify or put something else, etc...

...latter is important. S8 idea is to continue to keep the Smalltalk spirit. When I started using the canvas, I went to the Internet and look for an example. Something affordable in javascript and simple. After testing (making sure it works properly) I put in smalltalk. Once these chunk of javascript inside Smalltalk, the next time I have to use it, I have not to write everything. I need to write three words and that's working.
When I had to do something new, for example a div element always appears centered, this was investigated once, then I implemented a message that said "place the frame centered" and forget about it!
Suppose to do that in javascript you have to write ten lines. From my experience I know that these ten lines I could automate six, seven, no more. There are three I have to change every time I use it. It is not the case in Smalltalk. It's very simple to reuse things.
Before Telefonica event, I had four previous events. Complexity and pressure is always the same. The previous times there weren't S8 I had to work all in javascript. I was accumulating javascript code from those experiences...

We could say prior to S8 you already had javascript expertise. That's exactly why I talking about this. I am comparing the cost to find a chunk of used code I could reuse (because I knew that chunck of code was done ) but finding it was very expensive. And besides, I copied and did not work... had to copy everything and delete a lot of lines. In contrast with S8 never happenend.
This comparison seems to me not a subjective issue...

The use you've given S8 is mostly at very low level. Even without using almost nothing but a javascript console and text editors. Your success may also be due in part to your long trip as a javascript programmer. Surely when the tool reaches a certain maturity (Note. At the time of this interview WI8 + UI8 or U8 Debugger did not have the level of development they have today), people with less expertise may be experiencing it more accessible. ...at the beginning of development I use either javascript or smalltalk (using the syntax of {}) as development move forward, the use of pieces of low-level code (javascript) can be reorganized. The use of S8 helped me organizing code, helped me into abstraction. Something I needed. I needed build abstractions to develop quickly.
Another aspect to note is that rearrange classes in javascript is not trivial task. In Smalltalk it is easier to detect a missing class in between. That is, detecting scattered behavior on several clases and these bits of behavior could go in one class, I seem to be more noticeable in Smalltalk. To see this in javascript code and reimplement it, requires that developer has to have a very large abstraction capacity , almost like a chess player. Having everything in your head and see the picture in advance.-

It has been nine months since Newsletter Vol. 1. Miguel Isasmendi has made ​​significant progress in MVP development. Miguel, could you talk about current state of development? The current MVP contribution does not reflect the latest advances. The development contribution still needs testing. So it is not fully "publishable" yet. The most visible changes are I left the visual interface tabular model (using tabs) to windows based visual interface. Obviously it can still be configured to return to that model or another if necessary.

What other advances could you tell us? The TreeView has support for lazy loading, there are context menus, tooltips, windows, a kind of desktop where windows reside. I could decouple widgets styles so now I have themes. The MVP comes with two themes: the default theme and Metrostyle. This mechanism allows to work on changing the look from the outside of framework. Similar to HTML.
We should also give mention to the consolidation of JSON as a view serialization.

MVP with MetroStyle theme

What about this serialization mechanism? Basically the structure and configuration of the views and presenters are serialized in JSON. In other Smalltalks like VisualWorks and Dolphin serialization type is different.
Moreover there is still no ViewBuilder. On my to-do is located ViewBuilder; to work manually on JSON is especially cumbersome for complex views or presenters.

How deviated development of what was projected? For example in Dolphin you'd commented some commonalities. I do not deviate much from Dolphin. The metaphor built for Dolphin, as a mechanism, it remains. Mi MVP implementation internally works differently. For example, in my views MVP comprise the same creation protocol presenters. I lean management handling evenly and, as I said previously also change the interaction of objects that perform the deserialization to get it.

What new features can be expected in the future implemented in your MVP? Even I need to develop a taskbar-style bar where windows is minimized. Say, there are currently managing windows but still very basic. I need a layout mechanism configurable component-level graphics objects and separating the implementation, etc. I also lack all part of confirmation modal dialogs, error and warning. At more general level I am focusing all efforts on the browser on increasing usability and development framework. Achieving a more powerful tool closest thing to a basic IDE.-

Betaworks meetings are periodic meetings (one per week) in a day and schedule of fixed duration, open to anyone registered as U8 user. These meetings aim to make progress together in U8 development and answer questions related with U8 (and S8).

Want to join next meeting? Send an email to info@smalltalking to get the date/time/duration and access information to enter the virtual room. Also you can check smalltalking mail list for a betawork announce, or you can read more information in our swiki.