Infoq posted a nice presentation by Gregor Hohpe, where he talks about SOA. For him domain specific languages could be an answer to over complicated general languages like BPEL.
Also if you havent done so read his article about starbucks and the two phase commit: a very nice analogy about asynchronous communication in a real world example.
Well, who can say he didn’t see this one coming. JBoss development will apparently switch to the Fedora model. That means a community edition will be developed out in the open, and releases will be made on a regular basis with less attention to backward-compatibility. Based on that subscribers will get a more stable “enterprise” version.
Hard to say if this will work out in the application server market. If you want stability and backward-compatibility, you’ll most likely have to opt for the subscription model which is probably fine with companies relying on both.
On the good side this might mean faster integration of new features into the community edition.
The switch is supposed to happen in June. We’ll see how it works out.
Yes, I know, there is this great tool JRuby which will hopefully be an essential part of the JDK in the near future, and yes there is REST where Restlet seems to be the most promising framework, but all I wanted is to speak with a very simple Java Interface from a Rails application. So I thought there must be an easier way, but it has to deal with ongoing changes to the interface. The answer for me was the Burlap protocol which you get with Spring for free. All you have to do is to expose your Java bean with the Burlap exporter:
<bean id="fooService"
class="com.agelion.server.impl.DummyService">
<bean name="/FooService"
class="org.springframework.remoting.caucho.BurlapServiceExporter">
<property name="service" ref="fooService"/>
<property name="serviceInterface"
value="com.agelion.server.FooBackendService"/>
</bean>
. Thats it for the Java side. Burlap is a very simple protocol where you dont map classes, what you get is a map with key, value pairs. But thats fine for me.
But also the Ruby side is easy to implement. I am still a newby with Ruby but that was relativly quick done (though its still not as easy to get information like you get for J2EE for instance, where you get too much information). Because the Burlap protocol just supports the POST method you need the low level Ruby methods for Http:
Net::HTTP.start('localhost', 8080) do |request|
response = request.post('/backendservice/FooService',
'<burlap:call><method>myMethod</method></burlap:call>')
And here we go. All you have to do is to parse this XML:
vals = []
XPath.each( Document.new(response.body),
"//burlap:reply/list/map/*")
{|p| vals << p.text }
And as I said, what you get are key-value pairs with the exception of the first element which descripes the original type (classname). I converted it to a map skipping the first element in the array:
@bashvals = {}
1.step(vals.length-1, 2)
{ |i| @bashvals[vals[i]] = vals[i+1] }
Often forgotten because most of the time you want to proove that your code runs. Yes I know we all tend to be lazy. But to be complete in a sense of Sir Carl Popper you also have to falsify your assumption. You are forced to think about deeper about what your code does and what it should not do. But even further you proove that exceptions are treated correct in case of an error or worse like it happened to me it gets swallowed. I was about to refactor an ancient piece of software written in the early days of Java development. I wrote a test for a new feature and was happy to see my test was successfull. But writing a failure test I recognized that every exception was swallowed by an nice try {} catch (Exception) block just because this test failed.
While I like maven2 because of its productivity benefits now a simple task was taking me some time of research. I have to deal with some legacy code where some tests exists, but these are plain java code with main methods. I look forward to refactor them to junit tests, but step by step. So I have to tell maven what class to use and what not. For two reasons I’d like to gather them all in a testsuite. First I could start the suite easily from my IDE, and second I have another testsuite, which will require an external Corbaserver running. So I would like to seperate these tests.
There are two points to consider:
1) Because maven doesnt seem to work with suites you have to write a TestCase like this:
public class SuiteTest extends TestCase {
TestResult tr = null;
public void testSuite() {
TestSuite suite = (TestSuite) YourTestSuite.suite();
suite.run(tr);
}
public void run(TestResult res) {
tr = res;
testSuite();
}
}
2) Whereas in maven1 it was simple to configure the unit tests with the <unittest> tag, this doesnt work in maven2 anymore. In the pom.xml you have to configure the surefire plugin which runs the test. Thats not obvious for a maven1 user, so its not easy to find the right documentation. But the maven2 concept is to be more plugable. So its easier to include Testng for instance.
Retrospectives are (or at least should be) an important part of a team’s life, be it an agile one or not. The book “Agile Retrospectives” by Esther Derby (of “Behind Closed Doors” fame) and Diana Larsen aims to get you and your team going with them. In an “agile” team where you’d work in iterations, a retrospective should take place after each one, and ideally after the project’s done. The latter would be the case for teams working with more classical end-to-end development approaches.
The book starts out by describing how to approach a retrospective, assuming you’ve never done one before, taking into account things like timing, group dynamics and structuring. The main part of retrospectives are activities. That doesn’t mean just doing something, but achieving something. An activity is always related to a specific goal, e.g. identifying problems. You wanna keep retrospectives interesting. That’s why this book introduces a lot of possible activities which you can adapt or change more to your liking (or team, for that matter). The next about 90 pages list activities you can do in each stage of a retrospectives.
The stages basically split a retrospective into parts into beginning, end, and the stuff in between, the latter being data-gathering, generating insights and deciding what to do. There are different ways to achieve these goals, and the book describes a lot of them in a sadly not-so-glory detail. The list of activities is exhaustive, but each one doesn’t go into much detail. It’s basically a list of things to say or do, and how to deal with certain situations that might come up.
Though some of them come along with examples from real or invented teams, in my opinion there are too few examples going into insufficient detail. “Behind Closed Doors” lives from the story it was built around. I miss that here.
The rest of the book does a good job explaining in a more suitable detail, but the list of activities might get a little dry, since some of the activities are variations or build on others. I’m aware that it’s supposed to be a reference you can get back to, but even then a little bit more information or examples couldn’t hurt.
“Agile Retrospectives” is a good reference to get back to when you plan a retrospective for your or another team. It’s a manual, which is good and bad at the same time. It contains all the information you need to get going, but it doesn’t tell you how to do it in every nitty-gritty detail. You’ll have to figure out the details yourself. And if that was the authors’ intention in the first place, they did a good job. If you thought about getting started with retrospectives in your team I’d recommend getting the book and reading the all the stuff around the activities, maybe some examples of the latter. When you start planning a retrospective, come back to the book and skim through the activities to find the ones you’d like to include in your retrospective.
One last thing: Why the name “Agile Retrospectives”? Though constant self- and team-improvement is an important part of agile teams, using the Agile brand is unnecessary here. A title like “Effective Retrospectives” would be more fitting, since retrospectives aren’t agile-only, and in the end running effective retrospectives is what the book is all about.
Change isn’t always easy, especially when it comes to old habits. The longer you’re in a routine, the harder it will be to get rid of it or learn a new one. This is true for private as well as for professional life.
Being in one or more routines isn’t necessarily bad. You get up in the morning, get a shower, have breakfast and go to work. Nothing special here. And despite the fact that it’s just plain normal I find myself standing in the kitchen thinking about this routine and how it bugs me. I’m honest here, I hate routines. Doing the same every day for a longer time is just boring for me. I hate taking the same train to work, I hate always taking the same route to work.
But I adopted some small tricks that made these routines acceptable: I regularly (not to say routinely) change them. Not big time, but only small parts of them. It’s not that I’m afraid of routines. I just like to tweak them to keep myself happy and ready for change, and maybe even get an improvement as a result. Here’s some stuff I do to keep routines interesting:
Take a different route to work. This is especially true when I’m commuting by bike. Berlin is a big city, and the longer the way to work the more chances I have to go different routes and see different parts of Berlin. I don’t mind cycling one or to kilometres more or less, that’s not the point. I can have an eye on what’s happening in the city, and I don’t get bored seeing the same cars and cyclists every day.
Have something else for breakfast. I tend to eat granola with lots of fruit and yoghurt for breakfast. But after some weeks it’s time for a small break and I switch to buns for a few days. Spare me with health advice, I only eat them for a few days, since I then realise I like granola more.
Try to get rid of a nagging or annoying habit. Knuckle-cracking is a good example, since it’s not only bad for your finger, it tends to annoy people around me. I used to do it too, now it annoys me when other people do it. I’m tempted to write smoking as an example, but that’s up to you. Important thing is to get rid of old habits. If there’s something you liked about the old habit (which is not gonna happen for smoking I reckon), try to involve the good stuff into a new habit. Nicotine chewing gum anyone?
If you can’t think of one thing right now, ask others if something about you bothers them or if they see room for improvement in something you do. Think about it and find out how to do it better. But keep the change SMART. Finding room to change also has the advantage that you can accept necessary routines. Keeping one thing interesting makes it easier to let another thing not bore you.
You get the idea. Accepting change is hard in the big picture, but changing small details and seeing how it works out can help to be more open to change in general. Looking back over the last years, it worked pretty well for me. Which is not to say I don’t have annoying habits anymore. Then there wouldn’t be much to change, would it? It just keeps me interested in trying out news things and adapting them, if they help me to do something faster, better or with more fun. And no, I don’t smoke anymore.
In a discussion the topic of defaults in transaction demarcation for session beans I made an interesting yet somehow shocking discovery. Someone wanted to tell me that the default would be Supports (which means transactions are supported but aren’t created for the called method if none exists). Since all our session bean methods use access the database and write data this didn’t make sense. So I went through the specification, and to my surprise found not a single mention of the default transaction type to be used by the container in case the assembler forgot to specify it. Nothing on unspecified behaviours in this case either.
So the code worked until now without explicit demarcation, what gives? Seems like the JBoss default is Required (i.e. create a new transaction or use an existing one). While you shouldn’t rely on the default here, I’m rather shocked that it’s not mentioned anywhere. I browsed a few books on EJBs, searched the JBoss website, nothing except these forum posts.
I made sure the deployment descriptor now correctly demarcates the correct transaction type, but that still leaves a foul taste. So make sure you don’t rely on defaults, but declare exactly what you’d like the container to do for you.
Mind you, this changed in EJB 3.0, where Required is the default, in both annotations and the deployment descriptor.
I spent half of the day hunting down a nice issue related to external JavaScript files and a group of <script> tags with both external and inline-declared JavaScript. The problem and its solution is just so plain dumb that I just had to post it.
I had a JavaScript block that declared some global variables. That block just didn’t get parsed in Internet Explorer and Firefox, but worked just fine in Safari. Before the block two external JavaScript files were included, like this:
<script type="text/javascript" src="foo.js"/>
<script type="text/javascript" src="bar.js"/>
<script type="text/javascript">
var myVar = "something";
</script>
The block containing the variable declaration never got executed. The reason? Both Firefox and Internet Explorer went straight ahead and parsed the stuff until the ending </script> and because of the fact that <script type="text/javascript"> isn’t really valid JavaScript code, both couldn’t parse the real stuff, i.e. the variable declaration. Neat, no? So to keep it real, you gotta write the following:
<script type="text/javascript" src="foo.js"></script>
<script type="text/javascript" src="bar.js"></script>
<script type="text/javascript">
var myVar = "something";
</script>
As an experiment I tried declaring the HTML as being XHTML, but even that didn’t help. Or maybe I have been staring at this code for too long.
All those doubts and fears that I’m too stupid for this, they’re all real!
The Pragmatic Programmers have a new title in stock. “TextMate: Power Editing for the Mac” is now on the shelf in beta. Sweet! So TextMate now joins the likes of Vim and Emacs to have its own book as a text editor. Author is James Edward Grey II who also authored the Ruby Quiz and the corresponding book.
Great stuff! Now if they’d only sell the time to read all those books.