Memerocket

Use Java Lambdas Instead of Method Refs Sometimes

Sat, 27 May 2017 15:59:16 +0000

Java 8 method references are super useful in expressions like these:

Comparator.comparing(
    Person::getLastName,
    String.CASE_INSENSITIVE_ORDER)

Comparator.comparing is a generic method. Here’s its signature:

static <T,U> Comparator<T> comparing(Function<? super T,? extends U> keyExtractor,
                                     Comparator<? super U> keyComparator)

When calling comparing(), the first parameter (keyExtractor) can be provided in one of three ways:

a method reference (as shown in our example)
a reference to a Function object
a lambda expression

Which alternatives you may use depends on the situation. Depending on the situation, the compiler will either use the expected return type^[1] (of comparing()) to determine the type of keyExtractor, or it will use the type of the first parameter to determine the return type. In the latter case either a method reference or a reference to a Function object is required, since a lambda, in general might not carry sufficient type information.

Method references are also often seen when map()ing, either over streams, or Optionals like:

Optional<Speaker> speaker = Optional.of(new AdmiralStockdale());
System.out.println(speaker.map(Speaker::speak).get());

On the second line, though, the compiler knows the type of speaker, so it knows the type of the map() parameter. Here’s map()’s signature:

public <U> Optional<U> map(Function<? super T,? extends U> mapper)

U is known from the declaration of speaker. The type information carried by the method reference Speaker::speak isn’t actually needed in this case.

Not only is it not needed, it represents a minor but annoying maintenance trap. By explicitly specifying the type of speaker and also explicitly specifying the type of the first argument to map() we’ve set them in opposition when they needn’t be. Sure, the compiler will tell if some future code change causes them to be incompatible (say if the speak() method moves to another class or interface), but wouldn’t it be better if the map() expression was decoupled entirely from the name of that class or interface?

Since the compiler doesn’t need that extra type information, and since we pay a price in maintainability by including the extra type information, it’d be nice if we had another way to specify the method to map().

How about a trivial lambda:

System.out.println(speaker.map(s->s.speak()).get());

This code is shorter s->s.speak() versus Speaker::speak. It also has the advantage of not tightly coupling the expression to the interface name. By efficiently leveraging type inference, we’ve improved our code.

Here’s a little Github repo with the Java code: Lambda vs Method Reference on Bill’s Github

Summary

In Java 8, functional interfaces, method references, and lambda expressions provide wonderful new opportunities to create higher-order functions. In some situations, though, a method reference, by saying too much, presents a little maintenance trap that can be avoided via a trivial lambda expression.

Footnotes

[1] This is called the “target type” in Java type inference parlance.

These Are Not the K Combinators You Are Looking For

Thu, 25 May 2017 13:57:46 +0000

Since version 1.9, Ruby has had Object#tap. tap started life as Rails ActiveSupport Object#returning. Here’s the old Rails source code:

# A Ruby-ized realization of the K combinator, courtesy of Mikael Brockman.
#
#   def foo
#     returning values = [] do
#       values << 'bar'
#       values << 'baz'
#     end
#   end
#
#   foo # => ['bar', 'baz']
#
#   def foo
#     returning [] do |values|
#       values << 'bar'
#       values << 'baz'
#     end
#   end
#
#   foo # => ['bar', 'baz']
#
def returning(value)
  yield(value)
  value
end

Pass returning an object and a block and it returns the object, after running the block on that object. Object#tap is a slight variation on this theme^[1].

Clojure has a similar function called doto that generalizes the idea. Here’s an example:

;; Note that even though println returns nil, doto still returns the HashMap object
user> (doto (java.util.HashMap.)
            (.put "a" 1)
            (.put "b" 2)
            (println))
#<HashMap {b=2, a=1}>
{"b" 2, "a" 1}

The comment in the Ruby on Rails code and Jamis Buck’s, 2006 Mining ActiveSupport: Object#returning refer to this functionality as an example of the K combinator. Though returning and doto are useful, and they can really improve your (object-oriented, side-effect-dependent) code by making your intentions plain, they are not examples of the K combinator.

