Java

A colleague of mine made a good point today about a way in which implementing a continuous integration process varies according to the technology stack you have in place. The difference is small but fundamental. It serves however, to demonstrate the importance of following generally accepted ideas on how to develop an effective automated testing process. You can read more on these ideas in our previous post on effective automated software testing.

Two basic pillars of an automated testing process are unit tests and continuous integration tests.

To quote Wikipedia, unit testing is “a method of testing that verifies the individual units of source code are working properly.”

To quote Wikipedia, integration testing is “the phase of software testing in which individual software modules are combined and tested as a group. It follows unit testing and precedes system testing.

To quote Martin Fowler:

Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly.

Cited from: Martin Fowlers page on continuous integration

The point that my colleague highlighted today is that compiled languages have a nice, basic check which is pre-runtime compilation. It’s easy to see that something is wrong when code doesn’t compile.

Stacks based on interpreted languages however perform this basic syntax check at runtime, when the code is interpreted. So you need to ensure that at least some code in every code file in your codebase is executed in order to achieve the same completeness that you get with a compiled language like Java or C#.

Again, this isn’t a major difference between interpreted and compiled languages. But it does serve as a reminder of the value of code coverage in developing thorough testing procedures.

For more information on implementing thorough testing procedures, read our previous post on effective automated software testing.

Have you encountered more significant differences in developing effective automated testing procedures using different software stacks? Let us know! We’re always looking for new ways to improve our own testing processes.

Happy testing!

Good automated testing procedures (for unit and integration testing) use two metrics to gauge the overall effectiveness. The first metric is the pass rate observed when running the tests. If only 20% of your tests pass, you know there’s a problem. But a 100% pass rate doesn’t mean that you’re in the clear either.

The second metric that’s needed to ensure effective testing is something called “code coverage”. A code coverage value tells you how much of your code is actually being tested. It actually tells you what lines of code were executed during a test suite and which lines weren’t. Pretty cool eh?

So, a 100% pass rate is nice. But it’s a poor indicator if your code coverage is only at 40%. This would indicate that 40% of your code does exactly what you want it to do (or at least what you’ve written tests for). But, 60% of your code isn’t even tested. So, your application could be 60% broken and you wouldn’t even know it.

The third factor that comes into play is the quality of your tests themselves. Even if you have 100% code coverage and a 100% pass rate, there may still be use cases or user stories that you haven’t written tests to test.

As you can see, it’s a real exercise in rigor to write an effective, comprehensive test suite. In the last analysis though, it’s the only way to prove, not just be able to say, that your software works properly.

Tools are available to enable you to test effectively in all of the more common languages used today. PHP, Python, Ruby, Java, .NET, PERL and even Javascript. A quick Google will find you what you need to get started.

So, if the quality of your software matters, and it’s important to you to find bugs before your customers do (as it should always be and certainly is for us) then we encourage you to start thinking about the quality of your testing process.

We encourage you to tell us about your own experiences with automated software testing. Tell us what tools worked well for you and which didn’t. Tell us what was most valuable about having good tests. Tell us about how responsive your developers were to fixing broken tests. And any other information on what made your testing processes succeed and/or fail is very welcome.

Happy testing.

This is reply to Ali Loghmanis post “Why is Web UI Development Slow?” on DZone.

Nice post Ali.

I have to agree with you. HTML and Ajax is the best solution out there right now. Granted, the world would be a better place if we didn’t have HTML and could code everything straight in our language of choice. The fact is however that we’ll be stuck with HTML for years to come. So we’d better figure out a way to be productive with HTML in the mix.

Re: the cross-browser issues. I used to struggle with those issues as well. Did for years. The javascript frameworks such as Dojo, MooTools, JQuery, Prototype and ExtJS that have come out in the last few years have made the cross-browser issue all but non-existant for me.

The problem that the HTML layer introduces is a break from the server-side runtime environment. It’s a problem no matter what language or framework you use. It’s a problem with the underlying web ecosystem.

The best way to work around it, to bring the backend and front-end closer together is to embrace it. Stop trying to put a square peg in a round hole. Do one of two things:

1) Build rich interfaces using something like Flex or Flash (as someone mentioned). However, this just swaps around the pros and cons. RIAs (Rich Internet Applications) have many advantages, slick looking UIs not being the least among them. They don’t solve the basic problem howeer. They make UI construction easier. But you’e still got to integrate with all the backend systems such as XML-RPC and SOAP-based web-services. Plus it’s a whole new syntax and development infrastructure to get accustomed to.

