Tales from a JavaScript Developer

Simple Concurrency in Go

| Comments

I have been hearing about Go a lot lately including it being the most requested language at my work. This got me interested in why people find it so appealing. Developer enthusiasm boils down to one of a few reasons:

  • The New Hotness
  • Marketing (Develop 50% faster, that’s more time for showers!)
  • Developers wanting to learn something new

I fell very strongly into #3. I like to get my hands dirty, and learning a new language is a great way to do that. It gives you an opportunity to look at old problems in new ways. As somebody very experienced in JavaScript, I ususally groan at the site of static typed variables and compiling. However, there’s a few things in http://golang.org/doc/faq#What_is_the_purpose_of_the_project that really strucky my fancy. Go is statically typed compiled code and it’s excellent at catching errors right at compile time. It has super simple http://golang.org/doc/effective_go.html#concurrency with goroutines and communication channels. I’ve also found http://golangtutorials.blogspot.com/2011/06/formatting-go-code-with-gofmt.html to be very convenient and frees me from all the tedious steps of formatting my code.

Let’s do some examples.

utils.go
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
package utils

import(
  "fmt"
  "io/util"
  "net/http"
)

type HttpResponse struct {
  Url      string
  ByteStr  []byte
  Response *http.Response
  Err      error
}

func Get(url string) (chan *HttpResponse) {

  channel  := make(chan *HttpResponse)
  client   := &http.Client{}
  req, _ := http.NewRequest("GET", url, nil)

  go func(){
      resp, _ := client.Do(req)
      
      defer resp.Body.Close()

      bs, _ := ioutil.ReadAll(resp.Body)
      if err != nil {
          fmt.Println(err)
      }

      channel <- &HttpResponse{url, bs, resp, err}
  }()

  return channel
}

This example takes a url and makes a network request within a go routine. The function immediately returns a channel while the network request is being accessed in the background. The caller code looks like this.

main.go
1
2
3
4
5
6
7
8
9
10
11
12
13
package main

import (
  "fmt"
  //The utils code above is available by calling `go get github.com/drewwells/utils`
  "github.com/drewwells/utils"
)

func main() {
  channel := utils.Get("https://api.github.com/users/drewwells/repos")
  resp := <-channel
  fmt.Println(string(resp.ByteStr))
}

This code gets a reference to the Go channel and blocks waiting for any messages on the channel. This is a trivial example, but shows you how things happen asynchronously and it’s very easy to block where needed for concurrency. In this case, we block by attempting an assignment from the channel returned from utils.Get.

Pipelines in Go Templates

| Comments

go

Go templates mix an excellent blent of flexibility and powerful features. The html/templates package even has context aware templating for handling HTML escaping and JavaScript variable declaration.

One thing I tripped over is using the very powerful pipeline feature to specify custom pipelines. This worked fine for a single template, but I kept getting.

1
panic: template: view.tmpl:9: function "titleExpand" not defined

Doing this on each template is cumbersome, here’s how I applied titleExpand to all templates.

main.go
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
import (
     "html/template"
)

type Page struct {
   Title string
}

var funcMap = template.FuncMap{
  "titleExpand": TitleExpand,
}

var templates = template.Must(template.New("").Funcs(funcMap).ParseGlob("*.tmpl"))

func TitleExpand(args ...interface{}) string {
  ok := false
  var s string
  if len(args) == 1 {
      s, ok = args[0].(string)
  }
  if !ok {
      s = fmt.Sprint(args...)
  }

  return "Title: " + s
}

func renderTemplate(w http.ResponseWriter, tmpl string, p *Page) {
  p := Page{Title: "Blog Post"}      
  err := templates.ExecuteTemplate(w, tmpl+".tmpl", p)
  if err != nil {
      http.Error(w, err.Error(), http.StatusInternalServerError)
  }
}

Working With Dppx

| Comments

CSS3, SASS

There’s a better metric in retina detection called dppx, Chrome Canary will now warn you for continuing to use dpi.

Glossary

  • device-pixel-ratio: Number of device pixels per CSS Pixel
  • dpi: Dots per inch
  • dppx: Number of dots per px unit. 1dppx = 96dpi

Now your first question, why do we need dppx when device-pixel-ratio exists? Well in typical fashion, CSS was too slow on fixing the CSS resolution problem. In order to make retina usable in CSS, webkit invented device-pixel-ratio. This number while convenient is non-standard, awkward to type, and doesn’t align well with CSS resolution in the original spec. Thus, dppx was born.