Contrary to Buck’s analysis, a K combinator is not really a “function of two arguments”. Well, in a curried language like Haskell, it is usable as a function of two arguments. But the way that (potentially) two-argument function is almost always used, is as a one-argument function that produces a function. Dig Haskell’s const, an actual K combinator:

const :: a -> b -> a

Indeed you see what is potentially a two argument function. But the way const will be used is:

>>> map (const 42) [0..3]
[42,42,42,42]

See what happened there? const 42 produces a function, which, when passed any parameter, e.g. 0, 1, 2, or 3, will just return 42.

Similarly, Clojure has (constantly x) that:

Returns a function that takes any number of arguments and returns x.

These are K combinators.

Object#returning and doto are certainly higher-order functions (doto actually happens to be a macro) in that they take a “function” as a parameter. In the case of Object#returning the “function” is a block. doto is a bit more general in that it takes one or more forms, not merely functions.

But neither Object#returning nor doto, in general, return a function. Contrast this with const and constantly, both of which return functions.

Summary

Ruby on Rails’ Object#returning, Ruby 1.9’s Object#tap, and Clojure’s doto are useful for clearly delineating code whose only purpose is to introduce side-effects on or about some target object. Examples include:

tracing for debugging
multi-step object initialization through setters

These are higher-order functions in that they each take a functional argument (or in doto’s case, one or more). None of them, however, in general, produces a function.

The K combinator, as exemplified by Haskell’s const and Clojure’s constantly, is useful in cases where you need to succinctly construct a function that, irrespective of its argument(s), always returns the same value. A K combinator is a higher-order function that produces a function.

Object#returning, Object#tap, and doto are not K combinators. const and constantly are. These are two useful, but distinct, concepts.

Footnotes

[1] Whereas returning yields its first parameter to the block, tap yields self and so it only needs a block parameter.

Hamstar Transforms Immutable Ruby Collections Better

Sun, 01 Nov 2015 05:44:41 +0000

When working with Amazon’s AWS SDK for Ruby there are two flavors of API. The most mature parts of AWS have what’s called a resource interface. These are fine-grained object-oriented interfaces to AWS objects. Want to delete a bunch of objects having the /tmp-files/ path in an S3 bucket? Easy:

bucket.objects(prefix: '/tmp-files/').delete

That’s a convenient way to deal with S3 buckets. Alas vast swaths of the AWS service-space have no such convenient interface. Those services offer only a thin veneer over the underlying REST interface via a client object. A prime example of a service offering this more primitive interface is the EC2 Container Service or ECS.

If you want to say, change the version of a Docker image, referenced within an ECS task definition, the process is:

call describe_task_definition to retrieve the structure
pluck the container_definitions array from the structure and modify the image value for the container of interest
call register_task_definition, passing the doctored container array

Ruby is pretty good at this sort of thing. At step 2, you just mutate the structure retrieved in step 1. At step 3 you submit part of the mutated structure back to AWS.

If you’ve spent any time programming in Haskell or Clojure though, you may be hankering for a more “functional” solution. Do you really have to mutate that big complex structure? What if later you found that you needed two different versions of the structure, with two different mutations? Would you retrieve the structure from AWS twice? Or would you think about “deep cloning” the structure each time? That way lies madness.

First, we’ll take a look at how we would usually approach this in Ruby, then we’ll look at how a Clojurist might think about the problem, and finally we’ll apply a more functional appproach to our Ruby solution. In the process we may even do Clojure one better!

The Problem

The AWS ECS client returns a structure something like this from describe_task_definition:

response = {
  task_definition: {
    task_definition_arn: 'some-arn-string',
    container_definitions: [
      {
        name: 'front',
        image: 'nginx:1.7'
      },
      {
        name: 'my-python-web-app',
        image: 'my-python-web-app:latest'
      }
    ]
  }
}

Now there is a lot more stucture in the actual response. I’m just showing the parts that are essential for our discussion.

