Posted by Joris Bontje around lunchtime: May 15th, 2012
Apache Hive is a data warehouse system built on top of Hadoop. Using SQL-like language you can query data stored in the Hadoop filesystem (HDFS). Those queries are then translated into Map Reduce jobs and executed on your cluster.
As an example we’ll analyze tweets from the Twitter Streaming logs and calculate the top 5 hashtags per day which are associated with positive sentiment signals (smileys).
You can imagine how this can be expand this to simple sentiment analysis on your (potential) customer feedback.
Posted by Daniel Burm at around evening time: May 14th, 2012
Lots of groups struggle with product features in the discovery phase of their products and services. Here is a relatively easy and quick exercise to make sense out of a mess of stories.
(more…)
Posted by Misja Alma in the early evening: May 9th, 2012
The problem
Your project has a nice test coverage, let’s say 85%. Your nightly build reports a wide range of metrics and they are all above your accepted levels. Your team consists of well-motivated people all willing to learn the latest frameworks and techniques. And you have adopted Scrum, Agile, Kanban or another recent/agile software process.
But lately you have noticed that simple new features take more and more time to implement. That despite of your test coverage, bugs have crept in your production code which can take days to solve. And that solving the highest prioritized issues is sometimes delayed because specific knowledge is located at a single person, who can only handle one task at a time.
What’s going on?
Automated testing and metrics are certainly useful, but they don’t catch everything. For instance, it is perfectly possible to have meaningless unit tests which cover 100% of your code.
You could write code with splendid metrics but which is impossible to understand by your colleagues, because method- or variable names are badly chosen.
Maybe you have written code while a colleague has already written something similar, thus missing an opportunity for reuse.
And last but not least, while there are many tools for measuring the quality of Java code, the choice of tools for non-Java code is much more limited; Think of JSF or JSP pages or new languages for which tools have not had enough time yet to develop.
Solution: Code reviews!
Code is not only written for computers, but also for humans. So why not let humans take their part in the code quality process?
Your colleague can see immediately if your code is difficult to understand or not. He can check coding standards in those areas where tools are still missing. And there’s more:
- He could spot bugs in your code
- You might have misinterpreted or missed a functional requirement
- Your colleague might know of a cool third party library you could have used
On top of that, by letting colleagues read each other’s code, knowledge of the code base will be spread thoughout the team.
And by discussing suggested improvements of the reviewed code, general coding knowledge is spread through the team as well.
Tips for how to do it
In my experience, there are a few things which work well when integrating code reviews into your software development process:
First, arrange a brain storm session for your whole team, and agree on a set of review criteria.
By agreeing as a team on a set of review criteria, you prevent discussions later on.
Think of such things as:
- descriptive variable- and method names
- meaningful unit tests
- conformance to gui standards
- non functional requirements such as performance or security
When assigning reviews, make sure they are assigned to a random colleague. After all you have agreed on a set of standards to review on, so a junior colleague might just as well review your code as a senior. And, different people have different points of view, so it’s good to have many different colleagues review your code.
Look for integration with your bug tracking tool. Code reviews become much easier if commits can be traced back from a bug report or feature request.
For instance, Jira has a nice integration with Crucible which enables you to assign reviews to teammembers straight from a Jira issue.
Alternatives
The major disadvantage of code reviews is that they take extra time. It is my personal opinion that this investment in time will pay itself back with interest.
However, if you find it impossible to convince your manager or colleagues to allocate the extra time, then doing selective reviews might be a good alternative; for instance, you could subscribe to each other’s commit e-mails and check those.
But, if time is not an issue, an alternative that goes a even bit further might be pair programming.
Posted by Kristian Spek late at night: May 7th, 2012
At Xebia, we like experimenting with new solutions that enable us to give a more satisfying answer to our customers. One of these questions is: are Agile and Scrum applicable to non-IT environments? And though we are known with project such as wikispeed, we wanted to prove it on ourselves. So we did. (more…)
Posted by Jeroen Leenarts in the late evening: May 4th, 2012
Sometimes you would want a shadow on a view.
Easiest and quickest way is to just add it on the view’s layer:
-(void)loadView {
CGRect frame = [[UIScreen mainScreen] applicationFrame];
self.view = [[UIView alloc] initWithFrame:frame];
self.view.autoresizingMask = UIViewAutoresizingFlexibleHeight | UIViewAutoresizingFlexibleWidth;
self.view.backgroundColor = [UIColor blackColor];
UIView *glowView = [[UIView alloc] initWithFrame:CGRectMake(frame.size.width /2 -10, frame.size.height /2 -30, 20, 60)];
glowView.autoresizingMask = UIViewAutoresizingFlexibleBottomMargin |
UIViewAutoresizingFlexibleTopMargin |
UIViewAutoresizingFlexibleLeftMargin |
UIViewAutoresizingFlexibleRightMargin;
glowView.backgroundColor = [UIColor whiteColor];
[self.view addSubview:glowView];
//Setup the shadow on the view's CALayer.
CALayer *viewLayer = glowView.layer;
viewLayer.shadowOffset = CGSizeMake(0, 0);
viewLayer.shadowColor = [[UIColor yellowColor] CGColor];
viewLayer.shadowPath = [UIBezierPath bezierPathWithRect:glowView.bounds].CGPath;
viewLayer.shadowRadius = 10.0f;
viewLayer.shadowOpacity = 1.0f;
//Let's animate it while we're at it.
CABasicAnimation *animation = [CABasicAnimation animationWithKeyPath:@"shadowOpacity"];
animation.duration = 0.5f;
animation.timingFunction = [CAMediaTimingFunction functionWithName:kCAMediaTimingFunctionLinear];
animation.fromValue = [NSNumber numberWithFloat:1.0];
animation.toValue = [NSNumber numberWithFloat:0.0];
animation.autoreverses = YES;
animation.repeatCount = HUGE_VALF;
[viewLayer addAnimation:animation forKey:@"shadowOpacity"];
}
I must admit, this is kind of basic stuff. But it seems a lot of people actually forget about the fact that all UIView subclasses are based on Core Animation CALayers.
See the source code https://github.com/xebia/ios-DemoForBlog and try the example, the interesting bits about this example are all contained within the fourth tab of the application, it’s the XSDFourthViewController in the code.
Posted by Gerbrand van Dieijen in the late evening: May 3rd, 2012
Spring just started, so in time for an attempt at predicting the future (it has just started to use a cliché). Together with a few colleagues we brainstormed about what we think is important. After that I created the post below. In short: software development processes, local and public clouds and security. Minor disclaimer: this is my own view.
Posted by Daniel Burm mid-afternoon: May 2nd, 2012
My brother is a projectmanger in construction. He builds complex stuff and I admire him for that. During the build, he transforms large sums of money and a set of mandates into a set of sellable real-estate features (sellable…did I really just write this in the midst of our crisis?). When his projects finish, the deliverable is a tangible end-product that people can use for living, working or to generally enjoy.
In Dutch language we have the saying that something “stands like a house” when it is well built or well organized. So in that sense, when we change organizations into high performing highly adaptable entities, could we say change agents are builders as well?
Let’s take a closer look at this comparison and see if it makes any sense.
(more…)
Posted by Iwein Fuld in the early morning: May 2nd, 2012
This is a true story of a company. At the first of January this year ago this company was a great idea and a few pictures. It had been like that for a while. At the first of April it was a company with a production website doing actual business with actual clients. The 12 weeks in between that have been awesome, nerve-wrecking and scary at the same time. We’ve had to let go of some really cool features and we’ve found out things about the business case that we definitely didn’t know when we said we could build it in such a short time. At the beginning of the project I invented the term “Oh shit erlebnis” and I’ve had a few since then.
Because we were working in short iterations (1 week Sprints), we had awesome focus and we could deal with most discrepancies between dreams and reality quickly.
Posted by Martin van Vliet mid-afternoon: May 1st, 2012
At XebiaLabs, we build Deployit, the most advanced Application Release Automation (ARA) solution on the market. The main reason for customers to use our product is to speed up time to market for new software. The ability to deploy software, without errors and without down time, with the push of a button is a critical component in our customers’ agile, continuous delivery and cloud strategies.
As part of those initiatives, many of our customers are also virtualizing their infrastructure. The functionality that makes Deployit ideal for deploying new releases also make it a perfect companion to an on-demand infrastructure strategy. When spikes in demand for applications hit, virtualized infrastructure makes it possible to scale up quickly and automatically. But this infrastructure is not terribly useful without an application running on it. Deployit ensures that the newly provisioned servers run the right version of the desired application (configuring loadbalancers, static HTML, Java or .NET applications and databases) and join in shouldering the increased load.
read more
Posted by Kishen Simbhoedatpanday in the late evening: April 27th, 2012
Couple of weeks ago I realised something. As an Agile tester it’s really hard to communicate bugs! Testers are known for bringing bad news, but it is not easy to do it correctly. Specially when you’re in a Scrum Team and the heat is really on with bugs or issues flying all around.