Currently, a combination of device-pixel-ratio and dpi are used to target retina devices. Due to the varying support of these CSS data types, our media queries look a bit weird today. An example, Bourbon 3.1.6 has a hidpi tag that takes as input device-pixel-ratio and generates the others for you.

1
@include hidpi(1.3)

Outputs:

1
2
3
4
@media only screen and (-webkit-min-device-pixel-ratio: 1.3),
    only screen and (min--moz-device-pixel-ratio: 1.3),
    only screen and (-o-min-device-pixel-ratio: 1.3 / 1),
    only screen and (min-resolution: 125dpi)

A recommended change may be this:

1
2
3
4
@media only screen and (-webkit-min-device-pixel-ratio: 1.3),
    only screen and (min--moz-device-pixel-ratio: 1.3),
    only screen and (-o-min-device-pixel-ratio: 1.3 / 1),
    only screen and (min-resolution: 1.3dppx)

Yet, the likely outcome will be this:

1
2
3
4
5
@media only screen and (-webkit-min-device-pixel-ratio: 1.3),
    only screen and (min--moz-device-pixel-ratio: 1.3),
    only screen and (-o-min-device-pixel-ratio: 1.3 / 1),
    only screen and (min-resolution: 1.3dppx),
    only screen and (min-resolution: 125dpi)

I checked out the support. As per usual, it’s strange: CSS Resolution

Using Bourbon Neat

| Comments

In my last post, I talked about what I had done but not how I did it. Now let’s get into the nitty gritty of Bourbon Neat.

Bourbon is installed via the neat gem, once installed you can call neat to manage everything about neat.

    neat install
    neat update
    neat remove

This will install neat to a subdirectory, much like how bourbon is installed. The beauty of SASS is that we now have installed a ton of fundamental CSS functionality, but we get to pick and choose which features we want to take advantage of. This lets me use all that neat has to offer but only pay the pageweight of the things I choose to add.

To get started, you will want to setup a few things. This is all explained in their documentation. Here’s a basic config

     @import "bourbon/bourbon"; // or "bourbon" when in Rails
     @import "grid-settings";
     @import "neat/neat"; // or "neat" when in Rails

_grid-settings.scss

     @import "neat/neat-helpers"; // or "neat-helpers" when in Rails
     $grid-columns: 10;

     // Define your breakpoints
     $mobile: new-breakpoint(max-width 480px 4);
     $tablet: new-breakpoint(max-width 800px 8);

This instructs Neat to use a 10 column grid by default, 8 in tablet, and 4 in mobile.

Bourbon Neat

| Comments

Bourbon, Responsive Web, SASS

At work I was tasked with building a new Tablet version of the site. As a greenfield project, every stakeholder had two cents on how the project should go. Things I heard:

  • We need fat finger support
  • Our desktop site is ugly
  • How can we improve click through rate on Tablet?
  • Can we support responsive web aka Browser Wanking?

As many projects go, we leaped straight into answering all these questions without really thinking about what it all means. We begun building a new store page from scratch, then something happened. We realized we were not answering any of the big problems with web design. Standards. It is very common to build blindly, reusing nothing, and making nothing reuseable. We went back to the drawing board and a word that came up a lot was Grid Layout.

From a developer perspective, Grid layout is really design-speak for modular designs. Instead of having 6 different versions of what a button looks like, we now had one with different colors. Heights, line-heights, and font-sizes are now all standard thanks to maintaining vertical rhythm throughout the design. Dead are the days of making several variations of the same input field, wrapping text in spans, paragraphs, or divs to provide 3 variations of font size in the same block element.

Here’s a screenshot to show the difference.

We simplified the design of the page and as a result the CSS was much simpler. By making the offer larger, we also made more room for larger font size and buttons with more defined click targets. Instead of focusing on making our buttons bigger, we made all text margins larger and uniform. The page now has a steady rhythm going down the page.

Under the covers, this was a matter of having being consistent with our design and CSS. Line heights have a consistent ratio and margins are always standard multiples of our pixel ratio. When exceptions are made it’s on purpose, not on accident. For frameworks, I settled on Bourbon Neat. I was familiar and impressed with the bourbon mixin library, so it was an obvious choice to use Bourbon Neat. Thoughtbot does an excellent job integrating perfectly with SASS. If you are already using SASS, I would highly recommend using Bourbon.

