Targeting Public Speaking Skills via Virtual Environments

Recently I shared an a-ha! moment on the use of virtual environments for confronting the fear of public speaking.

The more I think about it, the more I’m inclined to claim that the real value of such technology is in targeted skills development.

Once again, I’ll use myself as an example here to make my point.

If I think back to my earliest attempts at public speaking as a graduate student, I’d claim that I did a reasonable job of delivering my presentation. And given that the content of my presentation was likely vetted with my research peers (fellow graduate students) and supervisor ahead of time, this left me with a targeted opportunity for improvement: The Q&A session.

Countless times I can recall having a brilliant answer to a question long after my presentation was finished – e.g., on my way home from the event. Not very useful … and exceedingly frustrating.

I would also assert that this lag, between question and appropriate answer, had a whole lot less to do with my expertise in a particular discipline, and a whole lot more to do with my degree nervousness – how else can I explain the ability to fashion perfect answers on the way home!

Over time, I like to think that I’ve approved my ability to deliver better-quality answers in real time. How have I improved? Experience. I would credit my experience teaching science to non-scientists at York, as well as my public-sector experience as a vendor representative at industry events, as particularly edifying in this regard.

Rather than submit to such baptisms of fire, and because hindsight is 20/20, I would’ve definitely appreciated the opportunity to develop my Q&A skills in virtual environments such as Nortel web.alive. Why? Such environments can easily facilitate the focused effort I required to target the development of my Q&A skills. And, of course, as my skills improve, so can the challenges brought to bear via the virtual environment.

All speculation at this point … Reasonable speculation that needs to be validated …

If you were to embrace such a virtual environment for the development of your public-speaking skills, which skills would you target? And how might you make use of the virtual environment to do so?

Confronting the Fear of Public Speaking via Virtual Environments

Confession: In the past, I’ve been extremely quick to dismiss the value of Second Life in the context of teaching and learning.

Even worse, my dismissal was not fact-based … and, if truth be told, I’ve gone out of my way to avoid opportunities to ‘gather the facts’ by attending presentations at conferences, conducting my own research online, speaking with my colleagues, etc.

So I, dear reader, am as surprised as any of you to have had an egg-on-my-face epiphany this morning …

Please allow me to elaborate:

• Yesterday, I witnessed a demonstration of Nortel web.alive (dubbed by some as ‘Second Life for business’)
• This morning I was brainstorming content with a colleague for an upcoming presentation on computing resources available for researchers at York

It was at some point during this morning’s brainstorming session that the egg hit me squarely in the face:

Why not use Nortel web.alive to prepare graduate students for presenting their research?

Often feared more than death and taxes, public speaking is an essential aspect of academic research – regardless of the discipline.

Enter Nortel web.alive with its virtual environment of a large lecture hall – complete with a podium, projection screen for sharing slides, and most importantly an audience!

As a former graduate student, I could easily ’see’ myself in this environment with increasingly realistic audiences comprised of friends, family and/or pets, fellow graduate students, my research supervisor, my supervisory committee, etc. Because Nortel web.alive only requires a Web browser, my audience isn’t geographically constrained. This geographical freedom is important as it allows for participation – e.g., between graduate students at York in Toronto and their supervisor who just happens to be on sabbatical in the UK. (Trust me, this happens!)

As the manager of Network Operations at York, I’m always keen to encourage novel use of our campus network. The public-speaking use case I’ve described here has the potential to make innovative use of our campus network, regional network (GTAnet), provincial network (ORION), and even national network (CANARIE) that would ultimately allow for global connectivity.

While I busy myself scraping the egg off my face, please chime in with your feedback. Does this sound useful? Are you aware of other efforts to use virtual environments to confront the fear of public speaking? Are there related applications that come to mind for you? (As someone who’s taught classes of about 300 students in large lecture halls, a little bit of a priori experimentation in a virtual environment would’ve been greatly appreciated!)

