illcode.org

Disclaimer: I’m not a fan of VBA. It’s a necessary evil; the reality is that Office documents are everywhere within the enterprise, and VBA is the shortest path to pull value out of documents and into other places/formats.

I wrote up a nifty bit of VBA that applies cell values into a template to produce some basic brand-specific CSS.

Unfortunately, the code didn’t work on our designers’ machines, as they are using Office for Mac 2011 - which supports VBA, but not all(/any?) of the “CreateObjects” like “Scripting.FileSystemObject” or “ADODB.Stream”.

The solution is to use the old-school Open / For Input As / Line Input functions. Here’s a mapping of old to new - the old is commented out VBA-style (‘).

You won’t need your “fso” or stream handles, but we’ll include them here for posterity:

'Dim fso, inputStream, outputStream
'Set fso = CreateObject("Scripting.FileSystemObject")

You will need vars for your file paths and file handles:

Dim inputFilePath, inputFile, outputFilePath, outputFile

To open a file for reading, use “Open … For Input As”:

'Set inputFile = fso.getFile(inputFilePath)
'Set inputStream = inputFile.OpenAsTextStream(ForReading, True)
inputFile = FreeFile
Open inputFilePath For Input As #inputFile

To open a file for writing, use “Open … For Output As”:

'fso.CreateTextFile outputFileName
'Set outputFile = fso.getFile(outputFileName)
'Set outputStream = outputFile.OpenAsTextStream(ForWriting, True)
outputFile = FreeFile
Open outputFileName For Output As #outputFile

To read some lines, you don’t need a “stream”: just read them with “Line Input”:

Dim currentLine

'Set inputStream = inputFile.OpenAsTextStream(ForReading, True)
'Do While inputStream.AtEndOfStream <> True
'    currentLine = inputStream.ReadLine

Do While Not EOF(inputFile)
    Line Input #inputFile, currentLine

To write some lines, again you don’t need a stream - just write them with “Line Output”:

'outputStream.WriteLine currentLine
Print #outputFile, currentLine

To clean up, use the “Close” syntax:

'inputStream.Close
'outputStream.Close
Close #inputFile
Close #outputFile

Now, the big gotcha: if you’re working with text files, odds are the input file is Unicode-encoded with a Byte Order Mark (BOM) header.

Using these file ops to copy lines from one to the other will lead to a broken BOM header in the output, and make the file look incomprehensible (Chinese characters, in my case).

I couldn’t find any options to get Excel to handle encodings gracefully - my “fix” was to just skip the first line of the file, which works great! If you wanted to get clever, you could try to omit the BOM from output, but why bother?

Finally, one last trick: if you want to deal with relative file paths, you’ll probably be concatenating onto ThisWorkbook.Path . For that, you’ll need a delimiter; and it’s colon on OSX:

Dim fsDelimiter
fsDelimiter = "\"
If Application.OperatingSystem Like "*Mac*" Then
    fsDelimiter = ":"
End If

Be careful out there.

I attended Timmy Willison (@timmywil)’s presentation about jQuery Attributes and Properties.

I was really trying to understand the message; The following was clear to me:

• Don’t use .attr(‘value’) ever. Use .val()
• Don’t use .attr() to get a value that doesn’t appear in the DOM itself
• The “checked”/”selected” DOM attributes should be accessed via .prop(‘checked’, bool)

Roger, got it, over and out. Obvious stuff for the most part, and thanks for the tip on checked/selected.

The summary slide said:

Use the .attr() method for attributes and the .prop() method for properties. Often, they will be the same value, but if you want any current values, meaning if it can change with user interaction, use prop. In cases where it doesn’t make a difference, prop will be faster.

So it seems that you should use prop() if you can - and if you want to read values changed post-DOM-load, you MUST use prop() to get the updated value.

If that’s the case, under what circumstances would one ever want to use .attr(), if it’s slower and can return a stale value? For a DOM attribute that didn’t correspond directly to a property? Are there any besides “checked” and “selected”?

Edit 09 Feb 2012: “disabled” is a third.