What I’d like to do is upgrade the NGINX Docker image used by the container named “front”, to version 1.9. Note that in my upgrade script, I don’t know what version of nginx is currently in place, nor do I want to upgrade every reference to the NGINX image. I only want to upgrade ‘front’ to NGINX version 1.9.

Here’s some typical Ruby to do the job:

response[:task_definition][:container_definitions].each { |c| \
  c[:image] = 'nginx:1.9' if c[:name] == 'front' }

Now our response object can be submitted back to the server. But what if we didn’t want to mutate the original (deep) structure? Let’s just do a plain old clone of that object and see what we get:

> r2 = response.clone
> response.__id__
 => 2155921900
> r2.__id__
 => 2161504860

So far, so good: we’ve made a copy of the response object! But wait:

> response[:task_definition].__id__
 => 2155921940
> r2[:task_definition].__id__
 => 2155921940

While the top-level Hash has been cloned, the internal values have not. This was not a deep clone.

You may want to take a moment now to follow the rabbit down the hole of deep cloning Ruby objects. Or you may want to go shave your yak. I’ve been down that hole and I’ve spent time with the yak and I believe there is a better way.

Forget Deep Cloning: Use Hamster’s Immutable Collections Instead

When we program in Clojure we never clone anything. Why is that? Well its because the day-to-day operations we perform on collections always automatically create what appear to be brand new, modified, copies. Part of the magic of Clojure is that this illusion is efficiently maintained. Hint: your structures aren’t really deep cloned every time you would otherwise mutate them. The Clojure Data Structures page explains it well.

Can we use the same idea to completely side-step this problem in Ruby? Well yes, we can! Some smart people already created a Clojure-like immutable collections library for Ruby. The Hamster Gem gives you a set of collection classes that mirror the familiar Ruby ones like Hash and Array. But the Hamster classes provide immutable operations (Hamster API documentation is here).

Here’s the Hamster code:

require 'hamster'
ri = Hamster.from(response) # convert to immutable containers
containers = ri[:task_definition][:container_definitions].\
 map{|c| c[:name] == 'front' ? c.put( :image, 'nginx:1.9') : c}
pp Hamster.to_ruby(containers)
[{:image=>"nginx:1.9", :name=>"front"},
 {:image=>"my-python-web-app:latest", :name=>"my-python-web-app"}]

We convert the response to immutable collections and then we use map to create a brand new container_definitions array (Vector). We examine each Hash in turn. If a hash has :name 'front' we apparently create a brand new hash. Hamster magic takes care of making that apparent duplication efficient. The new structure will share the unmodified parts of the original. Only the modified parts will require extra storage.

This is fine if we only need to modify one collection. But what if we wish to retain the deep structure? The Hamster example just given isn’t actually doing everything our original Ruby example did. This first Hamster example is only creating a new containers vector. What about the enclosing task_definition hash?

It is not necessarily obvious that immutable versions of Hash and Array will be sufficient for this task. The response structure is a hash containing a hash containing an array of hashes. Will Hamster provide a way for us to modify these deep structures in nested containers and create new nested containers (i.e. create the illusion of creating new nested containers)?

The answer is “yes!”. Hamster provides an update_in() method that works just like Clojure’s update-in() function. It’s accessed as a method on Hamster’s Hash and Vector classes and it is generic enough to transform deep structures consisting of Hashes and Vectors.

Hamster update_in() takes a path specification of “keys” (hash keys and array indices) into your deep (hash and array) structure and applies a block to the target value, deep within the structure. Applying that block modifies the target value, resulting (apparently) in a new collection object. As it unwinds the stack, update_in() modifies enclosing collections (apparently) creating new ones until it reaches the top-most collection. Because it’s all built on Hamsters efficient collection primitives, the whole thing is efficient.

With update_in you could, for instance, update the :image on container 0 to nginx:1.9 like this:

rv2 = ri.update_in( :task_definition, :container_definitions, \
 0, :image){|i| 'nginx:1.9'}
