I first noticed it when doing the following:

1. Searched for a solution to some obscure (often Notes-related) issue.
2. Accidentally hit a result for a site that requires registration and/or payment.
3. Immediately hit the back button.

If now that, if you press the back button quickly enough, Google will show a "block this site" link under the result you clicked on.

Or you can try and manually add sites at this page (?) if you're logged in to Google.

I'm in the process of writing code to loop all messages in a Notes inbox, so I can examine their content. Now, consider this document and its Body field:

The Body field is obviously MIME, right?

As confirmed by ScanEz.

If you were to run the following code against the above document, what would you expect to see?

Item item = document.getFirstItem("Body");

if (item.getType()==Item.RICHTEXT){
    System.out.println("Item is Rich Text");
    
} else if (item.getType()==Item.MIME_PART){
    System.out.println("Item is MIME");
    
} else {
    System.out.println("Item is another type");
    
}

Now, I'd expect it to say it was a MIME field. Wouldn't you? But it doesn't. It says it's Rich Text!

I put this down to a quirk and decided to ignore what it was telling me and just go ahead and examine the MIME parts directly. Here's the code I used at first:

session.setConvertMIME(false);

MIMEEntity me = document.getMIMEEntity("Body");

if (null!=me){
    System.out.println("FOUND MIME ITEM!");
} else {
    System.out.println("CAN'T FIND MIME ITEM!");
}

session.setConvertMIME(true);

Why on earth might Notes not be able to find a MIME field when it's obviously there and why might it consider it Rich Text instead? It's driving me spare.

UPDATE: Found the Solution

Ok, here's why it happens. If you combine the two code snippets above, like so:

Item item = document.getFirstItem("Body");

if (item.getType()==Item.MIME_PART){
    session.setConvertMIME(false);
        
    MIMEEntity me = item.getMIMEEntity();        
    if (null!=me){
        System.out.println("FOUND MIME ITEM!");
    } else {
        System.out.println("CAN'T FIND MIME ITEM!");
    }        
    session.setConvertMIME(true);
    
} else {
    System.out.println("Item is another type");
}

This won't work. The code will never get as far as the MIMEEntity bit as Item.getType() will never return MIME_PART.

However, this code will work:

session.setConvertMIME(false);

Item item = document.getFirstItem("Body");

if (item.getType()==Item.MIME_PART){
    MIMEEntity me = item.getMIMEEntity();        
    if (null!=me){
        System.out.println("FOUND MIME ITEM!");
    } else {
        System.out.println("CAN'T FIND MIME ITEM!");
    }        
    
} else {
    System.out.println("Item is another type");
}

session.setConvertMIME(true);

It all comes down to where you turn off MIME conversion for the session. It needs to happen before you look at the types of any field. Makes "sense". I guess. In a kind of it doesn't really kind of way.

Tim's the engineer for a local radio station and is responsible for making sure - amongst other things - the station stays on air. He wants a way to monitor the output level of the station's signal remotely. So he's bought an Arduino kit and written a "sketch" file to have it monitor audio signal levels via a 3.5mm input jack.

The Arduino board has a network connection and the plan is to put it on their network and it give a publically resolvable IP address. The Arduino board will respond to a HTTP request with a text/plain response that contains a number from 1 to 20 that is a measure of the output at that moment.

What Tim wants me to do is write a web front end to this. It needs to regularly "ping" the Arduino board to get the output signal and make some kind of visual indicator of historic output. If it drops to 0 for any length of time then he's got an issue. Either the Arduino has packed up or station is off air.

This is the kind of geekery I enjoy and I'm looking forward to getting stuck in to it. The Arduino in the shot above is in my possession and I'm free to mess about with it as I please.

Also on my to-do list is to make a website for Quinn's boyfriend's dad's driving school. He too has produced a "sketch" to show me how it should look:

