Documentation is spare and therefore a simple code example how to create a zip archive (and as a reminder for me):

| cfsPath zipArchive |
"where all my files are located"
cfsPath := CfsPath named: 'D:\json-sendelisten'.

"my zip archive to write"
zipArchive := MZZipArchive openWrite: 'd:\test8.zip'.

"i want to add all file from that directory ..."
cfsPath fileEntries do: [ :eachFileEntry |
  | singleFile fileContent |
  singleFile := cfsPath append: eachFileEntry dName.
  
  "method from MSKCfsExtension"
  fileContent := singleFile mskGetBinaryContent.	

  zipArchive 

    "create a current file within the archive"
    createFile: eachFileEntry dName 
    comment: '' 
    method: MZConstants::Z_DEFLATED 
    level: MZConstants::Z_BESTCOMPRESSION;

    "write the binay content of the file to the archive"
    write: fileContent ;

    "close the current file in the archive"
    closeCurrentFile.
].

"close the archive"
zipArchive close.

There are languages out there, that have a more complex syntax than Smalltalk has – that is right. But is this complexity really responsible for the (as mentioned) lower productivity ? I would not think so: actually Smalltalk in the hand of a “careless programmer” (or limited ?) is also bad.

I would also argue, that all the other languages have enough syntactical structures to enforce information hiding – but the programmers decide if they use it. Therefore it seems to be more a users problem – and not a language one.

The problem with the other languages might be, that they would like to build/offer a (forced) structured home for those “careless programmers” – perhaps because most of programmers are “careless programmers” ? – by introducing lots of keywords convering the (today hottest) computer-program analyse or design structures. This is a bad evolution – but it is much easier for large companies to work with these languages to get at least some structure in their projects.

And after all: not only Smalltalk has no real answer to the Internet: C#. Java, Pascal, C++ – all have to compete against Javascript and most of them might fail and look for their own market position to show their strengths.

And for all Smalltalk friends: ask what the hottest topics are today and what can
the various Smalltalk implementations offer here …

The best thing is how Amazon crew tries to get rid of this shitstorm by writing own good critics on facebook and twitter … to be able to delete the negative postings after some days …

… but they made a mistake … the crew communicate with each other via public communication channels … and some other listeners just made some screenshots of this communication … before those postings had been deleted again:

Other screenshots are available showing the “good” postings … and even postings showing, that the original posters noticed the problems.

Nice, nice …

Internet gehört inzwischen zu einer Basisstruktur und ISDN ist Technik von gestern und was war ich froh, als wir LTE bekamen – endlich Internet in guter Qualität.

Aber nun bekam ich die Kehrseite von LTE zu spüren: LTE ist ein mobiler Dienst (mit einer normalen Handy-Nummer) und jeder Kommunikationsdienstleister hat einen “Mobiles Bezahlen”-Dienst und der ist halt immer aktiviert.

Und so reicht ein einfacher “Klick” in einem PC-Browser aus und man hat sich ein “Abo” eingefangen. Ganz beliebt für diese Fallen (einige sagen Dienstleistungen dazu) sind “Quiz”-Seiten, die sich auch an Kinder wenden. Ab und zu werden Nachfragen gestellt, die nicht ganz eindeutig sind – und ein falscher Klick und das Abo wird sehr schnell eingerichtet: €4.99 jede Woche. Kinder (und auch Erwachsene) sind damit überfordert.

Das summiert sich …. und das Abbestellen geht deutlich umständlicher als das Bestellen.

Also lieber Eltern mit Kinder: Surfen via LTE ist eine Zeitbombe.

2360000000 / 2000 -> 1.18 Millionen EURO/Jahr -> 98000 €/Monat

Knapp €100000 pro Person und Monat. Nun ja, dann wissen wir ja, warum die Banken so riesigen Renditen verlangen müssen.

Wie bereits beschrieben, sollte das Endsystem auch als Einzelsystem unter Windows nutzbar sein. Daher habe ich ein Installationsscript mit Inno Setup auf Basis der 8.52 Serverruntime geschrieben und kann mit jedem Satz neuer ICs neu durchlaufen werden. Bei der Installation werden die üblichen Icons und Einträge erzeugt:

Der “lokale” Server lauscht nur auf der 127.0.0.1 und der “normale” Server auf der öffentlichen Adresse – kann also auch von anderen Personen im Netz erreicht werden.
Was noch fehlt ist die Portfreischaltung der Firewall – von der ich noch keine Ahnung habe, wie das geht .

Durch die Skripte wird der Smalltalk-Server gestartet, das Seaside-Interface gestartet, die ICs gelesen und diese melden ihre Seasideanwendungen bzw. jQueryMobile Anwendungen an. Das System startet einen Browser mit der korrekten Adresse, was in der Regel zu einen Login-Dialog von Portobello führt (hier mit einem Dialog für regsitrierte Benutzer bzw. einem Guest Account):

JQueryMobile
Portobello benutzt JQueryMobile als Oberfläche – und zwar den aktuellen Port 1.1.x von Squeak. JQueryMobile habe ich ausgewählt, weil alle notwendigen Resourcen bereits enthalten sind und man daher eine Anwendung ohne zusätzlichen Http-Server ohne Probleme laufen lassen kann. Weiterhin kann man damit alle Devices (vor allem die mobilen Geräte) erreichen.
Und wenn man trotzdem eine PC-Browser-Anwendung haben möchte, kann man die durchaus aus einer jQueryMobile Anwendung heraus in einem eigenen Fenster starten (so macht es auch der NAS-Hersteller QNAP).
Login-App
Wie oben bereits gezeigt kann man die “Login-App” konfigurieren, ob sie einen Guest-Account zuläßt, nur registrierte Benutzer erlaubt oder Zugriff nur als guest ermöglicht:

Die Login-App ist eine der beiden sogenannten “Basis-Apps”. Diese sind in einer Konfigurationsdatei beim Start zu definieren und ein Entwickler kann diese “Basis-Apps” mit eigenen Versionen austauschen.
Market-App
Eine weitere “Basis-App” ist die “Market-App”, die dem Benutzer die im System gefundenen “Apps” anzeigt. Der Benutzer kann die “Apps” durch einfaches anklicken starten – und wenn die Anwendung beendet wird, kehrt es zur “Market-App” zurück:

Die “Market-App” ist ebenfalls eine Basis-App und kann daher vom Entwickler überschrieben werden.

Struktur von Apps
Für den Anwender werden die “Apps” (durch den Entwickler – dazu später mehr) in Kategorien eingeordnet: “Spiele”, “Netzwerk”, “Demos” oder (wie im Screenshot) “Portobello System”. Dadurch kann die “Market-App” die Apps strukturiert anbieten.

Für den Entwickler sind die “Apps” (jQueryMobile-Pages) einfache Smalltalkklassen, die in einer Smalltalk-Application definiert sind. Smalltalk-Applications können mehrere “Apps” definieren. Eine oder mehrere Smalltalk-Applications landen später beim Paketieren in einem IC.

Dem Entwickler stehen vordefinierte Protokolle zur Verfügung, um beim Laden eines ICs die neuen “Apps” zu erkennen, diese im Market zu registrieren (damit sie dem Benutzer angezeigt werden können) und damit diese “Apps” ihre eigenen Datenstrukturen eventuell aufbauen können bzw. laden können.

“App”-Beispiel: SystemInfo

Am Anfang habe ich immer “System-Apps” geschrieben, die mir Informationen über das packetierte System gibt. Und was liegt näher, als die Systeminformationen anzuzeigen, die VA dem Entwickler anbietet.

Zusätzlich enthält diese “App” auch ein Verzeichnis aller geladenen Smalltalk-Applications mit ihrer entsprechenden Versionsnummer:

und
.

Das zu dieser Anwendung zugehörende IC (“unx_sysinfo.ic” bzw. “win_sysinfo.ic”) ist 28 KByte gross.

Das eigentliche Framework (das “Kern-IC” für Portobello – “win_portobello_base.ic”) hat eine Größe von 108 KByte.

