You can accept either by right clicking for a context menu and accpeting, or by alt+s for save.

The screencast was meant to show you what it’s like working in Smalltalk and Seaside. What it’s really like (ie hotkey use), not what it’s like in slow motion using the mouse for everything.

As with the Ruby demo, it’s not meant to teach you Seaside, it’s meant to peak your interest and make you look into it further. If you want to learn Seaside, screencasts aren’t how you go about it, rather, go download some sample applications and play with actual code.

If you don’t like how I did it, then don’t watch it. I don’t owe you or anyone else anything and what I offer here on my site I do in my spare time for my own enjoyment. I didn’t have the time or equipment to do audio, so I did what I could, take it or leave it, I don’t care.

HTF do I “accept” the frikking instance of BlogView? this is the problem with smalltalk you just demand that everyone be up to speed even when doing a so called “introductory” screencast. And the transcript? well that one is a lot of help too.. Create BlogView and then ACCEPT how THE EFF do I accept?

80 miles an hour (to imitate that danish A-Hole) screencasts that don’t make any sense and on top of that.. no sound and no explanations because we’re supposed to know it already.. if we did, why would we watch your screencast? ever consider that?

seriously, if you’re not going to do it properly, why even bother?

What can I do ?

I added this rule to the Magritte descriptor mostly to demo Magritte. Something like validating uniqueness very much depends on your data store. Personally, I’m still torn between databases and objects, and this is an example of why.

In a db I could declaratively say this field must be unique. In an object model (OODB)… I’d be forced to ask myself why this field is unique, what does it say about my model, and then create an object for this abstraction and hash the posts in it by the unique key, the title. Essentially the same thing the relational database is doing by declaring a unique index.

So, assuming an OODB like this post does, I’d do it in Magritte maybe by moving the descriptor to the instance side and change the condition to the following…

[((self class repository copyWithout: self)
    contains: [:each| each attr = value]) not]

Which essentially say make sure no “other” blog post has this title and would allow updates of this post. Uniqueness is one of those special things where the rule is really a rule on the set, not the object.

You know, now that I think about it, that rule doesn’t really belong on the object at all, it belongs on the set of objects, the repository itself. So maybe what I’d really do would be to make the repository a real domain object rather than just a generic collection, and put this rule in the add method of the repository, and throw an exception when you add a post that violates one of its rules. Maybe something like this..

OrderedCollection subclass: #BlogPostRepository

add: aPost
    self testAdd: aPost.
    super add: aPost

testAdd: aPost
    (self includes: aPost) ifTrue:
        [MAConditionError signal: 'Post has already been added.']
    (self contains: [:each | each title =  aPost title]) ifTrue:
        [MAConditionError signal: 'Another post has that title.']

Magritte would then catch the condition error and display the message to the user.

Taking into account that magritte validates form with a memento of object, specifying condition like [:value| (self repository contains: [:each| each attr = value]) not] just allow you to add a new model object once checking that attr is unique. But when you try to edit again that object, it just wont pass the validation, because condition will fail while comparing memento attr with the one already present in repository.

So, the question is: what’s the right way to specify magritte validation of attribute uniqueness.

Maybe in the future, I’ll focus on shorter terser screencasts and give Wink a try again. I’ll think about the Magma one. What exactly would you like to see in such a screencast, its setup, or use?

Hope you would make a magma show. I’ve never got it run. sad.

Using the image like this for persistence should allow one to develop the entire application without the burden of dealing with a database. I do this not for use in production, but for use in development when speed of development is my primary concern.

Once complete, and working, you could then either use an object database like Gemstone, Goods, or Magma and pretty much keep the code as is, or use Glorp to map your objects into a relational database, which still shouldn’t require many changes.

As for the keyboard commands, I did this on purpose, I can’t stand watching screencasts where only menus are used because this isn’t how real development is done. I wanted people to see what working in Squeak is actually like, for real development, not a dressed up nice mouse driven demo that doesn’t reflect reality. Real developers use the keyboard, a lot, I wanted this reflected in the video.

I should have put sound on it, but honestly, it’s hard enough writing and making videos, let alone voicing them, this is just a hobby after all, I don’t want it to start feeling like work.

A question I had at the end is whether this could be done in a real production site. Is OrderedCollection thread-safe, or does the fact that you’re programming in an image make it so? I’m wondering if there was heavy traffic whether posts and comments would start getting dropped, because two people posted comments simultaneously and one person’s comment was added to the collection but the other wasn’t. Would simultaneous adds to the collection cause a problem?

The only comment I’d have about the screencast is it was a little hard to tell what you were doing with keyboard commands (obviously). I kept wondering how you were getting the Intellisense-like selections to come up. I finally figured it out, but it would’ve been nice if there were some subtitles showing when you had the browser accept code, and explaining how you were getting the method selectors to come up (just once), etc. Also the menu selections you made could’ve been a bit slower. They sometimes went a bit fast, because once you found the item you wanted, you immediately clicked on it, causing the menu to disappear right away. Rewind was my friend. :)

Anyway, great screencast.

PS: played fine on WMP v10.00.00.4019

I agree with others that some narrative would be very useful: either with sound narration, or even better with text (like a animated Powerpoint presentation).

I even found Squeak development to be somewhat appealing. I’ve avoided Squeak in favor of Dolphin Smalltalk, because the UI seemed so baroque and unintuitive, however your screencast has eased some of those reservations.

Very nicely done.