Quinn's boyfriend is a talented artist and currently studying on a Computer Animation course at university. He must have gotten his talents from his mum's side me thinks.

Which website do you think I'll do first? Hmm....

I've replaced the MediaMates with a set of Companion 5s. They're a bit pricey, but I listen to music 8 hours a day, 5 days a week. The speakers I use are arguably as important a choice as the monitor. Well, that's the argument I made to my wife anyway.

The MediaMate's (which are on ebay if you want them) were always good speakers, but the Companions have blown me away (almost literally until I turned the "bass compensation" knob down). I can't believe the difference. Probably made by the subwoofer - sorry, "AcoustiMass Module" - under my desk.

I'm not an expert in acoustics but have an appreciation for what - to me - seems like a decent sound. If you read in the forums, which I don't, then you'll hear a lot of bad stuff about Bose. Over-priced and cleverly marketed, apparently, which may be true but they've got me. I get "brand blindness". Once I've bought something I like then I'll only ever buy another of them from the same company.

If you want to test out your speakers here's a good track. If they can't handle that you need a new pair.

In trying to catch up with the pace I posted on Friday about how I'd funked-up the search box. Not wanting to stop there I've now taken it a little further and converted as much of the site's markup to HTML5 as I dare.

The general structure of a page is now like this:

<!doctype html>
<body>
 <div id="container">
  <header>
   <nav>
    <ul></ul>
   </nav>
  </header>
  <section id="side">
  </section>
  <section id="content">
   <article></article>
   <article></article>
   <article></article>
   <article></article>
  </section>
 <footer>
  <nav>
   <ul></ul>
  </nav>
 </footer>
 </div>
</body>

If you're left wondering what all these new HTML elements are then worry not - they're simply new HTML5 elements. Most of them are simply used where you'd normally use a <div> but they give the markup more semantic meaning.

I now feel a bit better about the state of site.

Backwards Compatibility

Nothing's ever simple is it. To make sure these changes were backwards compatible I had to do two things.

First I had to add the HTML5Shiv trick, which uses conditional comments to load an extra JavaScript file for IE8 or less:

<!--[if lt IE 9]>
<script src="//html5shiv.googlecode.com/svn/trunk/html5.js"></script>
<![endif]-->

Can't say I'm over the moon that my site now needs JavaScript to make the CSS work, and I've always liked that fact that one code-base rules all browsers, but I don't want to be held back by old browsers.

At some point in the future I'll remove the above Shim trick and remove "support" for <IE8.

The other thing I had to do was add the following CSS to make sure older browsers like Firefox 3.6 understood what these new elements were.

article, aside, canvas, details,
figcaption, figure, footer, header,
hgroup, nav, section, summary, video {
    display: block;
}

All done.

This week - in a moment of boredom - I decided to spruce it up a little and now it should look like this:

Whether it looks like that for you or not depends on the browser you're using. If you're using a modern and capable browser it should. If not you might see something like this:

Either way it should still be obvious what it is without the field label or the "Go" button?

How'd I Do That?

Simple. First I changed the HTML markup to use a little HTML5:

<form method="post" action="search?CreateDocument">
        <input type="search" placeholder="Search" name="Query">
</form>

I've highlighted the key parts. Adding the placeholder attribute is what puts the "Search" text inside the field and removes it when clicked on (no JavaScript required!). That's a new HTML feature and you can use it on any input field.

Then I added some CSS3:

input[type="search"] {
        padding: 4px 6px 4px 23px;
        border-radius: 10px;
        background: white url(images/icons/search.png) no-repeat 2px 50%;
        -webkit-appearance: none;
        border: 0;
        -webkit-box-shadow: inset 0 1px 2px rgba(0, 0, 0, 0.4);
        -moz-box-shadow: inset 0 1px 2px rgba(0, 0, 0, 0.4);
        box-shadow: inset 0 1px 2px rgba(0, 0, 0, 0.4);
}

input[type="search"]:focus{
	outline: none;
}