Update (November 13, 2009): I just Google’d the title of this article and came up with a few, relevant hits; further research is required.

April’s Contributions on Bright Hub

In April, I contributed two articles to the Web Development channel over on Bright Hub:

• Introducing The Aptana Cloud
• HTML vs. XHTML: The Five Key Takeaways

ORION/CANARIE National Summit

Just in case you haven’t heard:

… join us for an exciting national summit on innovation and technology, hosted by ORION and CANARIE, at the Metro Toronto Convention Centre, Nov. 3 and 4, 2008.

“Powering Innovation – a National Summit” brings over 55 keynotes, speakers and panelist from across Canada and the US, including best-selling author of Innovation Nation, Dr. John Kao; President/CEO of Intenet2 Dr. Doug Van Houweling; chancellor of the University of California at Berkeley Dr. Robert J. Birgeneau; advanced visualization guru Dr. Chaomei Chen of Philadelphia’s Drexel University; and many more. The President of the Ontario College of Art & Design’s Sara Diamond chairs “A Boom with View”, a session on visualization technologies. Dr. Gail Anderson presents on forensic science research. Other speakers include the host of CBC Radio’s Spark Nora Young; Delvinia Interactive’s Adam Froman and the President and CEO of Zerofootprint, Ron Dembo.

This is an excellent opportunity to meet and network with up to 250 researchers, scientists, educators, and technologists from across Ontario and Canada and the international community. Attend sessions on the very latest on e-science; network-enabled platforms, cloud computing, the greening of IT; applications in the “cloud”; innovative visualization technologies; teaching and learning in a web 2.0 universe and more. Don’t miss exhibitors and showcases from holographic 3D imaging, to IP-based television platforms, to advanced networking.

For more information, visit http://www.orioncanariesummit.ca.

Book Review: Google Web Toolkit

Automagically convert Java to JavaScript. 

Thus begins the seemingly curious proposition of the Google Web Toolkit (GWT). 

Of course, it’s about a lot more than that. 

For one thing, GWT addresses a key gap in the rapid delivery of the Asynchronous JavaScript and XML (AJAX) based applications that are driving eyeballs and mindshare to Google’s Web site.

By the time you’ve read Prabhakar Chaganti’s book on the GWT, you’ll be significantly wiser on at least two fronts. You’ll know that:

1. There’s a broad-and-deep software engineering ecosystem around the GWT that is fueling progress and delivering highly significant results. 
2. Chaganti is an excellent guide with the ability to negotiate this ecosystem and drive you towards tangible outcomes.

Using a task-oriented approach, the book proceeds as follows:

• Chapter 1 rapidly places the GWT in context, and gets you started by downloading, installing and working with the samples provided. Available for Apple Mac OS X, Linux and Microsoft Windows, the GWT only requires the Java SDK as an installation prerequisite. The GWT is made available via the Apache Open Source license; this allows for the development of commercial and Open Source applications. 
• With the Java SDK, the GWT and the Eclipse IDE, the developer has a well-integrated and powerful platform on which to develop applications. After illustrating the development of the obligatory “Hello World!” application at the outset of Chapter 2, attention shifts rapidly to use of Eclipse. Google’s Web-wired DNA is evident in everything they do, and the GWT is no exception. The GWT leverages the Java SDK and Eclipse to the fullest, while closing the gaps in developing AJAX-based applications in a very organized way. By the end of this Chapter, the reader knows how to develop a simple application with both client and server-side components and execute the same in both hosted (i.e., non-deployed) and Web hosted (i.e., executing within a Web-hosted Tomcat servlet container). Made explicit in this latter deployment is GWT’s ability to support a variety of Web browsers – i.e., Apple Safari, Microsoft Internet Explorer, Mozilla Firefox and Opera.
• The creation of services is the focus of Chapter 3. To quote from this Chapter, and in the GWT context, service “… refers to the code that the client invokes on the server side in order to access the functionality provided by the server.” The author is quick to point out that this is a separate and distinct notion from that used in the context of Web services. True to its billing, this Chapter works the reader through the creation of a service definition interface (a client/server contract that defines the service’s functionality and establishes rules of usage) and service implementation. Particularly important in this Chapter is the creation of an asynchronous service definition interface, as this facilitates remote calls in the background to the server, and capitalizes on the AJAX support in the GWT. With definition and implementation taken care of, the remainder of the chapter focuses on use (i.e., consumption of the service by a client). Conceptual illustrations compliment screenshots to effectively convey this content. 
• Whereas the previous chapter delivered a prime number service, Chapter 4 introduces no less than six services that really showcase the capabilities of this application paradigm. With ample explanation and illustration live searches, password strength checks, auto form fills, sorting tables, dynamically generated lists and Flickr-style editable labels are each considered. Not only does one recognize these as design patterns that are already in everyday use (e.g., Flickr, Google Docs, Maps and Search, etc.), one also realizes their potential for re-use in one’s own projects. 
• Chapter 5 introduces five interfaces that are more complex than those presented in the previous chapter. These interfaces are pageable tables, editable tree nodes, log spy (the GWT spin on the UNIX tail utility), sticky notes and jigsaw puzzle. To reiterate, one recognizes these as design patterns already in everyday use, and the potential for re-usability.
• Browser effects are the subject of Chapter 6. Here the author introduces the JavaScript Native Interface (JSNI) as a vehicle that allows JavaScript libraries (e.g., Moo.Fx and Rico) to be accessed directly from Java classes. A wrapper-based approach, independent of JSNI, is also introduced to leverage the Script.aculo.us effects. Although compelling effects can be achieved, cautionary words are included in this Chapter, as the impact may be diminished by browser-level incompatibilities.
• By the end of Chapter 7, impressive calendar and weather widgets have been created, and readied for re-use. 
• In Chapter 8, JUnit is introduced in the context of unit testing. Standalone tests plus test suites are given consideration; this includes tests involving asynchronous services.  
• Although this is only the second book I’ve ever seen from Packt Publishing (the first I’ve reviewed elsewhere), I’ve become accustomed to expecting bonus content towards the end of the book. Chapter 9, which addresses internationalization and XML support, falls into this bonus category. Of course, it’s no surprise that Google expertise on internationalizations ranks high, and this is evident in GWT support for the same. The author provides an hors d’oeuvre of the possibilities. XML support is of particular personal interest, so I was delighted by the degree of support for creating and parsing XML documents. I share the author’s sentiments with respect to XML support wholeheartedly: I too hope that future releases of the GWT will provide broader and deeper support for XML.  
• In the final chapter (Chapter 10), attention is given to increasingly automated methods for deploying GWT-based applications. Starting with a manual deployment in Tomcat, then an automated deployment with Ant, and finally an Ant-based deployment from within Eclipse. 
• A single appendix details how to access and execute the examples provided throughout the book.

With the possible exception of a concluding chapter, page, paragraph or even sentence(!), to provide some sense of closure to the book, I am at a loss to report any omissions, oversights or errors of any consequence. And although it will have to wait for a follow-on contribution of some kind, additional discussion might be given to topics such as Google Gears or even Google Android.

Even though the book I reviewed was a complimentary copy provided by the publisher, I would happily pay for my own copy, and heartily recommend this book to others having interests in the GWT. 

By the way, Packt has an articulated scheme when it comes to Open Source projects:

Packt Open Source Project Royalty Scheme Packt believes in Open Source. When we sell a book written on an Open Source project, we pay a royalty directly to that project. As a result of purchasing one of our Open Source books, Packt will have given some of the money received to the Open Source project.In the long term, we see ourselves and yourselves, as customers and readers of our books, as part of the Open Source ecosystem, providing sustainable revenue for the projects we publish on. Our aim at Packt is to establish publishing royalties as an essential part of the service and support business model that sustains Open Source. 