pp Hamster.to_ruby(rv2)
{:task_definition=>
  {:task_definition_arn=>"some-arn-string",
   :container_definitions=>
    [{:name=>"front", :image=>"nginx:1.9"},
     {:name=>"my-python-web-app", :image=>"my-python-web-app:latest"}]}}

You can see the Clojure philosophy at work here. An array or vector is very much like a hash in that an array maps keys to values. In the case of an array or vector the keys all happen to be natural numbers. Hamster has stacked the deck by providing a core set of methods on both Hamster::Vector and Hamster::Hash, that update_in() can rely on, specifically fetch(key,default) and put(key,val). We Rubyists call this duck typing. Hamster’s update_in is described in the Transformations section of the Hamster API doc. Hamster defines a mix-in module called Associable that implements update_in() for classes that meet the criteria.

Not Quite There—We Need Something More

This would be great if we always knew the index of the Vector element that we wanted to update. But in general we do not. What we really want to do is update whatever Vector element is a Hash with :name equal to 'front'. Instead of specifying Vector offset ‘0’ we’d like to specify the element whose value meets our criterion.

What if we had a function called update_having() that could take a different kind of path specification e.g.

update_in():     :task_definition, :container_definitions, 0,               :image
update_having(): :task_definition, :container_definitions, [:name,'front'], :image

I’ve created a little gem called Hamstar that does just that. Dig:

require 'hamstar'
rv3 = Hamstar.update_having( ri, :task_definition, :container_definitions, \
   [:name,'front'], :image){|i| 'nginx:1.9'}
pp Hamster.to_ruby(rv3)
=> (exact same result as before with update_in)

Oh and Hamstar.update_having() uses the case comparison operator === on your match value so you can use regexps and ranges and other interesting objects besides strings there. So if you wanted a case-insensitive match on the name you could:

rv4 = Hamstar.update_having( ri, :task_definition, :container_definitions, \
   [:name,/FRONT/i], :image){|i| 'nginx:1.9'}
pp Hamster.to_ruby(rv4)
=> (exact same result as before)

Rather than injecting update_having() into Hamster classes (as a method) I opted to implement it as a (module_function) on the Hamstar module. This is less intrusive and might make it a little more apparent that update_having() operates on compound structures of arrays and vectors.

The name “Hamstar” is a portmonteau of “Hamster” and “star”. I chose the name because of the other feature Hamstar adds, and that is the Kleene star. You can use the Kleene star to match all container elements.

Say you wanted to capitalize the :name value on every element of the :container_definitions array. Doing this with update_in() would require one call for each element of the array. With Hamstar you can do it in a single call using the Kleen star '*'. Here we use a '*'at the top-level to select every association in the top-level hash, and another '*' to select every element of the :container_definitions value:

rv5 = Hamstar.update_having( ri, '*', :container_definitions, '*', :name){|n| \
  n.capitalize}
pp Hamster.to_ruby(rv5)
{:task_definition=>
  {:task_definition_arn=>"some-arn-string",
   :container_definitions=>
    [{:name=>"Front", :image=>"nginx:1.7"},
     {:name=>"My-python-web-app", :image=>"my-python-web-app:latest"}]}}

The addition of the Kleene star was inspired by the Instar Clojure library. That’s an interesting and powerful library. It doesn’t, however, provide the associative selection that Hamstar offers.

And finally, if none of those matchers work for you, you can specify your own Proc as a matcher. Here we capitalize all names containing an ‘f’:

rv6 = Hamstar.update_having( ri, '*', :container_definitions, '*', ->(k,v){ \
 k==:name&&v=~/f/}){|n| n.capitalize}
pp Hamster.to_ruby(rv6)
{:task_definition=>
  {:task_definition_arn=>"some-arn-string",
   :container_definitions=>
    [{:name=>"Front", :image=>"nginx:1.7"},
     {:name=>"my-python-web-app", :image=>"my-python-web-app:latest"}]}}

Conclusion

Thinking like a functional programmer is new territory for me. There is a menagerie of data structures, algorithms, and techniques to master. The rewards are considerable.

