Smalltalk with James Robertson

Instantiations is having a "State of VA Smalltalk" meeting in Stuttgart, Germany, on June 8. Follow the link for details.

Today's Smalltalk Daily looks at how tooverride a class definition, and save that definition into your own package. To learn about overriding methods, or adding extension methods, see this screencast. Click on the viewer below to watch it now:

You can download the video directly here. If you like this kind of video, why not subscribe to "Smalltalk Daily"?

Technorati Tags: class definition, override

This week's podcast is part 2 of our conversation with John Maloney and John McIntosh about Scratch. In this segment, we delved into the issues surrounding Scratch's removal from the app store - suffice to say, it wasn't the new policies they ran afoul of, it was the existing ones (using an interpreter, having downloadable, executable content for the application itself).

It was a fun talk, and things sound somewhat hopeful with respect to the app store - listen to the podcast to find out what I mean by that! To get Scratch now, visit the website and become one of the millions who've created an uploaded a project.

To listen now, you can either download the mp3 edition, or the AAC edition. The AAC edition comes with chapter markers. You can subscribe to either edition of the podcast directly in iTunes; just search for Smalltalk and look in the Podcast results. You can subscribe to the mp3 edition directly using this feed, or the AAC edition using this feed using any podcatching software. You can also download the podcast in ogg format.

To listen immediately, use the player below:

If you like the music we use, please visit Josh Woodward's site. We use the song Effortless for our intro/outro music. I'm sure he'd appreciate your support!

If you have feedback, send it to smalltalkpodcasts@cincom.com - or visit us on Facebook or Ning - you can vote for the Podcast Alley, and subscribe on iTunes. If you enjoy the podcast, pass the word - we would love to have more people hear about Smalltalk!

Technorati Tags: squeak, app store, apple, iPad, scratch

Over the last few years, there’s been a lot of development effort going into web frameworks - increasingly in non-Java languages. In the early 2000’s, it looked like web development was going to be mostly Java/Java beans based, with a few “fringe” technologies competing at the margins. It didn’t really work out that way though; Java was just too hard to work with for most people. Over time, the web has become dominated by code written in Perl, Python, and Ruby (using Ruby on Rails).

Smalltalk has seen some of that resurgence as well with Seaside. Unlike previous web efforts in Smalltalk, Seaside is open, and works in every single major Smalltalk dialect - and it’s actively supported by the major commercial players (Cincom, Gemstone, Instantiations).

Ruby on Rails has been touted as a simpler route to web development - if you watch this long screencast exploring various web tools, it’s clear that using RoR is much more productive than the other alternatives explored by the screencaster. One thing that screencast didn’t look at was Seaside, which is too bad - because Seaside is optimized for writing Web Applications, and removes a lot of the “housekeeping” you have to do, even in Ruby on Rails. To see that for yourself, take a look at the Seaside version (using Cincom’s WebVelocity) used in that screencast.

Let’s break down some of the advantages Seaside has over Ruby on Rails into a set of bullet points. This isn’t to say that Ruby on Rails is terrible; the large user base argues otherwise. Rather, it’s to point out a few things about Smalltalk and Seaside that users of Ruby on Rails (and other web frameworks) simply may not be aware of:

• Interactive Development. One of the things RoR is known for is interactive development. Make a change, refresh the browser, try again. Smalltalk has always brought that level of interactivity to development, and Seaside takes it one better - instead of a full reload, you can do exploratory development with partial iterations. Build what you understand, let the application break, and use the Smalltalk debugger. You may not fully “get” that statement without seeing it; here’s a screencast illustrating it.
• Beyond Active Record. You can use Active Record for database connectivity in both RoR and Seaside, but that only takes you so far. Sometimes (especially with existing data models) you have to go “off the rails”. With RoR, you’re on your own there. With Seaside, you have the full power of Glorp - an open source object/relational mapper that is available across all the major Smalltalk dialects.
• Speed. While Ruby is highly productive (for the same reasons that Smalltalk is), it’s not fast. Smalltalk, on the other hand, has been under active development for over 3 decades. The virtual machine technology behind Smalltalk is fast, and second to none in the field.
• Connected to the Enterprise. Need to deal with enterprise libraries using industry standards like WS*? Smalltalk gets you access to the enterprise - and full support from commercial vendors. When you really need a fix now, that means you can get a real person on the phone.
• Mature Development Tools and Libraries. Smalltalk has been around for over three decades - the class libraries supporting it are tested and stable, and the development tools are world class. Things like unit testing and refactoring were invented in Smalltalk - why not try the environment that spawned the entire TDD process?

