FusionGrokker

Customer Support and Time Zones

Tue, 21 May 2013 15:02:16 GMT

Let's talk about customer support. It's your first line of defense when customers are affected by bugs, so it should be a very high priority.

Of course I'm being set off (again) by ongoing issues with PhoneGap Build. Probably around 80% of my work is developing PhoneGap based mobile apps. And again, the site is experiencing issues...

This particular problem is not even one covered in my previous rant. They have (when occasionally bothering to respond to customer support tickets) mentioned that there were issues with the process that does compilations notifying the website that compile was complete, for one or two platforms. Well, if I had to guess, I'd say the issue is now more widespread. I uploaded a build around 2 hours ago and it still hasn't been marked as completed for a single platform.

But that's not what I'm flying off the handle about, today. No, today is about Time Zones in relation to customer support.

For the uninitiated, there's this whole section of the planet in a time zone called US-East, where a shitload of people — yours truly included — live and work. And while they don't post profiles of all of their employees, we can extrapolate based on their posting habits and the occasional twitter bio, and estimate that Adobe has two teams working on PhoneGap Build: One in India, and one in San Francisco, California.

These two time zones are almost directly opposite one another, so you might think that between them they could cover customer support needs fairly well; in 12 hour blocks, with one team handing over everything to the other team at the end of the day, never going un-covered.

Woe, but were that true.

Instead, what seems to happen is that at some point in the Indian late afternoon or early evening they punch out, and the customer support portal goes dark for the night. While it does feel a bit rare, subjectively, let's say that when the SF team wakes up and heads into the office, they do in fact pay attention to the support portal. It often doesn't feel that way, as someone who's under deadlines and frustrated with a support black-out, but let's give them the benefit of the doubt for the sake of argument.

If the India team stops handling customer support at 5pm in their local time, and the SF team starts handling support at 8am in their local time, then there's a chunk of time un-covered there. At first glance that time block doesn't seem so bad. It's 5:00pm until 8:30pm in India, or 4:30am to 8:00am in SF. But if we look at that time frame for US-East, that's 7:30am to 11:00am — basically the first half of every day is radio silence.

Not just radio silence, but when a big problem happens, like, you know, NOTHING WORKS, then we're sitting on our hands and our deadlines for half a day waiting for someone, anyone, to come save the day. When my applications are useless I get a notification, and I drag my ass out of bed no matter what time it is, and I don't go back to bed until it's fixed.

This is geographic discrimination, and it suuuuuuuuucks.

And let's be honest here: they're not jumping on tickets at 8am in SF. More like 11am, if at all.

I know I sound like a broken record, here, but come on guys. This service is the fucking cats pajamas... when it works. To quote a colleague of mine, if you could keep it online we would "fly to California just to throw a stack of money at you."

For at least two weeks now they've responded to every one of my "hey, btw, your service is down" tweets, more than 12 hours later (often even 24+ hours later!), with something along the lines of "sorry, we're making some changes soon to address this!". I don't think your definition of "soon" and mine are the same.

cf.Objective() Baseball BOF Logistics

Fri, 17 May 2013 21:23:11 GMT

For those of you who will be coming to our group outing to the Twins vs. Red Sox baseball game on Saturday evening, here's what you need to know logistically.

We'll congregate on the 2nd floor near the bridge into the mall, after the conference closing remarks, and plan to catch the 5:12 train -- that should leave plenty of time to use the restroom and drop things (e.g. your laptop) off back in your hotel room before we leave. You won't be able to bring any food or drinks into the ballpark, so don't plan on bringing them with you. Please try to meet at the rally point by 5:00. Don't forget your ticket!

The train station is just a short walk across the sky-bridge and through the mall:

You should probably also plan to eat dinner at the ballpark -- game duration can be a bit unpredictable but you should expect at least 3 hours (plus a ~45 minute ride back).

