In my previous article (Performance Tuning Resources For Web Clients) I discussed why you should care about the performance of your web client and then listed out some of the better places to go on the web to find information on how to go about tweaking your web clients to get that better performance. In this article I am going to dig a little deeper and call out specifically what I think are the Must-do-No-excuse-not-to-do-them-You-are-really-being-unprofessional-if-you-are-not-doing-them tweaks that you should be performing on every single one of your web development projects.Continue reading »

Recently I have been doing some research on tweaking websites to make them faster (either in reality, or at least in appearance to the client). Specifically the research has been focused on the actual client tier interaction – requesting the page, downloading the assets and rendering the page in the browser. In this post I will document some of the better resources I have found, focusing on client-side tweaks, so these resources should be relevant no matter if you are a Java, PHP, .Net or any other flavor of developer.Continue reading »

I had the privileged of seeing Ben Galbraith present at JavaOne last week, in fact his presentation was the very last presentation of the conference for me, late on the Friday afternoon.

I have seen Ben present before and his presentations are always engaging, informative and I always end up with a page full of action items from them. This one was no exception.

Ben has put a post up on his blog that roughly covers the same material that was in the presentation, so I wanted to link to it to give a little back to Ben as I have gotten a lot from him over the last couple of years.

I strongly recommend reading the article if you are interested in user experience design and its importance in Software Engineering.

Anyone with an email address has had to deal with spam. Insidious, potentially offensive, sometimes incomprehensible but definitely time wasting spam. It is such a problem that there is a whole industry of software products out there to deal with the spam. Some of these tools can delete the spam straight away, others just tag it and allow you to redirect it to a Spam folder or something similar. But what none of them can tell you is who gave away your email address? Was it that online store you purchased a gift from last month? Did they then sell your email address to a list broker? Maybe it was a co-worker playing a joke that gave your personal address to that porn site?

Wouldn’t it be nice to know who gave away your email address? I certainly want to know.

In addition, unfortunately as good as some of the tools out there are, some spam inevitably gets through. I have given up on email addresses because they had become so riddled with spam that the signal to noise ratio was not worth the effort anymore. My original Yahoo! mail account comes to mind. I want to be able to block as much spam as possible – not tag it or redirect it, I simply want to know nothing about its existence in the first place.

So this is how I manage my email and deal with spam.

Firstly I purchased my own domain name and I set up an email server to host the email for that domain. Even the most basic Linux hosting plans will be more than enough for this purpose.

Next I set up just one real account on the email server. I then configured the server to redirect all of the email sent to that domain to that one real account. This is often called a catch-all account.

Now whenever I need to provide an email address for something, I use a unique one-off address. For example, when I signed up for Netflix, I used netflix@mydomain.com as the email address for my account. Whenever Netflix sends me an email at that address, it still ends up in my Inbox because of the catch-all account. l also know that if I start getting spam email being sent to netflix@mydomain.com then I need to have some harsh words with Netflix (thankfully this has not happened with Netflix).

If you implement this strategy, you’ll be surprised how many of these one-off addresses you end up creating. So to keep things organized (and so I do not forget who I gave the address too) I try to map these addresses to the domain names of the website or the company I am giving them too. This however, will raise some eyebrows from time to time. When the car salesman at the BMW dealership asks for your email address and you tell him it is bmw@mydomain.com you will almost certainly get a strange look.

OK, so now I can give out unique (traceable) email addresses to companies and websites when they ask for them. If I start getting spam being sent to a specific address, I know who sold me out. It also means that the email address that my personal friends and family use is kept reasonably secluded and not plastered all over websites and in databases all over the planet.

Now what do I do if the spam being sent to one of these unique email address gets out of hand? Easy, I just block receiving email for that address on the server. Any email sent to that address will bounce back to the sender with a message telling them that the account is no longer valid. I never see the email, I am never even aware of its existence, I never waste time downloading it to my phone or laptop. Perfect. In addition, the rest of my email is not affected, it still all gets through.

In my environment I run Sendmail as my mail server. Configuring Sendmail to completely block certain recipient addresses is very simple. You will need to edit the file /etc/mail/access which is a simple text file – if it does not exist, you can create it. In this file, you will need to add a line for each address you want to block. Here is an example

To:bmw@mydomain.com REJECT
To:vistaprint@mydomain.com REJECT

Sendmail will reject/bounce any inbound message sent to either of these 2 addresses. In my actual file I have about 15 addresses total being bounced currently.

Once you have edited the access file, you have to turn it into the database format that Sendmail expects. This is also easy to do.

$ cd /etc/mail$ makemap hash access.db < access

That’s it. You don’t even need to restart Sendmail, the settings take effect straight away. Anytime you need to start rejecting another email you just add another line to the access file and regenerate the database.

Now, in the spirit of full disclosure, I admit that I do still get some spam. This is spam that is being sent to addresses that are legitimate and which I do not want to block. But I do know that the number of spam messages I do see versus the number that are getting bounced is slanted heavily in my favor – something like 1 or 2 per day get through versus 1 or 2 hundred that are getting bounced.

Let me know if you have any other ideas for taking better control of your email.

Step 4 – Change Default Port (Optional)
For my install I have no need to run Apache in front of JBoss, so I want JBoss to listen (or more correctly, have Tomcat listen) directly on port 80 – by default it listens on 8080.

I opened the $JBOSS_HOME/server/default/deploy/jboss-web.deployer/server.xml file, (which is a standard Tomcat configuration file) in an editor.

