Mired by a litany of confusion and growing pains our group managed to come out on top. Actually, that is a boldfaced lie; our group disbanded but I assure you these two things have little to do with each other! All joking aside, our plan at the outset was to learn about utilizing the information access management software known as Keycloak. As it was our first sprint working with completely unfamiliar technologies, the sensible thing seemed to be to read the darn manual and document our findings. While this worked for reinforcing our individual assigned topic from the official documentation, I have to wonder if it really helped us deliver a tangible product or just slowed us down. To elaborate, it seems as though we read a lot about the technical aspects of Keycloak but at the end of the day there was little to analyze and report other than that the documentation seemed to be thorough. In hindsight, I believe the better approach would have been to work together as a group and walk through the configuration process, documenting the whole thing. Moreover, we should have raised questions about the size and scope of user volume and based on those factors decided on a configuration (cluster versus standalone comes to mind) to attempt. While configuring Keycloak and WildFly on our local machines certainly gave us insight, we would have discovered that learning about WildFly and its subsequent installation may have been completely pointless depending on which configuration we decide on going forward.
Given our approach I found that the best work was done when we were collaborating together. I touched on this concept earlier when I was describing how – with the benefit of hindsight – our group ought to have approached the assignment, but synchronous communication and action taken towards configuration yielded drastically better results. It was during these sessions where the team was able to best overcome technical hurdles (such as versions of Docker mismatching) or discover some steps might be superfluous (such as installing and configuring WildFly when not using a local instance of Keycloak). It pains me to say it but it seems as though, of the work we got done, a very small portion of it ended up being useful and that our approach seemed to be driven more by how we could fit our work into the agile framework and not how the agile framework could best help us implement our work. This isn’t to say the framework is of no value or inherently a hindrance, nor is it an indictment of any particular person, but it seems as though our group was not able to mesh well with the framework to get results.
Individual improvements can mostly be derived from the same tired critiques in the vein of rugged individualism whereby things such as losing power, health problems, email harassment must not dampen one’s spirit and certainly, above all else, not their work ethic. Perhaps if I had instead made a measured effort to calculate how many hours of autodidacticism I could throw out so that I may stay in the low C range (as opposed to the upper range) of a non-major class, I may have been able to find more time to commit to exploring Keycloak. Is it unprofessional for a student like me to complain on an assignment for my personal blog? Perhaps. I would argue it’s at least as unprofessional for a teacher to underperform in their profession and that students should have to internalize that as an individual failing.
Links to work done on our team’s wiki:
This wiki entry is the reference page I accidentally wrote on the Authorization Services.
This wiki entry is the reference page I created for WildFly.
From the blog CS@Worcester – Cameron Boyle's Computer Science Blog by cboylecsblog and used with permission of the author. All other rights reserved by the author.