IE11 Things I Had to Learn

I've dealt with several quirks of the new version of IE in the last couple days. Here's what I've uncovered:

First, in IE11, you can setup a standard anchor tag to open up an app. This will try to load it side-by-side with IE, but typically it will navigate you to a blank window in IE11, which is not ideal experience. To launch an app directly into a side-by-side window without this problem, use a hidden iframe (0x0) and set it as your app link's target. such as "<a href='skype:5555555' target='helper'>Call us</a>"

The reason is that the app loading apparently needs an window to run its launch command in. Since the window will have no content (it's all in the app), you'll get the blank window. But if you use a hidden target in the web page, only this will get the blank window, which is hidden, leaving your webpage uneffected.

The second thing I dealt with was automatic Skpe links. The new feature in IE11 is that phone numbers (plain text) will turn into automatic Skpe links. Not a bad idea, but the browser decides to style these links for you. Without your permission or control.

I had to maintain the links' functionality, but also keep the original styling. Well, you can't just write CSS. It automatically underlines, changes the color, and removes the custom font. 

Working with this, I discovered that IE11 will attempt to match the color of the link based upon its background with a couple standard defaults. EXCEPT if you have an image background, then it will let you control the color. So you'll have to force one - either with transparent background applied or some solid color background. Unless of course, you have a background image already.

The underlining (even using !important inline) won't go away. The hack here is pretty simple - set a height on the element and overflow-y to hidden. Adjust the height until the underline goes away. It's typically 1px away from actually trimming your text. You'll have to adjust a few positioning components to realign things. 

I couldn't figure out a workaround for the font, but it will respect serif/sans-serif. 

That's it so far. The first issue is not necessarily a problem. The ability to quickly open apps especially things like Bing Maps is pretty cool and fast, but I just wish that I could've found documentation or an example someplace to get this behavior. 

The second issue however is crap. There is no point that a browser should be given the right to restyle a page. The standard for phone numbers thus far has been to create "tel" hrefs. Those are in fact ignored by the Skype linker, meaning, if you want to give users the option for your site, you have to have 2 layouts. And one of those will not let you style it. 

I know it's intended for convenience, but some numbers I may not want highlighted. In fact, that was the only information I could find on this subject - to simply eliminate it. Well, if you're in the middle ground, you have this struggle, which isn't empowering. It's now a quirk, alongside all our other fun tidbits with the legacy browsers. 


10 Print

10 Print
 is boring, code fetishist, smary, unbalanced and probably worth a read. 

Officially titled some long string of code I won't bother to repeat, the collection, part of MIT's Software Studies series, is made up of small essays surrounding a one-line program that when run on a Commodore 64 produces an infinite random maze.

Hitting on the general topics of mazes, the hardware of the 64, porting the program to other platforms, the nature/history of BASIC, randomness and traversing the maze produced, the book does a fine job of trying to hit this topic from every possible angle. Doesn't hurt that the cover is pretty freaking cool and the nods to the platform itself (64-style font for page numbers, listing chapters like BASIC line numbers, and the emblatic Blue of the 64 system) are also fun, especially, I imagine, if you were learning about those elements for the first time. 

The technical discussions, the historical tangents and the play with the program are the goods of the book. Showing the program in various 3D formats using the Processing language, porting it to the Atari and explaining path traversing in BASIC would really on point and carefully walk the line of exploring a technical subject with the aesthetic value of its output. 

The writers do a fine job of drilling down technical topics, emerging why subtle details of chip design, BASIC and business decisions have large reprecussions on computer function and expressiveness.

I insulted the book at the beginning of this post, and I should explain it. The book is aware that it's both smart and cool. While I enjoy feeling smart and cool, the subject is actually very interesting on its own and doesn't need attachments of hipness. Unfortunately, a lot of the chapters read like grad student responding to a writing prompt, pulling in complexity and reach as much as possible. While the authors never overreach, there's a lack of what makes good computer enjoyable which is genuine interest and exploration of a machine or language. 

There's already so much to say and go into, that reaching far out isn't necessary and is detrimental to the actual work ahead. A discussion on the history of mazes, regularity and randomness in art, while interesting, are essays about those matters that touch on the 10 Print program or use it as a jumping off point simply because that's what the book is about. While this makes the book far richer and posed for general audience acceptance, they clash with the books later more technical chapters and come off as "Look at all the tangents I can go off this small subject." 

I don't feel the authors failed in answering the prompt, but unfortunately this isn't about grading. The chapter on grids in art definitely turned me onto to new artists and have enriched my appreciation of organization in art, but they told me nothing new about the core subjects of the book. Essentially, they were out of scope.

But what is on about this book is spot on. 


2 Games I made in jest

Walken: The Fish with No Chance. 

During secret santa at my company last year, our UX Director was given a fish. A live fish. Do not give fish as a gift, even to small children. Shockingly it died over News Years. I made this game over the course of a couple weeks at night to commemorate this lost fish and to pay homage to the same company's Window's Store game Newton.

The Moutains of Meaninglessness

I had been reading a lot of apologetics and Russell last year. My company was building a demo for Microsoft to promote HTML5 game dev for the Windows 8 store called YetiBowl. Having a little fun with the pereception of Russell, I made this while going through some episodes of 30 Rock.

By the way, there's a bunch of bugs. But JEST!

Why I bought R.O.B.

I own lots of old vintage computer and gaming stuff. It's something I'm into. I like simple systems that are easier to wrap my head around. There's a charming simplicity to it all.

ROB - the Robotic Operating Buddy - is a piece of shit I have no interest in every getting my head around. 

ROB is an additional controller that hooked up with the original NES. He even came with system if you paid a little more. He basically only plays two games - Gyromite and Stack-Up. Which suck as well. The professional below bitches much better about the awfulness and absolute unplayable nature of these games. Specifically, because of ROB's failture to work correctly or time his motions right with the the game.

So why buy it? Because I've always wanted it. Seriously, back in the day, I really imagined that ROB actually had some of sort of personality to him and would be this super smart robot who would advance my pretty pathetic gameplay. If you watched the video above, obviously that wouldn't have been the case. Nostalgia sets in deep, I even have the The Office Nintendo Player's Guide, which lists a category of games know as the "Robot Series." Guess what - it's Gyromite and Stack-Up.

 However, I did want ROB for another reason. I like to see the faith people had in technology and the exploration it took in the past. ROB may have been quickly rushed to market to add novelty to a system that would be forever praised for its basic elements: games and square controllers. Call it desperation or Nintendo thinking kids will buy anything (guess they were right in my case), but holding ROB now, I know that, someone years ago thought that this was where games and human interaction with computers may be headed. 

Perhaps that's a little idealistic on my part, but I've been one of those people my whole life. Less so now, but I looked at games like Burncycle and I imagined the possibilities of such a medium.  

I didn't by any means think that it was the only and end of development, but it allowed me to really think about where I thought technology was going. It was a good practice. I still think of ads for games and movies that I knew nothing about and where I imagined their plots, most of the time, the actual plot (sans my idea for Jurassic Park) I enjoyed more.

When I looked at my lifeless ROB (I couldn't really afford a working one), I see the start of that process for me. I know it's nothing special, that quality, or even collecting for nostalgia's sake, but those reflective eyes remind me, not of a carefree time, but a place where I was forced to imagine the possibilities rather than be disappointed by their implementation. 


The worst waste of time is my exceptionalism. 

This is a two-fold:

The first component is my use of exceptions to excuse poor behavior. Oh, I worked late the other night, well I probably deserver to stay up all night drinking whiskey watching AVGN videos for the 400th time. I'll make an exception. Just this once.

The second part is assuming that I'm exceptional, by which I'm mean, espeically good at what I do or smart. That is irrelevant, though I'll just save myself some mockery and say I'm not either. Rather, imagine that you had an sweet truck and a bunch of dope ass ropes and shit. You agree to help someone move and don't show up till 10pm because your truck is so bitching as if it would compensated for their requested rendevous time of noon. That's what I do.



Deepity is a new term for me. I've grown rather fond of trying to identify them in my daily life. Unfortunately, I believe I'm the number one source of them.

A collision of discussions about business opportunities and this term, made me start to look for them in software development, or rather the business component of software.

Starry-eyed programmers may dream of creating a Facebook or Google, and may have, in an attempt to align themselves with these giants, developed some nebulous idea for what their billion dollar company will do: "Connect", "Engage", or "Expand".

Fortunately, software really brings this to deepity practice to a halt. Software and its many development practices, asks the question right up front - "What is this going to do?" Or some variant like "What's the deliverable?" "Lay down the starting feature set?" Even without wasting your time building up user narratives or ideal user scenarios, your confronted with the limitations of deepity.

Thus here comes my didactic - If you can't lay out exactly what your billion dollar software will do in these simple terms, you can't program it and you don't really have an idea. You have something that sounds right  - "People need to connect" - but doesn't really provide much value. 

So on that, and make sure to throw that in the face of the every hundreth person with a start up idea.

Revising Stories with Rails

I love rails. I love that I can sit do and just sweep through the model layer, building out all that abstraction for an applicaiton within a couple hours at most. Likewise with the view layer, using the prebuilt urls (new,create,show,edit...). Reusing partials throughout, so I can take a static site and use some of the partials to build a dynamic one. It's fucking beautiful.

That said, when I first got into Scrum and was looking out building stories within the rails framework, it occurred to me that a lot of what made rails fast for development didn't exactly work for how I was writing stories. So I had two choices - change how I developed in rails, or changed how I wrote stories. 

Well, it was obviously not going to be the first, so I changed the second. The main change wasn't so much the stories themselves, but the expectations that followed teh stories.

For example: "User can save a new contact." Off the cuff, this sounds like it would require a build from the model to the view layer, especially if the contact form was actually a lightbox or some pop-out, which would require some JS/CSS magic. Rails exposes that this may be a too big of story, or maybe that I need more backlog items in order to actually cover it.

Here's what I built instead:

- A new contact can be saved.
- A user can save a contact through a webform.
- Webform is integrated into the dashboard and a user can save there dynamically. 

How the last two make sense as added features and they fit with my eulogy to rails above. First I build a form using the standard new template, then I render that as a partial once I get to dashboard integration. In this situation, I can do tests against the form, and leave all the work of the final feature to template/visual work rather than submission/controller work. 

Finally, the first feature, segregates the model work to its own feature. A great way to confirm this functionality is to lean on the Unit test system that comes with rails. Now I could theoretically put all of my model tasks into one sprint and have verification of my feature, with the additional benefit of always having the ability to easily do regression testing. 

Clients may not find this as sexy, but I think most folks get that setting up saving is the first step in building an application and the UI comes next, even if all you have to show (if required) is the console confirming save and data retrieval.