Some cool debug output from presence. Just here for reference.
Navigating to MyWorkSpace
Session is: c5435a5c-ef0e-47f1-806a-78bc8ca6cdba
PresensePortlet.doGet location=~fred-presence Context=~fred
setPresence 07722bae-78cb-43f1-0056-00517927e3bd loc=~fred-presence
getPresentusers ~fred-presence
Navigating to my site
site/1c50bc19-bd71-4480-0003-05a77a41cab2
PresensePortlet.doGet location=1c50bc19-bd71-4480-0003-05a77a41cab2-presence Context=1c50bc19-bd71-4480-0003-05a77a41cab2
setPresence 07722bae-78cb-43f1-0056-00517927e3bd loc=1c50bc19-bd71-4480-0003-05a77a41cab2-presence
getPresentusers 1c50bc19-bd71-4480-0003-05a77a41cab2-presence
In effect the presense portlet is tracking the sessions who have run the presense portlet.
Navigating to Chat
site/1c50bc19-bd71-4480-0003-05a77a41cab2/page/1d49d1bf-b30e-452e-00db-8cd4e7668444
PresensePortlet.doGet location=1c50bc19-bd71-4480-0003-05a77a41cab2-presence Context=1c50bc19-bd71-4480-0003-05a77a41cab2
getPresentusers 1c50bc19-bd71-4480-0003-05a77a41cab2-presence
setPresence 07722bae-78cb-43f1-0056-00517927e3bd loc=72acc769-d887-412b-00ae-d108d3f3dc63
getPresentusers 72acc769-d887-412b-00ae-d108d3f3dc63
Take a look at this URL.
http://www.msnbc.msn.com/id/10794396/from/RS.3/
Think about what it really means..... It is so obvious... Read on.
I have no inside information here - just reading this article and filling in the very obvious missing pieces.
Step 1
Microsoft improves VirtualPC. VirtualPC will ultimately ROCK ROCK ROCK on Mac OS/X. Within a year we will have a VirtualPC that will be so sweet, that no one will want to dual boot. The agreement here is effectively that once VPC works really well, Microsoft will still support their mac versions of Office even after 85% of the Mac users use Word under VPC. But after 5 years, it is over.
One of the MAIN REASONS to use Dual core is so that VPC runs perfectly - think about it.
Step 2
Microsoft will want to make this all work eventually. Why not? Sell more operating systems.
Just my random musings for today.
Was thinking about what google would do next. Figured I would write it down so I could point back to it when it happenned. Of course if I am wrong - I will let this slide off into obscurity.
- Google Stocks (not trading - just information - in addition - they will search for patterns)
- Google Metadata - This will be Google poring through structured metadata - yes I know that they claim this not necessary - they will change their minds.
- Google Magazine - This will an attempt to produce the ultimate e-zine where people publish well done articles and Google finds them and uses peer ratings to produce a polished magazine
Some of the little bits of Mac setup as I retired my home Linux server and made my Mac Desktop also my server.
/etc/sshd_config
SSHD is started from xinetd
/etc/inetd.conf
Mac uses xinetd
/etc/xinetd.conf
/etc/xinetd.d/ssh
This does not specify the port because xinetd is doing the listening and by the time it starts sshd, the port is already established.
So where does it do it?
/etc/services:
ssh 1222/udp # SSH Remote Login Protocol
ssh 1222/tcp # SSH Remote Login Protocol
Port 8081
DocumentRoot "/Users/csev/www"
<Directory "/Users/csev/www">
Uncomment:
LoadModule php4_module libexec/httpd/libphp4.so
AddModule mod_php4.c
http://www.sanbeiji.com/tech/tutorials/php/index.php
Apple-> System Preferences-> Sharing
Check "Remote Login" (ssh) and "Personal Web Sharing" (apache)
applesrv:~/dev/sakai csev$ maven plugin:download -DgroupId=sakaiproject -DartifactId=sakai -Dversion=2.0.0
__ __
| \/ |__ _Apache__ ___
| |\/| / _` \ V / -_) ' \ ~ intelligent projects ~
|_| |_\__,_|\_/\___|_||_| v. 1.0
Plugin 'maven-deploy-plugin' in project 'Sakai' is not available
build:start:
plugin:download-artifact:
[echo] repo is 'http://www.ibiblio.org/maven/'
[echo] trying to download http://www.ibiblio.org/maven//sakaiproject/plugins/sakai-2.0.0.jar
[echo] repo is 'http://cvs.sakaiproject.org/maven/'
[echo] trying to download http://cvs.sakaiproject.org/maven//sakaiproject/plugins/sakai-2.0.0.jar
5K downloaded
plugin:download:
[delete] /Users/csev/.maven/plugins not found.
[delete] Deleting 5 files from /Users/csev/.maven/cache
[delete] Deleted 2 directories from /Users/csev/.maven/cache
[copy] Copying 1 file to /Users/csev/dev/maven-1.0/plugins
BUILD SUCCESSFUL
Total time: 13 seconds
Finished at: Sat Jan 14 02:43:11 EST 2006
applesrv:~/dev/sakai csev$
I decided to run through the JIRA's for WebDAV and fix a few for the maintenance release. Once you make a mod to a piece of software like WebDAV you might was well make a bunch of mods because even if there is only one mod to a crtitical system like DAV, it needs a bunch of testing before release.
Hit list:
SAK-798
SAK-3031
SAK-3303
SAK-3482
SAK-3483
When wanting to test modifications to
~/dev/sakai/kernel/component/src/config/org/sakaiproject/config/sakai.properties
It is sufficient to do a "maven sakai" from the ~/dev/sakai/kernel directory.
(i.e. you do not have to do maven sakai from ~/dev/sakai)
Lance has always wanted a way to include a user's resources tool in some other site - I think the IU school of business has a portal that wants to have a tab called "show user's resources". This now works r5218 and SAK-3465 now support this feature.
This allows Sakai to be more flexible and used to be the "Campus storage". I am guessing that over time, the development of the Sakai Resourse tool GUI will be affected by this stand-alone mode.
I wrote the code on my airline flight and cab ride from Detroit to Washington DC to go to the IMS Common Cartridge meeting at BlackBoard.
Lance can decide if he likes this enough to put it in the maintenance branch.
The following URLs are now supported in Charon:
http://localhost:8080/portal/page/sakai.resources?sakai.site=~csev
http://localhost:8080/portal/tool/sakai.resources?sakai.site=~csev
http://localhost:8080/portal/title/sakai.resources?sakai.site=~csev
In this form, the specified site is scanned and the first placement of the tool within the site is the one chosen. This works to replace either the page id or the tool id for these three forms (page, tool, title). When the page form is used, the definition is to select the page that has the specified tool placed on that page. If there are more than one tool is on the page, all the tools on the page are rendered. Unless the site allows anonymous visitors, the URL pattern demands the user to be logged in prior to looking up the site.
Chuck Hedrick (one of the Sakai community's superstars) is always way ahead of our ability to integrate patches/features. This is great because it leads us to figuring out how to handle materials coming from a broad community. This will knock out the cobwebs in procedures that we don't yet have.
But this is really pretty simple. Chuck H is not waiting for everyone to give him permission to move forward - he is just doing it. Since there is no paid system integrator in the Sakai foundation, we just have to get folks to work togther and try to get the community to render opinions on stuff so stuff can move forward.
In a way, since IU, OSP, and UM are doing most of the work in this area, they need to get involved to make sure these modifications are good and worthy to drop into trunk. Now IU and UM are just volunteers like Rutgers, but IU and UM are the "leads" in the areas that Chuck H. is working so they need to respond to these patches in some timeframe.
Some comments on these patches.
On Jan 7, 2006, at 12:27 PM, Charles Hedrick wrote:
We've started moving to 2.1. We're starting to move the Rutgers patches listed in Jira 2505 from 2.0.1 to 2.1. Other Rutgers staff will do most of this. I'm doing AccessServlet. It's been refactored, so most of the changes to into BaseContentService.java. Because I'm giving you only the changes to those modules, some feature are only half there. They depend upon changes to other files, which will have to come from other people. [However I believe that they can be easily adapted from the 2.0.1 patches, which you can find from Jira 2505.]
These changes are in a tar file attached to Jira 3442.
Implements 4 features. (These features are completely implemented by this patch. See below for the ones that are partly implemented.)
1) Aliases. If you create a mail alias for a site, you can access its resource section with the same alias, e.g. http://server/access/myalias
2) Content view. If you access a folder (as opposed to an individual resource) via /access/content, normally you get an error. With this patch you will get a directory listing in a format that is appropriate for end users. It shows the description of the folder and each item, so it looks a lot like a Melete organizer page.
3) If you specify ?basedir=xxx or ?sbasedir=xxx [for Sferyx], directory listings have a special format intended to support pick lists in HTML editors. Our users want to be able to insert images easily in HTML. Part of that is for the HTML editor to be able to show them a listing on their /images directory and make it easy to pick an image. This is the server side of that. The basedir format should be easy to use in any Javascript code. The sbasedir format is tuned specifically for Sferyx' file picker.
4) implemented file upload via HTTP POST operations. This is also intended for HTML editors, to let them upload images. Sferyx uses this technique, and I believe other HTML editors do as well.
I feel that these modifications are effectively upwards compatible and add good features that cause no harm to any of the current ways that code works. I would like to simply move these patches into trunk so Chuck does not have to maintain these. But I would like to hear from others who like these patches or think that these patches should not just become part of Sakai.
These features need documenting. We need a document ~dev/sakai/docs/architecture/sakai_access.doc that describes these features of access servlet in a style similar to the other documents in this directory. There is not a current document on access servlet so one should be started. To me documenting these features for posterity is an important aspect to getting these features into the code base. The simplest would be for Chuck H to write up the document - if not it will wait until someone else gets around to writing the document. I don't want to hold up the progress on moving this to trunk with a demand for documentation - but it is a strong desire that we don't go too far without writing the internal developer documentation so that folks can use these features. It is always easier to write up basic documentation while things are fresh in people's minds.
Interaction with other patches. I don't yet have 2.1.0 versions of our other patches. However I believe the 2.0.1 versions may port fairly easily except for this patch. (This one was hard because AccessServlet was refactored for 2.1.0.) See Jira entry 2505 for a list of our 2.0.1 patches.
1) Users without write access to resources are prevented from seeing inside a directory whose name starts with "protected." Other parts of this feature are in ResourcesAction.java, chef_resources_list.vm, chef_resoures_newlist.vm. If you don't want this feature, look for "protected" (with the quote marks) in BaseContentService.java, and remove the whole paragraph (surrounded by blank lines).
This feature is something that needs to be discussed. Security by naming convention is a quick way to add a feature but can result in brittle code. Chuck H - lets keep this one separate and keep talking about this. My concern with this feature is its design approach from a technical level - so we need to keep working on this.
So I would suggest that you make a separate JIRA item - call it something like "Adding protected folders and files to Content Hosting" and publish a patch. Perhaps this is best done as a requirement because it really is a request for new feature which also happens to have a patch.
2) Users can change the order of entries in resources. This patch uses the proper order in displaying directories, but ResourcesAction and the vm files [same list as (1)] need to be changed to let the use change the order, and to use the proper order in the Resources tool.
I think that this is a feature that many would like. I would also like to keep this patch separate from the others. My concern here is two-fold - first we need to look at how this is done storage-wise and whether the approach used for storage of the ordering information will perform at scale (we had a performance problem on the first implementation of tab ordering). The second concern I have is the user interface. Lots of people have opinions about how the Resources user interface is supposed to look and when the resources tool user interface is changed we need to get a lot of eyes on the proposed changes. So before we go forward on this I would like to see some kind of design proposed and made available for folks to look at.
We don't really have a good "procedure" for how we do this "hey take a look at this design" and give comments. I would propose that in lieu of waiting for a formal process that we come up with a confluence page which takes some screenshots of the current modified tool running at Rutgers in 2.0, add some descriptive text and get some discussion around the changes so we can get some agreement from the Resource tool stakeholders before going forward.
I would also suggest that you make a separate JIRA called something like "Ordering items in the Resource Tool" and publish your patches here for folks to play with. Also entering a requirement would be a good idea. Perhaps this is really just a requirement...
As Jim Eng has said separately this code (Resources Tool) is a real moving target right now. The end-user interface is not changing much at all, but it is being re factored in terms of *how* things are done internally for 2.1.2. It is going from a monolithic tool to a set of cooperating helper tools. SO expect that you will have to end up with a 2.1, 2.1.2, and possibly even a 2.1.1 version of this patch. Chances are good that the code won't change too much (similar to the Access Servlet refactor above) but it will be in different places and different files.
Since you are deploying 2.1 - the only patch that matters for you is the 2.1 versions of the patch (for now).
---- To the community ----
We all have a responsibility to take a look at these modifications - one of the best ways to know that folks "like" a particular patch and that the patch is high quality is for more than one site to successfully run it in production. This pattern worked very well for things like the SU tool - since several sites had already run it successfully it dropped into the release with barely a ripple. So I will be looking for some community reaction to and investment in these patches. If community simply say "yes do them all", that is fine input, but the speed at which these patches move forward depends solely on when folks from IU and UM have time.
It is much better input when the folks in the community say "I ran all of this in production for several months - it ran fast and reliably and my users loved it". :)
---- Summary -----
Please separate this into three thrusts.
The Access Servlet stuff can likely fold in nicely to trunk - I looked this code over in 2.0 and actually tried to get it into 2.1 but ran out of time - since the Access code refactor is already done in 2.1 - your patches should be solid for all 2.1 and 2.1.x versions giving us time to get them into trunk so you don't have to separately maintain these.
The ContentHosting stuff has some design issues. Keep it separate - use it at Rutgers - when we get some time, we need to talk about the right way to do this for the long term. This should probably become a "requirement" where the need is expressed in end-user terms.
The Resources tool ordering just needs some eyes to look at the GUI changes and "sign off" - this code is in the midst of refactor so keep these patches nice and separate and expect to have to keep moving the patches around through 2.1.2 - work with Jim Eng and perhaps we can smooth out some of the refactor bumps. At a minimum, since Jim knows about these patches, Jim can let you know when things have settled down so that you can work together to make the patches work in 2.1.2 while the refactor is fresh in Jim's mind.
Here is a question from Joseph:
This description sound right to you?
Stefano Mazzocchi:
Michael Mattson's thesis on "Object Oriented Frameworks: a survey on methodological issues" published in 1996 that on page 96, in the conclusions, reads:
An object-oriented framework is "a (generative) architecture designed for maximum reuse, represented as a collective set of abstract and concrete classes; encapsulated potential behaviour for subclassed specializations."
The major difference between an object-oriented framework and a class library is that the framework calls the application code. Normally the application code calls the class library. This inversion of control is sometimes named the Hollywood principle, "Do not call us, we call You".
Mattson's doesn't reference the source of that principle so I can't track it back any further.
Now it seems that IoC is receiving attention from the design pattern intelligentia:Martin Fowler renames it Dependency Injection, and, in my opinion, misses the point: IoC is about enforcing isolation, not about injecting dependencies. The need to inject dependencies is an effect of the need to increase isolation in order to improve reuse, it is not a primary cause of the pattern.
Moreover, I think Michael Mattson is right: IoC is not even a design pattern, but a general principle that separates an API from a framework, based on who is in control.Dependency Injection misses that entirely and misleads the reader to believe that this is just another way of composing objects. I don't blame Martin Fowler for that, I blame those who came up with IoC type 1,2,3 and missed the point entirely about hte fact that IoC is not what Avalon does (so not a design pattern), but a much more general principle that Avalon simply used.
Here is my answer:
I would say that IOC and Dependency Injection are not the same thing. Both are design patterns. Inversion of Control is the more abstract notion. Dependency injection is more specific.
They overlap a lot - hence the confusion above. I would say this - "Dependency Injection is only one pattern which makes use of the IOC pattern".
The IOC pattern simply says that objects are enabled for something else to configure/control them. This "something else" might be a framework or it might be another object - it is not necessarily a framework that is doing the configuring. In the most abstract sense a network of cooperating objects could mutually configure each other and all will be happy.
A perfect example of IOC that would *not* be dependency injection would be a piece of Java code which wanted to display a calendar widget within a GUI. The code creates a calendar widget object, then calls methods in the calendar widget instance and sets a few parameters like background color. Then the Panel widget is called (another example of IOC) and told to add the calendar widget instance to the panel in the upper left hand corner. The panel and calendar widgets are allowing themselves to be configured via IOC - but the calling code (in control) is just another piece of Java code and not particularly a "framework".
Martin Fowler's coining of the terms IOC 1,2,3 really were talking about the interaction between a framework and a component working within the framework. Perhaps a better way to title Martin's work would be "Three different ways that frameworks use the IOC pattern". Dependency Injection is best described as "What Spring Does". Spring (a framework) feeds an object (a component) configuration values and classes (implementations) for requested APIs (Interfaces) using the IOC pattern.
Another way to look at this from a Java perspective - the notion of setters is the most basic form of IOC. Martin's work took the setter pattern and suggested that the best way for a component to find its dependencies was through the setter pattern (i.e. IOC is the best way for a component to get its dependencies from a framework).
The Sakai framework component approach are based on this notion of Dependency injection. Sakai uses classic IOC throughout tools, presentation layer, etc etc.
There are places in Sakai where IOC/Dependency Injection is not practical or quite inconvienent and so different patterns are used. That is a different fun debate when IOC purists meet the real world.
Hi all, it is Saturday morning and I am sitting here with my cup of coffee so it is probably time for a status update. Hope you all had good holidays and took some time off. I had a great time learning Cocoa and Eclipse on my days off.
We have Sakai 2.2 penciled in for July 15 - we will likely need a longer QA period for 2.2 than any other previous version of Sakai because we will be integrating a number of new software from the community. We may need to do QA from May 15 through July 15.
Sakai 2.1.1 is already in the works - we should tag this soon and begin QA. Hopefully the 2.1.1 QA will be pretty straightforward. The maintenance branch code which makes up 2.1.1 is already in production at IU, so at some level the key element for community QA for 2.1.1 is to make sure we have no regressions from 2.1.
Sakai 2.1.2 is also in the works. This is scheduled for freeze for 2.1.2 in mid February and QA after that. If all goes well, Sakai 2.1.2 will be the base for OSP 2.1 and we will (finally) be at the point where the OSP and Sakai code bases are synchronized. The nice thing about 2.1.2 is that the OSP team will be doing QA on Sakai so we will have a more significant QA effort on the 2.1.2+OSP package. The hope is that folks can go to 2.1.2 Sakai and then "drop in OSP". It might not be that simple when it all works out - but that is the hope.
In terms of personnel, you have probably heard by now that Carol Dippel resigned as Sakai QA Director back in December. She will still be involved - just not as the QA lead. Carol did a great job for the Sakai project and she produced outstanding results in a challenging environment. We miss her leadership already.
We really cannot go for long without a QA Director - we are working on Carol's replacement and hope to have it all worked out and announced in time for the new director to lead the 2.1.1 QA effort.
Some big follow on work after the Austin conference is the Sakai Community Practices group. This is in the process of forming a charter. See http://bugs.sakaiproject.org/confluence/display/SCP/Charter for more details.
Another important area is the Requirements Group. There is now a really cool requirements form in JIRA. Go to http://bugs.sakaiproject.org/jira, Create New Issue, Project: Sakai Requirements, Issue Type: Requirement. The Requirements DG is going to lead a process where the community enters requirements, then prioritizes these requirements, and then we use the resulting list and try to find resources between now and May 15 to work on those requirements that the community wants the most. Of course the best way to get your favourite requirement worked on is to work on it yourself :)
I wish that the Challenger Space Shuttle never went down and created the concept of the Challenger memo. Because of the Challenger memo, our culture was forever changed. People feel that if there is some little complaint that forms in their head - they are duty-bound to blast the complaint out as loudly as possible in case it "saves the next space shuttle crew".
As a result, since the Challenger went down there have been literally billions of people who have written critical messages feeling all the while that they were saving the world. Mostly what they really want is the satisfaction that when something goes wrong - they get to point back to their memo written *before* the event happenned.
The problem with this is that events like the Challenger explosion happen very seldom and these memos get written many times per day in many organizations so the losers writing the memos are ready for the next disaster.
But these memos cause far more damage than simply wasting paper or E-Mail in boxes.
What if you were the person who was handed the Challenger memo, and then ignored it, and then the crash happenned, and then the memo writer points out that (a) they were so brilliant that they knew what was going to happen in advance of the event and (b) their idiot boss was handed the memo and ignored it.
So this creates a culture where we can't just tell the Challenger memo writer to "go back and actually work on the solution rather than just bitching about the problem". Each person handed the Challenger memo (remember that they almost never come true) must listen intently to the memo and engage in a long and useless disucssion with the memo writer that does not really get closer to the solution (remember the writer is not motivated by fixing the problem - just showing their brilliance in identifying the problem).
The purpose of the long discussion is so that when the one in a million chance hits and the problem actually happens, not only does the memo writer get credit for their brilliance, the boss of the memo writer can claim that there was a long involved discussion about the issue when it came to light and appropriate measures were taken.
Of course this does not apply to really bad things like sexual harassment or abuse or some other really bad thing - these should be brought to light and handle with care by all involved.
I am talking about the run of the mill Challenger memo which takes the form of, "If we switch from 45 pound paper to 40 pound paper, I predict dire consequences."
I once had a boss named Lew who had a phrase - "Don't bring me problems - bring me solutions." He shared this with me years before the Challenger incident.
This "bring me solutions" is the essense of how we break the endless cycle of wirting Challenger memos and then covering the exposed parts of the anatomy which result. All of this chatter drains ones energy and removes people's focus from the problem at hand and actually makes it more likely that some dire consequence will occur.
The sad thing is that the dire consequence is usually not the one the (hoping to be brilliant) Challenger memo writer predicted. Although perhaps some lucky person elsewhere wrote a challenger memo and can gain some benefit from the tragedy.
I went to Bloomington, Indiana in December and with Marlon Pierce's help, started working on the Sakai JSR-168 portlet again. A really great steak from Zagreb always gets the juices flowing - Marlon said I could not have any steak until I had an initial version done - so motivation was high.
Now four days later, I have an even better release with a bunch of usable features. I attach some PowerPoint and source for you to take a look at. Here is a set of new stuff:
- Added Gallery Portlet
- Added a tree view portlet that shows all of your sites and tools
- Moving the code into SVN (when I get a good network connection)
- Configuration flexibility
- Added proxy portlets for common Sakai tools:
Announcements (sakai.announcements)
Assignments (sakai.assignment)
Chat Room (sakai.chat)
Discussion (sakai.discussion)
Gradebook (sakai.gradebook.tool)
Email Archive (sakai.mailbox)
Membership (sakai.membership)
Message Forums (sakai.messageforums)
Preferences Tool (sakai.preferences)
Presentation (sakai.presentation)
Profile (sakai.profile)
Resources (sakai.resources)
Wiki (sakai.rwiki)
Tests & Quizzes (sakai.samigo)
Roster (sakai.site.roster)
Schedule (sakai.schedule)
Site Info (sakai.siteinfo)
Syllabus (sakai.syllabus)
This basically means that you can drop a Samigo into a JSR-168 portal after a few details have been handled.
These are some more Sakai principles that were discussed by a few other folks.
The Sakai Foundation Board directs resources that belong to the Sakai Foundation or have been given/loaned to the Sakai Foundation. With limited resources, the Foundation tends to focus on investments which build and sustain the community. The Sakai board also provides some support for community-wide design and technical activities like project management, release management and quality assurance in the best interest of the community.
Nearly all of the work of designing, developing and producing Sakai releases is done by volunteers. These volunteers may be individual contributors or may work for an organization that is involved in Sakai and is making a voluntary organizational contribution. That said, one of the Sakai Foundation's goals is to inform and guide volunteers making contributions how they might maximize the benefit of their efforts for the entire Sakai community.
Sakai's direction is driven by contributions from the community. In order for an organization to effect the direction of Sakai it is best done through contributing resources to that aspect of Sakai that the organization feels is important.
Sakai efforts are organized into a number of separate projects, roughly modeled after Apache. Each project has a set of committers who self-manage their commit list. Generally the path to becoming a committer in a project is for one to develop an understanding of that element of Sakai and begin contributing through an existing committer. Once it becomes clear that the new contributor has achieved the appropriate skill level, they can then be granted committer status. The Sakai Foundation Board delegates operational authority for appointing appropriate committers to the leadership of the technical community.
Sakai is software which must maintain 100% production capability over its entire lifetime. Maintaining the performance, quality and reliability of Sakai releases is the founding principle of Sakai software engineering.
This is a set of guiding principles that we wrote down at the first meeting of the Sakai Foundation Board. This is really a brainstorming session more than anything else - but the nicely capture some of the truths about Sakai.
They are not "adopted" - just discussed.
There’s acceptance that contribution to the code and contribution to the project will be provided in a variety of forms. That is encouraged and made as easy as possible.
The only way to positively effect the outcome of Sakai is to contribute resources to the project.
The focus of centralized activities will be to maximize the effectiveness of the community, making the large number of resources as effective as they can be.
The Sakai Foundation central staff will be light weight and push the work back on the community.
All the processes and activities in the Sakai community should strive for as much transparency and syndication of its activities as possible in recipient friendly format.
The process needs to be clear and well-known and well-publicized so that anybody in the community knows how to participate to make something happen.
To ensure the guiding principles of the foundation vision is clear to the community.
Sakai is on a trajectory and will continue to evolve in various area, with some things being more or less mature.
In my ever expanding quest for places to integrtate Sakai into, I have decided to start playing with VUE (http://vue.tccs.tufts.edu/). VUE is pretty cool - it makes context maps.
In my crazy design thoughts, I want Sakai to hand VUE maps over web services. Those maps will contain information about sites the user has access to on the Sakai Host, and pages within those sites.
This is a long term fun thing for me. Thanks to Jeff K and Anoop K for their help on this.
But I figured I would share how I got VUE to compile on my Mac in case you want to be a cool VUE developer too.
It is (yet another) Chuck C-Schell script that I wronte because I have a terrible memory!
It grabs source, does a bit of fiddling with the source, compiles, and runs VUE.
#!/bin/csh
# Chuck Severance's VUE bootstrap script - Only tested on a Mac OS/X
# To run this type
# cd ~/dev
# csh vue-bootstrap.csh
set MYPATH=`pwd`
# Download VUE source using curl if necessary
if ( -d keepzips ) then
echo keepzips directory exists...
else
echo Creating keepzips directory ...
mkdir keepzips
endif
if ( -f keepzips/VUE_1_4_0_src.zip ) then
echo keepzips/VUE_1_4_0_src.zip exists...
else
echo Downloading keepzips/VUE_1_4_0_src.zip ...
cd keepzips
curl -O http://easynews.dl.sourceforge.net/sourceforge/tuftsvue/VUE_1_4_0_src.zip
cd $MYPATH
endif
# clean up the directory and save current contents
/bin/rm -rf VUE-reallyold
if ( -d VUE ) then
mv VUE-old VUE-reallyold
echo Removing old version in the background
/bin/rm -rf VUE-reallyold &
mv VUE VUE-old
endif
mkdir VUE
mkdir VUE/lib
mkdir VUE/VUE_1_4_0_src
cd VUE/VUE_1_4_0_src
unzip $MYPATH/keepzips/VUE_1_4_0_src.zip
echo Moving jars from the checkout directory to the lib directory
mv *.jar ../lib
# comppile and run VUE
ant compile
ant
It is January 1, 2006, and sitting watching Television last night - I thought back to 2000 and thought about the fear that we all held watching the ball drop and half-expecting the sewers to back up on Times Square as midnight kicked over.
Also today I am "cleaning out my closet" and pitching some old stuff and came across a Powerpoint Presentation that I made in 1999 about Y2K - at the time, I was the CIO of the College of Engineering at Michigan State University and I got a bit of flak about this talk.
Now six years later I am going to throw away the printout of my slides as I clean my closet so I figure that before I pitch them, I would type them in in case anyone in the future decides to ever look back at this point in time. Kind of a time capsule.
Year 2000 - A view from a college
Charles Severance
Director of Computing Services
College of Engineering
Not too worried about Y2K
We have no core data processing activities
Problems
- getting the right version of Excel and Word
- Operating Systems (NT 4.0 and UNIX)
- Bad BIOS's - There is no $$ for new computers anyways
What we have done
Talked with AIS
- Helped identify areas we might have missed
- Reassured that AIS services are OK
When we encounter a patch or upgrade that fixes Y2K we apply it
What we will do
Educate our users to perform their own BIOS checks - Before Fiscal year-end
By Summer - All of our server infrastructure and public labs will be Y2K
Fall - Focus on heavy users of data software
- Know the version/pathc for Y2K
- Access, Excel, dBase, FoxPro
Concepts
Be educated about the problem
- AIS and Web Pages
We can lag behind because our problems are the same as millions of other desktops
- If they are not solved by the industry - The College of Engineering can't help
Assume that my trackball won't have broken everything in my office Jan 1, 2000
Observations
To the non-aware folks, Y2K is a soap opera
To the technology folks, fixing broken stuff is our daily activity - properly approached, Y2K is just integrated into our regular activity.
Some projects won't make it on time - what's new
The Real Disaster
When every person in the USA has $500 extra cash in their pockets and nothing happens Jan 1...
The lines at Mongolian Barbecue will be terrible....
And Best Buy will run out of 10GB disk drives - causing general panic