I cannot suggest that Packt is unique in this approach. Regardless, their approach is certainly welcome.

Cyberinfrastructure: Worth the Slog?

If what I’ve been reading over the past few days has any validity to it at all, there will continue to be increasing interest in cyberinfrastructure (CI). Moreover, this interest will come from an increasingly broader demographic.

At this point, you might be asking yourself what, exactly, is cyberinfrastructure. The Atkins Report defines CI this way:

The term infrastructure has been used since the 1920s to refer collectively to the roads, power grids, telephone systems, bridges, rail lines, and similar public works that are required for an industrial economy to function. … The newer term cyberinfrastructure refers to infrastructure based upon distributed computer, information, and communication technology. If infrastructure is required for an industrial economy, then we could say that cyberinfrastructure is required for a knowledge economy. [p. 5]

[Cyberinfrastructure] can serve individuals, teams and organizations in ways that revolutionize what they can do, how they do it, and who participates. [p. 17]

If this definition leaves you wanting, don’t feel too bad, as anyone whom I’ve ever spoken to on the topic feels the same way. What doesn’t help is that the Atkins Report, and others I’ve referred to below, also bandy about terms like e-Science, Grid Computing, Service Oriented Architectures (SOAs), etc. Add to these newer terms such as Cooperative Computing, Network-Enabled Platforms plus Cell Computing and it’s clear that the opportunity for obfuscation is about all that’s being guaranteed.

Consensus on the inadequacy of the terminology aside, there is also consensus that this is a very exciting time with very interesting possibilities.

So where, pragmatically, does this leave us?

Until we collectively sort out the terminology, my suggestion is that the time is ripe for immediate immersion in what cyberinfrastructure and the like might feel like or are. In other words, I highly recommend reviewing the sources cited below in order:

1. The Wikipedia entry for cyberinfrastructure – A great starting point with a number of references that is, of course, constantly updated.
2. The Atkins Report – The NSF’s original CI document.
3. Cyberinfrastructure Vision for 21st Century Discovery – A slightly more concrete update from the NSF as of March 2007.
4. Community-specific content – There is content emerging on the intersection between CI and specific communities, disciplines, etc. These frontiers are helping to better define the transformative aspects and possibilities for CI in a much-more concrete way.

Frankly, it’s a bit of a slog to wade through all of this content for a variety of reasons …

Ultimately, however, I believe it’s worth the undertaking at the present time as the possibilities are very exciting.

CANARIE’s Network-Enabled Platforms Workshop: Follow Up

I spent a few days in Ottawa last week participating in CANARIE’s Network-Enabled Platforms Workshop.

As the pre-workshop agenda indicated, there’s a fair amount of activity in this area already, and much of it originates from within Canada.

Now that the workshop is over, most of the presentations are available online.

In my case, I’ve made available a discussion document entitled “Evolving Semantic Frameworks into Network-Enabled Semantic Platforms”. This document is very much a work in progress and feedback is welcome here (as comments to this blog post), to me personally (via email to ian AT yorku DOT ca), or via CANARIE’s wiki.

Although a draft of the CANARIE RFP funding opportunity was provided in hard-copy format, there was no soft-copy version made available. If this is of interest, I’d suggest you keep checking the CANARIE site.

Finally, a few shots I took of Ottawa are available online …

On the Use of Informal Ontologies in the Delivery of Service Oriented Architectures (SOAs)

In Service-Oriented Architecture: Concepts, Technology and Design, author Thomas Erl frames ontologies (section 10.2) in a top-down strategy for the delivery of a Service Oriented Architecture (SOA) .

As the first step, in a multistep process, what starts with ontologies ultimately results in a Contemporary SOA (Erl, section 3.2.20):

Contemporary SOA represents an open, extensible, federated, composable architecture that promotes service-orientation and is comprised of autonomous, QoS-capable, vendor diverse, interoperable, discoverable, and potentially reuable services, implemented as Web services.