2) Expose data access on the server-side via JSON or XML formatted data feeds via services and construct UIs with using JavaScript for some things. I’ve seen component-oriented JavaScript frameworks, ExtJS comes to mind, tend to suck developers in, encouraging them to build entire UIs with Javascript components. This is a huge learning curve and can result in a real mess. I’e seen it happen. So I recommend using Javascript just to handle whatever needs to be dynamic after the screen has rendered. This leaves the majority of screen functionality to be coded on the server side, while providing the responsiveness and esthetic appeal of a responsive, dynamic, javascript-enabled interface.

My big thing is that I don’t need more tools in order to build better apps in less time. I already have all the tools I need. I don’t need more syntaxes, toolkits, development environments, etc. I have a great deal of success building apps with just the fundamentals of HTML, JavaScript and a server-side scripting language.

I’ve found it’s much more effective for me to stop looking outward to the developer community for a framework that will solve all my problems. I’ve been disappointed by hyped-up solutions too many times. I’m finding that by being more diligent and more clever with the fundamental components of the environment (web, desktop, mobile) and server-side language I’m developing with, I’m able to develop more functionality in much less time. And the resulting application is simpler and easier to understand and maintain (because there are fewer frameworks to understand).

I think it’s great that your readers are suggesting alternative frameworks. But, just like wearing Air Jordans won’t make you play basketball like Michael Jordan, using a better framework won’t make you a better developer. I don’t mean this as a criticism at all. As Donald Knuth said, “Software is Hard”.

We should experiment with different architectures and solutions throughout our careers. We must continue to learn and grow as developers. We shouldn’t forget that it’s our skill that makes us good though. It’s not the framework we use. And to say that using one framework or another is going to solve the problem of apps being hard to use isn’t accurate. The gains from using one framework or another are marginal compared to the gains you get from experience.

So, all things being equal, keep things simple. Complexity begets more complexity, which ultimately slows you down.

Until the fundamentals of building web applications change so that we don’t need to use markup, the simplest, best approach (in my opinion) is to use HTML and javascript for the UI and a scripting language on the backend.

Lastly, if you’re interested in some more of my thoughts on this topic, read a post I recently made title “Why are there so many Java web frameworks?”

Have at it everyone!

I posted a week or so ago about my solidifying realization that Java is no longer (if it ever was) one of the better languages for building web-apps.

The original article, Why Are There So Many Java Web Frameworks? can be found here.

One of the points made in that article was that as you mix different frameworks into an application you end up having to tweak or work around attributes of each framework that aren’t compatible with, or are undermined by features of another app.

For example …

A really good example of this, and the one that impacts me the most right now is probably how Spring and the hot-deploy capabilities of Tomcat interact.

When Tomcat reloads a class after the source file is changed, it dumps/clears the web context and reloads or rebuilds it. This is typical for the various application servers I’ve worked with (including Jetty, WebLogic and others). When Spring is being used, the context dump also dumps the Spring context, meaning that all of the beans that Spring manages need to be reloaded. Yuck!

Spring does have a refresh method which may avert some of the greediness of this process. I’ve never been able to implement it though because I don’t usually have control over the dispatcher servlet because I’m using Struts! This is yet another example of how frameworks compound application complexity when used together.

The net result for me is this. On an application with 3164 classes and 405 beans managed by Spring it takes me 63 seconds for the hot-deploy mechanism to pick up my changes.

So, in Java:

• I forgot a semicolon: Add a semi-colon, wait 63 seconds, refresh the screen in my browser.
• I need to change business logic: Change business logic, wait 63 seconds, refresh the screen in my browser.
• I need to tweak formatting: Tweak formatting, wait 63 seconds, refresh the screen in my browser.

Ugh!

In any interpreted language:

• Do anything. Inhale, refresh the screen in my browser, exhale, see the modified code in action.

The dream

Here’s what’s great about Java.

1. It runs everywhere.
2. There are an almost infinite number of libraries, tools (including IDEs) and frameworks available.

If you read almost any Java blog or talk to any junior to mid-level Java developer they’ll cite those two attributes as reasons why Java is so wonderful. There may be other reasons in addition. But you’re almost guaranteed to hear those two. Oh, you may also hear “It’s so much better than C++”. Who’s writes web apps in C++ though?