The forecast is currently calling for (potentially) some light rain, and temperatures in the upper 70's & low 80's (that's F... 24-27 C for you Brits). Personally I'll probably just plan on getting a little bit wet. A little water never hurt anyone! If you didn't pack any rain gear and you're so inclined, I'm sure there are places in the mall that would be happy to sell you a poncho or rain coat. The stadium should also be selling ponchos, but supply may be limited and you can expect them to overcharge.

In order to streamline the train-catching process, please try to take a few minutes to run down to the train station tonight or tomorrow and purchase your light rail tickets. We're going from Mall of America Station to Target Field Station (and back again), and each leg of the trip should cost USD $1.75.

Enjoy the rest of the conference, and if I don't bump into you before Saturday afternoon, I'll see you then!

Using Taffy Without an Application.cfc Base Class

Fri, 17 May 2013 20:06:12 GMT

One of the most common complaints I hear about Taffy is that it requires that you extend its base class in your Application.cfc...

component extends="taffy.core.api" {}

Sometimes you don't want to do this. Maybe you have another base class you're using, or you just don't want to. Whatever your reasons, it's a dealbreaker.

Talking with Chris Phillips at cf.Objective() today, I had an epiphany that it should be possible to get Taffy running without extending taffy.core.api from your Application.cfc. The only reason it's been a requirement thus far was to automatically bootstrap in Taffy's handling of the onApplicationStart, onRequestStart, and onRequest events.

But if you're willing to wire those up manually, you can write your Application.cfc any way you like as long as -- at some point -- you hand off the request to the appropriate Taffy method. Here's an Application.cfc that uses Taffy as an internal object without using extends in Application.cfc:

component {

    function onApplicationStart(){
        application.taffy = createObject('taffy.core.api');
        application.taffy.onApplicationStart();
    }

    function onRequestStart(thePage){
        application.taffy.onRequestStart( arguments.thePage );
    }

    function onRequest(thePage){
        application.taffy.onRequest( arguments.thePage );
    }

}

You can put whatever you want before and after those calls that defer to Taffy's internal implementations (e.g. the rest of your application), and it should still work exactly as described in the documentation -- variables.framework would still be used, etc -- but I haven't tested this extensively yet.

Just a little tidbit that I thought some of you may be interested to hear.

The Dude Does Not Abide (Long-standing Bugs)

Thu, 09 May 2013 14:14:10 GMT

We're all people. I acknowledge that. Nobody likes getting yelled at. So I apologize in advance for what I'm about to do. I don't mean to hurt anyone's feelings, but if nobody speaks up, we can never expect change.

I used to think that my personal Hell was getting stuck head-first in a small space and not being able to squeeze back out (claustrophobia like woah)... Today I'm officially changing my personal Hell to long-standing bugs that affect a significant number of people and get little-to-no response, resolution, or worst of all, communication on what's taking so long.

I'm looking at you, Phonegap Build.

I would rather get stuck in a tiny space than continue to put up with your bugs and lack of communication on their resolution status.

The worst part is that I fucking LOVE Phonegap Build. Independent manual builds for multiple platforms suuuuuuuuuuucks, so this service was begging to be built from day 1. The often-buggy or for-some-reason-offline debugger (weinre) is pretty sweet, too... when it works. If you were to start charging for the service, my company would be first in line with our checkbook open, fervently clicking our pen over and over until you named a price and told us to whom we should make the check payable.

But for fuck's sake, it's been nearly a year since it was reported that you're building android apps with the wrong icon in place for XHDPI (highest-resolution, aka best-screen) devices, and it's just a matter of copying the correct file into a folder before you compile the damn APK. It's so rudimentary that I've managed to write a tool that completely automates the fix including repackaging, re-signing, and re-zipaligning. If it's just a matter of copying the correct file into a folder, why hasn't it been fixed? And if the issue is not that simple, why aren't you communicating that to us? The icon is a pretty damn important part of an app, Android has the highest market share, and XHDPI devices are getting more and more popular every day.

It was 9 months ago (August 2012) the last time Adobe commented at all on the issue, and that comment claimed that the bug should be fixed. The slew of comments since then says otherwise. What... the... actual... fuck?

Moving on...

I've reported over and over that linking to external sites in a way that opens the device's native browser, rather than taking over the Phonegap Webview, does not work as documented, or at all, for that matter. I first reported the issue on April 5th, 2012 -- more than a year ago.

I've got an app that I just upgraded from Phonegap version 1.5 to version 2.5, recompiled by Phonegap Build, and here's how external links work:

iOS
- do abso-fucking-lutely nothing
Android
- open the link in the Phonegap Webview

And yes, I've tried every possible permutation of white-listing the domains (search for "<access", since they don't expose any deep-linkable ID's... fail, fail, fail, fail...). There's also this user-proposed "navigator.app.loadURL" solution, but for some god-forsaken reason, Phonegap doesn't support the "navigator.app" object (at all!) on iOS -- it's Android only, by design. (Way to provide a consistent API across devices there, guys...)

Considering the number of links that modern apps generally want to open, this is a big fucking deal.

There's good news for this issue, too, though. According to the Phonegap 2.7 documentation (note that at the time of writing, the latest Phonegap version supported by Phonegap Build is 2.5.0), a new syntax will be available for opening links using the ChildBrowser plugin and the device-native browser:

window.open('http://google.com', '_blank'); //childBrowser plugin
window.open('http://google.com', '_system'); //device-native browser

That's great and all, but we don't have 2.7 support on Build yet. On a whim, I tried both syntaxes on my Phonegap 2.5-based app built with Phonegap Build -- and it works... mostly.

window.open('http://google.com', '_blank'); //childBrowser

This syntax should open the childBrowser plugin, and as far as I can tell it seems like that might be what it's doing, but the top of it is getting cut off -- I can only see a few pixels along the bottom of the url bar and buttons, so it's kind of a guess. Whether or not it's trying to load the childBrowser plugin for this, it's not working properly.

window.open('http://google.com', '_system'); //device-native browser

Almost as if by magic, this seems to work. I couldn't believe my eyes. I took a closer look at the Phonegap 2.5 documentation and wouldn't you know it? It's documented.

Why haven't they been communicating this to us in the bug reports? I never saw it before today because I had been trying to avoid the ChildBrowser if possible. Only by giving up did I find the answer. Fail, fail, fail, fail, fail.

I can live with bugs. I have plenty in my own projects. I do not accept bugs + a year without resolution + no communication. This is stupid, and not in a good way.

Again, I don't want to hurt anyone's feelings. I'm not trying to get anyone fired. What I am trying to do is get you (Adobe) to communicate more effectively. Reply on bug reports (more than once a year, please), and if fixes are not what we expect then let us know it's going to take some time. When you shrink away into the shadows, it makes us feel neglected and abandoned, and that does nobody any good.

Extracurricular Baseball BOF at cf.Objective() 2013

Fri, 26 Apr 2013 18:34:18 GMT

Hat tip to Jim Fasoline for the idea!

I'm going to be staying an extra night after cf.Objective() this year (Saturday night, the 18th), and thought it would be fun to get a group together to go to the Twins vs. Red Sox game. I picked Saturday because I don't want to miss the BOF night or the Lightning Talks -- and I would recommend you not skip them either. They're always a good time!

Since the game is at 6:10 on Saturday night, we'll meet up immediately following the conference closing remarks, and head straight over to the stadium.

If you want to go, I suggest you buy tickets now! Yesterday the cheapest available tickets were $18, and today it looks like they're $22 and up. Don't really sweat where your seat is; I think the plan is to spend the majority of our time in Standing Room areas, and walking around to check out the stadium and the selection of local craft beers.

I have it on good authority from a local that we can expect basically door-to-door service from the light rail, and the ride should take just under an hour (which is why we'll meet immediately following the closing remarks).

So again, if you're interested, buy your tickets now and leave a comment here so we can stay in touch to keep organized. So far we have myself and my fellow speaker Carol Hamilton as confirmed going... who else is going to join us?

cf.Objective() Lightning Talks are in danger!

Mon, 15 Apr 2013 13:46:54 GMT

This morning Tim Cunningham, this year's overlord of all things cf.Objective(), tweeted that we're far short of the minimum number of Lightning Talk proposals to make them worth hosting. As I write this, there are only 3 proposals. I'll be submitting one myself after I publish this post, but that doesn't even get us to the half-way point.

@adamtuttle If we don't have 10 there really is no point of hosting them.
— Tim (@TimCunningham71) April 15, 2013

Personally I think that the Lightning Talks are one of the most fun events at cf.Objective(). Short, usually funny and/or interesting presentations, and everyone has already gone out for dinner (and usually a few drinks) so everyone's in a great mood. The atmosphere in the room is electric.

Some of the more memorable topics from the last few years have ranged from Beer (homebrewing), to Adoption, to Ben Nadel's epic Love Story, to what amounted to a job posting (showing off some of the fun stuff that the position offered). So clearly you don't have to talk about anything technical -- but you can. That's the beauty of it. You talk about whatever you're passionate about -- it's totally open ended.

But if we don't get at least 6 more proposals this year -- by tomorrow, Tuesday the 16th -- they won't happen at all this year. Do you want that to happen? You don't want that to happen.

So propose something. Or if you've got nothing to talk about, prod your favorite presenter or interesting person to get them to submit something!

Can you draw in a Dr. Seuss style? I need your help!

Fri, 12 Apr 2013 15:45:00 GMT

I have a Lightning Talk concept that I'd like to do at this year's cf.Objective(), but in order to really pull it off I'm going to need someone with a modicum of drawing skills (of which I have none) who would be willing to draw up a few illustrations for my slides -- in the art style of Dr. Seuss.

If you're not familiar with Lightning Talks, they are based on the popular but copyrighted "Pecha Kucha" (pronounced "pi-chach-ka") presentation style, where you get 20 slides each automatically advanced after 20 seconds, for a total presentation time of almost 7 minutes. So at most I'll need 20 drawings, but possibly less. Also, they need not be highly refined or even in color. I'd be thrilled just to get some sketches in pen that have been scanned.

Considering it's a 7 minute presentation that I might be lucky to give twice, I don't have a lot of money to spend on it... but I would be willing to barter for some of my time programming, if that's something you'd be interested in.

Please get in touch via my contact form if you're interested!

Taffy 1.3, codename: Excelsior

Fri, 12 Apr 2013 12:00:00 GMT

Today I'm happy to officially release version 1.3 of Taffy, continuing my quest to keep to a greatly-reduced release cycle:

I don't want to release so often it's annoying to have to upgrade, but still often enough to get bug fixes and new features out. How does 2 releases a year sound?

Download Taffy 1.3.0 stable

Here are the release notes for Taffy 1.3.0:

Meta / Project Management Changes
- From this point forward, the master branch will be used for day-to-day development, not just merging in stable releases. Stable releases will still be available for download via the tags page. Should any maintenance releases be necessary, they'll be done in branches created from the applicable release tag.
- We've had an extensive test suite for a while now, but I've finally setup a Jenkins instance and am doing a bit of continuous integration. You can see the build stats here: and this badge has been added to the ReadMe.
Bugs Fixed:
- #105 - Static URIs that would match dynamic URIs are now allowed (/user/logout would previously conflict with /user/{userId}). Pay special attention to URI Matching Order.
- #120 - Added support for */* Accept header value. Thanks to Brian Quackenbush for the patch!
- #124 - Fixed a Railo-specific bug blocking resources from being loaded when the resources folder isn't in the web root. Thanks to Jean-Bernard van Zuylen for the initial bug report and the pull request!
- #129 - Fixed a bug that MANY people have asked about recently: when you don't supply any form of requested return format (via header or URL "extension"), the dreaded "your default mime type is not implemented" error was returned. Jean-Bernard van Zuylen provided an epic detailed bug report, as well as the pull request that ultimately fixed it. A regular open source hero!
- #130 - Fixed a regression in changes to the dashboard to use the new endpoint url param. This one was also reported and fixed via pull request by Jean-Bernard van Zuylen.
New Features:
- Added a new queryToArray helper method for transforming query objects into an array of structures, preserving column name case.
- #91 - A message is now displayed if Taffy can't find any resources.
- #99 - Show dashboard without the ?dashboard query param (just browse to the root of your API). See deprecations, below.
- #102 - Added support for DI/1 bean factory. See this example for a sample implementation.
- #103 - Added environment-based configuration.
- #108 - Added helper method getBasicAuthCredentials() to api.cfc (so you can use it in your Application.cfc). It returns a structure with keys username and password, and if NO basic auth credentials have been included in the request then both values will be blank.
- #109 - Added helper method saveLog() to resource classes, which delegates to your configured exception logger. You may now use: saveLog(cfcatch) from inside a resource.
- #115 - You can now use properties instead of setters to have Taffy autowire dependencies. (Setters are not deprecated; this is just an additional option.)
- #117 - Added support for endpointURLParam. Thanks Marco Betschart.
- #122 - Added support for ETag based caching
- #128 - Now support Access-Control-Allow-Headers to list allowable headers for Cross-Domain requests. Thanks to Marco Betschart for the bug report and the patch!
Deprecations:
- Using ?dashboard to display the dashboard is now deprecated in favor of simply browsing to the root of your API, with or without /index.cfm in the url. E.g. http://api.acme.com/ or http://api.acme.com/index.cfm instead of the old http://api.acme.com/?dashboard

As always, the full changelog history is available on the Release History page of the wiki.

How much Taffy is 5 pounds?

Thu, 11 Apr 2013 17:12:33 GMT

This much:

If you're going to CFObjective, please come ask me for some Taffy. If you don't, my teeth will surely rot out of my head.

ColdFusion (Taffy and Mura) job opening

Tue, 09 Apr 2013 12:08:27 GMT

I've been contacted by a recruiter from Fusion Alliance about a job opening where they're looking for someone to do ColdFusion programming with Taffy and Mura. It sounds like working remotely is an option, but in case you're in the area the customer site is in Dayton, Ohio.

I don't know much about the project aside from the fact that it will be using both Mura and Taffy -- that and their target delivery date is at the end of June.

If you're interested, contact Amy here:

Amy Denison
Corporate Recruiter
Office: 513.618.6675
Mobile: 513.544.4414
fusionalliance.com
LinkedIn
Twitter

Bootstrap Typeahead Customization Examples

Thu, 21 Mar 2013 16:16:14 GMT

Last night, after receiving many requests to provide working examples for my Heavily Customizing a Bootstrap Typeahead post, I've updated the original post with inline, embedded, live-running examples. I'm using a service called Plnkr (pronounced "Plunker," I assume), which has a really nice interface for working on, and more importantly, sharing example JavaScript code.

Here are some screenshots of it in action on the bootstrap typeahead customization post. When it first loads you can see the example running live. If you choose to look at the source code at some point you can get back to the live running view by clicking the "play" button in the upper right:

And here's how you can find the source code. One really nice feature of plnkr (over something like jsfiddle) is that you can have numerous files, even of the same type, so many JS files for example, in one sample. In these examples I've got my "api data" in a static JSON file that I'm loading via AJAX. It's technically not an API but it demonstrates the idea and expected data format quite well.

I know that in the past I've railed against bloggers "outsourcing" code samples, and believe me the irony is not lost on me. Firstly, You'll note that I haven't removed any of the code samples that were originally included in the post. They're still there. The plnkr samples are just adding more value. Secondly, this is a lot more than simple code snippets.

I still feel like people who embed gists in their blogs are being lazy, because the only benefit would seem to be the no-effort syntax highlighting and formatting... But this live-running example functionality is not something easily duplicated, and it is pretty compelling for embedded demos.

For now consider me conflicted on the matter. I still believe that your blog should own and be the primary source for the example code, but I can also see how it would be annoying to have the code both inline and in a plnkr. For now I plan to just continue to play with Plnkr when appropriate to see if I can find a happy medium. Maybe I'll embed the original source code in posts as HTML comments or something... Who knows?

Tattle On Your Applications with snitch.io

Mon, 18 Mar 2013 16:30:20 GMT

I made a thing! You could even call it a bootstrapped startup. It's my first though, so please be gentle...

For the last three weeks I've been spending almost all of my nights and weekends (and I do mean almost all. My average bed-time was around 3am and there was more than one all-nighter...) creating snitch.io, a hosted exception logging and analytics service.

What does that mean? It means that instead of emailing yourself whenever your application has an error, you send it to snitch.io via our REST API. We automatically provide statistical information about the errors you send us. Currently we can show you:

The number of errors grouped by many different time metrics:
- Last 60 minutes, grouped by minute
- Last 24 hours, grouped by hour
- Last 30 days, grouped by day
- And several more...
The number of times each unique exception has occurred (since you started sending us data)

The occurrences count metric is interesting. If the data you send includes a stacktrace then we hash that and use it as the unique identifier. This means that if the exact same error happens 20 times, you'll see 20 occurrences listed. If you don't include a stacktrace, then we hash the entire data object that you send, and use it the same way.

This next feature hasn't landed yet, but you can easily see how we can take this data and show you which errors in your application happen most frequently, or which have recently spiked, and so on. And speaking of features, our roadmap is public and public voting is enabled; so you can see and even have a voice in shaping the future of snitch.io!

Now, if you're not comfortable working with a REST API directly, I've already started a collection of API wrappers, including a CFC for your CFML applications. You can pass it a native cfcatch object from a try/catch block, or the exception object in your Application.cfc's onError() method, and these look and work beautifully in snitch.io. The exception detail reports we provide should look pretty familiar to CFML developers:

Of course, in the unlikely event that our API goes down or just takes too long to respond, the wrappers fall back to emailing you -- so you're absolutely no worse off than currently. I'll also throw this out there: If you are an existing customer and you contribute a new wrapper or get an accepted pull request to an existing wrapper, I'll make sure we credit you for a free month or some free notifications or something, to say thanks!

Pricing

$5/month gets you 500 exceptions/month
$15/month gets you 1,500 exceptions/month
$40/month gets you 4,000 exceptions/month
If you need more than 4,000 exceptions/month, email me or jump in #snitch.io on freenode (irc) and we can figure something out.

The current prices may change, but at least for now we're charging: $0.01 per exception logged, on monthly subscription plans. We'll soon be adding notifications through things like web-hooks, tweets, SMS, Amazon SNS, and so forth. Notification types that are free to us are free to you. That means that web-hooks and tweets are and always will be free, but we're going to charge a small fee -- probably $0.01 -- per other notification.

What do you think?

I'd love to hear your feedback: good, bad, or otherwise. As I said, this is my first startup, and it's only just getting started. I've got tons of ideas and I'm eager to make this into the best exception logging service available.

General Pull Request Etiquette

Thu, 14 Mar 2013 12:15:39 GMT

Having spent the better part of the last few years working on, using, and contributing back to open source projects on GitHub I've found a few rules of thumb that I tend to follow that I sometimes see others breaking -- probably unintentionally. I thought I'd list them here, and if you disagree or want to add to the list then we can talk it out in the comments.

I should start by saying that while I did draw the inspiration for this post from Carl Von Stetten's recent pull request for my CF-JSON-Tests repo, I am in no way picking on Carl, or anyone else that might not follow these suggestions. Again, these are rules that I've realized that I subconsciously made up for myself to make the job of evaluating my pull requests easier and less stressful for the person on the receiving end of the request. Having experienced first hand the simultaneous joy and frustration of having someone find your project worthy of their contribution, but not having the time to immediately evaluate and accept the PR, I know that every bit of effort I put into making their job easier is appreciated. So, thank you Carl for your pull request, and please don't take any of the below as an attack on you!

Change as little as possible to accomplish your goal

I use the setting in SublimeText to trim whitespace on save. When the project author(s) don't use a similar setting, I tend to see a lot of blank-line differences in my diffs pre-commit:

The only change visible here is that my IDE has stripped out unnecessary whitespace. This is just noise to a project author. When I'm contributing my changes back, I do not commit these line changes at all. Fortunately, Git makes this incredibly easy. I stage just the functional changes, and then after committing I can easily discard the whitespace changes (effectively putting the whitespace characters back into the file).

Not only is this a courteous thing to do when sending a pull request, it's a smart way to treat your own repositories. I do commit whitespace changes to my repos, but never mixed in with functional changes; always grouped together with any other whitespace changes, and it bears repeating: no functional changes. I also include a commit message that says something like "whitespace". That way if I ever have to go back and do a bisect or otherwise look for where a bug was introduced, I can easily ignore any commits that are whitespace-only.

Include test cases if at all possible

Some changes are untestable (or at least not easily automated), or sometimes the project doesn't already have any testing setup. In these cases it's somewhat excusable, though still not ideal, not to include test cases with your pull requests.

But if the project already has testing setup, you should include tests with your pull requests for several reasons:

If you don't write it, someone else has to; and nobody understands the problem better than you do while you're adding the feature or fixing the bug.
You really should be running the existing test suite to make sure you haven't introduced a regression with your changes -- and since you're already working with the tests, why not add some for your changes?
It's the only way to help prevent those that come after you from introducing bugs into your code.

If a project doesn't have any tests at all, even just creating the first test or two would be a great pull request.

Strong Opinions, Weakly Held

Be ready and willing to explain why you did what you did: Was there another approach that you tried that might seem more obvious at first glance but once implemented had too many edge cases? If something seems more obvious than your solution (right or not) then the author may ask you about it.

A couple years ago, I was talking the Institute’s Bob Johansen about wisdom, and he explained that – to deal with an uncertain future and still move forward – they advise people to have “strong opinions, which are weakly held.” They've been giving this advice for years, and I understand that it was first developed by Instituite Director Paul Saffo. Bob explained that weak opinions are problematic because people aren’t inspired to develop the best arguments possible for them, or to put forth the energy required to test them. Bob explained that it was just as important, however, to not be too attached to what you believe because, otherwise, it undermines your ability to “see” and “hear” evidence that clashes with your opinions. This is what psychologists sometimes call the problem of “confirmation bias.”

-- Bob Sutton

You should be capable of explaining the choices you made, but don't feel that the code embodies you. Sometimes you get it right, sometimes not. You are not a failure because your pull request was not accepted. In fact, you might even define success as being willing to walk away from code that you've written while being happy about it. After all, you want what's best for the project, right?

Don't be afraid to be the noob

Everyone is always a noob at something. Sometimes the best way to learn and improve is to put some code out there and see how it stands up to scrutiny. Again: You are not your code. Everyone looks at code they wrote 6 months ago and cringes -- everyone that's learning, at least, and most developers are.

Just do it!

It doesn't matter if you're a total noob or a 30 year veteran, open source is (usually) a complete meritocracy. The best ideas rise to the top no matter where they came from. The only requirement is that you try.

You Can Help Fix ColdFusion JSON Serialization

Mon, 11 Mar 2013 11:58:41 GMT

Over the weekend I got word from Rakshith, the ColdFusion product manager, that it was ok to share the following news with the community at large.

Adobe plans to continue improving the JSON (de)serialization functionality that was added in ColdFusion 8, at the very least including those improvements in the next version of ColdFusion (codenamed "splendor" (pdf) [...gag me with a spoon]). Considering we have this awesome updater, I'd also love to see a patch for CF10, but that may be a pipe dream. Still, any improvement would be welcome.

So what's wrong with serializeJSON? Currently, there are many edge cases that serialize incorrectly, necessitating the use of an alternate serializer like CFJSON or my personal preference JSONUtil. For example:

WriteOutput( serializeJson( { foo: '3' } ) ); //should be {"foo":"3"}

=> {"FOO":3}

Not only is the key name annoyingly upper-cased, but the value, which was a string containing the number 3, has been converted to the numeric value 3.

These are two known issues. There are a bunch of these issues that are known, and possibly some that are still unknown. Fortunately, Adobe is being forthright with us in sharing the fact that they're attempting to fix the bugs, and they're happy to accept feedback and bug repro cases.

To that end, I've taken the first step and created a set of tests demonstrating all of the issues of which I am aware. Those tests are on GitHub, you can see them run against ACF 9.0.1 here, and I am ~~happy to accept~~ begging to you send pull requests with additional tests for more bugs.

Showing the bugs in action is paramount to getting them fixed. If you know of a bug, and you don't report it, you only have yourself to blame for it not being fixed.

If you aren't familiar with writing tests using JavaScript, take a look at the code. It's very readable and you just mind find that it's easier than you thought... But if you're too lazy, or you still just don't quite have the hang of it, I would settle for you filing a bug against the repo, so that someone can add a test for it.

One last thing: Do you have ACF10 hosting and want to volunteer to host a copy of the tests? It would be helpful! Contact me!

My Sublime Keymap & Common KB Shortcuts

Fri, 08 Mar 2013 13:06:26 GMT

What follows is nothing new or unique; it's just a collection of keyboard shortcuts and tips that I've picked up from various blog posts, videos, and personal recommendations from friends over the last ~year of using Sublime full time. I'll go over each setting on its own here in the post, but if you just want the keybindings, you can find them in this gist.

Comma first! You'll notice that I'm using a comma-first formatting. I like it because it makes missing (or superfluous, in the case of the first line) commas stick out like a sore thumb. You don't have to like it or use it, but it suits me well.

Line swapping

{ "keys": ["alt+up"], "command": "swap_line_up" }
,{ "keys": ["alt+down"], "command": "swap_line_down" }

Alt+up / Alt+down to move lines up or down. This is a neat trick I picked up from Eclipse back in the day, and I use it a lot; especially to move large chunks of code -- just highlight several lines and use it.

Duplicate line

,{ "keys": ["ctrl+alt+down"], "command": "duplicate_line" }

Ctrl + Alt + Down creates a copy of the current line on the next line.

Pro-tip: If you have less than 1 line selected, that text is duplicated and placed after the selection. No more copy+paste to create a quick series of <br/>...

Delete line

,{ "keys": ["alt+d"], "command": "run_macro_file", "args": {"file": "Packages/Default/Delete Line.sublime-macro"} }

Another favorite shortcut from Eclipse was Cmd+D; but Sublime does something ~~else~~ better with Cmd+D, so with a little effort I re-trained my brain to use Alt+D instead.

Split View

,{
    "keys": ["ctrl+alt+left"]
    ,"command": "set_layout"
    ,"args": {
        "cols": [0.0, 0.75, 1.0]
        ,"rows": [0.0, 1.0]
        ,"cells": [[0, 0, 1, 1], [1, 0, 2, 1]]
    }
}
,{
    "keys": ["ctrl+alt+right"]
    ,"command": "set_layout"
    ,"args": {
        "cols": [0.0, 0.25, 1.0]
        ,"rows": [0.0, 1.0]
        ,"cells": [[0, 0, 1, 1], [1, 0, 2, 1]]
    }
}

I don't always use split view, but when I do, it's F&^%ing useful.

I use the above commands in conjunction with the built-in commands for Super+Alt+1/2/... Using Super+Alt+2 puts you in split-mode with each side taking up 50%, but sometimes you want to focus more on one side or the other. For instance, maybe your CSS is nice and tidy and doesn't need much horizontal space, so you want to give that available space to the HTML on the other side. With the above additions, Ctrl+Alt+Right gives 75% of the code's screen real estate to the right pane and 25% to the left (think "focus right") and Ctrl+Alt+Left ("focus left") gives 75% to the left pane and 25% to the right. Rarely do I ever need 3 panes, but when I do I just resort to the mouse for any resizing that needs to be done.

Pro-tip: Use Super+K+B to toggle off the file navigator for even more screen real estate during split view.

In addition to the above shortcuts that arrange panes, these move the cursor to the specified pane (e.g. super+1 focuses the left-most pane, super+2 focuses the 2nd pane from the left, etc):

,{ "keys": ["super+1"], "command": "focus_group", "args": { "group": 0 } }
,{ "keys": ["super+2"], "command": "focus_group", "args": { "group": 1 } }
,{ "keys": ["super+3"], "command": "focus_group", "args": { "group": 2 } }
,{ "keys": ["super+4"], "command": "focus_group", "args": { "group": 3 } }

And these shortcuts move the focused file to the specified pane:

,{ "keys": ["alt+1"], "command": "move_to_group", "args": { "group": 0 } }
,{ "keys": ["alt+2"], "command": "move_to_group", "args": { "group": 1 } }
,{ "keys": ["alt+3"], "command": "move_to_group", "args": { "group": 2 } }
,{ "keys": ["alt+4"], "command": "move_to_group", "args": { "group": 3 } }

Bookmarks

,{ "keys": ["f3"], "command": "next_bookmark" }
,{ "keys": ["shift+f3"], "command": "prev_bookmark" }
,{ "keys": ["super+f3"], "command": "toggle_bookmark" }
,{ "keys": ["super+shift+f3"], "command": "clear_bookmarks" }
,{ "keys": ["alt+f3"], "command": "select_all_bookmarks" }

Bookmarks are crazy-useful when you find yourself jumping back and forth around a long file. When working on an app with a long Mach-II.xml file I'll often bookmark the section of events that I'm working on, and views, and listeners, so that I can quickly jump back and forth between these sections.

All of these are modifications to the built-in bookmark settings because I use a plugin called Sidebar Enhancements to add in some extra functionality for improving keyboard-focused workflow, and it overrides the default F2 shortcut for flipping between bookmarks into a rename-focused-file action. I spent many years on Windows, so I'm actually quite happy to have this action and F2 is easily remembered because Windows uses F2 for file renames; so I just bumped everything for bookmarks up to F3 instead.

Create XML/HTML Tag Pair

,{ "keys": ["alt+,"], "command": "insert_snippet", "args": { "name": "Packages/XML/long-tag.sublime-snippet" } }

This is another re-mapping of built-in functionality. By default the shortcut for this is Ctrl+Shift+W, but I found that awkward to perform, so I switched it to Alt+< (it's really Alt+, but I think of it as Alt+< because I'm creating a tag-pair). This is a very handy tool, because it changes the closing tag to match the opening tag as you type. It defaults to a P, but the "p" portion is highlighted and if you overwrite that to "div" then the closing tag automatically becomes </div>. Another great thing about this is that when you hit space and start adding tag attributes, they are not added to the closing tag. It's one of those elegant moments where everything just works perfectly. I love this shortcut!

Other Keyboard Shortcuts

Quickly, here's a list of other built-in shortcuts that I find myself doing all day, every day:

Super+K+B toggles the file navigator
Super+P opens file search. File search is super powerful!
- Fuzzy matching: you don't have to spell perfectly or even do consecutive chunks. Say I wanted to open "RecruitWeb.less" but I have 3 of them in different folders, named main, mobile, and new. If I hit Super+P and start typing "mobrecrless" it matches mobile/RecruitWeb.less.
- Line-jumps: Jumping into a file to fix a bug and you know the line number? select your file with fuzzy matching then add a colon and the line number: "mobrecrless:47" puts your cursor on line 47 of the file you choose.
- Symbol search: Instead of using a colon to jump to a specific line, say you know the CSS selector you want to modify but you don't know where it is in the file. Use "@" and start typing the selector: "mobrecrless@.ui-widget"
Super+Shift+P opens the command palette, from which you can run package control, or toggle the minimap, or execute just about any command for which you can't remember the keyboard shortcut. This uses fuzzy matching as well.
Super+Alt+Left/Right flip between open tabs

Plugins Without Which I Can't Live

Package Control: Don't leave home without it! Use this to install and enable/disable other plugins. Very handy! And the reason I won't include links to the rest of these plugins, because you can just search for them on Package Control.
Sidebar Enhancements: Adds the aforementioned F2 to rename, confirm deletes, and many other goodies
Advanced New File: Super+Alt+N to create a new file and you can type out its path relative to the project root, so if I have a project open and type "assets/less/style.less" it will create style.less at the specified location within the project, creating any of the folders necessary in that path (and open the file for editing).
Gist: I store all of my snippets in their own github account so that they are not tied to my editor, and they can be shared, forked, and collaborated on. There is a small latency initiating an "insert gist" command while it indexes my available snippets, but I find that I use them infrequently enough that it doesn't bother me. If I used them more regularly I would probably do something local. Using gists also means I don't have to use the sublime snippet syntax, which is not difficult, but it is another set of (minor) "lock-in" that I would have to go back and remove if/when I move on to another editor in the future.
Live Reload: because refreshing pages to see your changes is for chumps.
Markdown: I write a lot of things in markdown, including blog posts here and elsewhere, articles for things like Learn CF In A Week, and so on. It's become a core part of how I write. This plugin adds syntax highlighting for Markdown.

I think that about covers it... for now. I seem to be continuously evolving how I use Sublime, which is a tremendous part of what makes it so useful: you can mold it to the way you like to work.