Recently I was invited to join a discussion forum to discuss the relationship between architecture and an agile software development process. During the talk with the person that invited me, we talked about what to expect. Then he mentioned students asking the question how architecture and agile relate and he spoke the phrase: “In theory they don’t. They are really a different philosophy.” That triggered a thought train in my head that kept me thinking for some days. Because is it really a different philosophy? In my opinion it is a different craftsmanship.
Our core business is software development and we’re good at it. We know our job and are proud of our work. Our customers say we are professionals and we agree. We listen to our customers, we build what they need and appreciate their feedback on a regular basis.
Atlassian Hipchat is a Private Group Chat and IM Service. It allows you to communicate within rooms, get build status notifications, send files, use on any device and much more.
Some weeks ago a client approached us because he wanted some assistance with his IT infrastructure. The client has many systems that interact with each other and are quite tightly coupled. Due to some upcoming changes in their business, the time had come to start thinking about how to improve their architecture. One of the goals of the project was that they wanted the ability to decouple the systems so that they could change systems independently of each other. Our solution ended up being a really powerful combination of Apache Camel and Scala.
Every now and then you come across an interesting engineering challenge. What defines an ‘interesting challenge’ differs for each of us. For me, the kind of problems that spark my interest involve parsing data streams, especially larger amounts of data (probably because it’s low-level in nature and there’s a hardcore feeling that comes with it). That’s exactly what this post is about.
This weekend me and the kids decided to do something different. Something a bit crazy. We decided to make purple pancakes. At the grocery store we bought some purple coloring, and after making the batter we added some purple to it (and yes, I knew the kids might get a bit overexcited from this, but sometimes you have to take the risk).
The intended effect really came to life and Saturday evening we ate some delicious deep purple pancakes!
Today, many companies face an ever growing pool of data they need to store. Data such as logging user activity, audit feeds, marketing data, user analysis data and so forth… Whatever the case, large amounts of data are no longer the exclusive realm of the Googles and Microsofts of the world.
More and more companies realize they need to tackle the challenges raised by Big Data wether it’s for the present or for the future.
A very important part of our software development cycle is functional testing. Luckily, functional testing techniques have evolved tremendously since the dark days of old school testing. Back then, testing was done with countless Excel sheets each having multiple tabs that reflected all the individual scenarios. Each tab looked a bit like this:
- Goto web-page: http://myincredibletestproject.com
- Click on the login link
- Enter username: test
- Enter password: secret
- Click login button
- Verify response: “Failed to login. Invalid credentials.”
Ok, so we all understand that building great software requires a lot more than just a bunch of super skilled nerds producing superb code (see my previous post on the subject). It’s all about teamwork – about dedicated people from all disciplines collaborating efficiently throughout the entire software project lifecycle.
But how is this best achieved when each discipline uses different tools?
People tend to talk a lot about software quality, but what is it exactly? Sure, there are a number of tools that promise to measure your software’s quality level. Some of them are certainly quite good at helping you visualize their results. Sonar for example, is a tool that combines multiple matrixes to make up a quality index. The output is a value from 1 to 100%. This is great because we are all quite number oriented in software. We get that a quality index of 5% means the software sucks and that 100% means it’s the best piece of software ever.