SOA can establish an abstraction of business logic and technology, resulting in a loose coupling between these domains.

SOA is an evolution of past platforms, preserving successful characteristics of traditional architectures, and bringing with it distinct principles that foster service-orientation in support of a service-oriented enterprise.

SOA is ideally standardized throughout an enterprise, but achieving this state requires a planned transition and the support of a still evolving technology set.

In the same chapter, Erl also provides an abridged Contemporary SOA definition:

SOA is a form of technology architecture that adheres to the principles of service-orientation. When realized through the Web services technology platform, SOA establishes the potential to support and promote these principles throughout the business process and automation domains of an enterprise.

In other words, buying into the top-down strategy can ultimately result in a Contemporary SOA and this is a big deal.

Erl also discusses the bottom-up strategy for delivering a SOA (section 10.2).

In striking contrast to the top-down strategy, and as Erl describes it, the bottom-up strategy does not incorporate ontologies. Despite the fact that “… the majority of organizations that are currently building Web services apply the bottom-up approach …” (Erl, pg. 368):

The bottom-up strategy is really not a strategy at all. Nor is it a valid approach to achieving a contemporary SOA. This is a realization that will hit many organizations as they begin to take service-orientation, as an architectural model, more seriously. Although the bottom-up design allows for the creation of Web services as required by applications, implementing an SOA at a later point can result in a great deal of retro-fitting and even the introduction of new standardized service layers positioned over the top of the non-standardized services produced by this approach.

After reading this chapter, one is left with the impression that Erl favors the agile strategy (Erl, section 10.4) as it attempts “… to find an acceptable balance between incorporating service-oriented design principles into business analysis environments without having to wait before introducing Web services technologies into technical environments.”

I would be willing to accept all of this on spec if it weren’t for the fact that it’s possible to create informal ontologies, in non-SOA contexts, during bottom-up processes.

And if this is possible in non-SOA contexts, then it’s reasonable that informal ontologies could be incorporated into the bottom-up strategy for SOA delivery.

I believe this is worth exploring because use of informal ontologies in a bottom-up strategy for SOA delivery may improve the potential for ultimately achieving a Contemporary SOA. (An outcome, you’ll recall from above, Erl stated wasn’t otherwise acheiveable.)

I also believe this is worth exploring as, as Erl states, most organizations are attempting to gravitate towards SOAs from the bottom up.

Because the agile strategy (ideally) combines the best of both the top-down and bottom-up approaches, I also believe it’s worth exploring the potential for informal ontologies in this case as well.

Although further research is required, the figure below extends Erl’s Figure 10.3 (pg. 367) with a first-blush suggestion of how informal ontologies might be incorporated into the bottom-up strategy for SOA delivery.

It’s important to note that Erl’s original figure illustrates a five-step process that culminates with “Deploy services”.

Based on work I’ve done elsewhere, in this first-blush depiction, I believe the steps required to make use of informal ontologies would need to include:

• “Extract service relationships” – In the work I’ve done elsewhere, this extraction has been achieved by Gleaning Resource Descriptions from Dialects of Languages (GRDDL). GRDDL extracts relationships and represents them in RDF from XML via XSLT.
• “Generate informal ontology” – These days, ontologies are often expressed in the Web Ontology Language (OWL). OWL is a semantically richer and more-expressive variation of XML than is XML. Much like the previous step, the generated informal ontology is expressed in OWL via processing that would likely make use of XSLT. This step might also involve the need to incorporate annotations.
• “Integrate informal ontologies” – Because each act of modeling through deploying application services will result in an informal ontology, there will eventually be a pressing need a integrate these informal ontologies. This ontology integration, which may also involve top-down or formal ontologies, will provide the best possibilities for ultimately realizing a Contemporary SOA.

Even at this early stage, the use of informal ontologies in the delivery of a SOA appears promising and worth investigating.

What’s in Your SOAP Toolkit?