Bourbon Neat is a framework for implementing a Grid Design. Installing Bourbon Neat is as simple as running:

    gem install neat

Enjoy!

New Job

| Comments

life

I started a new job and haven’t had much time to update the blog or various github projects. Well actually I’ve had plenty of time to update these, but I haven’t due to major data loss with my SSD.

As part of the job move, I have also relocated to Austin, TX. It’s been a pretty stressful move, but everything is in it’s place now and I’m back on track running regularly. Hopefully, I will be in great shape prior to the 115F summers here.

I have decided this year I will learn Erlang. I will be somewhat starting over thanks to the SSD failure. Going to a strict functional language is quite interesting. I also end up spending hours and hours just to write 2 lines of code. Erlang is pretty good at doing a lot of amazing things in just two lines of code, but it does take a while to get there.

Octopress has become very difficult to manage, I would have updated this sooner if I was still on Wordpress.

Peace out

Getting More

| Comments

life, social engineering

I’ve been reading a book lately, okay that’s a lie. I fell for the Audible trap and have been listening to a few audio books lately mostly while driving in a car. The book in particular is Getting More.

Audible is great, especially if your family and girlfriend are a three to five hour drive away depending on Atlanta traffic and if there is a Knoxville/Florida game that weekend. My only beef with listening books instead of reading them is the time involved. Even the slowest readers can get through a book much faster than the artful narrations these Audio books are read as.

I mostly read technical books, so I will talk about it in terms of what I understand. I would call this book a cookbook for effectively communicating your desires to others. For those unaware, a cookbook is the opposite of a technical reference that exhaustively enumerates every facet of a topic. A cookbook tries to come up with an extensive list of problems you may encounter and provides solutions to those problems.

Take for instance a cookbook on kitchen disasters. It may go something like this.

Problem: You burned the cookies. They are dark brown but not black

Solution: Serve the cookies with milk and nobody will notice the difference.

The key part of books is organization. People will buy these books then refer to them over and over, so you want to make it easy for them to find what they are looking for. On this part, the author does an excellent job separating the topics into very descriptive categories, he understands pronouns and being vague are poisonous to Getting More. He has sections for work, getting hired, children, sales, and business situations.

I would also applaud his ability for effectively illustrating techniques for Getting More. The entire book could be shortened to this.

  • Don’t assume, listen
  • Be incremental
  • Role reversal
  • Framing
  • Trading things of unequal value

The one you may not be familiar with is framing. Let’s say you wish your girlfriend would support you in you exercise routines by participating. From her point of view, she doesn’t like to exercise or to be outdoors. You tell her that running together will help us reach our mutual goals of us spending more quality time together (and you losing some weight).

Let’s say this isn’t enough for her to justify the energy expenditure. You can use framing. Explain to her that her commitment to run with you on a regular basis will show that she is able to keep committments. In return, he will be more likely to commit to her.

If this still isn’t enough, we can use trading things of unequal value. She supports you in your exercise routines, and you support her with some fancy jewelry that she has been wanting.

From this point of view, how could she NOT agree that running together is a mutually beneficial thing?

He has many other methods for when these techniques are not enough, in my opinion they are borderline bribery, taking advantage or plain abuse of skills. He talks extensively to defend those techniques on how they were used, and why they are mutually beneficial. He obviously is naturally very persuasive, and be prepared to have these themes repeated many timesover. Each and every one of us has trouble listening, so repetition is key to learning the topics in the book.

Conclusion

I have unfortunately not used the skills in this book effectively. He will remind you over and over that the keys to Getting More is to practice Getting More. So I endeavour to practice these skills, and serve myself better by Getting More myself.

My Adventures Into WebGL

| Comments

So I have been pretty busy trying to get into WebGL. It is easily the best way to have a bad time in programming right now. The combination of experimental browser support, bad linux drivers, and JavaScript’s direct mapping to very old C code made it quite difficult.

I started by looking at a Learning WebGL. I 100% recommend this especially if you are unfamiliar with the domain. Why would you keep reading this if you weren’t? If you go through these lessons copy/pasting code, you will think this is simple. However, the first thing I tried was tweaking things.

Who wants a pyramid? I made a triangle cube. Who wants a cube with solid color sides? So, I made a cube with blending (gradients).

The first thing I noticed, you ever heard of perma-death games? One typo, one vertex without a color and the whole thing fails to load. There’s no 1%, 50%, or even 99% working it’s all or nothing. So, much of my time was debugging the tiniest details of my application.

