So it’s been a busy few months since the last blog about Code Club when I promised to go into more detail about the next steps.
As a developer, it’s often less important what the code is actually trying to achieve compared with how it achieves it. From the very start it was agreed that we’d focus our efforts on something that could benefit the company as a whole.
One thing that came to the forefront was resourcing. Varying project lengths, unexpected issues, unanticipated slippages, extended review phases and many other factors contribute to making planning a critical and time intensive task. After some deliberation, we agreed that the project we could make the most impact with was creating a production planner tool to enhance and extend the current resourcing model.
With that in mind, we divided ourselves into several smaller groups to investigate the various aspects of the project. These activities have been divided into four groups: documentation, API investigation and prototyping, knowledge shares and development.
Documentation
High level requirements – this was initially produced in Code Club, followed by meetings with various levels of production to expand and rationalise the requirements.
Technical requirements – this was again done by the members of Code Club, with input from the Systems department. (Complete)
Wireframes – from the initial sketch designs to the current state, this has been a very useful exercise. While not complete, the current set represents a solid foundation for develop to start.
User stories – in order to sense check the UI design and prevent scope creep mid-development, the entire Code Club has been pitching in to get these done. Again, the full range isn’t complete; however a solid set pertaining to core functionality has already proved invaluable.
API investigation and prototyping
Replicon timesheet API – one of the early areas tagged for further investigation was the timesheet system used at Epic. We’ve been looking into both reading from and writing to the timesheet system in a variety of ways.
LDAP Web services – given one of the objectives for the planner was to reduce administrative overheads, we wanted to hook into the company’s existing directory listings. We were also looking into single sign-on; however that sadly proved unviable.
Codeigniter vs. Laravel – as two of the plethora of PHP frameworks, these were shortlisted for adoption in the project. Each of them was taken by a member of Code Club and researched, with Laravel coming out in first place.
jQuery + jQuery UI – we decided to focus our initial client-side framework investigations on jQuery and jQuery UI. As such a variety of test beds were created and evaluated, several are now serving as templates for implementation.
Templating engines – A common feature of any modern web app is some form of HTML templating. We looked at a spread of different templating systems such as Moustache, Handlebars and Underscore. Eventually we decided on our own in-house system for a variety of reasons including:
- Familiarity – our system has provided a good training opportunity to those who weren’t familiar with our in-house code bases
- Speed – it’s an exceptionally quick templating method compared to some approaches. This is mainly down to its reliance on string manipulation, which brings the added bonus of regular expressions (for when a nut *really* needs cracking)
- Markup/ code light – it’s ultimately a stylistic and environmental choice, but for Epic a templating engine doesn’t need or want excessive amounts of inherent functionality. Such approaches are useful where less technical people are producing the templates, but where you have some very talented developers, the logic is best kept inside the programming language itself.
Knowledge share presentations
Javascript OO primer “Everything’s an Object” – a presentation covering Object Orientation basics within Javascript. It turned out to be a surprisingly popular session, so much so that it was run twice; once for the members of Code Club and once for interested staff from the rest of Epic.
Laravel PHP framework primer – after Laravel was adopted as a framework, Kasparas created a presentation outlining the basics. He also wrote a basic ‘to-do’ app and got a rousing round of applause to boot!
SASS vs LESS – as we’ve been getting to the point of actual production, we decided to look into deploying (initially) LESS to aid the CSS development. However, developer Joby had had a lot of good experiences with SASS and put that forward as an alternative in the form of an awesome presentation on the abilities and virtues of SASS!
Development
With all the other things that have been going on, I sometimes find myself forgetting that we’ve actually been putting together a fairly solid baseline for the actual planner itself. Some of the highlights include:
Push notifications via websockets – as nobody had had the opportunity play with websockets previously, the first order of the day was to put a test bed together as proof of concept and to understand the underlying technology. We’re now in the final stages of implementing that via Laravel and Ratchet, which I’m really looking forward to seeing.
Framework prototyping – it’s always interesting getting to grips with a new framework, especially when several don’t actually write the language involved as their mainstay and the need to familiarise yourselves is obvious!
HTML Framework – as we’re creating a web app, getting the structure of the HTML right is key. What to create as a skeleton, what to template and how to integrate the 3rd party APIs have been the focus of this development strand, which has progressed nicely to a semi-functional (if a little quirky!) prototype with some lovely colours chosen by yours truly…
If you’re interested in joining the Epic team, head over to our Careers page to find out about current opportunities in our development teams.