It’s fun and even profitable to take some of these ideas back to our Ruby cave for experimentation. You’ve seen how the Hamster Gem’s immutable collections can be used to do an everyday job in a different way. My Hamstar Gem’s update_having() extended the functionality of update_in(), with associative selection criteria and a Kleene star.

You may look at the original (idomatic) Ruby and conclude that it is more readable than the more functional alternative. You may also encounter surprising results from your new “functional” code. For instance:

x = Hamster.from({name:'Pat'})
 => Hamster::Hash[:name => "Pat"]
x.update_in(:name){|name| name << 'sy'}
 => Hamster::Hash[:name => "Patsy"]
x.update_in(:name){|name| name << 'sy'}
 => Hamster::Hash[:name => "Patsysy"]

“The collection x is immutable—but it appears that x was modified by the first update_in()”, you say. What happened here is we used a mutating operation << on a String stored in an immutable collection. The Hamster main page says:

While Hamster collections are immutable, you can still mutate objects stored in them. We recommend that you don’t do this, unless you are sure you know what you are doing.

If we had written it this way, we would have gotten the expected results:

x = Hamster.from({name:'Pat'})
 => Hamster::Hash[:name => "Pat"]
x.update_in(:name){|name| name + 'sy'}
 => Hamster::Hash[:name => "Patsy"]
x.update_in(:name){|name| name + 'sy'}
 => Hamster::Hash[:name => "Patsysy"]

Since the whole Ruby language, environment and eco-system formed around mutability, while functional programming in Ruby is possible, there are many pitfalls. There is a heavy intellectual burden, at least initially, when you attempt to go functional in Ruby.

My experience experimenting with functional programming in Ruby mirrors what Mister Miyagi said about karate:

Miyagi: get squish just like grape. Here, karate, same thing. Either you karate do “yes” or karate do “no.” You karate do “guess so,”

from IMDB Karate Kid quotes

Clojure, on the other hand, started from a more functional place. Immutability is the default there. While you can port much of Clojure to Ruby, you may find after you’re done, that you’ve created a somewhat confusing and hostile environment.

Let Who Die?

Fri, 16 Sep 2011 18:22:35 +0000

I watched Ron Paul’s response to Wolf Blitzer’s medical insurance question and I do not hear anybody in the audience shouting “let him die”. I do hear strong applause in response to Paul’s comment “that’s what freedom is all about—taking your own risks”. And I do hear a couple audience member shouting “yeah!” to Blitzers question “are you saying that society should just let him die?” The audience reaction got a lot of attention this week. But it seems to me Blitzers line of questioning (and lack of follow-up) was the bigger story.

The first thing is that Blitzers hypothetical “young man, makes a good living” is a bit of a straw man in this context. The point of the healthcare debate is not so much about the young man who makes a good living. It’s more about the young man or woman who does not make a “good living”. It’s about the baseline we are willing to accept as a society. How low are we willing to set the bar?

Secondly, it seems to me that the obvious follow-up question Blitzer should have asked is:

Blitzer: OK Mr. Paul, well when that (uninsured) young man shows up in the emergency room after a car accident are the doctors going to treat him or not?

Now make that young man an old grandpa with Alzheimer’s disease. Or a baby with RSV. Yes I know we have Medicaid for the very poor and Medicare for the elderly. But lots of folks are falling through the cracks (about 1 in 6)!

Then it might have been nice if Blitzer quizzed Paul on the economics so we could listen to Paul’s’ explanation of how if we just let the market do it’s job, see, and privatized everything, our healthcare costs would not be rising at double-digit annual rates.

So fie on Blitzer, for the straw man of a scenario and the total lack of follow-up.

Finely Tuned

Fri, 16 Sep 2011 00:41:11 +0000

“Shostakovich and Stalin by Mait Jüriado via Flickr”

It’s hard to decide whether to loathe or applaud The BioLogos Forum. The purpose of the project is to convince evangelical Christians that evolution is real. Nobody can argue with that right? The world (certainly the United States) would be better off if fewer people thought the planet was 6000 years old and cave men rode dinosaurs right?

