Oftentimes languages such as Java are called “high ceremony” languages compared to languages like Ruby or Python. This refers to the fact that there’s generally a bit more plumbing involved in firing up a Java application – particularly a web application – than there is with the scripting languages.
Of course, Java is compiled (to byte-code at least), so it’s not quite a 1 to 1 comparison with a more interpreted language such as Ruby, but still, even in a “high ceremony” language it’s important not to get too high a “cycle time” for developers, IMO.
By “cycle time” I mean the time between making a change and seeing it working – either in a test, or, ideally, in a running application. Most modern IDEs made the cycle time for tests pretty darn low (and great tools like Inifinitest can take all the manual work out of it, no less), but to see a running application and be able to exercise your changes deployed in a container is a bit more of a grind.
That’s where a tool like Jetty can come in handy. Jetty is a lightweight web app container that can be easily added to your development cycle in place of a heavier-weight solution to allow you a faster cycle time, and, often, greater productivity and interactivity.
Especially in combination with it’s integration with Maven, Jetty can get your app deployed far faster than with other solutions. For most webapps, it’s just a matter of saying:
And you’ve got a container up and running with your app in it within a few seconds.
Jetty can even do a certain amount of “hot update”: modify a JSP (or even some code – although there are limits) and the running webapp is updated, and you’re able to test, edit… cycle away without the painful wait for a deployment any more often than necessary.
You can pass required system properties to your app via maven’s -D mechanism, and they’ll be available to your app:
mvn -Dsome.property=someValue jetty:run
And even control the port your application binds to on the fly (or via the handy jetty.xml file if you want to set it more permanently).
Jetty and maven also give you the ability to easily script, for example, if you need to run a test utility on your running webapp to ping a series of REST calls, for example, you can:
mvn clean package # Build the webapp
mvn jetty:run & # start jetty, spawning it in the background
java -jar mytestutility.jar # Run my test jar, which pings the URLs for all my rest services, maybe does performance checks, etc
mvn jetty:stop # Stop the jetty instance we fired up in the background
Lightweight containers such as Jetty are just one way to help crank down the “cycle time” for developers, of course. Some other possibilities I’ll leave for a later entry.
By: Mike Nash
I have been working on a creed for business analysts in an agile project. The purpose of this is to help guide and give direction to the various business analysts we have working on a number of different teams in our organization. This has not been an easy process nor is it complete. I believe it is important that we follow the agile manifesto http://www.agilemanifesto.org, adapting to the individual and to the organization while still providing direction to encourage improvement.
If we look at the extreme roles from the c2.com wiki http://c2.com/cgi/wiki?ExtremeRoles there are a number of places a business analyst could fit: The Customer, The Tester, The Doomsayer and The Manager. Based on my historical knowledge a business analyst will be more than one of these roles and this should be encouraged. Pigeon holing any one person into a clearly defined role assumes that everyone has the same skill set. When creating a creed we must ensure that it does not limit the role(s) the business analyst can perform within the team.
Every company has a different model, a different set of customers and issues that prevent the “ideal” agile management and development scenario. In our organization we have a customer base rather than a customer and a large number of stakeholders each with their own areas of expertise. The business analyst acts as customer proxy and is responsible for gathering information from a number of sources and writing the users stories (though not generating them). The process that we follow is as a result very different then if we had one internal customer that sits at the next desk over. When developing a creed it must be for a specific organization.
It seems clear that the creed needs to be dependent on the organization. It should be general enough to allow the business analyst to fill the best position for them in the team while giving enough direction to guide them towards making working software.
With all that in mind I give you our creed item number one:
A business analyst must be a subject matter expert for all user stories that are in development
By: James Townley
Having attended PyCon 2009 in Chicago I would like to highlight a few tools which were demonstrated and I feel stood out from the crowd.
It’s safe to assume you have read online tutorials for a programming language and had the following setup: a) a web browser window open displaying the tutorial documentation, b) IDE / Command Prompt open to write and execute code, c) multiple monitors so you can show it all at once (if you’re lucky). Crunchy takes a different approach and delivers HTML formatted documents with an interactive python shell so that you can try the code snippets as you encounter them. A demonstration of this tool included the user being able to read the requirements for a function, implement that function to the best of their ability, and finally execute pre-existing unit tests to check if their implementation works!
It can be annoying running a time-consuming python program and after 2 minutes of execution you find there is a problem and have to start over. This would really start to gnaw at your patience if this happened a few more times. Wouldn’t it be great to have a Python shell that clearly showed you which line the execution was hanging on, allow you to make a fix, and then only re-execute the code that is necessary to realize your change? This Python graphical shell implements this, and more, great functionality which I really hope to see adopted elsewhere.
Chances are this has happened to you or someone you know:
You plan on demoing some code to a group of peers. You begin to code and upon execution you get an error. You try to recover but are too nervous and cannot get the %&*$ thing to run. The demo ends with an awkward bit of silence and a brief apology.
First of all, let’s avoid live code demos. Second, let’s pretend they’re live demos! For those of you who don’t know, a Player Piano is a self playing piano running pre-programmed music. PlayerPiano is a great python tool that runs doctests inside a fake Python shell; effectively it runs your pre-programmed demo while you can focus on speaking and paying attention to your audience.
Please, please, please no more live code demos.
By: Logan Peters
Key ingredients to success and career growth, at least the two on my mind right now, are focus and determination. Why are these things important? I’ll tell you why, because when most people are asked how to be successful, focus and determination will probably slip off their tongue, however if you were to actually observe them at work and in their personal life, you would most likely see a lack of one or both of these.
Lets start with determination as it seems more obvious. Determination isn’t really something in and of itself, it’s more of a measurement of what lengths you are willing to go to in order to achieve your goals. So being very determined to accomplish something really just means you are willing to do certain things to get there, which usually will consist of things like:
- Looking for teaching/coaching
- Anything else that makes sense.
Many people may say they are determined to accomplish something, but what they really mean is they really wish they could just wake up tomorrow and be at their destination. That’s an exaggeration for most people, but for many it’s somewhere between that and what’s actually required to reach their goals.
Focus on the other hand is something that most people probably don’t think about enough. Determination by itself is not good enough. The problem is that when your goals are to become an expert at anything, no matter how determined you are you won’t be able to accomplish that goal without focusing on it. You’ll need to cut out distractions, and stop trying to focus on improving skills that are not related to the skill you wish to be an expert at. There is an old saying you’ve probably heard before “Jack of all trades, master of none”. It’s relevant in all industries, and IT trades are definitely no exception. I’d say it may be worse in IT but that wouldn’t really be an informed opinion so i won’t make any bets on it.
So, if you take my word for it, lack of focus will result in a jack of all trades. To be more specific, a lack of refocusing will result in a jack of all trades. The reason for that is because at the beginning of your career you won’t know what you want to focus on besides becoming a better developer, business analyst, sys admin etc. Sticking to the development track because it’s what I’m most familiar with, you’ll initially need to focus on how programming works, basic skills related to the industry, and probably try to get a basic level of knowledge on as many things as possible.
So now you’re done school and ready for your first job. You start out by soaking up as much information as possible, learning everything you can. You learn about things like object oriented design, service oriented architecture, domain driven design, database design and performance tuning etc.
Skip forward 3 or 4 years, you’re quite competent in every aspect of your job, you’re a go to guy for your team, you can become competent at a new skill in short order at the drop of a dime. You have basically reached the epitome of most peoples career – broad competence with the ability to pick up new basic skills quickly.
Now you’re faced with the decision everybody in the industry runs up against, and most people don’t even realize it. Do I want to keep getting better, and if so, how? The answer to the first question is a factor of determination. How much are you willing to do in order to keep getting better? The answer to the second question is focus. Up until now in your career you’ve enjoyed getting better at everything, making constant improvement in everything. Bad news – that’s not going to last forever. You’re going to have to pick a skill, or subset of skills and focus on improving those skills. The side effect of this is that you’re going to have to “defocus” on all skills not related to the ones you’ve chosen to focus on. It’s a large hurdle for most people to jump because it’s easy to understand but hard to accept and work with.
This will be a turning point in your career. You’ll either accept the hurdle and jump over it, taking a turn down the road to becoming highly skilled in narrowly focused areas, or else you can understand the hurdle but not choose to jump it (lack of determination) and decide to take the easy path which unfortunately leads to the dead end of being average, the jack of all trades trap.
So to sum up the thought, you’re going to continue to refocus your skills throughout your career. Every so often you will zoom in on a new area that you’ll specialize in. Once you have reached a certain level in those skills you’ll zoom in your focus again on yet another area to become more specialized in. Only you can decide when you’ve focused enough. The less focused you are the more skills you’ll be able to maintain a specific skill level at, at the expense of increasing that skill level. At some point the only way to increase skill in some area you’re interested in will be to defocus on another skill and allow your ability in that area to lapse.
Focus and determination. How determined are you to reach your goals? Determined enough to allow your skills in something you used to be good at to lapse? Willing to not be the go to guy for a laundry list of skills? How many are you willing to drop, how much are you willing to work at the ones you’re going to focus on? Keep asking yourself this question, it will play a key role in your career development.
By: Chris Dagenais
Over the last year I’ve learned a lot about people and business. I’ve observed that there are two basic types of interaction – those that involve logic and those that involve emotion. These interactions are applied to people and business on a daily basis, but they are generally applied in the wrong ways.
Logic can be described as a system of reasoning. When asking questions such as “which server platform should we choose, Windows or Linux”, you can weigh data points against other data points and use reason to come to a conclusion about which platform is best for you.
Emotion can be described as a mental or physiological state associated with a variety of feelings or thoughts. In essence, our moods. Emotion does not follow any system of reasoning – it just exists. There is no reason for me to be annoyed by people walking by my desk. Sometimes it just rubs me the wrong way. (I’m not really annoyed; it’s just an example.)
Now that we have defined logic and emotion, let’s look at how they are applied incorrectly.
HR managers sometimes need to tell people that they are not performing adequately. Imagine how you would feel if you were hauled into your boss’ office and told that you needed to pull up your socks. Your boss presents the logical side of your performance problems (being late, introducing bugs, etc). Your boss then logically presents a plan, metrics, and alternatives for this behaviour. Everything is cold and calculated because the boss thinks that you are logical and you can not possibly disagree with the facts.
But people are emotional. Maybe you’re late because your spouse is sick and you had to take the kids to school. Maybe you ran out of jam for your toast. Maybe your kid keeps turning off your alarm clock. On top of your home/commute/extracurricular frustrations you’re nervous about being called into the boss’s office, and now you’re angry and defensive that you don’t get to explain.
But imagine the difference if you have a great boss and emotion is applied to this situation. The boss tries to understand why you are late. The boss empathizes with your situation and realizes that the kids will grow out of the turn-off-the-alarm-clock phase. You both have a shared understanding and there is actually no problem. You say “I’ll check the clock before I go to bed”. The boss doesn’t need to prescribe a solution.
Now let’s look at the business portion of … business. People can have strong emotional attachments to things like product lines or brands. An example – there is a need for servers, but do you choose Windows or Linux? Ideally you would identify required features, the pros and cons of each platform, and come up with a formula of some sort to weigh the options. In reality you get people who are emotionally attached to one or the other and they debate based on their attachment. “Windows sucks because the kernel isn’t separated from the UI.” “Linux sucks because it has no drivers.” Or whatever. This is not the situation to make a decision based on emotion. You need to analyze the facts because you can’t properly make decisions any other way. What you end up with is one party capitulating – “Whatever, use Linux” just so you can move on and get something done.
Have you noticed this? Do you agree or not?
By: Ryan Shuya