https://source.sakaiproject.org/contrib/simonides/
Please direct all feedback or questions to simonides.help@nyu.edu
]]>I'll send an email to the dev list when it's out there and we'll probably have something in the newsletter too.
I also know that our esteemed colleagues are doing some demos of the tool for those who didn't see it at the conference, so let me know if you're interested in that.
]]>The old idea of "hybrid" mode is still going strong - in fact, it's really the only idea going for transitioning users from one to the other. We're still operating on the idea that we can run Sakai 2.x "headless" and show Sakai 2.x tools inside of a Sakai 3 container. However, my concern is that at some point, there has to be some mapping and migration from a Sakai 2 tool to a Sakai 3 tool.
User data that relates to a particular instance of a course in a particular semester is not so important - although we have an obligation to retain that for a certain period of time. The data that really does have to be migrated to Sakai 3 tools is what Lance called the "structure" of the course. By that, we don't mean the particular layout - which would obviously be pretty different in Sakai 3 - instead we mean the content, but also the assignments, and the forum topics (although not the posts themselves), etc: anything an instructor would need to bring over to teach the course again to a new group of people.
Could we migrate this data piecemeal based on Instructor course copy? That is to say, when an Instructor is ready to teach a course in Semester B, and they want to copy old content from Semester A (we already have this metaphor in Sakai and Blackboard), the course copy process will migrate any tools to their Sakai 3 versions if those tools are available. For the other tools, Sakai 2 versions will be nested inside.
And then, when the Instructor is ready to teach Semester C, she initiates another course copy (from B->C), and now any remaining Sakai 2 tools are now migrated to their Sakai 3 equivelents (which are now available).
]]> Other thoughts: a recent BOF focused on what tools will be in Sakai 3 course sites. Putting aside the notion that a tool-centric approach may be innately flawed, how are "course" sites going to be different? Perhaps the point of Sakai 3 is to do away with site types entirely?]]>However, a recent post on his blog (yes, he has one) has thrown all that into question...
]]> Judge Posner's thoughts on the Future of Newspapers mostly cover familiar territory: newspapers are losing money, large, respectable newspapers are closing, what is the future of the Fourth Estate?He rightly points out that online news is free because the cost for newspapers to post content they already have online is close to zero, so why not? The second reason online content is free, he claims, is because, "...online providers of news who are not affiliated with a newspaper can provide links to newspaper websites and paraphrase articles in newspapers, in neither case being required to compensate the newspaper."
Bwah? That's true, of course, but it's not why content is free. Newspapers control whether or not their content is free online or not. Full stop. They have control. The end.
If they provide they content online for a fee, and someone reproduces it in full (going way beyond fair use), or even if someone takes a print paper and manually types it up, and attempts to post it online and present the work as their own, then YES, that should be illegal, and content owners are already allowed to pursue legal options to rectify the problem.
But the idea that merely linking to content online is somehow "mooching" off others? That's bananas! It's the Guardian that focuses on this claim. Posner seems to believe that linking to free stories on newspaper's websites is somehow hurting them, and taking away revenue.
Am I profiting off Judge Posner or the Guardian by linking to them? Hardly. In fact, I'm driving more people to their site, which, if you're providing content for free, is how you make a profit (off ads).
And for Judge Posner to seem to be recommending a ban on linking, or a fee for linking, seems to go against logic for a conservative. I thought the invisible hand was supposed to take care of this for us...
I don't get it - does Judge Posner not understand "the internets"? He's coming off like Ted Stevens 2.0 here, and it's just sad.
]]>What is the official Sakai tag? #Sakai2009? (Since we're one conference a year now, and it's good to be Y3K compliant.)
Update: Looks like the official tag is #sakai09.
]]>Restart Safari, and when you load an applet, it should pop right up.
]]>Take a moment to think about, or even blog about, a women in technology that inspires you. If you can't think of one, the Anita Borg Institute has some suggestions.
Recently, my heros are this girl scout troop that entered a LEGO robot competition, even though their troop leaders didn't know anything about robotics. It's a cute article, even though you have to read it in their silly interactive book format.
]]>Special thanks to Ian Boston, Seth Theriault, Kevin Wiggen and Julian Reschke.
]]> It's worth noting that enabling JCR in Sakai does just that and nothing more - JCR can only be used by tools that are designed to use it (this is true no matter what repository you ultimately use). OOTB, nothing in Sakai 2.6 will use the JCR. In 2.5, experimental code was written to force Resources to use JCR instead of native Sakai conventions for storing content on the file system and the database. The instructions include information on how to enable this experimental code for 2.6, but be aware that this particular approach is largely abandoned in Sakai 3.Also be advised that this is a work in progress - there are things that we'll probably do different if we put this code into production and I welcome all suggestions.
Assuming you've already got a Sakai 2-6-x branch install set up, and that you've build and run this sakai instance already, here's what you'll need to do.
Navigate to sakai src home.
svn co https://source.sakaiproject.org/contrib/tfd/trunk/xythosservice
You'll need to change these files:
pom.xml
deploylocalrepo/redeploy-m2.sh
xythos-impl/pom.xml
xythos-impl/pack/pom.xml
Basically, you just need to make the poms all agree on their parent version (which is 2.6.0RC1-SNAPSHOT in my case), swap out some dependencies which have now moved to kernel, and update the redeploy script, as we use a slightly different xythos version.
Next, you'll need to load the xythos jars (from the xythos system) into the sakai maven repository. The necessary jars are:
/bin/xythos-jcr.jar
/wfs-7.0.50/lib/jlansrv.jar
/wfs-7.0.50/lib/hibernate2.jar
/wfs-7.0.50/lib/xssoracle.jar
/wfs-7.0.50/lib/lucene-core-2.0.0.jar
/wfs-7.0.50/lib/xssmssql.jar
/wfs-7.0.50/lib/xssdb2.jar
/wfs-7.0.50/lib/xsscore.jar
/wfs-7.0.50/lib/xss.jar
/wfs-7.0.50/lib/WorkflowCommon-6.0.7.jar
You'll need to get these jars and the xythos.properties file from the xythos machine you want to connect to.
Create a dir for all the xythos jars and xythos.properties file somewhere on the sakai file system.
Next, cd /sakai-src/xythosservice/deploylocalrepo/
./redeploy-m2.sh [xythos jars dir] [xythos jars dir]
(yes, you need to pass the dir parameter twice.)
This will load up all the xythos jars into your maven repository.
cd sakai-src
vi pom.xml
add: <module>xythosservice</module>
Now, rebuild you sakai src:
mvn clean install sakai:deploy -Dmaven.tomcat.home=/usr/local/tomcat -Dmaven.test.skip=true
xythosservice should build as part of sakai.
Now, we'll need to make changes to the kernel. In normal sakai installations, kernel is never part of your Sakai src. It gets pulled down as a dependency during build time as a zip, and stashed away in the maven repo. Then, during deploy time, the zip is exploded into the tomcat dir.
Kernel is a separate project, so it shouldn't be checked out in your sakai-src dir. It gets it's own src dir (which I will call kernel-src).
svn co https://source.sakaiproject.org/svn/kernel/tags/kernel-1.0.2 kernel
(As of this writing, kernel-1.0.3 has just been tagged. Really depends on what 2-6-x is using.)
You will need to modify the following files:
pom.xml
kernel-component/src/main/webapp/WEB-INF/components.xml
kernel-impl-experimental/content/migration/sakai-content-jcr-migration-impl/pom.xml
kernel-impl-experimental/content/migration/sakai-contentmulti-impl/pom.xml
kernel-impl-experimental/content/migration/pom.xml
kernel-impl-experimental/content/pom.xml
kernel-impl-experimental/content/jcr/pom.xml
kernel-impl-experimental/content/jcr/sakai-content-jcr-impl/pom.xml
kernel-impl-experimental/pom.xml
In components.xml:
replace <import resource="jackrabbit-components.xml" /> with <import resource="xythos-components.xml" />
replace <import resource="preloadcontent.xml" /> with <import resource="xythos-preloadcontent.xml" />
uncomment <import resource="content-jcr-components.xml" />
comment <import resource="content-components.xml" />
And you will need to add the following files:
cp sakai-src/xythosservice/xythos-impl/pack/src/webapp/WEB-INF/components.xml kernel-src/kernel-component/src/main/webapp/WEB-INF/xythos-components.xml
cp sakai-src/xythosservice/xythos-impl/pack/src/webapp/WEB-INF/preloadcontent.xml kernel-src/kernel-component/src/main/webapp/WEB-INF/xythos-preloadcontent.xml
vi kernel-src/kernel-component/src/main/webapp/WEB-INF/xythos-components.xml and change this line to include the 'xythos' part: <import resource="xythos-preloadcontent.xml" />
(jar files will still need to be added to lib afterwards)
If you look at the output from the maven build, you should see where it is stashing your overlay zip. Mine goes in: ~/.m2/repository/org/sakaiproject/kernel/deploy/kernel-assembly/1.0.2/kernel-assembly-1.0.2-tomcat-overlay.zip
rm that sucker so that you can build your new one.
cd to kernel-src and build it
Obviously, this won't include the xythosservice jar and for some reason (which I have to look into), the experimental jars aren't included either. So we will copy them in.
cd /usr/local/tomcat/components/sakai-kernel-component/WEB-INF/lib
cp sakai-src/xythosservice/xythos-impl/impl/target/sakai-xythos-impl-SNAPSHOT.jar
cp kernel-src/kernel-impl-experimental/content/jcr/sakai-content-jcr-impl/target/sakai-content-jcr-impl-1.0RC2-SNAPSHOT.jar .
cp kernel-src/kernel-impl-experimental/content/migration/sakai-content-jcr-migration-api/target/sakai-content-jcr-migration-api-1.0RC2-SNAPSHOT.jar .
cp kernel-src/kernel-impl-experimental/content/migration/sakai-content-jcr-migration-impl/target/sakai-content-jcr-migration-impl-1.0RC2-SNAPSHOT.jar .
cp kernel-src/kernel-impl-experimental/content/migration/sakai-contentmulti-impl/target/sakai-contentmulti-impl-1.0RC2-SNAPSHOT.jar .
Finally, add this to your sakai.properties:
jcr.experimental=true
defaultService@org.sakaiproject.content.api.ContentHostingService=jcr
xythosHome@org.sakaiproject.jcr.api.JCRService.repositoryBuilder=/usr/local/xythos_jars/
Files uploaded in Sakai will now be deposited in Xythos.
Also, files uploaded to the right place in Xythos will show up in Sakai.
You also now have a JCR (backed by Xythos) that you can develop Sakai tools for.
Pretty folders - on the Xythos side, files are stashed in a folder structure that uses Sakai's site ids, blah!
Mapping of xythos home folders to Sakai My Workspace/Dashboard Resources.
Shared metadata, as far as I can tell
Even though this solution "works," you still get this error periodically logged:
2009-02-27 14:19:46,728 ERROR main org.sakaiproject.content.impl.BaseJCRResourceEdit - Content is being stored in memory, this is bad! ... but we will do it anyway, memory used = 12616 2009-02-27 14:19:48,012 WARN main org.sakaiproject.content.impl.BaseContentService - Edit Object not closed correctly, Cancelling /group/PortfolioAdmin/system/ 2009-02-27 14:19:48,047 ERROR main org.sakaiproject.thread_local.impl.ThreadLocalComponent - Failed to unbind Object org.sakaiproject.content.impl.BaseJCRCollectionEdit@166de66 java.lang.NullPointerException
I still have to figure out where this error is being generated so I can see if it's really as terrifying as it sounds.
]]>
The eee I got comes with Xandros Linux installed. Although in its "easy" mode, its basically a "beginner" linux GUI, I found it was pretty good at everything I needed to do. I had originally decided that I would probably put Ubuntu on it (since everyone seems to love it and they make a distro specifically for the eee pc) but I asked around. Most people at work seemed to believe that they didn't really gain that much by switching to Ubuntu. Plus, the startup time for Xandros is pretty fast.
However, if you want to customize anything, it's a giant pain in the ass. I did eventually decide to install Ubuntu because of one particular deal-breaker. NYU's wireless network uses WPA(2) Enterprise, and Xandros doesn't support Enterprise (and the authentication it enables) OOTB. Ubuntu does.
I have to also say that the eee's battery life is fantastic - when wireless is off. With it on, its pretty much what you'd expect for something this size and price. Thoughts on the eee?
Yesterday Essex County College in Newark, NJ was our gracious host for another NYC Regional Meet Up. Essex, Rutgers, NYU, NYU School of Medicine, and CampusEAI were all well represented. We had a chance to talk about a variety of topics, specifically tools, adoption, and content authoring. We also looked at different Sakai sites and spoke about how different organizations have different approaches to using Sakai for teaching and learning in their respective environments.
The subject of portfolios did come up, and we discussed at length the types of use cases for portfolio functionality. Apparently both Rutgers and LaGuardia are doing some type of portfolio work, and NYU is interested. Perhaps we may have a portfolio-centric meetup at some point.
Jason and I also gave a recap of the Paris Conference and covered some of the trends that came out of it. It was great to see both new and known faces, but one of the things I was especially impressed about was variety of experience represented. There were, of course, Developers and Instructional designers, but also quite a few Faculty and Librarians!
If you're interested in particpating in the NYC Regional Sakai Group, please subscribe to the mailing list by joining our site on http://collab.sakaiproject.org (you may need to create an account first).
]]>I was happy that we could articulate (at least partially) the tension between content creation that is structured (and probably based on templates) and content that can be organized any which way ("wild wild west" content authoring). These approaches to content authoring are really more of a spectrum and a potential feature would have to be able to satisfy needs all along that that spectrum.
I liked the idea that we could both accommodate the ability for system-provided templates and also allow users to promote their created pages to templates.
I was also happy that while sequencing and tracking were articulated as important, everyone seemed to agree that neither were crucial for a first implementation.
I was also ecstatic to learn that the groundwork is being laid for Sakai to be aware of content/items/entities inside of tools (like discussion thread, assignments, etc.) in order to accomodate the need to place them on a page and treat them like any other piece of content in Sakai.
]]>Like many US institutions, we are largely a Research university - our instructors (and many of our students) are also researchers. So I felt that the claim that Instructors are wholly unfamiliar with research approaches to teaching and learning slightly jarring. True, they aren't applying ALL those techniques to their teaching, but they are doing some of them. (Post continues below...)
]]> Their goal is to teach their course - they have no investment in any overarching strategy to educate more individuals on a massive scale. (In fact, little initiative exists at the University level for these ideas in the States.) Anything that helps them teach their course is good, anything that throws up barriers to teaching is bad. For them, the initial time investment in learning new tools is a barrier that distracts them from their real work: research.(If you like, I made a cute diagram for this. Also, apologies to Ethan Ehrenburg who first articulated this.)
Their goals are to get tenure and prestige, and to do that, they need to do research, then publish. Teaching could almost be seen as a chore, something that merely pays the bills. I admit, this is a slightly cynical view, but I think it really helps to articulate why our teachers are risk-adverse when it comes to teaching with technology. When it's 1 AM, they need some that they know will "work" for them.
Our challenge is in convincing instructors/faculty/teachers to actually use the technology tools we provide. I think the angle for us is to help these instructors to be agents of change when it comes to teaching with technology by emphasizing to them that they can get more accomplished with less teaching and prep time by shifting their teaching approach away from lecture and more towards online tools. Diana Laurillard's tool and approach is the perfect way to show instructors exactly how this bears out.
One last thing: I thought it was interesting she referred to the instructors as "lecturers" at the end - isn't the whole point that instructors are much, much more than just lecturers and they need to get away from the reliance on the time-consuming lecture-based approach of teaching?
]]>