This project is part of my Learn.co curriculum, yes, but it is one that I’ve actually been interested in doing for a while.  I discovered the wonderful land of Codility last year when I tried out (and sadly failed) for Toptal.  I know I shouldn’t feel bad because (according to them) I’m just not in the top 3% of developers.  I can get over that.  What I can’t get over is how excited I am to be moving into this realm of remote/distributed software development.

Codility – Language Agnostic Software Skills Assessment

It really is an incredibly difficult puzzle to solve: how do you assess someone’s software skill level?  Should there be a time limit?  Should there be a quiz about some obscure functionality that the test’s authors like or utilize?  Should it be totally open-ended: “tell me everything you know about software?”  Should there be a language-specific problem that the candidate needs to know about, or that shows some level of intimacy with a given language?  I think those are all legitimate questions, and the answers will vary between companies.  Codility gives a company the chance to have a “first line of defense” against being overwhelmed with candidates.  Codility’s business model makes them a neutral third-party to the candidate’s assessment and is funded by companies that pay them to proctor tests to candidates, and is totally free for programmers to practice and learn.

They do this by offering language-agnostic lessons and tests aimed at testing a candidates abilities to take an abstract problem description and turn it into a usable program.  Their problem descriptions have been, in my experience, some of the best out there.  Very specific, and difficulty-level appropriate, as well as marked accordingly with ‘painless’, ‘respectable’, or ‘ambitious’.

Open Source

You don’t really realize how amazing it is until you start to think about it.  Only 20 years ago this idea didn’t even exist for even the most well-funded and immutable companies on the planet.  Now anyone with internet access can write programs and share them with the world.  People who have common interests can come together and make something amazing and share it with the world.  This is a huge step in helping the world be a better place, and Ruby is part of that world in a big way.

Nitty Gritty

You can read the source code to the gem if you want.  Hence it’s, “open source”.  But the TL;DR of it is this: it pulls text from specific portions of codility.com and displays them in the terminal window.

 

So I needed 3 classes: Lessons, Tasks, and Difficulties.  This way you could link them together in such a way that made sense without having to have a gazillion lines of code in one file.  This also makes it easier to extend the program later, or re-use parts of it.

Lessons Learned

So I think the most frustrated I got was the 2-hour window when some portion of my code magically didn’t get saved correctly.  I put in some changes, saved the file, and then re-ran it, but the changes were obviously not there in what was running.  So I spent *way* too much time

Draw as many diagrams as you can before you write a single line of code.  Picture as much of it in your head as you can to try and find out things that you’ll eventually wish you had started out knowing.

Keep a running list of “future plans” and if at any point what you *actually* plan on doing becomes too hard to re-factor for, take a break.  Take a long break.  Use it to decide which is more important, saving the work you’ve put in going down the current path, or saving yourself trouble by factoring for the future plans now, but have to throw away some code in the process.

The ‘interface’ part of a ‘command line interface’ is incredibly annoying.  If users will be ‘navigating’ data through your interface, you’r pretty much better off figuring out how to wedge your data into somebody else’s interface.  Plus there’s really no point in re-inventing the wheel.  There are tons of good interfaces out there, and if inventing new interfaces is your thing, rock on.  But for most ‘command line interface’ tools, the ‘interface’ part of it is pretty weighty.  Aliases, searching, help, loading, nesting, displaying; each piece of it adds new complexity to your code that really shouldn’t distract you from what you’re really trying to do.  If I had this to do over again, I would probably have all of the information scraped into files and directories instead of objects and variables.  That would solve SO many of the interface issues and open up a world of possibilities for the user.

Future Expansions

The first thing I saw happening was the snowballing of HTTP requests that had to go out.  As soon as I knew I was sending around 100 HTTP requests, I knew Asynchronous requests would bring an order of magnitude speed increase.  But that’s for later in our coursework, so I’m excited for that.

As already mentioned above, I can definitely see value in having these saved as text files.  My original decision to keep them as object variables was because I thought a student-level gem that downloads a fair amount of material, just for the sake of seeing it, is probably not the best idea.  But I think this, my future self, would encourage my past self to go for it.

Arguments.  As already mentioned, the ‘interface’ part of this is, in my mind, so much more annoying than parsing an HTML response.  That’s the interesting part, and I only spent maybe 10% of this project’s time on it.  The rest is on creating classes, instantiation, blah, blah, blah…  A much more rich interface would be one that could accept “open task 5” instead of just “open task” and then prompt the user for information that could have just as easily been passed in already.  Again, a better interface, but not the point of this project.  Requesting and parsing the HTML was, and I’ve done a smashing job at that if I may say so.

The ‘task’ object I created just stores a text value for the ‘level’ property for the ‘difficulty’.  A more truly Object Oriented solution would have stored an actual Difficulty object there.  I can do that, and I see the benefit of that if this were a business or money-making software, but not for a tiny project.

Test-Driven-Development is much better when you’ve written 2 lines of ruby test code.

Listing lessons and tasks would probably look better in columns.  But columns are hard.  And annoying.

There was a small amount of code that could have been pulled out into a separate module.  Again, pet project, pet-level complexity.

Summary

All-in-all, I’d say it’s a winner!  Check it out!

 

Advertisements