The last rule in the code above is to stop the field getting and orangey outline when the user clicks inside it.

And that's all there was to it really. Next time you add a search field to a form why not consider using a similar approach?

When coding I try and follow the DRY approach but with CSS am usually "happy" to duplicate rules over and over; copy and pasting all over the place until CSS files become unmanageable.

Writing CSS if no fun! Especially when you get to the nitty gritty of vendor-specific stuff in CSS3 like border radiuses, background gradients and drop shadows. If you plan on embracing CSS3 then you might want to read on for a better way to code CSS.

A Better Way

Writing CSS should be more like programming - with variables, methods and the like. This is where LESS steps in - calling itself a "dynamic stylesheet" - it lets you use variables, operators, functions and arguments.

LESS is how CSS should have been implemented in the first place!

Show Me Some LESS

Here's a basic example of some LESS code:

@the-border: 1px;
@base-color: #111;
@red:        #842210;

#header {
  color: @base-color * 3;
  border-left: @the-border;
  border-right: @the-border * 2;
}
#footer { 
  color: @base-color + #003300;
  border-color: desaturate(@red, 10%);
}

When the above code is passed through the LESS "compiler" you get the following CSS out the other end:

#header{
 color:#333333;
 border-left:1px;
 border-right:2px;
}
#footer{
 color:#114411;
 border-color:#7d2717;
}

Perhaps that's enough to convince you of the need to use LESS? If not, read on.

Getting a bit more advanced let's look at another example:

input{
 .border-radius(8px);
 .inner-shadow();
}

The CSS outputted for the above LESS code is:

input{
    -webkit-border-top-right-radius:8px;
    -webkit-border-bottom-right-radius:8px;
    -webkit-border-bottom-left-radius:8px;
    -webkit-border-top-left-radius:8px;
    -moz-border-radius-topright:8px;
    -moz-border-radius-bottomright:8px;
    -moz-border-radius-bottomleft:8px;
    -moz-border-radius-topleft:8px;
    border-top-right-radius:8px;
    border-bottom-right-radius:8px;
    border-bottom-left-radius:8px;
    border-top-left-radius:8px;
    -webkit-box-shadow:inset 0 1px 2px rgba(0, 0, 0, 0.4);
    -moz-box-shadow:inset 0 1px 2px rgba(0, 0, 0, 0.4);
    box-shadow:inset 0 1px 2px rgba(0, 0, 0, 0.4);
}

Which would you rather maintain - the LESS or the CSS? If you want to change the border radius to 6px you'd have to do it in about a dozen places in CSS, compared to 1 place in LESS. Sold on the idea yet? You ought to be!

In the LESS code above the .border-radius() and .inner-shadow() bits are what's known as "mixins" in LESS parlance. You can write your own mixins but I just downloaded a load of predefined ones called "LESS Elements". This gives you a file called elements.less which you need to include in your LESS code before using the mixins. So the LESS code I pasted above should actually have been this:

@import "elements.less";

input{
 .border-radius(8px);
 .inner-shadow();
}

For a good example of advanced use of LESS download Bootstrap and take a look at how they organise their LESS files and how it all works.

If you do any decent amount of CSS coding then I'd say it's worth your while looking at how using LESS could help with that. I love it!

I've only really scraped the surface of what it can do in this post. To get a better example, take a look the LESS website and the Bootstrap code.

Where to Write LESS?

The best way I've found to write LESS code and compile to CSS is with the Crunch App, which you can see below:

There's a .Net library with which you can write LESS directly in Visual Studio and have .Net produce a cacheable CSS file from it - on the fly!

If you're a Domino developer then you'll have to resign yourself to the idea of maintaining the CSS outside of Domino Designer. Although I guess you could use WebDAV to save CSS files directly in to the NSF? That's a rainy day project I guess...

While any browser will do (but Chrome is IMHO the best) you really need to check out ScanEz!

