Going into fourth year and setting my own brief was a fairly daunting experience. My early concepts were mostly focused around the community and skill sharing. There were quite a few factors which influenced me to finally settle on the concept that would become Codelight. I was introduced to html and php at a relatively young age and would happily spend hours combing through open source applications and trying to build someone functional form the scraps. But many people I speak to view coding as some kind of arcane process which is completely removed from reality, often because they’ve just not had the opportunity or motivation to experience it or don’t know where to look for useful resources. I wanted to create a place where people could interact in real-time whilst tinkering with what one another had written. Noble intentions aside, I have to admit that the technical challenge in building such a complex, real-time application from the ground up was a major contributing factor in my decision.
During development this year I was able to build on some of the principles I employed during our previous designing social networks module which I picked up from developing themes and plugins for wordpress. After putting together an early ‘proof of concept’ prototype, I made a point of forcing myself to overcome the ‘whatever works’ mindset of just throwing things together as they are needed that often comes with the excitement of a new project and create a structured foundation. Although I wish I’d had this reformation earlier in the year and saved myself a lot of heavy refactoring throughout the process, being able to see such a sharp contrast between poor, thrown-together code and a well thought-out, structured application really drove home how much it can speed up development and make implementing new features less painful.
At the start of the year, I considered myself reasonably competent with front-end javascript and was expecting Node to be abstracted or augmented to the point that it would be almost like a completely different thing to the javascript I was familiar with. But after having a slight struggle wrapping my head around Node modules and seeing that they both functioned identically, I began to realize that there were entire dimensions to javascript that I knew nothing about. This realization only deepened once I started using Angular.
Angular uses the same Model-View-Controller pattern that I had aimed to build my application around and was invaluable to developing my understanding of how to implement it. However, I adopted Angular at a relatively late point in the project which limited the extent to which I could put this knowledge into practise in the back end of Codelight. Similar to my late adoption of the MVC for the server, delaying the introduction of Angular resulted in the need for some heavy refactoring due to the fact that Angular’s ‘Model’ requires that Javascript have access to data such as items in a gallery or comments on a page in order to manipulate them and I had focused on serving data inside of the markup where possible to enable indexing by search engines. If I were to start the project from scratch or begin another also using Angular, I’d make sure to have a more exposed API to allow Angular to gather the data in much the same format as it is available to Jade to enable the two to complement one another rather than having angular ‘bolted on’ over the rest of the application.
Despite having problems I’d encountered bringing in technologies and architectural patterns late in development, I feel like this was the best way for me personally to learn the technologies and improve. Beyond the fact that the software I used in Codelight was built on Javascript, HTML and CSS, I had never used any of them previously except for one or two small experiments with Node and each came with a distinct learning curve. Angular in particular, which uses two-way data binding to automatically sync HTML elements and their values with variables in javascript to avoid manipulating the DOM directly took a lot of trial and error to get to grips with.
Designing the interface was an interesting experience. Graphical design and creating beautiful colour palettes is something that i’ve never had a strong affinity for. So rather than attempting to create an ‘artistically’ beautiful interface, I decided to focus on the more technical elements of the graphical interface and their interactions. During early development, I considered using a framework such as bootstrap to handle some of the heavy lifting for the interface. Eventually I decided against these, partially because such comprehensive frameworks will inevitably have performance overheads which, although small, I couldn’t justify given how many of the elements I’d expected to use. But also because I felt using pre-packaged UI elements would detract from the identity of the application. I spent some time playing with margins and padding, ensuring elements were aligned, fitted together well and didn’t become too cluttered.
Overall, I feel my project was a success. Despite the fact that I pushed myself quite far out of my comfort zone by using the MEAN (MongoDB, Express, Angular, Node) and caused myself a lot of setbacks. During my early planning of the project, I had envisioned a much more broad range of functionality which it would have potentially been possibly to implement if I had focused on simply firing out features. However, I feel like by focusing on a small set of core features, implementing them with best practises and testing them thoroughly with users I’ve improved my skills across the board much more than if I had attempted to poorly build the application to the scale I’d first envisioned. I’ve gained a much greater idea of the development time required for more complex applications which I’m glad I have before entering the professional world.