Interest Remote Pair Programming

Lately I have been thinking of collaborating in real time online.

The reason for this is because one of the best ways to get better on your own terms is to work with another interesting coder. However, this is something I have yet to try, as there may be challenges and work-arounds that I do not know of yet, such as availability of developers and the level of skill required to write software.

There are many different editors that allow you to start using to code, run shell commands, and interact with other developers remotely, each with different strengths. So I will gather some insights into them and decide which one I should start with.

July 2015: Haven’t written in a while

There’s not much to write about what I learned – strictly dev-wise.

Between May and July, I’ve mostly been reading up some things in Ruby and Rspec testing. However, I have not been practising the skills as much, as my responsibilities have been including my day job and other lifestyle/personal aspirations. When I do come back and practise more coding work, I will have more insights to show here.

As for my personal projects, I will most likely keep them in the repository, but won’t be working on them for a while.

Lambda, Truthyness

I’ve been working through some Koans in both Ruby and Javascript, there are a few new concepts and ideas that intrigue me. I’m not going to go in depth in all of the ideas here, as I have been really busy lately.

Working with Ruby lambdas is a neat way to write functions because sometimes it precludes you from having to declare functions by name. In other words, they are anonymous functions. I hope to work with them more in depth one day.

Truthyness in Javascript means that some values are simply evaluated to true. For example, if you write an expression “1” in a while condition or an if condition, that would automatically mean true. If 0, it means false.

Koans for Javascript!

I know that from last week, I have mentioned that I will pay a bit of attention to Javascript and JS frameworks, but I found that, there needs to be an efficient, closed-loop feedback system for me to learn better.

So during the week, I’ve been sifting through books and tutorials and other online resources for learning JS better. Yes, I have had experience working through the Javascript course on Codecademy, but there are other resources that would teach me more techniques and tools to build my skill set. As for books, while they’re great, they require much time to read through before knowing how to learn efficiently and effectively. Slogging through hundreds of pages isn’t going to make you a better developer.

Fortunately, I have found these tools, the Javascript Koans. There are two of them. The first one is by Liam McLennan, which I would think is a great place to start, and the second focuses on functional Javascript coding, by David Laing. Having been familiar with Ruby Koans, I learned that learning a language through unit tests and feedback is a great way to discover its nuances. It gives a closed-feedback system that would help me gain skills and confidence in the language. As a fan of the notion of deliberate practice, I look forward to see how my Javascript skills grow through the Koans.

Will tackle the first Koan next week!

Made a thorough test coverage for one of my hobby apps

I have worked through a few unit test cases on my application, usually around the model and controller of the same resource.

These tests, because they are small, are usually not very complicated to build. Turns out that if you follow some of the conventions of doing test-driven development, it shouldn’t be very difficult to create some.

The one test, however, that left me scratching my head for weeks was how you update an ActiveRecord once you validate it. Here is a controller action for that resource:

def update
if @blah.valid?
@blah.update_attribute(:attr, @course.calculate_attr)

And here’s the corresponding test for that controller action:

test "should update blah" do
sign_in users(:one)
patch :update, id: @blah, blah: {attr: 8, attr2: 16, attr3: 28}
assert_response :success

Most scaffolds, when you generate one, give you an automatic test suite. For the update test, instead of assert_response, you get a redirect assertion, which fails in this case.

I learned that the reason it fails has something to do with validating the ActiveRecord in the first place. Turns out that this process was a bit more complicated and tricky than I thought. In updating the ActiveRecord, I had written a model method to calculate the value for an attribute in question, which is then updated through the update_attribute(). For the test, trying to patch an ActiveRecord this way would lead to a status code of 200 – which simply means that the request to patch is successful. So instead of testing for redirect, I verified that the ActiveRecord is properly updated.

I will probably take a break from testing after this point and focus on some Javascript and front-end frameworks. I have been familiar with Javascript already, but there may be intricate details about the language that I might need to know to work with the frontend well enough to enhance my development skills.

Became a bit familiar with Spec/DSL based testing

I recently followed a tutorial on minitest testing on Rails.

Personally I like how the red-green process is followed through, and I think I understand the process.  Generally, you start with a test on a feature which you test, and then figure out whether a route or controller action or data model is needed to make the tests pass. Sometimes, I might need to write a new test before all tests passed, just to clarify what needs to be built correctly.

I have also found that when building software this way, usually there may be multiple errors because they tend to spit out what is missing before filling it in and collapsing them into failures. For example, if I am to write specs that test for attributes in a model, and the model doesn’t exist, then there are errors that say the model doesn’t exist. But if I generate a migration on one, running the test again will result in failure, leading you to know what exactly you need to resolve.

The DSL/Spec-based writing is something I’m not too familiar with, but I could see how expressive it is to writing tests, and I appreciate how intuitive it felt while using minitest (and some capybara) to guide software development. If I am to continue this route, I might get really used to it, and I’ll look forward to it.

Early stages of taking minitest seriously: thoughts.

Throughout the last 6 months, I have been avoiding test-driven development.

Not because I dismiss testing in general; in fact, I care about the building well-maintained software projects, but because I’ve generally been intimidated by the frameworks and the syntax/semantics of building tests. Whether it’s following tutorials, or building projects, usually you have a tendency to just want to hack something right away and show to other people. After all, that’s part of software development right?

It wasn’t until recently when I decided two weeks ago that I was going to start taking this seriously. When I was following the Hartl tutorial, I have already learned how important testing was, but never truly internalized it and decided that I was going to put it off until I’m ready. The amount of coding that  I learned while building my personal projects was tremendous, and after figuring out how to implement certain features and understanding web development in general, I decided that I am going to start taking testing seriously.

This might seem backwards: normally, quality-software projects are built in a red-green-refactor fashion (if you are an experienced developer, I’m sure you know this is the norm in best industry practices). But in my case, it was mostly hacking, then refactor, then red-green testing. What’s interesting about this approach in learning is that by testing with existing code, I get to see what is proven to work and what is not proven not to work. If an ActiveRecord object turns out not to be valid in a test case that I assumed, then I know that this is a bug to fix.

Testing, in both my experiences of following the tutorial and mostly in my head, can be intimidating when you don’t know what to test in the first place. Starting a project might make you think about what to build, but also you don’t know how to test it. I suppose that, by having some experience with hacking, testing the features and use cases of an app might teach you something about quality code.