I changed the port of the HTTP connector to 80 (you can find it by searching for 8080). I also change the HTTPS connector to use 443 (you can find this one by searching for 8443). I then changed the value of the redirectPort attribute of the HTTP connector to match.

Step 5 – Change Portal to be the root web app. (Optional)
For my install, the Portal will be the main application on the server, so I want it to be accessible from the root of the server, and not have to enter the portal context path all of the time.

The installation process started the mysqld service automatically. It also installed MySQL as a service automatically.

I checked that it was running

$ mysqladmin version
mysqladmin Ver 8.42 Distrib 5.1.34, for unknown-linux-gnu on x86_64
Copyright 2000-2008 MySQL AB, 2008 Sun Microsystems, Inc.
This software comes with ABSOLUTELY NO WARRANTY. This is free software,
and you are welcome to modify and redistribute it under the GPL license

If you have trouble accessing your URL, there could be an issue with the address that JBoss is listening on. This can be caused by various issues with your server setup (hostname, hosts file etc.). One quick thing to try is to pass -b 0.0.0.0 as an argument to the run.sh script – this tells JBoss to listen on all addresses, which might help you figure out where the issue is.

Step 10 – Setup JBoss Portal as a Service

I opened the file $JBOSS_HOME/bin/jboss_init_redhat.sh in an editor.

First I double checked the environment variables set at the top of the file (particularly JBOSS_HOME and JBOSS_USER) were correct.

Then at the very top of the file, below the shebang line, I added the following 3 lines to make the script compatible with the chkconfig system

Don’t wait! The early bird pricing is still available! Only $1799 for a
regular registration – and many discounts are available. See
http://agile2009.agilealliance.org/ “Registration” tab for more details.

Agile software development was defined from small, colocated projects in
the 1990s. It has since spread to large, distributed, commercial
projects around the world, affecting the IEEE, the PMI, the SEI and the
Department of Defense. Agile development now sits in a larger landscape
and needs to be viewed accordingly.

Jared Spool will give keynote “The Dawning of the Age of Experienceâ€

Experience design is no longer a nice-to-have luxury of a few
organizations with tons of money and exceptional visionary management.
Itâ€™s become commonplace for organizations that build products and web
sites. In his usual entertaining and insightful manner, Jared will talk
about what it takes to build a design team that meets todayâ€™s needs.

More info on the keynotes http://agile2009.org/keynotes

Agile 2009 is the premier international Agile conference. The full
program has just been announced, and you can see all of the sessions
listed here:

http://agile2009.org/programOverview

Show your support – Get a cool badge for your website or blog! When
visitors click on it they’ll be directed to the Agile Alliance home
page. Get your badge here

How many times have you been writing a piece of code and thought “Oh, that piece is going to be tough, I will put a dumb version in for the moment and come back and put the complete version later”. Probably often. Particularly if it is near the end of the project.

Usually this choice seems pretty benign, in fact it is second nature to most developers. But what are the issues with this approach?

The reality is that very few people ever get to go back and fix poorly written code. Even with the hype on refactoring these days, it really is not a widely spread practice (yet). Projects get pushed out the door prematurely to meet the almighty deadline and the team moves straight on to either the next version or the next project. In fact it is probably fair to say that if you have a bunch of time to be refactoring (assuming you are working on a “traditional” project where refactoring is a luxury at the end and not an everyday occurrence) that you are probably on a downward spiral in terms of job security. Your team should be 100% committed all the time – any other situation is probably a bad sign.

So what’s an engineer to do? Simple, just get it right the first time.

Getting it right the first time is actually spectacularly difficult for a whole bunch of reasons, many of which the engineer has no control over. What seemed perfectly logical will at some point turn out to have been a total waste or miscalculation. This is one of the main reasons the agile community has evolved. Agileists accept that getting it right straight off the bat is difficult, so they follow practices that limit the possible wasted effort by getting feedback early and often so they can more quickly identify when things are going wrong and change course quickly.

If you don’t have the luxury of working in a progressive company where agile techniques are embraced, you really have to be able swallow some hard truths. The biggest of which is, be careful what code you write as it will likely end up in a production environment and once that happens you will likely be supporting it for a long time, perhaps years or even decades. I once read a story (I forget where, someone please let me know if this sounds familiar), about a development team that wanted to ensure they did not commit too early to any technology or give customers false impressions about how much progress had been made, so what they did was literally prototype the UI experience with the customer using cutout felt squares and pinned them to a board and rearranging them until the customer had what they needed.

So think about what you are writing, quality is something you need to worry about now, not just during the QA phase of your project. And quality is more than just whether the code meets the functional requirements without setting the computer on fire. Quality is everything from following your teams coding conventions and code documentation, to extensibility and maintainability.

So if you are in an agile team, realise that the higher the quality of the code base, the more value it has to your company and/or your customer. To that end, refactor mercilessly. If you work in a traditional team, before you write a single line of code, think to yourself “would I want to maintain this piece of code I am thinking of writing” because that is exactly what you will be doing if you write it.

JavaOne 2012

CON8122 - Amazon Web Services for Java Developers

Abstract: Amazon Web Services (AWS) is an ideal platform to develop on and to use for hosting enterprise Java applications. The zero up-front costs and virtually infinite scalability of resources enable Java EE developers to start small and be confident that their infrastructure will grow with their application. In addition, the nature of AWS and the services available help solve some of the problems Java developers often face in more-traditional environments. In this session, you will be introduced to AWS concepts, gain an understanding of how existing Java EE applications can be migrated to the AWS environment, what advantages there are in doing that, and how to architect a new Java EE application from the ground up to leverage the AWS environment for maximum benefit.