At first make it work, then make it usable, and lastly make it pretty. I find that getting starting on a project is more successful if you break it down into parts and pieces. I currently just do this in my head, but I’d like to work towards putting it down on paper as pseudo code to enhance collaboration. For KpiTrackr I decided that I want to be able to allow users to create company meetings with a meeting overview, post-meeting takeaways, and for meetings to have many comments. So first thing is first, we need to create a place to store our information so I added two tables to my database, one for meetings and another for comments. Next, I created the models, relations between the two tables, and the serializers for each model. After the serializers were created, I implemented the routes and controllers paying special attention to the rendering of the controller actions I would need to use in order to build out my API endpoints. I created some basic placeholder views with the standard Rails way, but instead of rendering html I found it helpful to ensure everything was working by rendering JSON for the create, show, and index actions first and foremost. After all if we’re going to be consuming our own API we’ll need to ensure that it’s returning the expected data before trying to render something more complex.
For previous projects I spent time meticulously building out unique user experiences but since I’d be using jquery to interact with the DOM to render views via ajax requested data I found it helpful to simply use html tables to display a lot of information all at once. I’m using Materialize, a front-end visual framework much like bootstrap, and I wasn’t entirely certain if jquery-rails gem would have issues with Materialize’s javascript so starting with a minimal interface made the most sense. A lot of potential issues in this capacity are smoothed over with React and React specific front-end npm packages like MaterialUi or ReactBootstrap that make more sense for creating a more flexible js frontend. I believe it to be particularly important to keep things simple as possible when creating an ajax/jquery front-end because it can be more tedious to debug.
Similarly, I decided against using turbolinks in this project because I had experienced numerous issues with it interfering with Materialize’s javascript enabled features in previous projects. There’s still a bit of a debate around turbolinks because if a project moves to React, then turbolinks will ultimately be overlapping react-router. As a fullstack developer it’s your job to learn and try out the latest technology but it’s also your job to make the judgement calls on whether or not it’s necessary for your particular project. It’s far too easy for new developers to tunnel vision into a project using all the latest tech just because they can. However, just because you can doesn’t mean you should and this is where learning valuable project management skills can really come in hand for effectively scoping the task at hand. Success of a project should not be measured on the technology used or lines of code written but rather the amount of time/effort to completion and collaborative longevity of the code if, and only if, it’s likely to be reused or abstracted in the future. All developers should be constantly asking themselves if the stack and project architecture decisions they’re making are immediately, or in the near future, adding real, tangible, value to the company they’re working for.
Other than frustrating mismatched JavaScript parenthesis causing strange bugs, I rather enjoyed creating this project because I have an unexplained preference for ‘getting’ and ‘posting’ json data.
