Setting souls ablaze

Let’s start by fast-forwarding to the end of the talk. Right before the very end of the talk, Michael quotes Alexander de Sainte-Exupéry:

“If you want to build a flotilla of ships, you don’t sit around talking about carpentry. No, you need to set people’s souls ablaze with visions of exploring distant shores.”

I haven’t been able to find references to the quote anywhere else (yet), but even if it would have been Michael himself who made it up, I am still totally happy with it. I do believe this quote captures one of the essential virtues of people leading teams in a (software) company. People who are not able to ‘set people’s soul ablaze’ should not be in front of a team, as far as I’m concerned. Period.

Should we really eliminate waste?

Michael’s talk also raised another question. I have been working on agile adoption for years in a row now, and until today, I considered ‘eliminating waste’ a vital attitude for running a healthy development process. You don’t want waste; you want working software instead.

However, Michael’s talk makes you wonder if reducing waste isn’t really just sub-optimimizing it. He basically promotes: “shifting from a linear, wasteful, polluting way of using resources to a closed loop model”, and shows how waste created by one natural process often can be fed back into another natural process to grow something else. (Like using the waste of coffee grains as a substrate for growing mushrooms.)

Now, I am sure this not new to any of you. He just has better examples than you have ever seen before. But it made me wonder if there might be a counterpart to this in our industry as well. I mean, not creating any waste at all seems like the ultimate goal, but could it be that there is a way in which we – instead of focusing on getting rid of it, just for sake of getting it out of our system – could feed it back into our system in an efficient way? (And then I don’t mean reusing paper copies of pointless documents as cat litter.)

Honestly, I don’t have the answer. It seems like a crazy idea to consider in our industry. But perhaps the environmental guys are ahead of us. It might be worth to consider it for a while, since we spend quite a bit of energy getting rid of it.

This is how Michael says it:

“But perhaps more than anything, what this thinking provides is a really positive way of talking about sustainable design. Far too much of the talk about the environment uses very negative language. But here it’s about synergies and abundance and optimizing. And this is an important point.”

It seems to me that if we would be able to shift our focus in a similar way, there might be some room for further optimization.

Roger Bodamer from 10Gen, the company that develops and supports MongoDB, has agreed to come speak about all things MongoDB on Wednesday February 16th, at Xebia in Hilversum. We will start with a basic technical introduction to MongoDB but Roger knows MongoDB inside and out so feel free to suggest topics that you would like to hear more about. Of course there will be a Q&A at the end.

For more information about Roger and 10gen, have a look at their team page (he’s third from the top).

Note that we need to put a limit on the number of registrants, so if you considered joining, register now. You can register at the Dutch NoSQL Meetup page found here.

Say what?

Have you ever been in a position in which you had a lot of useful content inside Confluence, but you did not necessarily want it to be published out there as a Confluence web site, with all the bells and whistles it offers. If you were in that position, then the Deconfluencer might be just what you need.

The Deconfluencer is doing exactly what you would expect from its name. It takes a Confluence space, and republishes it, stripping off everything you don’t want, and rewriting the bits you want to have rewritten.

Let’s look at an example. Suppose this is your Confluence page:

Then the Deconfluencer could turn it into something like this:

Same contents, just rendered differently.

How does it work?

The Deconfluencer is simply a reverse proxy with some built-in transformation logic. (And some other features that come in handy when republishing Confluence content.) It’s not a war. It’s simply a commandline tool that – once started up – listens on a certain port, forwards incoming requests to Confluence, transforming  the results before sending it back to the browser.

I don’t like your look and feel

Well, rightfully so. The good thing is, you can transform the Confluence page in any way you like. If you unzip a Deconfluencer distribution, you will find a conf directory with a filter.xsl file, and a resources directory containing static resources, such as CSS and imagery. To start with the latter: if you only want to change the CSS, then you simply change the style.css file, and you’re good. However, if what you want to do is a little bit more involved, you need to adjust the filter.xsl file.

The filter.xsl XSLT template is used to transform the page coming from Confluence into the resulting page. It is this file that actually generates a page header that points to the resources found in the resources directory I mentioned before. However, it also has some basic templates to filter out contents you probably don’t want to see. In order to be able to transform an HTML page using XSLT, the Deconfluencer first transforms the incoming XML into a DOM.

That sounds like a painful exercise

