HyperCard Mailing List

[HC] The December 2011 JyperCard report
(Msg 1 of 2)
Dr. Anthony G. Rich <lists@[redacted].com>
Thursday, 29-Dec-2011 05:57 GMT
Hello, all.

This is an update on the progress that my students made
in creating a HyperCard clone in Java as a class project
at UW-Eau Claire this semester.

I'm Dr. Anthony G. Rich, a long-time HyperCardiac
on this mailing list. This fall I returned to teaching
computer science at the University of Wisconsin - Eau Claire.
Eau Claire is in northern Wisconsin, about 90 miles east of
Minneapolis, Minnesota.

One of the classes I was privileged to teach this fall
was Software Engineering II, a class where seniors do a
large team software project to gain experience in dealing
with the issues of working on big software projects.

It's a difficult course to teach, because by definition
any suitably huge project is too large to complete in a
semester -- but students only have one semester to work on it.
So getting a "satisfying feeling of completion" is elusive. :)

I decided to have the entire class of 24 students work on
the single project "Reimplementing HyperCard", a suitably
too-large-to-fit-in-one-semester project.

One of my students, Justin Glorvigen, emailed this list
a while back asking for pointers to any HyperCard info that
could be used in the project. Thanks to all who responded.

PROJECT SETUP:

We set up five five-person or four-person teams working on
various aspects of reimplementing HyperCard. The overall goal
was (and is) simply to create a HyperCard clone on a modern
computing system. Beyond that, I allowed the students to make
all of their own decisions about *how* to do that, requiring
only that they always considered alternatives, and that they
justified and documented whatever decisions they made.

I also required them to do "a build a week", where they
built and demonstrated whatever was working on the project
every Wednesday -- to keep the project moving, and also
so that everyone saw visible progress on the project every
week to keep interest and morale up.

THE DECISIONS:

They decided to use Java as the implementation language,
since that was their most-familiar language. They used
Eclipse as their development environment, although one
team also used NetBeans because it has a nice graphical
interface builder.

Their next decision was what to name the project. Since
it's HyperCard done in Java, they chose "JyperCard". :)
One student, Alex Wettstein, created a nice logo:
a fat J with a stacked-cards look in its squared-off
lower-right corner.

A major decision was to incorporate Rebecca Bettencourt's
open-source openXION HyperTalk interpreter. It looked
like a good fit, so they integrated openXION into the project.

(Rebecca: Seeing your code projected up onto the big screen
in our college classroom was *glorious*. Ya done good!
The students all have nothing but praise for the quality and
accessibility of your code.)

Students decided on using a Model-View-Controller approach
to writing the code, which simply means that their Java
code is organized into three parts:

Model: stores the internal representation of a stack.
View: the graphical user interface code.
Controller: shuttles data between the Model and the View.

HOW FAR DID THEY GET?

The Model: The team that implemented the model worked
very hard. The model is essentially complete,
containing the definitions of essentially all of the
properties of stacks, buttons, fields, etc.

The View: Has a good start. The menubar has the
basic menus in place, but as yet only a few menuitems
are currently implemented, such as New Stack,
New Card, New Button, and New Field.

Cards can be created and traversed, but they have no
backgrounds yet. And although their properties are defined
in the model, those properties can't be set and changed in
the card properties dialog yet. Likewise for buttons and
fields. Buttons and fields can be created and dragged
around on a card, and text that is entered into card
fields stays in the fields, but so far that's it.

The HyperTalk team worked on integrating Bettencourt's
openXION interpreter into the project. openXION is a
command-line interpreter for an extended version of
HyperTalk. As such, it doesn't support HyperCard's
cards, buttons and fields -- yet. :)

So to accommodate openXION, the HyperTalk and GUI teams
implemented HyperCard's message box, a kind of command-line
window. They were able to get openXION commands typed into
the message box to execute. There is no facility yet for
writing, storing, and executing entire scripts.

They also got the basic functionality of the Variable
Watcher window to work. For example, if one types
"put 7 into x" into the message box, openXION does
that, and then a variable named "x" and its value 7
appear in the Variable Watcher window in the usual way.

