Ruby is weird, feat. Starring into the void and few practices of the dark side of the Force

„It takes strength to resist the dark side. Only the weak embrace it!
It is more powerful than you know…“
―Obi-Wan Kenobi and Darth Maul [read more]

Void value expression – have you ever get this error? We had, and that’s how we discovered the void in Ruby. It happened yesterday, while we were working on the class creating test methods in our Ataru tool. The existence of void in Ruby surprised few of our coaches & friends.

Dirk and Lucas was very suprised about the dark side of the force

Dirk and Lucas was very suprised about the dark side of the force

We stayed cool this time, not knowing that it was a kind of discovery…

In the first attempt to write the above mentioned class, we used the define_method in the body of another method, which made us to use send method as well, as define_method is private. Send and define_method are useful, but they can also cause problems, if you don’t use them carefully.
Besides of the define_method, we are also using eval in our class. That is also potentially dangerous. Therefore it felt a bit like touching the dark side of the Force.

What is more, it caused our test methods to pass or to fail, depending on which test method was run as the first one. Today we worked hard to fix those issues. Supported by Jedi master coach Kacper we wrote a new method that is even more amazing than the old one. It solves the problem by creating a new class every time the method is called. It also wraps our code samples into a MiniTest test method.

You can check out our repo for the code:

https://github.com/CodePadawans/ataru/blob/code_ex/lib/ataru/code_samples.rb

you can see the results of running tests here:

Testing Ataru with Minitest

Testing Ataru with Minitest

And here’s how it made us feel like:

Even Star Trek guys are getting excited about this.

 

Lucas and Dirk (really awesome guys) are from Cologne and came to Berlin for eurucamp. They both were also guests in the new Asquera office. And yes, we assimilated them into our coaches cloud. :)

We learned a lot of important things from them:
using gifs for pull requests, getting a pink color scheme for the editor and cats instead those arrows for warnings in vim.
Amazing, isn’t it? They have to leave tomorrow, but we’ll see them soon again, at RedFrogConf, where we are giving our first talk!

Week 2 Day 3 Nano Test by Padawans

Let’s walk on the path of enlightment in becoming a test driven Code_Padawan!
And what could be better to learn something about tests than writing our own small test framework?

The Test superclass has this functionality:

  • find all methods that end on  „_test“ and run them
  • find all classes that inherit from Test
  • make assertions and get the result of the method

It’s super helpful, as you don’t want to run every single test method one after another. Test finds all of tests for you (or those that you want to be found) and runs them all at once.

Yes, this sounds like nothing big, but we have learned a lot out of it:

  • What it means, that all classes in Ruby are an object
  • That there is something called „self“, that gives you access to the current object
  • You can search for method names and save them into an array, and run them then by using „send“

We had to read a lot to find out how we can implement this. It was a good exercise to read through Ruby-Doc, use Stack Overflow and find some helpful tutorials about MiniTest for example.

We had to deal with the fact, that our first ideas didn’t work as expected…

Magda is working hard

Magda is working hard

But at the end of the day we wrote something, that worked. It’s still not finished, we have to do some refactoring, buuuuut it’s a piece of working code. Written by ourselves…

Firt sight of nano_padawans_test

Firt sight of nano_padawans_test

nano_padawans_test is born. You can take a look at our repo, if you like: nano_padawans_test

Week 2 Day 1 – Issues with branches

issues with branches

issues with branches

Magda says: it was great working today. But my brain got full, no more comments, check out the picture 😉

Week 2 Day 2 – So this is a real world project

How our website looks like at the moment

How our website looks like at the moment

It’s the time to get used to working with github, github issues, branches and pull requests. We create now issues for features we want to implement, create a branch for each implementation and make a pull request once we are ready with it.
At first this workflow needs some exercise, but after making a few pull requests one gets used to it and, what’s most important, it makes work more transparent and organized.

Today we closed two issues:

  • Remove the .html file extension from the links in the sidebar menue.
  • Make some adjustments with text aligment and floating

As you can see, our simple website looks different now.

For the first issue, it was neccesary to understand how the class pathname works. you can remove the file extension by giving „.*“ to the method „basename“ as a parameter.

The second issue was fixed with the help of some CSS research (google).

In the afternoon we talked to Dario from the Padrino Core-Team about some technical details of the website and – as it happens to the real world projects all the time – we decided, for the time being, to postpone the project 1. (bulding a documentation website) and move to our second and bigger project – creating a documentation testing tool.

We also recorded our first podcast episode.

You can find us on SoundCloud.
Since this is our first podcast we’ve ever done, there are some things that could have went better. We will improve it next time around. As for now, we hope you still enjoy listening.