Getting Started with Jekyll (on Windows!)

 This week Kichwa Coders’ intern Jean Philippe found out the hard way that when it comes to building websites, having the right tools for the job is vital to success. Follow his progress as he explores the potential of using Jekyll to build a user-friendly, easy to maintain static website on Windows.

What is Jeykll and why do we use it?

Jekyll uses Markdown – a text-to-HTML conversion tool – to create a a blog-aware static website that doesn’t require a huge amount of maintenance. Once you have created the structure you just have to add your own Markdown file and Jekyll will add it to the website. The appeal of Jeykll for many users is that it allows content editors to edit the site without knowing how to code. After some rudimentary experience I can now create a basic Jeykll website.

How easy is it to get started with Jeykll?

This week I built my first website using Jekyll. I had some initial difficulties understanding how to use it, but once I’d got the basics I was able to come up with ideas on how to get the best out of it. Before you can install Jekyll you need to install Ruby and Bundle. I’m on Windows, so at first it was hard to install Jekyll as it is more suited to Linux, Linux users are most familiar by using command line and it’s easier to install Ruby and Bundle on Linux but I found this website.  However when I attempted to build a new project with the command “Jeykll new newproject” I got this:image

This wasn’t what I was expecting Continue reading “Getting Started with Jekyll (on Windows!)”

Untested Code is like Schrödinger’s Cat – Dead or Alive?

catinbox2

If every line of untested code is like Schrödinger’s cat – Potentially dead or alive – how important is it to ‘open the box’ properly and know for sure if the code will leap out and run?

The perceived wisdom that if a piece of code hasn’t been tested you can assume it won’t work, is proof – if any were needed – that coders will always expect the worst case scenario when creating code. Unlike Schrödinger, a coder will not waste time mulling over the metaphysical possibilities of whether their code might be dead or alive or even dead AND alive at the same time – they need certainty, and as quickly as possible. However any amount of testing will only be worthwhile if the quality of that testing is high.   In this blog Yannick Mayeur, a Kichwa Coders intern, describes how he kept his fur on whilst improving the testing coverage of Eclipse January.

An introduction to JUnit

This week I was reintroduced to JUnit, having forgotten most of what I had learned about it at the University Institute of Technology back home. JUnit is a unit testing framework. It is used to test the different methods of a program to see whether or not the intended behaviour is working. It is often said that a method that is not tested is a method full of bugs, and after a week of testing  I can confirm that this saying is indeed grounded in truth.

My job this week was to improve the test coverage of Eclipse January. You can calculate the coverage of a program using the EclEmma plug-in. I worked on the DatasetUtils class, improving the coverage from 47% to almost 58%, and fixing bugs using two methods:  (https://github.com/eclipse/january/pull/178 and https://github.com/eclipse/january/pull/188).

Seeing that bugs can exist in untested code written by people that know a lot more about what they are doing than I do, really showed me the importance of testing.

How I did it

This is a test I have written for the method “crossings”. Writing this test helped me highlight some unexpected behaviour in the way it works.

@Test
public void testCrossings3() {
	Dataset yAxis = DatasetFactory.createFromObject(new Double[] {
			0.5, 1.1, 0.9, 1.5 });
	Dataset xAxis = DatasetFactory.createFromObject(new Double[] {
			1.0, 2.0, 3.0, 4.0 });
	List<Double> expected = new ArrayList<Double>();
	expected.add(2.5);
	List<Double> actual = DatasetUtils.crossings(xAxis, yAxis, 1,
			0.5);
	assertEquals(expected, actual);
}

This shows what the values look like: behaviour

The expected behaviour of the method as written in the test would be that the 3 crossing points would be merged into one at 2.5, but this wasn’t what was happening, indeed the code was using “>” instead of “>=”. If left untested this code’s bug would probably never have been discovered.

Conclusion

Discovering bugs like this one is crucial. When users employ this method they are almost certainly expecting the same behaviour that I was, and therefore won’t understand why their code isn’t working – especially if they can’t see the original code of the method and only have access to its Javadoc. I hope that correcting bugs like this one will create a smoother user experience for coders in the future.

 

 

 

 

What is it like to work in Open-source?

Open-source software (OSS) is computer software with its source code made available with a license in which the copyright holder provides the rights to study, change, and distribute the software to anyone and for any purpose. – Wikipedia

Yannick_opensource

I am Yannick Mayeur, a French computer science student currently gaining work experience at Kichwa Coders in the UK, and this is how I feel about working with Open-source.

Why Open-source ?

Let me tell you a story. A company asks someone in their software team to build some software to do a certain task. It takes him a lot of time but he manages to do it. He is the only one working on the project so there are no comments in the code nor any documentation to help maintain the code. He later leaves the company, the software slowly becomes useless as nobody else knows how to use it.

If this company had created an Open-source project instead, this problem wouldn’t have occurred.

Help spread Open-source – or ensure a job for life by using this guerrilla guide on how to write unmaintainable code. But seriously don’t.  Continue reading “What is it like to work in Open-source?”