Bisher habe ich für Portobello meistens meine Serveranwendungen umgeschrieben – nun laufen sie halt unter Portobello und bieten ein jQueryMobile Interface für die Konfiguration der Serverdienste an.

Aber auch zwei Anwendungen wurden bereits geschrieben, die sich an “Endnutzer” wenden – aber mit jeder Anwendung hat es auch Änderungen am Konzept gegeben.

Warum ?
Einer der Stärken von Smalltalk ist der hohe interaktive Grad der Entwicklung. Ein wenig anders sieht es aus, wenn man den gesamten Entwicklungszyklung betrachtet – bis hin zum Packaging.

In älteren Versionen (vor 8.52) von VASmalltalk war das Packaging von Seaside-Anwendungen ein Abenteuer und sehr mühsam. Ein Grund ist sicherlich, dass diese Quelltexte von Squeak/Pharo kommen und Referenzen in den Quelltexten beinhalten, die der Packager von VASmalltalk nur mühsam bearbeiten kann.

Da ich – für mich – zum Schluss gekommen bin, dass ich versuchen will, GUI Entwicklungen nur noch im Browser durchzuführen und auf die Entwicklung von Fat-Client-Anwendungen möglichst verzichten will musste ich irgendwie den Entwicklungsprozess unter VA beschleunigen und vor allem das Packaging vereinfachen.

Im Endziel soll ein System geschaffen werden, dass sich unter Windows wie eine native Anwendung installieren lässt, aber einen Browser zur Ausgabe benötigt – und als Einzelplatzanwendung taugt.
Zusätzlich soll es aber auch bei Bedarf hinter einem Apache geschützt unter Linux laufen können und für als Mehrbenutzersystem gelten können.

Wie schon in der Vergangenheit heisst das fuer mich: Headless-Packaging um “echte” Serveranwendungen zu bekommen.

Es sollten die Plattformen Linux/x86 und Windows unterstützt werden. Die Entwicklung findet i.d.R. unter Windows statt – die Programme laufen aber – produktiv – auf Linux/64Bit Servern im Internet.

Das Packaging wurde auf “IC”-Basis umgestellt und die Anzahl der Komponenten wurde radikal reduziert.

Das Umstellen auf IC’s hat den Vorteil, dass man sich nicht um das “Reducing” kümmern muss – es wird nichts beim Packaging rausgeworfen – alles bleibt drinne. “Tote” Referenzen gibt es dann nicht mehr.

Inhalt des Basis-IC
Es gibt ein “Basis”-IC, dass aus dem Grundsystem von Smalltalk und zusätzlichen Applications besteht:

• Base-Applications
• Datenbanken (ODBC, DB2, Oracle)
• TCP, Sst-Framework
• Compiler, Management
• XML

Zusätzlich zu den Paketen von Instantiations kommen dann noch eigene Pakete und von Squeak portierte Applikationen. Z.B.:

• Seaside, jQuery, Javascript, jQueryMobile
• CouchDB, JSON, ICU, SQLite, PostgreSQL, FreeImage
• Glorp, Announcements, EMan
• PDF und Postscript Support
• TNetString, MessagePak, REST

Wenn man das dann alles zusammenwirft, bekommt man ein Basis-IC, von dem man (vergeblich ) hofft, dass es sich nicht so stark ändert. Es bildet aber eine Grundlage, mit der man so manches IT-Problem lösen kann.

Die Grösse des ICs bleibt im normalen Rahmen und zusätzliche Arbeiten zum Reduzieren der Dateigroesse scheinen mir daher unnötig.
Die Resultate bei beiden Plattformen:

• win_base.ic (13 MByte)
• win_seasidestarter.ic (17 KByte)

oder unter Linux:

• unx_base.ic (11.5 MByte)
• unx_seasidestarter.ic (14 KByte)

.
SeasideStarter IC
Das IC “seasidestarter” habe ich bereits früher vorgestellt. Es soll den Adapter starten, so dass Seaside arbeiten kann und zusätzliche ICs laden – aus denen dann die eigentliche Anwendung heraus gestartet wird.
Auch wenn dieses IC ein Leaf-IC ist, wird es so gepackt, dass ein rauswerfen unterbunden wird.

