Guanxi moving to Spring
With so many SAML2 profiles coming along I thought it was time I futureproofed Guanxi by moving to Spring. (more…)
With so many SAML2 profiles coming along I thought it was time I futureproofed Guanxi by moving to Spring. (more…)
I used my Guanxi PHP Guard to shibb Elgg. What I’m doing at the moment is creating a web content tool in Sakai, which is shibbed using the GSK. This means I can run Sakai as an IdP and Elgg as an SP. I had some trouble to deal with from Elgg: (more…)
Posted & filed under Guanxi.
We’re going to be piloting the use of rwiki in Sakai as well as blogs in ELGG at UHI, so I had the requirement to link Sakia and ELGG and I plumped for Shibboleth integration. So I needed a PHP Guard to sit in front of ELGG for SSO between Sakai, which acts as an IdP using my GSK and ELGG, which acts as an SP, using my PHP Guard.
The documentation is on the Guanxi wiki and the PHP code is on sourceforge.
Posted & filed under CLAN.
I originally penned this draft a while ago, just prior to the demise of Bodington as our VLE solution. Our instance was called CLAN and had a lot of groovy things in it. However, we’ve now moved on and Blackboard is our VLE solution, along with webct and the non teaching people who are still using CLAN. I thought I’d publish this draft for posterity, lest I forget how much I worked on the last release of CLAN.
There are still groovy things happening with Bodington, with Jon Maber, the creator of Bodington, about to launch an interesting new service, Campus Academicus, which will add a load of new features to Bodington. One new feature would have been very useful for our CLAN, the virtual host support that Jon is going to build into Bodington. So instead of the root level being a set of buildings, it will be a set of virtual sites. e.g. it could have been perth.clan.uhi.ac.uk, moray.clan.uhi.ac.uk. But the powers that be have binned CLAN.
So what follows is a blast from the past. Farewell CLAN and I hope Jon has every success with the next iteration of Bodington.
So we’ve got a CLAN release coming up, which is our version of the Bodington VLE and I’ve been working night and day to get it ready. A few improved features that I’ve coded are:
So CLAN has 3 databases to worry about:
plus a whole screed of Guanxi, mvnForum, Bodington, Minerva and Sucker config files.
The original intent was make Minerva an Enterprise Group Service, dishing out Domain objects and each application would provide connectors that knew how to map the UHI Domain model to their local models. However, this is academia remember, so the whole lot ended in a huge hackfest to get it out the door in record time and now it’s a complete mess. What’s happened is CLAN has become the “enterprise”. Rather than query an enterprise group service, it JDBCs in to the database directly and sucks out and spews in what it needs.
The version of an enterprise system we have at present is clearly not sustainable. Applications cannot query database tables directly. I’ve already had to add a crappy hack table to cover module non-enrollments and that table space will grow. So the only way forward for the eFramework is to move to an enterprise group service.
What’s happened is a shared database type of enterprise integration pattern has occurred, organically. It wasn’t planned. It just happened. It was hacked into existence by the political requirements at that time. Minerva was built to mirror our SITS SRS as an authoritative source of user information that could be updated with information from other applications in the enterprise but what’s actually happened is CLAN has walked all over its database and is now claiming ownership. The two-way comms between CLAN and Minerva is polluting the enterprise data space and as other applications rely on it, such as our Wildfire chat server, that pollution will slowly spread throughout the enterprise.
But now that the release is ready, I can concentrate on the Enterprise Group Service. I’ve already done the Domain model so next is the set of ORM mappings, which should be fun. Wrap it all in Axis2 and off we go. In the meantime, CLAN can continue to use it’s direct route in to the SRS data, and I’ll slowly migrate it to the group service in due course.
But with this release, CLAN has moved up a notch or two on the integration-ometer.
Posted & filed under Software Engineering.
I’ve been reading about the three levels of learning and understanding, not just in the context of agile software development but how they also apply to other aspects of human development, such as Shu Ha Ri of Aikido. Reading about the different levels, I can relate to this quite well, especially when I started working in the XMPP domain, which I’d never been near before. I thought I’d try out my understanding of the text by attempting to explain the three levels, as suggested by the book.
Level 1
is the the most basic. You’re starting from a clean sheet and you have no idea how the domain works. You are in need of instruction, which, in open source systems, is all too often lacking or patchy at best. At lot of open source systems are aimed at Level 2 practitioners, of whom we’ll get to in a minute. How many times have you moved into a new application domain, for example, Sakai and wondered how on earth does all this work. The Sakai documentation is well spread out and a lot of it is hard to decipher and the newer parts are not documented at all. Sakai expects you to be familiar with other domains, which have nothing to do with “Sakai the approach to learning” such as dependency injection and other Spring Framework ideas. At this level, all you want is a concrete example of how to do something, e.g. how to write and deploy a tool. And here you come up against another problem for Level 1 people. The fact that a lot of tutorials are written for the wrong audience. They’re mostly written for Level 2 people. People who have mastered the basics and are ready to branch out, to learn different ways of doing the same thing. My Sakai tool Really Simple Tutorial is an example of a tutorial intended for a Level 1 audience. It states that, if you follow these steps, it will work. At Level 1 you don’t know why it works. You just know that if you follow the instructions, it will work. Everything is longhand in Level 1 communication. There are no shortcuts of shared experience. Everything is raw and unpackaged. No patterns emerge and if you are confronted with another way of doing the same thing, you get confused and disillusioned. Which one do you use? Why is that guy using that way? Is the way I have learned wrong? Is it out of date? Should I learn the other guy’s way? To dispel these fears and start to understand the new domain, we have to move to Level 2.
Level 2
is where we can comfortably work with multiple ways of doing the same thing. Our circle of technical contacts widens and our experience builds over many project iterations. We pick up new ways of working within the domain and we save state in our professional lives, marking them with concepts along the way. Concepts that encapsulate the rote and tedium of Level 1 learning. We communicate in shorthand. We use UML to express our ideas. We refer to well known concepts and paradigms but at the same time, we’re conscious of using a particular development process to achieve our project goals. We know we are “doing XP”. We know that what we are doing is called “pair programming”. We’ve taken all the Level 1 learning that we’ve done, packaged up individual methods into wider concepts, tagged them with well understood names and now use them as communication shortcuts. We’re still working in the new domain but we’re aware of what we are doing. If you asked someone at Level 2 what they were doing, you’d get an answer along the lines of “we’re upgrading the existing chat system of the Sakai VLE, using pair programming, TDD and XP”. Level 2 practitioners have new concepts and terms to throw around. They sound good to talk about and they give confidence that we are getting better at what we do.
Level 3
is the “nirvana” of software engineering. Level 3 practitioners understand their domain so well, they can, when asked, give a pretty good estimate of whether what is being proposed will work. Why it will work and why it might not. They don’t have heuristics on the wall to guide them in this. They just “know”. They know from past experience of multiple domains. Experience of communicating with existing Level 2 people. They not only know how the domain works, they know how their political environment works too. At this level, no-one mentions XP or TDD. They just do it. If a software project management researcher came and sat next to a Level 3 person, they would identify the core concepts of TDD, XP etc that they are doing but ask the Level 3 bod why they do it, they would just reply “because it works”. This is what the Level 1 person says too. “Because it works” but at Level 1, it only works because they’ve been told it works. At level 3, it works because they’ve tried it for years and it works all the time, with modifications here and there, depending on the political and technical climate prevalent during that project.
Posted & filed under CLAN.
I originally penned this draft mid January 2007, just prior to the demise of Bodington as our VLE solution. Our instance was called CLAN and had a lot of groovy things in it. However, we’ve now moved on and Blackboard is our VLE solution, along with webct and the non teaching people who are still using CLAN. I thought I’d publish this draft for posterity, lest I forget how much I worked on the last release of CLAN.
There are still groovy things happening with Bodington, with Jon Maber, the creator of Bodington, about to launch an interesting new service, Campus Academicus, which will add a load of new features to Bodington. One new feature would have been very useful for our CLAN, the virtual host support that Jon is going to build into Bodington. So instead of the root level being a set of buildings, it will be a set of virtual sites. e.g. it could have been perth.clan.uhi.ac.uk, moray.clan.uhi.ac.uk. But the powers that be have binned CLAN.
So what follows is a blast from the past. Farewell CLAN and I hope Jon has every success with the next iteration of Bodington.
So we’ve got a CLAN release coming up, which is our version of the Bodington VLE and I’ve been working night and day to get it ready. A few improved features that I’ve coded are:
So CLAN has 3 databases to worry about:
plus a whole screed of Guanxi, mvnForum, Bodington, Minerva and Sucker config files.
The original intent was make Minerva an Enterprise Group Service, dishing out Domain objects and each application would provide connectors that knew how to map the UHI Domain model to their local models. However, this is academia remember, so the whole lot ended in a huge hackfest to get it out the door in record time and now it’s a complete mess. What’s happened is CLAN has become the “enterprise”. Rather than query an enterprise group service, it JDBCs in to the database directly and sucks out and spews in what it needs.
The version of an enterprise system we have at present is clearly not sustainable. Applications cannot query database tables directly. I’ve already had to add a crappy hack table to cover module non-enrollments and that table space will grow. So the only way forward for the eFramework is to move to an enterprise group service.
What’s happened is a shared database type of enterprise integration pattern has occurred, organically. It wasn’t planned. It just happened. It was hacked into existence by the political requirements at that time. Minerva was built to mirror our SITS SRS as an authoritative source of user information that could be updated with information from other applications in the enterprise but what’s actually happened is CLAN has walked all over its database and is now claiming ownership. The two-way comms between CLAN and Minerva is polluting the enterprise data space and as other applications rely on it, such as our Wildfire chat server, that pollution will slowly spread throughout the enterprise.
But now that the release is ready, I can concentrate on the Enterprise Group Service. I’ve already done the Domain model so next is the set of ORM mappings, which should be fun. Wrap it all in Axis2 and off we go. In the meantime, CLAN can continue to use it’s direct route in to the SRS data, and I’ll slowly migrate it to the group service in due course.
But with this release, CLAN has moved up a notch or two on the integration-ometer.