In my experience …

Unfortunately however, that’s not the whole story. If you start asking around, talking to Java developers with more experience, and particularly those who’ve worked in other language environments, particularly using interpreted languages, you’ll start to fill in more of the picture.

1. Application servers start to get more and more difficult to deal with during development as the size of the application increases. So, by the time I get to take advantage of all of the support for “enterprise-level” applications that Java promised, I’ve discovered more than enough difficulties to offset what I thought I would gain.
2. I’ve worked with dozens to hundreds of frameworks over the years. Every framework solves (or at least claims to solve) a problem. Unfortunately though, for every problem it solves, it creates 2 new ones. Sometimes I have to deal with them. Sometimes I don’t. When I do have to deal with them it’s usually twice as hard to solve the new problems as it would have been to just deal with the original problem that the framework solved.
3. I get bored and lose a lot of time and focus while waiting for my darned application server to redeploy 50 times a day. Fortunately though this leaves me a lot of time to check the news on CNN and see what’s new on YouTube.
4. Spring proxying is fantastic in terms of delivering a real platform for modular, pluggable, SOAs (Service Oriented Architectures). But it broke my debugger! My stack traces are full of references to proxies that I can’t pull up in my IDE. I have to know where the exception is occurring before I can figured out where to look to find the problem.

I could go on. But you get the point.

So have at it!

Live and let live I say. If you’re happy with your development life-cycle, the speed at which you develop applications and the tools available to make you more productive I’m truly happy for you. I would, however encourage you to look further afield. Try using some different languages. Try NOT using frameworks and just deal with the problems that the Java fundamentals (things like Servlets and JDBC as opposed to component-based UIs based on markup and ORM (object relational modeling) tools. You’ll be surprised how much faster your applications are. Whatever you think you’ll gain most likely won’t be worth the complexity and learning curve to attain it.

And lastly, if you’re a framework developer, keep it up! There may be a killer app out there that will boost Java past the yuckiness I’ve described. And you may be just the right guy to discover and/or develop it.

A final clarification

Just as a final clarification, lest you think that I’m a Java hater, I’m not saying that Java is bad. I’m just saying that it’s not the best tool, or even the best starting point for building applications for the web.

I feel that a lot of businesses have felt the need to embrace “enterprisey” platforms. At the same time, they’ve felt the need to embrace an increasingly web-based delivery model and Java has catered to that crowd. Businesses have embraced Java mostly because there weren’t any better alternatives, and or they didn’t have enough experience and knowledge about Java to be discerning or find alternatives. That is to say that there weren’t other platforms that catered to the crowd interested in “enterprise-scale web applications” to the degree that Java and Sun did. So Java was a safe choice for managers and developers starting out and looking for a technology to use as the basis for their career.

My thoughts in this article are intended to encourage IT managers and developers to look outside of the vast confines (isn’t that an oxy-moron?) of the Java landscape and consider options and alternatives for enterprise-scale computing platforms. It’s become simpler and simpler to achieve scalability (one of the biggest demands from the “enterprise” crowd) since Java became King of the Enterprise. And I think it’s time for businesses, particularly IT managers and senior/lead/principal developers and engineers to build on a platform of simpler, more nimble technologies to meet ever increasing demands for agility in the marketplace.

Every day it seems I read an announcement of the release of a new Java framework, or an upgrade release for an older framework.

Three facts should tip you off to a problem with using Java for web projects:

1. There are a lot of Java frameworks for building web-apps.
2. Many of these frameworks try to solve the same set of problems.
3. Many frameworks are built just to improve upon weaknesses in other frameworks.

The third point causes the most concern. If every framework needs yet another framework to make it complete, then you’re never going to end up with a complete solution. You’re going to be passing the buck endlessly, and forever looking for a solution to your immediate problem.

Next question is, why are there so many of them? Surely if someone could build the perfect Java framework for building web-apps someone would have over the last ten years.

This leads me to think that:

“You can only put so much lipstick on a pig.”

Java is just the wrong tool for building web-apps. Scripting languages are far superior. The main reason for this is the statically compiled nature of Java. Interpreted languages will give you a much faster and continuous development cycle.

I welcome your comments on this topic. If you think I’m wrong, show me how and why. In particular, tell me what combinations of frameworks work best for you.