Well, it may sound that way, but it really isn’t. Once you started the Deconfluencer, you can simply update the filter.xsl file on the fly, and check out the results immediately after hitting the refresh button. Rest assure, the Deconfluencer will not load the template from the file system for every request. Instead, it will monitor the conf directory and only reload the filter.xsl file if the file was changed.

Overwriting existing files? I don’t want to do that!

Then you don’t. You don’t have to. You can also start the deconfluencer and point it to alternative locations. Simply run the deconfluencer without any options, and it will tell you which options you have to use. Just for sake of convenience: these are the commandline parameters it currently supports:

 -b BASE URL   : The base URL of the URL space we want to deconfluence.
 -f FILTER     : The location of the XSLT filter to be applied. (Defaults to con
                 f/filter.xsl.)
 -n PORTNUMBER : The portnumber on which the reverse proxy will run (8082)
 -o NAME=VALUE : Parameters to be passed to the transformation
 -p PASSWORD   : The password used to authenticate to Confluence.
 -s PATH       : Location to be used for serving static resources. (Defaults to
                 resources/.)
 -u USERNAME   : The username used to authenticate to Confluence.
 -v            : Verbose mode. Logging data to std err.

Enough about that; where can I find it?

The Deconfluencer project is hosted on Github. You can download the sources and build it from scratch, but I have to warn you that JNotify is not listed in one of the central Maven repositories though, so you probably need to install that yourself. Alternatively, you can download a distribution from Github directly, by pointing your browser here.

What’s missing?

There are certainly some things that could be improved. Like, currently it’s not dealing with attachments in a useful way. As a result, images you have on your Confluence page will most likely not show up correctly. It will not require a major overhaul, but it’s certainly something that would be nice to have.

Now, what do you think about all of this?

Does this sound sensible? Do you see other purposes for it? Feel free to comment, or – even better – just fork the project yourself.

A couple of weeks ago, I overheard a discussion between a couple of people involved in the music business. They concluded that the days of the megastars are officially over; they didn’t think there would ever be another artist rising to the same levels of stardom as Madonna, Elvis, Michael Jackson or the Beatles.

The Music Industry

The reason why these people from the music industry figured there’d never be anything as big as the artists mentioned, ever again, is because of the Internet. It just has never been as easy as it is today to share music. I can put something together in an afternoon, and have it available on Bandcamp or Facebook that same night. And if it’s any good, it will spread like wildfire.

But, hold on, it has not only become way easier to put something out there on the Internet. It also became much easier to pull something down from the Internet. I recently switched over to Spotify. Even though I have a convenient setup that allows me to listen to my (legally acquired) MP3 all over my place, I haven’t touched it since then. And before that, I tried Last.fm for a while and found a load of new artists. The collection of music I listen to has grown significantly, last year. (As an example, I found about the “Wifi?” song through Facebook. A song right from the heart for many of us, I’m sure.)

Back in the days, both the artist and the listener depended on the record labels to tie supply to demand. That basically acted as a big funnel. In went all artists, out came the ones that were most likely to generate a lot of money. For a record label, it made way more sense to have one world-famous artist, than having several targeting a smaller audience. Because of that, some artists got all the exposure (radio, TV) and others hardly any at all.

The Internet has changed that. It basically short circuited this relationship, and boosted the supply.

The Software Industry

Let’s assume for a while that there is some truth in all of this. I can imagine that marketing funding has contributed a lot to putting some artists in the spotlight, and keeping others out in the dark. That seems to be exactly what happened to Java as well; only this time it wasn’t one single vendor, but a lot of them; and the same goes for SQL. (IBM, Sun, Hewlett Packard, Sybase, Oracle, etc.)

That doesn’t mean Java is awful or SQL is a piece of crap. Au contraire. It just means that because of critical mass of these big corporations, Java got more visibility, and therefore more momentum than any of its competitors.

It’s interesting that Java may actually both have profited and ‘suffered’ from the Internet. Java’s appearance coincided with the rise of the Internet. The first people enthusiastic about Java liked it because of its Internet potential. (I remember my boss at Sun saying that, one day, his friend passed by and showed him Java tooth tumbling inside an Applet; that’s the day he applied for a job at Sun.)

