So, after writing the article I blogged about a few minutes ago which I wanted to publish on Code Project it seems that it’s been added to the “Unedited” articles side of the site. This was actually less painful than I would’ve expected aside from the fact that I had to do HTML for the first time in a while. If you’re interested in reading it and giving me your feedback, I would love to hear from you. You can find the article both on this site under my article “Memory Queue” or on Code Project as the article aptly named “Memory Queue”. The article on Code Project has the source code that goes with it and I’m hoping to have more articles to publish soon… 🙂
My team was recently assigned to help out another team who had a bit too much to do for a bit too long. So, I wanted to see how easy or how hard it would be to use some of the tools that I’ve become quite use to. One of those tools of course is Jenkins. The idea was to set this new environment up to be a slave to my Master Jenkins Build Server running on Ubuntu while the slave would run on Windows. Of course Jenkins has a lot of features with regards to this and I managed to fiddle enough to get it to work and I’ve released another article called “Setup – Jenkins and Windows” where I take you through how to do this.
The next thing I’m going to do is get it to pull the source code from Team Foundation Server and running the tests so we can know when we break something. Just in case you were wondering, I do try to follow the Test Driven Development (TDD) way of writing code as much as possible and love the fact that it makes my life easier and safer. I’ve decided to write another article on this as well, but you’ll have to wait and see when it comes out whether you agree or disagree with the things I write in there J
I hope you enjoy this new platform that you can use for your CI…
So, I’ve cleaned up some of my articles to point to the “Setup – Requirements” page and will be using this as a living article for any new requirements I may come across.
As some of you may have seen, I have been quite active over the course of the last few weeks and if you’re wondering why, well it’s because I’m trying something new 🙂 It’s always fun when you try to do something different and if you find that it works. To explain in the space of a Blog, I’m trying to follow a new process (new for me) whereby I do my own notes, test code, research and code all at the same time. The way it works is quite simple… It’s very similar to Test Driven Development (TDD) where you write your code before you start coding. So, the first thing you do in your test code is you “wish”. This means that you simply write out all the different Test Methods with no code in the body of these methods. In other words you’re declaring your test code before you actually write the test code. Once you’re done with that you start with the first method and you write the code. While you’re doing this first method you may find that you have another scenario that you would like to test, so you add another method once you’re done with the test method you were busy with. Once you’re done with the first test’s code, you run it and you should see a failure. Now you start writing the actual business code and on completion you run your test again to see that it passes. When you’re done with that, you move to the next test method and so it goes until you’re done with both your code and your tests. After all this, you refactor 🙂
To get back to the thing that I’ve been trying… Before I start with a new task, I start up Microsoft Word. The I write all the headings in my document that I would like to cover i.e. “wishing”. When that is done I start doing my research and I make notes in the relevant section in my document. Once these notes are there I start with the implementation of that research and once that is done I’ll update my document. Now if you take a scenario where I’m busy writing code, I would write the outline for my document first, then write the test methods, then update my document and start with the test code. And so I continue until my Document is complete, my tests are complete and my code is complete.
Why do I do this? I found that it gets me to focus a lot better. Seeing that I have to explain what I’m doing in the document, I find myself understanding the problem better and seeing that I need to write the test code I find myself implementing the logic as I understand it. All the while I’m learning more about the problem, I’m also updating the document until I find myself where everything is complete and at that stage I finish the document first, then I do some refactoring on the code.
If all this doesn’t make any sense, try by documenting what you are going to do before you do it, instead of after the fact 🙂 You may just be surprised at how easy you pick up things and how well you understand them when you’re done… It’s like being the teacher, the student and the writer all at the same time 🙂
Anyway, Have Fun…