Still not convinced? That’s fine - see for yourself. Download Smalltalk now from the Cincom Smalltalk website and give Seaside a test drive. Check out the “Smalltalk Daily” video tutorials to get started - we have a basic Seaside tutorial and a WebVelocity specific section for you.

Technorati Tags: seaside, RoR, ruby on rails

Today's Smalltalk Daily looks at how debugging works for web applications built in Seaside. The cool thing - it works just like debugging for any other Smalltalk app. Click on the viewer below to watch it now:

You can download the video directly here. If you like this kind of video, why not subscribe to "Smalltalk Daily"?

Technorati Tags: seaside, web development, debugging

The Toronto STUG has an interesting meeting coming up on May 10:

The agenda for the next meeting of the Toronto Smalltalk User Group, on Monday, May 10, includes:

• which Smalltalk to use for an OO course?
• demo of a Self-like programming environment for JavaScript (on top of Dan Ingalls' Lively Kernel)
• demo of the Teleplace app in Cobalt, the 3D virtual world that is taking over for Croquet

Meetings start at 6:30 and are hosted by Ryerson University. 245 Church Street

They're a great group - mark this one down in your calendar!

Technorati Tags: toronto

I ran across an interesting post from a guy who's made the move from Rails to Seaside - not because he has anything against Rails, but because he decided that Seaside was a better choice for him. You should really read the whole post - he goes through his learning process (yes, there were and are some hurdles to getting into Smalltalk) - but I really liked this bit:

A real debugger - in reality, most development time is spent editing code, and debugging. Debugging web apps has always been a tough thing. With seaside, it’s really a matter of going to a debugger on a crash, and inspecting the objects. You can edit the objects (and their methods) while they are live. While the system is running. you can also set breakpoints willy nilly, and inspect and edit the system on the fly. It’s hard to describe how alive the system is. You just need to try it.

People underestimate the importance of this a lot. In fact, you can find plenty of developers (including Rubyists) who will tell you that you shouldn't debug at all; tests will do it all for you. What that really means is this: debuggers in other languages are very, very different from what we have in Smalltalk, and when you get into Seaside, it's even more cool:

• It's not just a debugger - it's a live editor of your code that happens to be debugging a live process
• In Seaside, you can debug intra-hit

That latter part tends to throw people unless they see it; here's a screencast showing it off in Seaside, and here's another, showing it off in WebVelocity - which moves the entire Smalltalk environment into the browser itself - allowing for a seamless develop/debug/deploy chain. I like to describe it this way: normal debugers let you play the part of forensic pathologist - you get a dead body, and have to figure out what killed it. With Smalltalk, you're a surgeon - the patient is knocked out, but you can patch him up and send him off after you wake him back up.

One thing that I just noticed - I haven't done new versions of those videos in a bit - so I guess I have a couple of screencasts to do in the near future :) When I do that, I'll update this post. Anyway - they show off what I'm on about. Give WebVelocity a try, and see what Smalltalk can do for your Web Apps - it combines ActiveRecord with Seaside, along with the full support of the Cincom Smalltalk team.

Update: The Seaside screencast has been updated

Technorati Tags: seaside, webvelocity, RoR, ruby+on+rails, rails

Sometimes you run flat into a brick wall - you can usually resolve issues with the Smalltalk debugger, but - what if you're having problems at the VM level?

Well, there are two online resources that should give you some tips on getting started:

• Virtual Machine Debugging Notes
• Screencast on Command line arguments for the VM

Have a look - if you need more information, and you're a customer, try Cincom Smalltalk Support

Technorati Tags: debugging, VM

Today's Smalltalk Daily looks at how to create a BlockClosure on the fly, based on user input. This screencast is based on a user request; the actual example is very dangerous! To download the code used, click here. Click on the viewer below to watch it now:

You can download the video directly here. If you like this kind of video, why not subscribe to "Smalltalk Daily"?

Technorati Tags: block, closure

I was asked how to store a block from a string this morning, and store the result in an input field. It's actually pretty simple:

string := '[:a | a + 1]'.
block := Compiler evaluate: string.
block value: 10

Now, if you put that behind an input field in a UI, you would want to be extremely careful - you wouldn't want someone typing, say,

[Object := nil].

and just executing the result at some point. To go all Spiderman, "With Great Power Comes Great Responsibility" :)

Technorati Tags: compiler