The File Formats team decided to use Java's
"serialization" feature to quickly save and load
an entire stack to/from disk in one chunk. So
saving and loading stacks produced by JyperCard
also works.

They also chose the filename suffix ".jyc" to use
in Windows-based systems to indicate that a document
is a JyperCard stack.

I'm pleased with the progress the students made in
the limited time they had. Obviously it's still a big,
unfinished project, but I think they made good design
decisions and overall did very well on it.

Interestingly, in their final project writeups, they
pretty much all agreed that the main things that they
learned was (1) clear team communication is very important,
and (2) documenting their progress and decisions are
also very important in keeping a project on track.

WHAT NEXT?

This spring semester I'm privileged to teach Software
Engineering I, our first-semester software engineering course.
(Yes, I'm teaching these two courses in reverse order.
Somehow these scheduling anomalies happen at universities.)

This first-semester course involves learning the fundamentals
of software engineering, so there's a heavier lecture
component; it isn't strictly a projects course. But there
is still a project component to it, so I intend to try
having these first-semester students pick up and continue
work on the JyperCard project this spring.

There will be about 50 students in this spring's class,
so it'll be a whole different ball game.

We're going to need more HyperCard reference books.
They're hard to find. Back in August I scoured eBay for
some, and we found about eight, but we could use more.
If you have sources for either the Winkler or Goodman
"HyperCard 2.2" books, please let me know.

I'll report back again, probably in late May or early June.
Wish us luck!

Wait, no -- it shouldn't be just a matter of luck.
Wish us good skill. :)

-- Tony
[HC] The December 2011 JyperCard report
(Msg 2 of 2)
Ralf Könner - SOFTID <koenner@[redacted].de>
Thursday, 29-Dec-2011 11:02 GMT
Hello Tony,

great to read you and hearing about your JyperCard project.
Its always astonishing to me again to know that people out there still k
eep HyperCard alive. Chapeau!

I have a handful of old HC and HC/Programming related books standing in my shelves which might be of interest for you and your students: http://www.soft-id.de/books2donate/books2donate.html

Let me know if you are interested and Ill be happy to send them to Eau C
laire right away.

Good luck and best wishes,
Ralf

Am 29.12.2011 um 06:57 schrieb Dr. Anthony G. Rich:

> Hello, all.
>
> This is an update on the progress that my students made
> in creating a HyperCard clone in Java as a class project
> at UW-Eau Claire this semester.
>
> I'm Dr. Anthony G. Rich, a long-time HyperCardiac
> on this mailing list. This fall I returned to teaching
> computer science at the University of Wisconsin - Eau Claire.
> Eau Claire is in northern Wisconsin, about 90 miles east of
> Minneapolis, Minnesota.
>
> One of the classes I was privileged to teach this fall
> was Software Engineering II, a class where seniors do a
> large team software project to gain experience in dealing
> with the issues of working on big software projects.
>
> It's a difficult course to teach, because by definition
> any suitably huge project is too large to complete in a
> semester -- but students only have one semester to work on it.
> So getting a "satisfying feeling of completion" is elusive. :)
>
> I decided to have the entire class of 24 students work on
> the single project "Reimplementing HyperCard", a suitably
> too-large-to-fit-in-one-semester project.
>
> One of my students, Justin Glorvigen, emailed this list
> a while back asking for pointers to any HyperCard info that
> could be used in the project. Thanks to all who responded.
>
> PROJECT SETUP:
>
> We set up five five-person or four-person teams working on
> various aspects of reimplementing HyperCard. The overall goal
> was (and is) simply to create a HyperCard clone on a modern
> computing system. Beyond that, I allowed the students to make
> all of their own decisions about *how* to do that, requiring
> only that they always considered alternatives, and that they
> justified and documented whatever decisions they made.
>
> I also required them to do "a build a week", where they
> built and demonstrated whatever was working on the project
> every Wednesday -- to keep the project moving, and also
> so that everyone saw visible progress on the project every
> week to keep interest and morale up.
>
> THE DECISIONS:
>
> They decided to use Java as the implementation language,
> since that was their most-familiar language. They used
> Eclipse as their development environment, although one
> team also used NetBeans because it has a nice graphical
> interface builder.
>
> Their next decision was what to name the project. Since
> it's HyperCard done in Java, they chose "JyperCard". :)
> One student, Alex Wettstein, created a nice logo:
> a fat J with a stacked-cards look in its squared-off
> lower-right corner.
>
> A major decision was to incorporate Rebecca Bettencourt's
> open-source openXION HyperTalk interpreter. It looked
> like a good fit, so they integrated openXION into the project.
>
> (Rebecca: Seeing your code projected up onto the big screen
> in our college classroom was *glorious*. Ya done good!
> The students all have nothing but praise for the quality and
> accessibility of your code.)
>
> Students decided on using a Model-View-Controller approach
> to writing the code, which simply means that their Java
> code is organized into three parts:
>
> Model: stores the internal representation of a stack.
> View: the graphical user interface code.
> Controller: shuttles data between the Model and the View.
>
> HOW FAR DID THEY GET?
>
> The Model: The team that implemented the model worked
> very hard. The model is essentially complete,
> containing the definitions of essentially all of the
> properties of stacks, buttons, fields, etc.
>
> The View: Has a good start. The menubar has the
> basic menus in place, but as yet only a few menuitems
> are currently implemented, such as New Stack,
> New Card, New Button, and New Field.
>
> Cards can be created and traversed, but they have no
> backgrounds yet. And although their properties are defined
> in the model, those properties can't be set and changed in
> the card properties dialog yet. Likewise for buttons and
> fields. Buttons and fields can be created and dragged
> around on a card, and text that is entered into card
> fields stays in the fields, but so far that's it.
>
> The HyperTalk team worked on integrating Bettencourt's
> openXION interpreter into the project. openXION is a
> command-line interpreter for an extended version of
> HyperTalk. As such, it doesn't support HyperCard's
> cards, buttons and fields -- yet. :)
>
> So to accommodate openXION, the HyperTalk and GUI teams
> implemented HyperCard's message box, a kind of command-line
> window. They were able to get openXION commands typed into
> the message box to execute. There is no facility yet for
> writing, storing, and executing entire scripts.
>
> They also got the basic functionality of the Variable
> Watcher window to work. For example, if one types
> "put 7 into x" into the message box, openXION does
> that, and then a variable named "x" and its value 7
> appear in the Variable Watcher window in the usual way.
>
> The File Formats team decided to use Java's
> "serialization" feature to quickly save and load
> an entire stack to/from disk in one chunk. So
> saving and loading stacks produced by JyperCard
> also works.
>
> They also chose the filename suffix ".jyc" to use
> in Windows-based systems to indicate that a document
> is a JyperCard stack.
>
> I'm pleased with the progress the students made in
> the limited time they had. Obviously it's still a big,
> unfinished project, but I think they made good design
> decisions and overall did very well on it.
>
> Interestingly, in their final project writeups, they
> pretty much all agreed that the main things that they
> learned was (1) clear team communication is very important,
> and (2) documenting their progress and decisions are
> also very important in keeping a project on track.
>
> WHAT NEXT?
>
> This spring semester I'm privileged to teach Software
> Engineering I, our first-semester software engineering course.
> (Yes, I'm teaching these two courses in reverse order.
> Somehow these scheduling anomalies happen at universities.)
>
> This first-semester course involves learning the fundamentals
> of software engineering, so there's a heavier lecture
> component; it isn't strictly a projects course. But there
> is still a project component to it, so I intend to try
> having these first-semester students pick up and continue
> work on the JyperCard project this spring.
>
> There will be about 50 students in this spring's class,
> so it'll be a whole different ball game.
>
> We're going to need more HyperCard reference books.
> They're hard to find. Back in August I scoured eBay for
> some, and we found about eight, but we could use more.
> If you have sources for either the Winkler or Goodman
> "HyperCard 2.2" books, please let me know.
>
> I'll report back again, probably in late May or early June.
> Wish us luck!
>
> Wait, no -- it shouldn't be just a matter of luck.
> Wish us good skill. :)
>
> -- Tony
>
>


HyperCard® and HyperTalk™ remain trademarks of Apple, Inc.; other trademarked products and terms mentioned in this archive are the property of their respective trademark holders. Individual messages remain the intellectual property of their respective authors.