One time, I spent two hours drawing and staring of my 3d object on a piece of paper. It actually didn’t help at all, the real problem was totally unrelated. I think maybe paper helps those people either with super complex or super simple problems. Mine was a problem of misunderstanding so staring at a 3d model on a 2d piece of paper did not help me.

So I will go into the most basic details here. What is WebGL and why is canvas so much better? Let’s say I want to draw a square.

I define my 4 points and tell OpenGL to go draw it. OpenGL says go fly a kite. OpenGL only understands triangles. There are two ways to do this. A triangle for every 3 vertices (gl.TRIANGLES), or one triangle, then every subsequent point forms a new triangle (gl.TRIANGLE_STRIP). Obviously, the second one is ideal as it is far more efficient on the GPU to reuse existing vertices. However, if you use the strip it will treat every new point as the foundation of the next triangle. This can cause significant problems if you want to connect vertex 3 to vertext 7 and 8. You can get some really crazy shapes that made my brain hurt looking at them.

Next post, I will start getting into the code behind Graph 3d and try to justify the few dozen hours I lost working on it.

Jodoc-js

| Comments

javascript, projects

So it’s about time to post an update on things I’m working on lately which have been a lot, just look at my github feed: https://github.com/drewwells

Today I want to talk a bit about the documentation framework we are now using at work. It’s rather fantastic and based on a python implementation: https://github.com/davebalmer/joDoc. It hasn’t been updated at all this year, but azakus has ported the whole thing to NodeJS!

The idea is quite simple, take markdown based comments in your JavaScript file and throw them into a web page. How hard was that? No complicated syntax, no huge comment blocks to facilitate special formatting. KISS.

So!

What does this thing do, and why should you care?

First off markdown knowledge would be good to know. You have two paths here

I know markdown, but rusty on syntax Try my demo I don’t know markdown give me the Full details

Sample JavaScript file

file.js

1
2
3
4
5
6
7
8
9
10
11
/**
# file.js
Some information about the file.  The h1 above is
## main

Hey what is this, C code?
*/

function main(){
  return 'I am not C code, see ' + 5;
}

So, thanks to the /** part you will get a big h1 tag with ‘file.js’ which also acts as the index. Anywhere you link to [file.js] now links to the html page created for file.js.

There are two forms created, single file where links use hash tags to find documentation, or multi page where each html page is run through a template and an entire page with header links is provided.

Fring features: I have been adding cool features to it which can be found in ‘joapp-experiment’. I’m working with the owner to get these integrated into his repository.

File based configuration

Currently, you must maintain complicated command line scripts to use it. Why must it be so? It’s great to put these in a build tool, but sometimes you want to set it and forget it. So I have implemented via ‘require()’, Node 0.3.0+ I think, to require a separate file. This is cool, because those files can require other files say to provide a dist and a dev version of your docs <3 require().

I made a pull request for this feature on 9/8 and here it is 2 weeks later without even a comment: https://github.com/azakus/jodoc-js/pull/10. It includes a demo since I properly commented jodoeJS itself to dogfood and provide an easy demo for others. There are notes on how to use this in the README.

Serve the docs via NodeJS as a web page

It’s cool that the docs run in NodeJS b/c they are sub second fast. But why do I need to run a build command to get them going? Can’t NodeJS serve to a browser instead? The answer is Yes it can. So I wrote a small web server inside the app. It has no dependencies, so it’s very simple and dumb. I had to add proper mime-types for picky browsers like Chrome.

As the HTML is created, it is sent to the browser by hitting the URL in your browser. It can also serve the files created on disk, but way less cool. Oh did I mention, it will reparse all your source files before doing so? So, if you are actively writing documentation just hit refresh to see your changes. It couldn’t be simpler.

Testing for Optional False Params in JavaScript

| Comments

Sounds like a silly thing, but sometimes you want optional false parameters. If for nothing else than to make your parameters human readable, not just syntactically convenient.

So let’s start out:

1
2
3
4
5
var config = {
  //blur: false
};

!config.blur //Oh noes reports true

The trick here is to detect whether the variable is undefined, then for it’s truthy value. Fixed implementation:

1
2
3
4
5
6
7
8
  if( !config.blur === false ){
  //Won't execute
  }
  config.blur = false;

  if( config.blur === false ){
  //Will execute
  }

Pretty cool huh? Test with if/else structures or you will get errors.

Update: Thanks Toby for that one