My love of ScanEz is in no way influenced by the fact they gave it me for free. I say it because I genuinely think you'll be better off once using it. My promotion of it is like a public service kind of thing.

Imagine for a second that you do use both. Wouldn't it be nice to link them? To have a button that magically appeared in Chrome when viewing a Domino website, which, when clicked, opens ScanEz straight to the document you're currently viewing in Chrome.

Like this:

For me this is a massive time-saver. If you like the idea you can get it for yourself here.

Here's a quick video of the concept:

Over-Coming Hurdles

It wasn't long after I started working on this that I realised there were two flaws in the idea. Firstly that the hostname used in URLs doesn't always match the actual name of the Notes server. It needs to in order for ScanEz to connect.

As an example, www.codestore.net is hosted on a server called domino-99.codestore.net and ScanEz can't find a route to www.codestore.net but can to the latter. So I added an Options pages for the extension which lets you add a hosts-like list of mappings:

The other hurdle was that not all URLs to Domino document have the document UNID in them. For these cases I had the extension look for a special Meta tag in the HTML of a page, which would look like this:

If it finds this meta tag it knows where to send ScanEz to. Problem solved.

If you're not excited by this then you obviously don't know how brilliant ScanEz is and what you're missing out on. That's a topic for another blog entry though...

The major benefit of this - for me at least - is easier debugging. I use ScanEz day in and day out for all sorts of tasks. If you haven't tried it you really should. As I've said many times before I couldn't get by without it. Well, I could, but...

Debugging Web Documents

When working on a Domino web app I often need to take a look at all the fields stored on the document and this is where ScanEz comes in. To get to see a web document in ScanEz here's what I normally do:

1. Copy the document's UNID from the URL.
2. Tab to Notes and click on the database's icon in the workspace.
3. Click the ScanEz toolbar icon.
4. Press F6 to open the "Search by UNID" dialog.
5. Paste in the UNID in question to open the document.

It works but takes time. Now that we have a scanez:// URL I can just add links to documents, like the one below:

I added the link like this:

The link in the above screenshot points to the following URL:

scanez://tyne/8025740000797E3D/0/4B4D390AE16FCDFB80257981003A00BD

Once clicked it opens ScanEz automagically to the document itself as below. Brilliant!

Notice that I've selected the option to enable the scanez:// URL from the Tools menu!

Practical Use

To make practical use of this I'd probably hide a button like it in the footer of a database but either remove it before going live or (probably better) hide it using an [Developer] role and an isDeveloper field.

Then I realised what had happened. A couple of minutes before I'd mopped up a spillage after one of the kids knocked over a jar of olives on the kitchen worktop. The "brine" from which had trickled down the back of the worktop and in to an electrical socket beneath. Ten minutes with a hair dryer on it and everything's back up and running.

Meanwhile, out in the office, this series of 5 or so power outages in the space of half an hour was more than my Mac Mini could handle and it was now refusing to start. Only after a PMU reset could I get it to boot and - when it finally did - the fan was running full speed making it way too noisy to serve its primary purpose as an iTunes jukebox.

To add to my stress levels the laptop needed a hard reboot as well (the docking station doesn't like losing power) and it too refused to boot following this. Only after a couple of attempts did it finally boot. All this at the same time I'm in an email exchange with a customer I'm trying to fix a "top priority" bug for. Needless to say I was a bit stressed out.

To make sure this never happens again I did two things:

1. Sealed around the edge of the electrical socket in question with some decorator's caulk.
2. Made sure the docking station and Mac Mini were supplied by one of the two UPS units in the office.

Everything in my office is now running with a backup power supply!

From what I can gather on the forums the noisy fan issue is not un-common on Mac Minis and there's no known fix. I'm now on the market for a Mac!

On the plus side, at least I don't need a new fridge. I'd much rather be buying a new Mac than a boring old fridge any day. I "needed" a new Mac anyway...