Config-Maps und Fixes
Die Version 8.52 glänzt nicht gerade, und es sind bereits zahlreiche Bugfixes erschienen, um Features überhaupt zum Laufen zu bekommen bzw. um Fehler zu beheben. Wieder einmal – und das meckere ich seit Jahren an – hat ein aktiver Kunde erheblich Probleme oder Mühen, sich über den aktuellen Stand an Bugfixes zu erkundigen. Etwas was auf open-source Projekten inzwischen üblich ist – kommerzielle Anbieter tun sich schwer damit.
Daher habe ich für das Basis-IC neue ConfigMaps erzeugt und den von mir benötigten Kram hineinkopiert mit den mir bekannten Fixes. Bei einer neuen Version von VA bedeutet das leider wesentlich mehr Arbeit, da das System nun vollständig durch meine ConfigMaps beschrieben werden und nicht unbedingt durch die Maps von Instantiations – aber ENVY ist dafür ja sehr gut zu gebrauchen.

Das alles hat noch nichts mit Portobello zu tun – aber diese Arbeiten bilden die Basis für das Portobello Framework.

I just installed the Ubuntu 12.04.1/64Bit from disc and with that system you will not even be able to start the installer of VA, because its a 32bit application.

Therefore you have to install the 32 support libraries via:

sudo apt-get ia32-libs

which install quite a lot of stuff to your system.

Then I wanted to change the locale to the actual german one via:

sudo locale-gen de_DE@euro

and I change the file “/etc/environment” and “/etc/default/locale” (if present) and add/change the LANG entry to:

LANG = “de_DE.ISO8859-15@euro”

Then I did a reboot and I was able to enter german umlauts in VA.

Hello Joachim ) !!!!

This system is still a small, but has much more power than those machines 25 years ago.

Perhaps this is the feeling, this machine also produces on all these new users and I think it might become something like the C64 or the Atari or Amiga.

Ok, today I played with Linux on that system and after that again with RISC OS.

General

After reading lots of posting about this little part I noticed, that similar (ARM) systems seems to be available – offering more for more money. But they have more RAM, more cores and deliver also 1080i output.

Other postings mentioned large problems with USB implementation of the PI and then there seems to be the Ubuntu community, which seems to support only the ARM-V7 path and not the PI (ARM-V6) processor path.

But all these alternative systems have a small problem: no large community.

Linux

Nothing really new – perhaps this is the bad thing – but it looks nice, as most Linux systems looks smart with todays GUI. And you have everything you might expect from a Linux system – but on a low end system and this can be noticed, when working with it.

But you get strong support for this Linux and a large community behind it – therefore the system will get improoved over the next months.

On the other hand I’ve read, that people are asking for a more powerful system – perhaps other persons noticed the same thing that I did notice.

I tested Scratch on that system – and boy, that’s a very slow program on a slow system, but it looks nice.

I am more or less amazed: I’ve been using Smalltalk on my Atari ST with a 16 MHz CPU and 4 MB of RAM and now we have 700 MHz and 512 MByte of RAM and the situations has not changed that much for Smalltalk.

RISC OS

Now the other system. When started it only consumes around 10% of the system memory and leaves 410 MByte to the applications.

RISC OS is actually well suited for this system – it has enough power and the system feels much, much snappier that the Linux system.

But the GUI is strange and one can see the ages of that system. And getting software is not so easy.

I downloaded Squeak 3.8 and tried to start that old version – the initial GUI comes up, but actually no input (mouse or keyboard) is possible. Therefore the system is not suitable.

Summary

A new system – with perhaps hardware problems (at least for power users) – with the potential of getting a large community.

I tried both the Linux distribution, but also RISC OS to get a feeling for this little device.

But it seems, that one should consider this as a light machine and therefore RISC OS feels pretty snappy working on 1920×1200 pixels.

Perhaps we might see Squeak running on this machine