So, just 5 more days left until the release date of my newest project.
For those of you that’s followed my blog during the last year, you have
seen that I’ve been working on the new Internet site for my fraternity.
I don’t even want to reflect on the amount of hours that I’ve spent on
this project, nor do I want to count the lines of code that I’ve
written. The part I want to reflect upon though, is all the improvements
we’ve done in the the architecture comparing to the architecture of the
existing application. Besides this I’ll give you a brief introduction to
the new features of NAUT.
One of the greatest challenges when designing a solution for the
fraternity is the immediate loss of know-how that a group like this will
experience. Seeing how people with core competence will leave the group
within the next year, the architecture must be easy to understand, and
still maintain it’s flexibility, so one can continue to develop it
without being locked down due to design decisions. This is, from my
point of view, one of the major flaws in the current solution.
Brilliant as their solution is, there is just one or two guys that understands how
it work in our group of people. That fact haven’t kept other
folks from writing buggy code on top of it, ruining it, and thus made
it much harder for new people to write code on top of that. Do this for
a couple of generations, and you can easily see where it ends.
This brings us to NAUT. Learning from the previous experiences, NAUT is
your textbook example on using layers in your application. Having used
the Spring framework, we’ve forced a strict policy of dividing the
functionality into their respective layers. Doing this, a virgin
coder on NAUT can extend the code base by using the already written
interfaces to provide new functionality. Earlier today we had a guy
port his old application to NAUT without touching a single line of
db code, nor Hibernates own HQL. All he needed to do was to use the
Event-Manager we provided. This is shows the true power of a well
designed architecture.
Features:
One of the major features the regular user will see is the event system.
The backend is mostly written by �mund Eldhuset, while I’ve done a lot
of work on the front end. The event system is the system that handles
admissions to different events like parties, lectures and presentations
of companies. The two major differences here from the old system is the
new queue system. This completely removes the need for refreshing your
browser to get in. When you sign up for an event you’ll be placed in a
queue and you’ll get in if there’s room for you, either by somebody
giving up their seat or the administrators raising the number of
allotted people. Another new feature is that one now can allow different
registration time for people based on their group belongings instead of
their class. This means that one can give first-graders the right to
start registering two hours before the rest, but a given committee, e.g
Webkom the right to register two hours before that.
Besides this we’ve also done a complete redesign of the news system
where one no longer need to ponder around with the layout manager. The
system itself chooses which news to put on the front page based on the
weight of the article during that period, and the publish date of that
news. We’ve also done a great deal of code on the part not shown to the
end users, whereas the authentication mechanisms like group belongings
and roles are to be mentioned. Much of this system is to be credited to
Idar Borlaug and his ACGI skills.
I’ll get back to you on the new URL when we’ve reached our release date.
I can’t wait until it gets into production.
*me gets back to writing our release presentation in bash, *Webkom
style*
