Archive for December, 2008|Monthly archive page
For the past few weeks I have been working on helping my kids better understand what I do at work everyday, i.e. programming. Admittedly I do not not program everyday but they will have years to learn about other topics such as organizational politics and communication overload , so no reason to start on those topics yet and besides my eldest son has always shown a high degree of interest in computers and the workings behind them.
Keep in mind that my kids are fairly young to understand programming concepts. My two eldest are 4 and 6. You cannot have high expectations at that age for programming but just provide them the knowledge and the tools so that their creative minds can go to work & have fun and that is what I attempted to do.
Before diving into the details of this programming experiment below, for those just interested in the end product of our holiday weekend, the “Thor’s Christmas Feast” project, click on the following image.
Where to Start?
First question you are confronted with when attempting to show your kids how to program are “what tools to use?” I knew C++ would be out of the question and considered what I could do with Java or ActionScript. I then did the next logical thing, I Googled the topic (kids & programming) and eventually came across some very interesting tools, which I hadn’t heard about before; Scratch and Alice. After a brief look at both I decided to start with Scratch and later try out Alice.
Note: For parents with older kids I also came across another excellent resource, “Java Programming for Kids, Parents, and Grandparents,” written by Yakov Fain.
What is Scratch?
Scratch is a programming language developed by the Lifelong Kindergarten Group at the MIT Media Lab to help young people learn how to develop computer programs. The development of Scratch (and its name) was supposedly inspired by the scratching process that DJs use to create new sounds and music by rubbing old-style vinyl records back and forth on record turntables, creating new and distinctively different sound out of something that exists. Similarly scratch projects allow young developers to mix together graphics and sounds, using them in new and creative ways.
Technically Scratch is an interpreted dynamic visual programming language based on and implemented in a derivative of Smalltalk, called Squeak (hmmm.. need to play around with that as well). Being dynamic, Scratch allows code to be changed even as programs are running. As a visual language, Scratch does not involve writing code in the traditional sense; instead, you write “code” by dragging and dropping component blocks onto a graphical editor (Hey, Sounds like LiveCycle;-).
Developing a Lesson Plan
Admittedly, I am not a teacher and know little about the process of education, however like most parents I am driven to learn more about education both to help me communicate with my kid’s teachers at school and to help my kids learn at home as well. If anyone has any good recommendations on resources, please forward them to me!
My first step in teaching my kids programming concepts in Scratch was to write a list of goals to attain:
1) Learn the Scratch terminology and Environment
2) Co-develop a program to make our dogs bark
3) Co-develop a program to make our dogs spin
4) Have them write a program by themselves
5) Co-develop a game and publish it to the Scratch WebSite
Goal 1 – The Scratch Terminology & Environment
First we talked about this computer program called Scratch which allows you, a Computer Programmer, to write programs such as video games. Next, we discussed the primary concepts within Scratch of a Stage and Sprites. Technically the stage is the area in the Scratch IDE, located in the upper right hand side, where your Scratch applications execute. For my kids, however, the stage is the area where all the Sprite pictures play with one another. Then we opened up Scratch and identified the purpose of the various panels in it as shown below.
- The Stage: Place for Sprites (i.e. pictures of things) to play with one another
- Sprite List: Panel for selecting a Sprite to work with
- Code Blocks: The top panel is a set of Category buttons. You can see different types of blocks by clicking on different categories. Code Blocks are what computer programmers use to tell Sprites what to do. The color coding for the various categories seemed to help my kids immensely when referring back to categories of code blocks.
- Script Area: Technically the place where you compose programs by assembling code blocks. but for my kids its the place you move blocks to tell Sprites what to do.
- The Flag and Stop buttons: The two primary buttons for starting and stopping Scratch applications respectively.
This part went fairly smooth and after a few sessions of messing around my kids quickly picked up on the concepts of Stage, Sprite, Block, Script, etc…. By pulling up some of the sample apps such as Pong they learned how the Flag and Stop buttons worked while having a bit of fun as well.
Goals 2 & 3 – Co-Developing Applications
After learning the environment and trying some samples we set off to create our own very basic Scratch applications. I have to admit that I initially didn’t get it as to why a Kids programming language should be so media centric (yeah I am a little slow like that), but after seeing my kids interact with Scratch it became much more clearer to me. One of the nicest things I saw with the Scratch was that it personalized the development experience in new ways by making it easy for my kids to add personalized content and actively participate in the development process. Not only could they develop abstract programs to do mindless things with a Cat or a box, etc… but they could add THEIR own pictures and THEIR own voices to the Scratch environment which has given them hours of fun and driven them to learn. Awesome Job to the Scratch dev team!
Anyway, over a few sessions I sat in the drivers seat while the kids and I worked on making Thor, our English Bulldog, bark and spin.
Goal 4 – Have the Kids Write a Program Themselves
For this one both of the kids chose to make Thor Bark. Now the interesting thing for me here was the differences in my two kids. For my older son it probably took about half an hour for me and him to walk through creating a scratch application with Thor barking. He clearly knew what he was doing and needed to be done (We had done it several times with me in the drivers seat), but he was more interested in the process of creating the app than the actual end result, so he ended up asking me TONS of questions along the way (e.g. Why do Sprites need commands? What if I use the move Block instead?, etc….). My younger son on the other hand cared little about the process, but definitely wanted to see the end result. He managed to complete the program in a couple of minutes with little direction from me with the anticipation of hearing him self say “WUFF” repeatedly 😉
Another interesting point here was that I noticed that this was the first time that my younger son had learned how to drag and drop an object on a computer (in this case blocks onto the script area), that was the bulk of my help to him here. I was amazed how quickly he learned to do it and how quickly it seemed to become second nature (now compare that to his Grandparents, thats a different story 😉
Here is the source code for the Bark application.
This script simply tells a Sprite (named Thor in this case) to make a sound “Wuff” when the Flag is clicked. Simple aye?
Goal 5 – Co-develop a game and publish it to the Scratch WebSite
Okkk…. Now it was MY time to Shine!! I quickly grabbed back the drivers seat and went on to create an actual game in Scratch (The inner geek acting in me). The kids helped me to pick the theme (once again dog related). We decided to make a game where our dog Thor was eating all the goodies (Candy, Cookies, and Cake). Realize that my kids have a lot of experience with getting tackled by this 40 lb brute if they ever dare to venture around the floor with food in their hands. The boys learned this harsh lesson early on, but my daughter (age 1) is still in the learning process unfortunately.
My 6 year old did the Wuff sound for the game, while my younger son came up with the idea of making Thor get “fatter” as he ate more food and “smaller” as he missed food. Unfortunately, they couldn’t sit and watch me develop the program because well, it took me to long (couple of hours at most). I think it only took that long due to the learning curve I had with Scratch myself. In the and I was pleased with the end result (My wife was not so impressed). While I found scratch lacking in some ways (lack of functions, re-use, objects, encapsulation, polymorphism, etc…) the composition capabilities where impressive and the ways it dealt with expressions and variables visually. Moreover, building parallel threads in Scratch came naturally to the point that you weren’t even aware that you were doing it, which is the first time I can say I have seen that in an IDE.
Finally, another great aspect of the Scratch experience was the ease with which it enables you to publish and share code through a Scratch hosted service. You can find tons of great applications and examples at –> http://scratch.mit.edu/. This was yet another great lesson for the kids. They can investigate games out their on scratch and easily download the source and see how it works. Now I don’t think my kids quite grasp all of that yet, nor do they quite know the process of downloading the code themselves and opening it within the Scratch IDE, but I see it as a great foundation for working in a more open and collaborative development environment.
On several occasions I have been asked about the possibility of integrating LiveCycle ES with UDDI to provide a standards based way of browsing LiveCycle services. Well I figured MAX2008 was a good motivator for getting such an integration working and so that is what I kicked off several weeks prior to MAX. I decided I would build a LiveCycle Component that allowed for both the publishing and querying of data to and from UDDI from within LiveCycle. Unfortunately, I quickly realized that there still seemed to be limited tooling around UDDI. So while, I could use a complete Java implementation of the UDDI specification from Apache, JUDDI, there was no easy means for me to browse the registry to show the results. This inevitably lead to the 2nd part of this proof of concept which was to build a UDDI browser with Flex. Note: there is an open source Java UDDI Browser available at http://uddibrowser.org/ that works well, however using it for a UDDI LiveCycle demo didn’t seem right for my purposes 😉
You can view an entire walkthrough at screencast.com Or the following lower res videos at YouTube.
So why did I create this demo?
- To provide a Proof of Concept for Integrating LiveCycle with UDDI
- To Discuss features and concepts around the LiveCycle Registry
- Learn How-to(s) with Flex and Web-Services (i.e. another excuse for me to improve my Flex chops)
IMPORTANT DISCLAIMER: This was a demo done as a proof of concept for which I am making the source code available. However note that the LC Component, and UDDI browser need a lot of fine tuning, which I have not and probably won’t have the time to complete anytime soon. The demo did accomplish its goal of proving that it is not only possibly but very feasible to integrate LCES with UDDI.
Below is a high-level diagram for the architecture of the UDDI/LCES proof of concept.
- JUDDI: A Java based implementation of the UDDI 2 Specification which was used for purposes of this demo. You can find more info about JUDDI at http://ws.apache.org/juddi/
- UDDI Component: A custom LiveCycle component deployed in a LiveCycle Instance capable of querying the LiveCycle Registry and publishing service meta-data to a UDDI Registry
- UDDI Browser: An AIR application for browsing Businesses, Services, and TModels in a UDDI Registry.
LiveCycle ES Registry
The “Collective” Registry within LiveCycle ES is made up of at least 6 sub registries that store meta-data around the components deployed within ES. The meta-data in the LiveCycle Registry is used at both Runtime (e.g. Service & version resolution) and Designtime (e.g. to build composite applications).
- Component Registry: Stores the base information relevant to a component such as component id, title, description, etc…
- DataType Registry: DataTypes are Java classes that are exported from a component and that can be leveraged by the LCES tooling
- PropertyEditor Registry: Property Editors are UI elements implemented in Java that control the visual rendering of types and properties within LiveCycle ES tooling.
- Connector Registry: Connectors are integration mechanisms that define a means by which to invoke a LiveCycle service. Example connectors include EJB Connector, SOAP Connector, and VM Connector.
- Service Registry: Maintains all the meta-data we have around services such as the signature of a service, description, hints, config values, etc…
- Endpoint Registry: Stores configuration necessary to bind a service to one or more connectors. This provides for the loose coupling between service implementations and the means by which they are invoked (i.e. Connectors).
Trying out the UDDI Proof Of Concept
Unfortunately, I have not setup an environment where demos such as this are available online.
For now however you will need to do the following steps:
- Download and install the LiveCycle trial (if you haven’t already) from http://www.adobe.com/devnet/livecycle/trial/.
Note: This demo was built on LCES Update 1 (also known as 8.2.1)
- Download the Source Code for a) the AIR app and b) the LiveCycle Java Component (i.e. uddi-dsc.jar) used from Download Source Code Note: uddi-dsc.jar contains the related Java code within
- With LiveCycle up and running go to LiveCycle Workbench and click on Window–>Show View–>Components. In the Components view you can right click the top node to then install the Java Components downloaded (i.e. uddi-dsc.jar) Note: You will need to configure the UDDI3Service by right clicking it in the components view, setting the user/password expected by JUDDI (‘admin’/” for me), and setting the publishAsHost & publishAsPort (used to fill int the WSDL URL in the UDDI Registry)
- Import the Flex Project included in the Download to your Flex Builder environment
- Run the AIR APP!
- Oh wait….. Before any LC Services are available in the UDDI Registry you need to invoke the UDDI2Service.publishLiveCycleService. You can do this from the “Components View” in Workbench, however, you need to first turn on the unsupported workbench option –> -Dcom.adobe.workbench.unsupported.dscadmin.invoke.enable=true in the workbench.ini file
Anyway, Good Luck! there is a lot to play with there.
Few more notes for those digging deeper:
- I packaged two modified WSDLs from which the WebService ActionScript stubs were generated within Flex Builder. I had to modify the WSDL to get around issues with the decoding of arrays.
- If you need to regenerate the WebService ActionScript stubs then you will need to modify the src/webservices/inquiry/BaseInquireService.as file to change the isWrapped properties of the WSDLMessages to false rather than true.
- The calls between LiveCycle and JUDDI seem to be slow on the perf side, but I haven’t drilled into that aspect as of yet