…have I got the Sublime Text 2 theme for you.

Select Preferences > Color Scheme > Amy

Tone down the Side Bar by pasting the below in the following file:

/Users/yourid/Library/Application Support/Sublime Text 2/Packages/User/Default.sublime-theme

[
    {
        "class": "tree_row",
        "attributes": ["selected"],
        "layer0.opacity": 0.2
    },
    {
        "class": "close_button",
        "layer0.texture": "Theme - Default/cross_over.png",
        "layer0.opacity": 0.2,
        "layer1.opacity": { "target": 0.0, "speed": 4.0, "interpolation": "smoothstep" }
    },    
    {
        "class": "sidebar_tree",
        "row_padding": [8, 3],
        "indent": 15,
        "indent_offset": 15,
        "layer0.tint": [30, 15, 30],
        "layer0.opacity": 1.0
    },
    {
        "class": "sidebar_heading",
        "color": [192, 170, 192],
        "font.bold": true,
        "shadow_color": [0, 0, 0],
        "shadow_offset": [0, 1]
    },
    {
        "class": "sidebar_label",
        "color": [128, 100, 128]
    }
]

My current track of @droneage development is building a prototype UI for navigating a “sector map”, consisting of a number of solar systems.

Before I spend a single moment writing server-side code, I’m trying to get the UI as far as possible with static HTML and JavaScript.

As it turns out, I can go pretty far - my main “controller” class was up to 600+ lines of JavaScript, and getting difficult to maneuver around. It was a mishmash of 18+ methods for initialization, event wiring, canvas rendering, DOM manipulation, data model manipulation/transformation and of course “business logic” controller code. I even had a couple of unused methods that I was “saving for later”.

I couldn’t see a simple way to separate these into multiple classes - there were too many interdependencies:

• The event wiring needs to reference the data model and controller methods, and modify the DOM
• The canvas needs to reference the data model and controller methods, and pull images from the DOM
• The DOM manipulation / view template rendering needs to reference the data model

Just going through the exercise of mapping out the above dependencies hurts my brain - and even if I had them all mapped cleanly, I’d need some dependency-injection framework to wire everything up; way overkill.

Instead, I decided to keep everything in the same class (so “this” always refers to the “main controller”), but separate them into multiple files for ease of editing and bookkeeping.

Here’s what I ended up with:

sector-ui.js

• constructor
• .initialize()
• .handleTouch()
• .selectSystem()
• .selectDrone()

sector-ui.canvas.js

• .convertPixelsToWorld()
• .render()
• .renderStarlanes()
• .renderSystems()
• .renderDrones()
• .countFrames()
• SystemControlReticle // canvas support class, with one method: render()

sector-ui.dom.js

• .renderDroneBar()
• .loadPoiImage()
• .preloadImages()

sector-ui.model.js

• .getSystemById()
• .getFactionById()
• .getDroneById()

… and I dumped my save-for-later methods into sector-ui.obsolete.js

Syntactically, you have to use the .prototype with care. The “main” sector-ui.js has the Constructor, and initializes the class’ .prototype:

function SectorUI(sector) {
  // constructor stuff
}
SectorUI.prototype = {
  initialize: function() {
    // init stuff
  },
  handleTouch: function(point) {
    // touch handling stuff
  },
  selectSystem: function(system) {
    // controller / logic stuff, etc.
  }
}

… and the “subordinate files” gently add methods to the prototype via SectorUI.prototype.foo = function() { }.

sector-ui.canvas.js

SectorUI.prototype.render = function(arg) {
  // main render 
}
SectorUI.prototype.convertPixelsToWorld = function(point) {
  // etc.
}

They cannot use SectorUI.prototype = { /* lots of methods */ }, because that would blow away what was decared in sector-ui.js.

Perhaps it would be safer to always use SectorUI.prototype.foo = function() - I’m just not in that habit yet.

Update 10/1/2011: I have since converted to the habit of always using Sector.prototype.foo = function() - and I don’t think I’ll go back.

The net result:

gbmbp:sector-ui gb$ find . -name "sector-ui*.js" | xargs wc -l
     362 ./sector-ui.canvas.js
      47 ./sector-ui.dom.js
     147 ./sector-ui.js
      30 ./sector-ui.model.js
      31 ./sector-ui.obsolete.js

Much simpler and easier to get at what I need when I’m adding or changing some functionality.

If you have thoughts about the above or techniques of your own that you prefer, I’d love to hear about them on twitter, @_gb.

The project I’m working on doesn’t depend on the middle tier for much - basic MVC, security, validation, and secure access to my CouchDB store.

This means that most of my UI is JavaScript/HTML-powered, using a big chunk of JSON data as input and output. The JSON data structures are preserved largely untouched through the server and all the way down to (and up from) the database.

Prototyping new features is a blast:

1.) Mock up the underlying data structures as JSON in a text editor, sending around to other engineers and functional designers in plain-text email for feedback

2.) Write a simple static HTML page that reads the mocked-up JSON data file, and instantiates a simple JavaScript controller

3.) Build out that JavaScript Controller and the underlying HTML to implement an unstyled “sketch” UI of the most essential interaction

We can be up and running with a basic UI within a day of completing the data model - and without a minute of writing server-side or database code. We can tweak the UI as we start to see it “in the flesh”, and can feel free to make big changes without any significant wasted effort.

The result: much more time refining a functional interface before you make a big investment in “finalizing requirements” - which leads to more heavily-polished and generally higher quality functionality.

I love the ease of use and presumed robustness of the Ehcache Spring @Cacheable annotation, but I hate the fact that it doesn’t work on internal calls (within a single object). It relies on some sort of inter-object AOP black magic - not my cup of tea.

I decided to roll my own simple object cacher - something that could cache an expensive-to-obtain object, like a List or Map, for a certain period of time - going out to get a new one when the cached result expired.

My solution relies on Java Generics and an abstract class - the intent is that you pass in an anonymous implementation of the abstract retrieveFreshResult() method when you construct this guy.

Here’s how you use it:

    private CacheableResult<List<DroneDesign>> cacheableDroneDesignsResult = 
            new CacheableResult<List<DroneDesign>>(new Duration(1000 * 60 * 15))
        {
        // tell the class how to go get a new result        
        protected List<DroneDesign> retrieveFreshResult() {
            List<DroneDesign> userDesigns = new ArrayList<DroneDesign>();

            // go do something expensive to populate the list

            return userDesigns;
        }
    };
    

Here’s the underlying CacheableResult class:

    package com.droneage.dao;

    import org.joda.time.DateTime;
    import org.joda.time.Duration;
    import org.joda.time.Period;

    /**
     * Returns a cached version of an object if it's younger than a certain time 
     * period.
     * 
     * Otherwise, goes and retrieves it.
     * 
     * @author gb
     */
    public abstract class CacheableResult<T> {
        
        private T result;
        
        private Duration freshnessDuration;
        
        private DateTime lastResultRetrieval;
        
        public CacheableResult(Duration freshnessDuration) {
            this.freshnessDuration = freshnessDuration;
        }
        
        protected abstract T retrieveFreshResult();
        
        public T getResult() {
            
            if(result != null
            && new Duration(lastResultRetrieval, new DateTime())
                    .isShorterThan(freshnessDuration)) {
                return result;
            }

            synchronized(this) {

                // we might have been blocked - check again before 
                // incurring the retrieval

                if(result != null
                && new Duration(lastResultRetrieval, new DateTime())
                        .isShorterThan(freshnessDuration)) {
                    return result;
                }

                lastResultRetrieval = new DateTime();
                result = retrieveFreshResult();
            }
            
            return result;
        }
        
    }

What I’m really not sure about is - is this thread safe? Is the stuff I’m doing in my synchronized block good form, or not? I’m a little bit afraid that it could go wrong. Tweet me at @_gb if you have an opinion.

All agree that Java is a syntactically-heavy, verbose language. Even when code is concise, it’s not easy to tell what it does at a glance.

One thing that really bothers me is overly-verbose constants, that take something simple like this:

model.addAttribute("userProfile", userProfile);

…and turn it into this monstrosity:

model.addAttribute(WebConstants.REQUEST_ATTRIBUTE_USER_PROFILE, userProfile);

Worse, the other parts of the code (config, view templates, JavaScript, etc.) will have to come into the original values sooner or later, and it won’t be obvious without looking in the WebConstants file what that string value is anymore.

My complaint isn’t with constants; just with their lossy CAPS_AND_UNDERSCORES naming convention.

What if there were a way to author a string once, and “lock” it somehow, so that everyone shares the same value, but everyone can see clearly and concisely what that value is?

It occurred to me that there is such a way:

public class C {    
  public static final String _userProfile_ = "userProfile";
}

To use it:

model.addAttribute(C._userProfile_, userProfile);

// for comparison:
model.addAttribute("userProfile", userProfile);

You’re not going to miss that constant when scanning the code - it’s visually distinct, it stands out. Much more legible than a bunch of capital letters and underscores, and much more concise. And it’s perfectly valid syntax in Java, C#, what have you.

Any takers?

Since all the cool kids are using light-on-dark text editors, I wanted to join the party now that I’m using an IDE that supports themes.

Netbeans “Norway Today” theme seems cool, until you realize that it has a fair amount of light-and-light and dark-on-dark illegibility once you get into the details of debugging, etc.

I’ve been making subtle tweaks to Norway Today over the past several weeks, and am reasonably happy with what I’ve ended up with:

You can download it here. To import, go to Preferences > Import > (Select File) > (Check Colors and Themes) > OK.

(Updated 23-Dec-2011 to provide darker backgrounds to diff views)

A few weeks into my switch to Netbeans, I’m definitely a fan:

• Command-Click on any member/var to “hyperlink” to its definition is life-changing. All IDEs should adopt this immediately
• Subversion integration is built-in, and just works
• The key bindings have reasonably good defaults, cues on what to use in all the menus, and allow for easy customization
• Object-Oriented JavaScript has some basic support - the Navigator parses out the constructor, member methods, and the first declaration of each member var
• The (Ctrl-R) Refactor/Rename option also works in JavaScript (but only within the scope of that file)
• “Go To Type” (Ctrl-T in Eclipse) includes support for Types parsed out of JavaScript files
• The JavaScript editor does a good job validating JSON data structures
• Autocomplete of pom groupIds / artifactIds is fantastic
• Reasonably good support for themes - even allows you to color the visible-whitespace chars (which Eclipse did not, insisting on a high-contrast dark gray/black)
• The “Find” feature works in the modern, Firefox-inspired way you’d expect
• The IDE is reliable and performant

That said, I do have a few gripes:

• Stopping and Starting the internally-managed Tomcat server requires doing a right click context menu dance. I do this a lot, and it slows me down
• Lack for Freemarker Template support is painful. I now just ignore all the bright red syntax errors in my FTL files (for which I’m using the text/html syntax highlighting rules).
• The searchable options screen from Eclipse is missed
• JavaScript autocomplete, while I’m happy to see something, reminds me of the horrendous XCode 3 autocomplete experience; too slow, and lots of false positives.
• Expand tabs to spaces is set on by default - yuck. (Options > Editor > Formatting to change)

And while the Theme support is great, the default themes are not. “Norway Today” looks cool at first, until you realize that breakpoints / selected members / etc. lead to illegible light-on-light text. I’ll be posting a version of Norway Today with some legibility customizations soon.

In spite of the gripes, I really have to say that I am loving working in Netbeans. Not only will I never go back to Eclipse, but I think Netbeans sets the bar for all other IDEs (I’m looking at you, Visual Studio 2010 and XCode 4). I would consider using Netbeans for a JavaScript-only project.

Finally, an anecdote: a partner on a side-project who is not a programmer installed Netbeans, checked out my multi-module project from subversion, built, and ran the codebase within half a day, while I was spending over a week getting a new application to open and run in Visual Studio 2010.

I’m very happy to be working in Netbeans.