- Basic Smalltalk Dev Environment Concepts
- Installing Seaside, and Squeak/Pharo Basics (saving and exiting, basic navigation)
- “Setting It Up Right” – Loading Useful Extensions (Except it turns out, not really)
- Creating a Seaside “Hello World”, localhost
- Interlude: Getting a Remote Server
- Packaging Your Image for Deployment
- Installing Pharo on the Server
- Closing the Loop – Deployed Pharo Hello World On Your Domain
Before we install Seaside, I’d like to explain some terminology.
For example, if you go to the Pharo Download Page (though that’s not the one we’ll be ultimately using for this tutorial — we’ll use the Seaside Download Page instead), you’ll see several headings – “One-Click Image”, “Custom Downloads” with subheadings of “Image”, “Source Files” and “Virtual Machines”. What are all of these? First, let’s discuss some key concepts that you will be working with in the Smalltalk world.
If you’re coming from the Java world, this is the Runtime Environment. It’s a small virtual machine, specific to your operating system, that runs Smalltalk bytecode. Hence, in the “Custom Downloads > Virtual Machines” section, you’ll see binaries for Windows, OS X and Unix.
Which VM should I use, Cog VM or “standard”? Don’t worry about it for now. Use Cog, which is a new JIT VM that promises to be faster than the standard one.
If the Virtual Machine is the Runtime Environment, the Images are Eclipse (or a similar IDE), your workspace (with saved preferences and windows positions) and the code you’re working on.
Let me repeat that: The Image is the IDE, your workspace AND the code that you’ll be working on.
The Image is OS-independent. (Hence why there’s only one link, say, Pharo 1.1.1. image (stable) – use this for all operating systems). That means you can develop your code on Windows, then switch over to Linux, load up the image into the VM, and continue coding exactly where you left off, down to the placement of the code editor windows on the screen.
The image is also the unit of deployment. (Again, with the Java metaphor, think of it as the .jar file, that you’ll be rolling out to the server).
Wait, if I’m deploying the image, and the image also contains the IDE and workspace, does this mean my deployed app will contain all sorts of extra cruft? Good question. No, it will not — when preparing an image for deployment, you strip away all that non-essential code. So fear not.
Why is it all integrated like that (the IDE, workspace and code)? For various historical reasons I’m still fuzzy on, and which don’t really matter in this tutorial. However, the thing to take away is this: the tight integration is not going to hurt you, it will not create bloat (see the above), and it buys you some incredibly useful development and debugging capabilities.
What about collaboration? How do multiple developers work on one image? That’s where source control comes in. Though the Squeak/Pharo world does not use the usual source control tools (CVS, SVN, Git or Mercurial), it does use source control — Monticello, a “distributed, optimistic, concurrent, versioning system”, written in Smalltalk. (Again, the theme of tight integration, of Smalltalk all the way through, down to the support and development tools). Your day to day workflow will be roughly the same working in Monticello as with other source control tools, the same concepts apply — you’ll be updating your code to the latest revision, working on it, then committing, merging with that of other developers, etc.
Ignore these. These are minimalist images for advanced users and core developers of the Pharo project itself.
This is the source code to much of the Virtual Machine, as well as some libraries and core classes. (In Debian/Ubuntu world, think of this as the source packages, to go with the binaries.)
The virtual machine will still work without source files, but when you click on some of the base classes, you’ll just see bytecode, and that’s not very useful.
You’ll want source files in your environment — part of the beauty of Smalltalk is that the source for the entire stack is available for your perusal.
Though these are not referenced on the Download page, in various Smalltalk tutorials, you’ll hear mentions of change files, as in “copy your image and .changes file to your backup directory…”. You know how some database systems keep a transaction log, so that when the db server crashes, you can still recover all of the transactions from disk? This is what the .changes file is. It’s a log of all of your actions in the workspace, so that if your image crashes or becomes corrupted, you can still recover your code and data.
How often will it crash / will I have to use the .changes file? I’ve been developing in Smalltalk for 9 years, and I haven’t had to use it yet. That doesn’t mean you won’t have to, so I just wanted to mention it.
Putting It All Together – Windows Installer, and the “one-click image”
Now that you understand the basic components of a Smalltalk dev environment, those download links help you put it all together.
The Windows installer packages together a Windows VM, a starting image, and a sources file to go with it. If you’re developing on windows, just use this.
The Pharo x.x.x one-click image is a similar packaging, except it contains VMs for all 3 OSs (Windows, Linux and OS X), as well as an image and sources to go with them. So the idea is, you just download that one distribution, and then use whichever runtime your OS requires.
Finally, the Seaside 3.0 one-click experience on the Seaside Download Page is a zip file containing all 3 OS-specific VMs, sources, and an image file with the Seaside project already loaded into it, and the web server started. This is the one we’ll be using for our Deployed Hello World.