The part that I often get hung up on though, is the inconsistency of the argument put forth on BioLogos. On the one hand, they make the case that we should all believe in the theory of evolution because of all the really great evidence for it. Evidence is important right? We are all interested in figuring out how things really work right? Of course, especially when we are talking about something as important as life on this planet, where it came from, and where it’s headed.

But then BioLogos takes a sharp left turn. Observation and evidence and logic are really important when studying biology, but when it comes to everything else, we should really not apply those criteria. It’s NOMA you see. The crux of their position is that you don’t have to throw out your Christianity in order to believe in the theory of evolution.

One thing that has always bugged me about that position is that it seems like such a small victory. The scientific method is so much more powerful than that. Why stop with the theory of evolution I say. Why not slay more sacred cows while you’re at it? Line ‘em up and knock ‘em down. You thought the earth was flat. Busted. You thought demons caused illness. Busted. You thought we all evolved from a single breeding pair (Adam+Eve). Busted. So far so good. Why not go on… You think there is a magic bearded guy who intercedes on your behalf? Busted. You think there is a “spirit” that enters your body at conception and leaves it at death. Busted.

I get enthused. And then I am reminded of my real world experience discussing and debating these very issues with friends and family. I’m reminded of how hard it is to change someone’s mind. And when I think of that, I become much more sympathetic to the BioLogos approach. Maybe the scientists have to excuse (temporary) hypocrisy in the interest of progress. Any progress. Small. Slow. Progress.

One can view BioLogos cynically (and I often do). But one can also detect a sort of genius at work. A great example of this is the recent series of articles by Dennis Venema about his journey from de facto Intelligent Design proponent to evolutionary theory advocate:

From Intelligent Design to BioLogos, Part 1: Early years From Intelligent Design to BioLogos, Part 2: Embracing Intelligent Design From Intelligent Design to BioLogos, Part 3: An Unexpected Opportunity From Intelligent Design to BioLogos, Part 4: Reading Behe From Intelligent Design to BioLogos, Part 5: Epilogue

Venema is the perfect messenger: young, handsome, devoutly religious. His rhetoric is scientifically accurate (on the subject of evolutionary biology) and at the same time perfectly tuned to his audience. Nowhere is BioLogos’ perfect sense of their audience more evident than in the Ask an Evolutionary Creationist: A Q&A with Dennis Venema. Just look at how this question is posed:

7. From Jane (from her husband, an atheist): All of the questions posted so far approach the topic from the viewpoint of assuming belief in a god. As an atheist, I don’t share that assumption. (For those who might not appreciate it, evolution offers a mechanism for understanding the existence of living organisms that doesn’t require the existence of a god.) If you transitioned from an anti-evolutionary/pro-intelligent design view to an evolutionary creationist view a few years ago,” why didn’t you keep going and just embrace evolution and drop the theistic aspect?

For those who haven’t spent much time on BioLogos I must explain that there is almost no real debate on the site itself. Through their ground rules for commenting and their diligent enforcement, the comment section is little more than an echo chamber. Question 7 (above) though is a masterwork of subtle self-inflicted echo chamber intrusion. We have Jane (not an atheist), interceding on behalf of her husband (an atheist) with a substantive question. And it’s the very same question that’s been on my mind all along! Venema’s response, while unsatisfying, represents a fair piece of rhetoric. I admire the way Venema turns God of the Gaps around on itself in his response:

This (Jane's husband's position) is a God-of-the-gaps approach, where God has less and less to do as we understand more and more how nature works (and a view I reject). Logically, if I held this view I would view science as an inherently evil activity, since any natural explanation diminishes the activity of God from this viewpoint.

Did you see what he did there? He responds to the atheist, but he’s playing to the gallery. It is brilliant. The side effect is that he may just be able to convince his co-religionists that he’s not such a bad guy after all. He’s not an uppity scientist. He’s a true believer. Maybe there really is something to this evolution stuff.

Google Sites Adds Keyboard Shortcuts