These were probably also the people who started to talk about their ideas on how to use Java in new ways. Java dates from 1995. Sourceforge from 1999; it now provides a home for 45,186 Java projects. (And remember, they got some competition since then: Github, Java.net, Codehaus, Apache, etc.) At OOPSLA 2004, in Vancouver, all posters where about Java, with the exception of the ones that were not about programming at all. Sharing has been the basic attitude of the Java world, and that – I feel – contributed a lot to its popularity.

The same also goes for having other languages running on the Java VM. And in that sense Java (the language) also ‘suffered’ from the Internet. The first other language running on the Java VM might have been Ada (back in 1996), but now it’s hard to keep up with the numbers: Clojure, Scala, Jerlang, JRuby, Mirah, JavaScript, and I could go on for a while.

So, the genie is out of the bottle. People got used to polyglot programming, and no marketing budget will ever be able to make any more noise than the buzz coming from the community directly. Again, it’s not unlike the demise of the music industry. The Internet short circuited supply-demand both in the music industry as well as in the software industry.

And alternatives to Java on the Java VM are not the exception. The same goes for storage solutions. Back in the days, the only real option for storing your data used to be a SQL database. (In fact, in many cases, the only option used to be Oracle or DB2.) But since then, people started to scratch their head, wondering how on earth SQL solutions would solve their scalability problems, and came up with other, sometimes simpler ways to store their data. And then, they spread it through the Internet.

Conclusion

In summary, it seems our world is coming to a joint conclusion that Java and SQL are no longer the only options out there. Phew! That’s a breeze of fresh air! I therefore declare this year to be the year to celebrate the “No” movement: NoSQL (Not only SQL), NoJAVA (Not only Java) and – well – basically No[you name it] (Not only ‘you name it’). Back in the days, all we had was NoCHOICE. But now we have. Let’s take advantage of that.

The image that pops up in my head when I think about NoSQL and alternative languages on the Java VM (and the music industry) is one of a lava lamp. Down at the bottom, you see blobs of wax trying to cut loose to make their escape. Often they get pulled back, only to settle back at the bottom and wait for a new opportunity to make their way. It sort of reminds me of the big corporations and monumental industry standards preventing creative ideas to escape. But now, the old industry seems to loose its grip. The knot is slipping. Many bright ideas managed to cut themselves loose and have crossed the chasm. It’s unlikely that anything will be able to pull them back now. Welcome to 2011. Up, up, and away!

(And for that reason, it might also be good to mention the NoSQL NL meetup scheduled for January 24, the Dutch Scala Enthusiasts, and the Clojure meetup. If you want to learn more about your options, it might be good to drop by somewhere soon.)

Before going into that, first a short message to anyone who feels like XML or JSON are the only data encoding formats we will ever need:

WAKE UP!!! Only a fraction of the data on your hard disk is encoded as XML or JSON. A lot of it is binary encoded data. How would you feel about not having images, mp3, videos, PDFs and Word documents (well that would be ok, I guess)? If you really think that text-based formats are all you will ever need, then you can kiss all of that goodbye. So, with that out of the way, now read on.

Binary data is there to stay. In fact, a large part of the world evolves around binary encoded data. (The Internet for instance. TCP-IP packets are not XML documents, although there has been an RFC suggesting something like that in the past.) In fact, with the rise of NoSQL, the importance of having better ways of dealing with binary encoded data has probably only increased. (Many of these databases store arrays of bytes, and leave it up to you to reconstruct that into something useful.)

The agony!

Unfortunately, dealing with binary encoded data is not all that easy. Even understanding what is getting decoded and why can be extremely hard. On the plus side, we do have tools such as hexdump and hexl-mode (Emacs), but the output of hexdump -C will only be meaningful to a few people. For the rest of us, we still need to work really hard to understand what on earth is represented by the binary encoded representation.

Here is the top of a Java class file, presented with hexdump -C, as an example:

00000000  ca fe ba be 00 00 00 31  00 2b 0a 00 0a 00 1d 09  |.......1.+......|
00000010  00 09 00 1e 09 00 09 00  1f 07 00 20 0a 00 04 00  |........... ....|
00000020  1d 0a 00 04 00 21 0a 00  04 00 22 0a 00 04 00 23  |.....!...."....#|
00000030  07 00 24 07 00 25 01 00  03 66 6f 6f 01 00 12 4c  |..$..%...foo...L|
00000040  6a 61 76 61 2f 6c 61 6e  67 2f 53 74 72 69 6e 67  |java/lang/String|
00000050  3b 01 00 06 4c 4f 4e 44  4f 4e 01 00 0d 43 6f 6e  |;...LONDON...Con|
00000060  73 74 61 6e 74 56 61 6c  75 65 08 00 26 01 00 03  |stantValue..&...|
00000070  62 61 72 01 00 01 49 01  00 06 3c 69 6e 69 74 3e  |bar...I...|
00000080  01 00 16 28 4c 6a 61 76  61 2f 6c 61 6e 67 2f 53  |...(Ljava/lang/S|
00000090  74 72 69 6e 67 3b 49 29  56 01 00 04 43 6f 64 65  |tring;I)V...Code|

As I said, it does provide some help, but not a lot of help.

But what if

But wait, if the computer knows how to decode this into something useful, why isn’t it able to provide some more insight in what I’m looking at? I mean, it’s quite a lot of work to interpret the above. Why isn’t a computer capable of annotating it, in order to help me understand what it says here?

The good news is: now there is a way to get that. Last year at OOPSLA, I presented Preon (now a codehaus project), a framework that captures the mapping of the in memory representation and the binary encoded representation in a declarative way. Preon is capable of giving you a decoder and encoder for free, and it also used to be able to generate documentation on the encoded representation.

But now, there is something new: in the next release, you will have the ability to – while you are decoding data – output an HTML document that clearly explains how the in memory data structure is represented in its encoded representation! Here is an example of exactly the same Java class as shown before. (Click to jump to the live page.):

As you can see, you can just move your mouse around over the page. Once it hits a byte that it knows about, it will highlight the bytes that together make up a data element, and show meta data on the side, including the value from these bytes.

Done?

Now, this is far from done. There is plenty of more stuff that will be added, such as a better presentation of the metadata, and an explanation, showing the dependencies between the decoded data and other parts of the encoded presentation. But it does show one of Preon’s strengths: by capturing the metadata on the mapping between the encoded representation and the in-memory representation, Preon is capable of explaining what is getting decoded. None of this was present in Preon before. Everything has been added to the framework without changing an existing line of code.

The version of Preon capable of doing this, currently resides on Github.

Just a heads-up for everyone interested in NoSQL: the next NoSQL Meetup meeting will be held at VPRO’s headquarters, on Tuesday September 21, next week. Nils (VPRO) will talk about the adoption of CouchDB at VPRO, and Paul guide us through the remainder of the Dynamo paper. (So if you haven’t read it yet, check it out here.)

If you feel like joining in as well, find the meeting details here. Make sure you register though; we want to make sure we have enough space to fit in everyone.

Fifteen years ago, at the end of the two-tier client server age, people started to realize the importance of distinguishing between at least three different layers in the architecture. A business layer, providing a convenient API allowing you to address a particular business concern, a data layer storing related data, and a presentation layer providing a convenient user dialog on top of the business logic.

At some point, it became apparent that modularizing like this was not going to cut it. We needed to modularize the business tier and create ‘services’ addressing particular concerns. This is what we ended up having:

In our new world, we did have services with clear interfaces, and these services communicated through each other through clearly defined interfaces (either local or remote). However, we were cheating. In most cases we couldn’t figure out how to preserve consistency without relying on the convenience provided by SQL solutions, so we allowed for some ‘integration’ at the data layer; that is, we stored all data in a single database, and essentially faked isolated services on top of that. And then – since we still needed to be able to present a single integrated user interface – we created a single presentation layer component that pulled in everything it needed from the business logic below.

The rise of SOA essentially caused us to focus on service boundaries even more. And although we had different schools of thought – and there were actually quite a few folks who felt like service oriented had nothing to do with web services – the focus started to shift from a modularization problem to a remote integration problem. So it was essentially about pulling the different things already identified even further apart.

Now, if you pull services apart like illustrated above, the link to a single data store is obviously going to hurt. So a good thing about everything that happened back then is that everybody started to feel the pain of linking to a shared data store. The technical complications forced people into making services have their own data layer, and drop ‘integration’ on a data tier.  It might not have been the ideal reason for doing it, but the net effect was this:

This is when people also started to realize that ACID wasn’t going to cut it in the long run, and we should consider other was to preserve consistency, paving the way for NoSQL and spreading the word on compensating transactions and idempotence.

