What will Google do Next?

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

How to install the Sakai Maven Plugin

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$

Having more fun

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

Note To Self

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)

Hee hee – Added Lance’s new feature to Charon

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.

Continue reading →

Rutgers Modifications

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.

Continue reading →

Is IOC and Dependency Injection the Same Thing?

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:

Continue reading →

Sakai Status Update

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 :)