Tue, 21 Dec 2010 23:38:41 +0000

I love Google Sites (wiki). I just noticed a whole bunch of keyboard shortcuts on the “More actions” menu. More to love!

Of Workmen, Tools and Logical Argument

Sun, 05 Dec 2010 23:04:37 +0000

I’ve often heard the saying “It’s a poor workman who blames his tools”. Remember in 2009: Twitter: blaming Ruby for their mistakes. While I agree with the substance of that post (that Twitter could’ve picked different tools or made Ruby suffice), seeing that saying again kind of set me off. Hence the present missive…

Whenever I hear (It’s a poor workman who blames his tools) used as a blanket statement it bugs me. You know, some tools really are better than others. And you know, sometimes a (workman) chooses or must make do with poor ones. Again, I’m not talking about Ruby here—I’m talking about that saying.

A quick search yielded some fascinating history on the origins of that saying. It looks like the saying started off rather differently:

Mauves ovriers ne trovera ja bon hostill. [A bad workman will never find a good tool.] (French proverb, late 13th C. )

And that usage prevailed for about six centuries or so until this:

Good workmen never quarrel with their tools. (Byron, _Don Juan_, 1818)

which is pretty close to the prevalent version I hear all the time in the software community.

The earliest version says (a poor workman can’t do good work, no matter how good the tools are). Now I can get behind that one. No controversy there.

The latest version says a good workman can do good work no matter how poor the tools are. That presumes that the workman cannot choose his tools. For if he could choose his tools then he would be evaluated on his ability to choose them, and choosing bad ones would reflect poorly on his ability. Or perhaps the workman wouldn’t even bother choosing tools at all since all tools are equally usable (to the good workman.) And that just seems absurd on its face.

Tools do matter, and the ability to pick good ones often sets the very best workmen apart from their peers.

Github Implements Agency-Aware Identity

Wed, 07 Jul 2010 01:10:25 +0000

[caption id=”attachment_304” align=”alignleft” width=”277” caption=”Github lets you specify your agency context”][/caption]

Github gave me a whole new reason to love them last week when they introduced agency-aware identity in their new organizations offering. Crazy cool. Now each of my clients can have their own Github organization and I can participate in each! Same goes for each of my Open Source projects. And I can use it for a day job if I had such a thing. And all with one identity—one set of credentials. Brilliant Github!

Watch a Video While You Work

Thu, 17 Jun 2010 21:25:27 +0000

I like to have a TED or SALT talk playing while I work on something mindless. The problem is that on my single 15” display, there isn’t really enough room to keep my work and the video (window) side-by-side. I’d like to designate the video window as the top window so that it never gets buried.

[caption id=”attachment_300” align=”alignleft” width=”171” caption=”Unsanity WindowShade X Icon”][/caption]

I found two OS X solutions, each of which appear to be OS X window manager hacks to let you force a window to float atop all the others: ∞labs Afloat and Unsanity WindowShade X. I installed the latter and can attest that (after a reboot) it will indeed keep a browser window afloat. Just select the window of interest and hit the command key twice (⌘-⌘). The keystroke is configurable.

WindowShade X relies on Unsanity’s Application Enhancer. I was concerned about security vulnerabilities introduced by that thing but since my Google searching didn’t turn up any obvious warnings I went ahead with it.

Run Google Chrome on Your Mac Now (with Extensions)

Thu, 17 Dec 2009 16:06:03 +0000

Google Chrome runs on your Mac now. Google Chrome supports Extensions now. Unfortunately, Google Chrome on your Mac doesn’t support extensions now.

Well that’s not exactly true. It’s hard to find, but you can get the developer build of Chrome for the Mac. It’s prebuilt on the Chromium Buildbot Snapshots for Mac Page. Scroll to the bottom and download the latest Zip archive. It contains the app (Chromium) which you just drag to your Applications folder.

After it’s in place, use it to browse to the Official Google Chrome Extensions site. Then check out the Google Quick Scroll Extension, which continues your Google search beyond the results page, right on the third-party pages you jump to.