So what do we have now? On the plus side, we do have services that are pretty much isolated from each other (good!). However, the integration with the UI is still pretty much one big blob. And for some reason, that is considered quite ok. But is it really? In many cases, the dependencies between the presentation layer and the business logic layer are pretty tight.

Let’s take a payment service as an example. Whatever the payment service will require from the user to enter, obviously needs to be entered in the presentation layer. Replacing one payment service with another type of payment service will most likely have big implications on the presentation layer. At the same time, the rest of the dialog offered to the user probably is completely independent of the dialog presented when dealing with the payment service.

So, if we feel strongly that services should be isolated from each other as much as possible (free interpretation of Parnas) and keep what needs to be exposed to an absolute minimum, why not cut the presentation layer apart as well?

Presentation layer service integration

For some reason, the idea of presentation layer based integration doesn’t land very well in a world once dominated by the WS-flavor of SOA. However, mashups are omnipresent on the Internet. It’s just often not considered as a way to do integration of services within a single system in a single organization.

Organizing your service oriented architecture as outlined above bares some resemblance to the ideas expressed by Allen Holub more than a decade ago, but then applied on a larger scale. The central message in his article was to prevent objects from exposing too much of their own internal state by making objects responsible for providing a UI representation of themselves. That sounds like a horrible idea according to the model that promotes strict separation between presentation layer and business logic layer, but I think it makes perfect sense in a service oriented architecture.

Back to the payment service example: let’s assume for a minute that the left-hand service is a shopping service (including the presentation layer dialog with the user) and that the right-hand service is the payment service. Integrating the services would require some integration on the presentation layer as well as the business logic layer.

When the user selects a payment method associated to a particular payment service, the payment service’s presentation layer should be pulled up, passing clues on what to do after the payment succeeded or failed. From that point on, the payment service itself is in control of (part of) the dialog.

When the payment is cleared, the payment presentation layer will hand back control to the shopping service’s presentation layer. However, the business logic layer might communicate more information on the status of a payment through the SPI defined by the shopping service. (Like settlement related information.)

Consequences

By considering the presentation layer to be part of the actual service, you introduce a couple of new degrees of freedom. First of all, depending on how the integration in the presentation tier is done, you might have the option to have part of the user dialog executing in the same address space as the business logic. Instead of having to do several remote calls for pulling together all data to be presented to the user, the presentation layer would do all of these calls internally and then ship the resulting presentation to the place where it will get integrated with the other presentation part components. It could give you the option to enjoy the benefits of spatial locality.

Another benefit that was already mentioned before is the fact that you can easily rip and replace a service. You only have to worry about the presentation and business logic layer interfaces, not about what’s actually happening behind those interfaces. Think Field Replaceable Units (FRUs) but then software.

Counter arguments

The counter argument for presentation tier integration is that you would basically have to redo the presentation layer interfaces for every new type of presentation you are targeting. I tend to disagree, and since this is just a blog post, I’m going to try to walk away from it by just asking for some proof of that first.

Implementation

In “Understanding UI Integration” from 2007, the authors provide an overview of the UI integration state of the union. They basically talk about browser plugin components, mashups, portlets and WSRP (which would be one of the ways to achieve the spatial locality benefits outlined above). However, they state this:

“Although the efforts we’ve described here are certainly useful, we believe that effective standardization similar to that of standardizing service interfaces is needed for UI integration to really take off. In general we see a lack of abstraction to conceptualize composition-oriented features in the context of UI integration.”

I think that still holds today. There might be a few initiatives to push boundaries a little further (OpenSocial comes to mind), but there is no clear direction.

So what is your opinion on this? Do you consider services having a presentation layer interface malpractice or critical to true service oriented architectures? And if you do have services offering a presentation layer interface, what principles do you have in place to keep it all organized?

The Dutch NoSQL community is alive! Now, if you are new to NoSQL and you happen to have a Relational Database background, then rest assure: the NoSQL movement is not a militant group trying to get rid of SQL altogether. The N.o. in NoSQL represents: Not only. In the NoSQL community, we are looking at alternative ways to handle data (in particular big data), and it turns out there a myriad of solutions popping up these days, such as:

• Google Big Table
• HBase
• Tokyo Cabinet
• Cassandra
• MongoDB
• CouchDB
• Voldemort