Your choice of SOAP toolkit may be the most important decision you make in implementing a Service Oriented Architecture (SOA) based on Web Services.

This wasn’t always the case.

For example, First-Generation Web Services (WS-1G) typically depicted SOAP, WSDL and UDDI as more-or-less equal players.

In reality, however, UDDI was and remains (e.g., Erl, Chapter 3) a bit of a non-starter.

WSDL remains key, and continues to evolve with version 2 well on its way to becoming a bona fide standard.

So, what about SOAP?

In learning more about Second-Generation Web Services (WS-2G), I continue to be struck by how much value is being driven through SOAP. In turn then, WS-2G are being driven through XML, as SOAP makes use of XML. It is for reasons like this that SOA-guru Thomas Erl states that SOAs are ultimately all about XML and not Web Services (Erl, Chapter 3, Section 3.5.4).

And this returns us to the point made at the outset.

Because so much value is being driven through SOAP, you must choose your SOAP toolkit wisely. More specifically, toolkit choice will determine, for exanple, which WS-2G specifications are supported via implementations. Even more specifically, as a third-generation SOAP toolkit, Apache Axis2 includes core (e.g., WS-Addressing) and extended (e.g., WS-Coordination, WS-ReliableMessaging, WS-Security, etc.) implementations of a number of WS-2G standards.

SOAP toolkits may also reflect vendor bias. For example, IBM has championed WS-Notification, whereas Microsoft’s emphasis has been on WS-Eventing. These vendor biases at the standards level are quite likely reflected at the SOAP toolkit level. For example, it is reasonable to expect that an IBM SOAP toolkit would include an implementation of WS-Notification, whereas a Microsoft SOAP toolkit would offer one of WS-Eventing instead.

Even though working with SOAP may initially appear a low-level detail at the outset of conceptualizing a SOA, it turns to be a very important consideration that is amplified as SOA adoption proceeds.

Cooperative Computing Program Operating in Stealth Mode

Normally I don’t like to bandy about words like ‘cool’. It bespeaks narrative laziness. However, in this post I will purposely make an exception.

While at Platform, one of the coolest projects I worked on was one of curriculum development.

Working with a team of faculty, administrators and industry representatives, a curriculum was developed for the Michingan Jewish Institute’s (MJI) degree program in Cooperative Computing.

What is Cooperative Computing? We defined it this way:

Cooperative Computing is the facilitated interchange of information between willing participants for individual or mutual gain.

Specifically:

• Facilitated implies use of a enabling environment (e.g., .NET, J2EE, etc.), along with its associated data (e.g., XML with related standards and technologies) and programming models (e.g., C/C++, Java)

• Interchange emphasizes the (e.g., XML-)detailed interaction that is mediated via standards-based protocols and interfaces (e.g., SOAP plus Grid-enabled Web services)

• Information is the payload of the interchange – and note that it’s information purposely, instead of data. Why? Information is “data that has been interpreted, translated, or transformed to reveal the underlying meaning”. (Use of a lingua franca like XML ensures that this is the case.)

• Willingness implies that the interaction is agreed upon – in fact, it’s most likely negotiated

• Participants may be one or more people, but might also be other concrete entities (e.g., the environment) or even abstract entities (e.g., software and/or hardware components like agents, machines, robots, etc.)

• Gain conveys the individual and/or mutual benefit derived from the interaction – e.g., the provision of service, a step in a business process, etc.

Use of this definition was consistent with MJI’s desire to use Cooperative Computing as an umbrella that could encompass Grid Computing, Web Services, Service Oriented Architectures (SOAs), and so on.

Although the curriculum was laid out almost-exactly two years ago, it took MJI a little bit of time to do the real work of developing the content.

When I recently connected with marketing director Dov Stein, he indicated that the first cohort of students has almost completed the program.

If you open http://mji.edu/inside.asp?id=99929 and search for “Cooperative Computing” you can have a closer look at the curriculum. (Well, I said they were operating in stealth mode!)