Showing posts with label Code. Show all posts
Showing posts with label Code. Show all posts
on Saturday, 26 May 2012
I've just started reading Software Build Systems: Principles and Experience
by Peter Smith PhD and one of the chapters discusses development tools and how to best manage them. This is only a small part of the book, but it's one of my favourites because it's easy to implement and the benefits are huge.
#1 Take Notes
I think this is one of the most important things to do when testing tools or running a proof of concept. It's so easy to get carried away with simply getting something to work that you actually forget the steps you took to get there. I would recommend getting yourself a little notepad and jotting down some bullet points - this can be fleshed out later. I personally like to open a text editor like notepad and put everything in there. Mainly because its easier to copy and paste file paths than jott them down on paper.
#2 Use Version Control for Source Control
This rule relates to tools you use that need to be compiled for different targets. You shouldn't always trust that your files will be available online (if thats your source). By keeping your tools in version control you can always rest assured that if anything catastrophic ever happens to your source, or even if they just remove them, you will always have them.
#3 Periodically Upgrage Tools
I'm going to aproach this rule quite differently to the book. I think there has to be a happy medium here; you need to upgrade your tools regularly to stay inside support, but also do it in a controlled manner and not as soon as a new release is made available.
A short time ago I was caught out upgrading one of the plugins on our continuous integration tool. To cut a long story short the latest version of one plugin was faulty and braught down our whole CI system. At the time I done a big bang upgrade of the plugins the CI used and it was a nightmare to track down the root cause and rectify. The moral of this is time the upgrades well, give new releases time for error's to manifest, but upgrade so you get new features and bugfixes.
#4 Version Binaries
I think this should be an extension of rule #2 because the reasons are pretty much the same. Just to reiterate though, keep the tools you use versioned and in your repository so that they are always available!
by Peter Smith PhD and one of the chapters discusses development tools and how to best manage them. This is only a small part of the book, but it's one of my favourites because it's easy to implement and the benefits are huge.#1 Take Notes
I think this is one of the most important things to do when testing tools or running a proof of concept. It's so easy to get carried away with simply getting something to work that you actually forget the steps you took to get there. I would recommend getting yourself a little notepad and jotting down some bullet points - this can be fleshed out later. I personally like to open a text editor like notepad and put everything in there. Mainly because its easier to copy and paste file paths than jott them down on paper.
#2 Use Version Control for Source Control
This rule relates to tools you use that need to be compiled for different targets. You shouldn't always trust that your files will be available online (if thats your source). By keeping your tools in version control you can always rest assured that if anything catastrophic ever happens to your source, or even if they just remove them, you will always have them.
#3 Periodically Upgrage Tools
I'm going to aproach this rule quite differently to the book. I think there has to be a happy medium here; you need to upgrade your tools regularly to stay inside support, but also do it in a controlled manner and not as soon as a new release is made available.
A short time ago I was caught out upgrading one of the plugins on our continuous integration tool. To cut a long story short the latest version of one plugin was faulty and braught down our whole CI system. At the time I done a big bang upgrade of the plugins the CI used and it was a nightmare to track down the root cause and rectify. The moral of this is time the upgrades well, give new releases time for error's to manifest, but upgrade so you get new features and bugfixes.
#4 Version Binaries
I think this should be an extension of rule #2 because the reasons are pretty much the same. Just to reiterate though, keep the tools you use versioned and in your repository so that they are always available!
on Saturday, 12 May 2012
Sonar has one of the most boring user interfaces I think I've ever seen -- it's butt ugly! but, as ugly as it is there's no denying how useful it is.
A dashboard should be simple, provide enough information about the project ,but not overwhelm the user. If your customers or stakeholders have access to this they may not be technically minded and so this page should show info that anyone can understand.
Dashboard
To change the dashboard, log in as the admin user and on the right of the page select "Edit Filter":
The column headings that I have selected are:
- Lines of code
- Rules compliance
- Unit test success (%)
- Coverage
- Complexity /method
- Complexity /class
- Public documented API (%)
- Duplicated lines (%)
- Total Useless Code (plugin)
- Build date
Project Layout
When you select a project from the name column on the dashboard you will be presented with a page like the following:
Now this is where you can geek out and go crazy with metrics. Hopefully, by this point the non-techies have seen what they wanted and left. This page is where you can get creative.
I hope i'm not generalising too much but I would like to think most technically minded people are working with widescreen monitors for maximum productivity. If this is true I would strongly advise going for a three column layout. This can be done by selecting "Edit Layout" on the right and choosing the tri-colum option.
Finally, to select the widgets you want to display press "Configure widgets" and then you can drag and drop them at your desired locations.
Subscribe to:
Posts (Atom)