… and this is only scratching the surface. So, there is plenty of stuff to explore and discuss. The Dutch NoSQL Community is getting people together to discuss these topics.

Our first mission is to be the Dutch host of the NoSQL Summer initiative: a seasonal, worldwide reading club for databases, distributed systems & NOSQL-related scientific papers. Because – as the Berlin group stated it – “What could be a better excuse to hang out in a sunny beergarden after work than to discuss dry CS fundamentals like Relational Algebra or Paxos with fellow geeks? Err … anyway, this is gonna be fun.” And fun it will be.

So, if your interested to join in and meet your fellow swimmers, we warmly welcome you to our first meeting, on July 1, in Amsterdam. If you consider joining in, please sign up for it now. (If you can’t make it to that meeting, but you would consider attending some other time, or if you just want to express your sympathy for NoSQL solutions in general, don’t hesitate, just join the group.)

In order to contribute my share of changing all of that, I just uploaded a single serving site, Scala Tribes, serving only one purpose: to provide an overview of all of these Scala user communities found across the globe. This should not only help you to find a local group of Scala users wherever you are; it will hopefully also serve as a way to integrate these disjoint isolated Scala communities.

Currently, it’s just a list of pointers, allowing you to directly jump to the various communities, to directly tap into their news feeds, or to keep track of the events they organize by accessing their calendars.

If you happen to be part of local Scala initiatives like these, then I would encourage you to send me some pointers. Currently, the list contains only to 15 user groups, but I am sure there is more. (Like, I am not capable of decoding anything but Dutch, English, and to some extent German. That means that anything in any other language escapapes my radar.)

Since every group in this list is associated with a woeid (Where On Earth ID), creating a map out of it turns out to be quite easy. The result is below. As you can see, there’s not too much coverage for Asia, Africa and South America yet. Perhaps you can be the first to add some pointers for those continents.

I would also be interested to hear other thoughts on this. Is there anything else that you would like to see?

Well, anyway. While staring at the rebranded front page, I wonder how they made the transition. I remember that – in the past – Sun went over a couple of rebranding efforts. Rather than actually changing the CSS classes in use, they would actually redefine those classes. But since most of the classes were for one sole purpose only – to set the color – they used the names of these colors as the names of the CSS classes.

So you would have a CSS class called purple. In order to adopt the new style, they just redefined purple to be yellow from now on. So the CSS would have something like this:

.purple { color: yellow; }

It turns out they did exactly the same thing for restyling the Oracle way: they replaced all color definitions to shades of grey:

/* table colors */table.dkgrey{background:#666}.sunred{background:#f00}.sunblue{background:#525252}.sunyellow{background:#a4a4a4}.sunred,.sunblue,td.sunred a,td.sunblue a{color:#fff}td.sunred b,td.sunred div.navtitle{color:#9f9f9f;font-weight:bold}td.sunred li,td.sunblue li,td.sunred ul,td.sunblue ul{color:#fff;list-style-image:url("../im/ic_bullet_white.gif")}td.sunyellow b,td.sunyellow div.navtitle,td.sunyellow a:link,td.sunyellow a:visited{color:#000}td.sunyellow a:hover{color:#666;text-decoration:underline}table.white,td.white,th.white,tr.white td,tr.white th,table tr td.white,table tr th.white,td.white,table.white1,td.white1,th.white1,tr.white1 td,tr.white1 th,table tr td.white1,table tr th.white1,td.white1{background:#fff}table.ltgrey,td.ltgrey,th.ltgrey,tr.ltgrey td,tr.ltgrey th,table tr td.ltgrey,table tr th.ltgrey{background:#ccc}table.vltgrey,td.vltgrey,th.vltgrey,tr.vltgrey td,tr.vltgrey th,table tr td.vltgrey,table tr th.vltgrey{background:#ddd}table.grey3,td.grey3,th.grey3,tr.grey3 td,tr.grey3 th,table tr td.grey3,table tr th.grey3{background:#e3e3e3}table.blue1,td.blue1,th.blue1,tr.blue1 td,tr.blue1 th,table tr td.blue1,table tr th.blue1{background:#999}table.yellow2,td.yellow2,th.yellow2,tr.yellow2 td,tr.yellow2 th,table tr td.yellow2,table tr th.yellow2{background:#fff}

It can’t help feeling there’s a message hidden here.