Photography Goodies
Gear and gadgets:
- LR/Enfuse – This is a plugin for Lightroom that uses opensource Hugin project. The results tend to be very natural, but you don’t have much control through the plugin UI.
- Photomatix – Pretty much the standard others are compared to. The UI is a bit outdated, but you have a great deal of control over the end result. (pro and light versions)
- HDRtist – Seems like a good middle of the road option. Nice UI, good image results, but missing histogram and some more advanced features. (pro and free versions)
- HDR Pro Photo – Haven’t tried, looks full featured, on sale in the Mac App store.
- HDR Express — Haven’t tried it, looks like it is full featured, on par with Photomatix, but a better UI.
- Others in the Mac App store… none stand out
Nikon P7000 Notes
The p7000 is almost the perfect high end compact camera:
- raw support
- excellent zoom range (better than the G12 and LX5)
- nice ergonomics
- decent low-light performance
- great image quality
- easily accessible manual controls
I was aware of these three issues when I bought it:
- slow shot-to-shot speed
- poor low-light focus
- no dedicated ISO dial
- 28mm, f2.8 on the short end is ok, but not as good as the Panasonic LX3 or LX5
- Flickr thread on interesting after market products for the p7000
- Retro faux-leather cases on eBay for the p7000
Notes on MacRuby and sqlite3
Each time I install the latest version of MacRuby, I spend an hour re-figuring this out, so here it is…
Under certain conditions installing the ‘sqlite3-ruby’ gem on OSX with macgem fails with this error:
Building native extensions.
This could take a while...
/bin/sh: line 1: 27196 Abort trap
/Library/Frameworks/MacRuby.framework/Versions/0.11/usr/bin/macruby extconf.rb
ERROR: Error installing sqlite3-ruby: ERROR: Failed to build gem native extension.
/Library/Frameworks/MacRuby.framework/Versions/0.11/usr/bin/macruby extconf.rb
checking for sqlite3.h... yes
checking for sqlite3_libversion_number() in -lsqlite3... no
sqlite3 is missing.
Try 'port install sqlite3 +universal'or 'yum install sqlite3-devel' and check
your shared library search path (the location where your sqlite3 shared library
is located).*** extconf.rb failed ***Could not create Makefile due to some
reason, probably lack of necessary libraries and/or headers. Check the mkmf.log
file for more details. You may need configuration options.
Provided configuration options:
--with-opt-dir
--without-opt-dir
... etc ....
/Library/Frameworks/MacRuby.framework/Versions/0.11/usr/lib/ruby/Gems/1.9.2/
gems/sqlite3-ruby-1.3.2/ext/sqlite3/extconf.rb:20:
in `asplode:': sqlite3 is missing. Try 'port install sqlite3 +universal'or 'yum
install sqlite3-devel' and check your shared library search path (the location
where your sqlite3 shared library is located). (SystemExit) from
/Library/Frameworks/MacRuby.framework/Versions/0.11/usr/lib/ruby/Gems/1.9.2/
gems/sqlite3-ruby-1.3.2/ext/sqlite3/extconf.rb:29:
in `<main>'\
The problem is that macports installs into /opt/local by default so even after doing ‘port install sqlite3 +universal’, you’ll get this error message. You need to specify the install prefix using this awkward command line:
sudo macgem install --version '= 1.3.2' sqlite3-ruby -- --with-sqlite3-dir=/opt/local
Version 1.3.2 is the one I’ve had luck with on MacRuby up to version 0.11.
Platform as a Service (PaaS) Bag of Links
Big players:
- Amazon Web Services
- Google App Engine
- Azure (Microsoft)
Most of the other large software vendors also have a cloud story, but only their captive customers care.
Ruby-centric:
- Heroku (Ruby, bought by Salesforce.com)
- Engine Yard (Ruby)
Various others, some of which are more in the Infrastructure as a Service space than Platform providers e.g. hosting plus some Content Deliver Network (CDN) capabilties, and other focussed on specific app building tools and scenarios:
- Rackspace Cloud (Iaas)
- GigaSpaces (Iaas)
- Joyent (a bit of both)
- GridGain (Iaas)
- VMForce (Salesforce.com & VMWare — a bit of both)
- Cordys (app builder)
- WorkXPress (app builder, No Programming Required! right.)
- Wolf (app builder)
NoSQL Bag of Links
NoSQL Comparisons & Overviews
Performance Comparison (Tokyo Cabinet, Berkley DB + Memcache, Voldemort + Berkley DB, Redis, MongoDB)
Discussion of Popular NoSQL Projects
Ruby Centric
Notes on using MacRuby and WebView
After much head bashing, the following works for two-way calling between MacRuby and Javascript within a WebKit WebView. Key issues:
- Get the script object via the callback method. Many tutorials show obtaining it via [webView windowScriptObject]. This does not always work since the script object may not be ready (e.g. the page isn’t fully loaded).
- Take note of which delegate methods are static (isSelectorExcludedFromWebScript) and which are not.
- MacRuby names that you want callable from javascript must consist only of lower case characters. The mappings given in the docs (fooBar: converted to fooBar_, foo_bar converted to foo$_bar) have some idiosyncrasies.
- For no-args methods, everything works smoothly as long as you use all lowercase ruby method names with no underscores.
- If you want to pass an argument, you need to call it from JS with an underscore, declare it in macruby without the underscore, and also register it via ‘respondsToSelector’. To summarize:
- Define method in macruby: mymethod(somearg)
- Call from javascript: webscriptObj.mymethod_(somearg)
- In the webView initialization on the object that contains mymethod(somearg): self.respondsToSelector(‘mymethod:’)
- All of this confusion seems to arise from translation between JS methods, selectors, and strings/symbols in macruby. The colon at the end matters and it doesn’t work if it is a symbol, :’mymethod:’. For no-args methods though symbols work just fine.
- It is handy setting up the delegate methods to trap the console.(log|error|warn) methods as well as window.status changes.
- Note the WebScriptObject does not exist for the iPhone UIWebView, only for the OSX WebKit WebView. The PhoneGap project has a workaround for UIWebView for call from Javascript to Objective-C. For the opposite direction, Objective-C calling Javascript, the method stringByEvaluatingJavaScriptFromString is portable across both UIKit and WebKit.
class MyMacRubyController
attr_accessor :scriptobj
# In this example, the top level app_controller creates MyMacRubyController
# and initializes it with a WebView created via Interface Builder.
def initialize(view)
@view = view
#@view.delegate = self # only for UIWebView, below are for WebView
@view.UIDelegate = self
@view.frameLoadDelegate = self
@view.setMainFrameURL(NSBundle.mainBundle.pathForResource(‘test.html’, ofType:nil))
set_body_content()
end
def set_body_content(name)
js = ‘document.getElementById(“content”).innerHTML = “some html text”’
@view.stringByEvaluatingJavaScriptFromString(js)
end
#### Methods exposed to javascript via ‘myController’ object ####
def test
puts “In test method”
end
def test(somearg)
puts "In test method with arg: #{somearg}"
end
#### WebScripting delegate related ####
# This WebScripting delegate method required and must be static.
# Ensures only methods you want are exposed to javascript.
def self.isSelectorExcludedFromWebScript(selector)
if selector == :test or selector == 'test:'
return false
else
return true
end
end
# Delegate method for obtaining the script object. Sets up the main
# application callback object, myController. MacRuby method names
# seem to need to be all lowercase characters e.g. ‘runme’, ‘test’
def webView(wv, windowScriptObjectAvailable:obj)
@scriptobj = obj
puts “Got window script object #{@scriptobj}”
@scriptobj.setValue(self, forKey:’myController’)
self.respondsToSelector('test:') # this registration is only needed for methods with args
end
# Called whenever window.status is called in JS
def webView(wv, setStatusText:text)
puts “JS status -> “ + text
end
# Private WebViewUIDelegate method to trap console.log messages
def webView(wv, addMessageToConsole:message)
puts “JS console -> “ + message[‘message’]
end
end
<html>
<head>
<script type=“text/javascript”>
function doSomething() {
console.log(“in dosomething”)
window.status = “status set in dosomething”
console.log(window.myController);
console.log(window.myController.test());
console.log(window.myController.test_("arg passed"));
}
</script>
</head>
<body>
<form>
<button type=“button” onclick=“doSomething()”>Click me</button>
</form>
<div id=“content”></div>
</body>
</html>
Update: found this related article from the merbist.
Versioning REST APIs
There are three broad approaches to communicating version information:
In the URL
This is the most common approach. Simply add an identifier, usually near the root of the URL and version the entire set of resources below it (and hence the entire API).
| http://myserver.com/api/v1/someresource http://myserver.com/api/v1/another/resource |
This technique does a bulk versioning of the entire API and suggests that you shouldn’t mix resources across API versions. It is analogous to traditional API releases by sending out a new library versions. Bits within the old version (classes, data structures) are not intended to work smoothly with the new version. FWIW, this approach is common and well understood.
In the Media type
This seems to be the most RESTful to me, but hasn’t been widely deployed yet.
| Content-type: text/vnd.mycompany.mytype+v1 |
There are other possible variations that change the scope of the versioning:
| Content-type: text/vnd.mycompany.mytypesv1.sometype |
It feels a bit awkward when using content type degradation conventions:
| Content-type: text/vnd.mycompany.mytype+v1+xml |
In general, the whole idea of extending mime-types to make them more flexible seems necessary but also limited. That little string simply can’t scale too far. What if you want to have a vendor specific type that also happens to follow some xml standard. Can you subsume that XML standards mime-type which may also have a +xml at the end?
In the Content
This is how the human driven web currently works. The content is returned with an un-versioned media type, usually from an un-versioned URL, and the handler of that media type needs to sniff the content to figure out what version was sent back. That is why we have HTML content declarations and a convoluted set of rules that are different for each browser on how to handle combinations of content declarations and browser versions (quirks mode!). In general, it works for the simple case but is difficult to manage when things get complex.
My preference right now is to define a small to medium number of media types and have them versioned independently of the resource space used to access them. Exceptions to this are when the media types are tightly related and are likely to all be consumed as a whole anyways. In this case, versioning the whole API offloads the dependency tracking from the consumer and guarantees them a complete, cohesive API. However, when this happens you should consider whether that coupling is truly necessary in the first place.
http://www.stucharlton.com/blog/archives/000589.html
http://stage.vambenepe.com/archives/1300
http://barelyenough.org/blog/tag/rest-versioning/
http://www.codeoncotton.com/blog/2008/05/19/versioning-rest-web-services/
http://www.infoq.com/news/2010/03/rest-versioning-strategies
Estimation Rules of Thumb
Software project estimation is hard. In fact, it is so hard that estimating within the accuracy most people expect is actually impossible. To get as accurate as humanly possible, read McConnell’s software estimation book,[1] collect your own metrics, and then carefully and critically apply the principles. If you just need to get a quick order of magnitude check, here are some heuristics and techniques for a bottom up approach based on estimating code size.
The basic numbers are:
- 5-20 LOC per developer per hour
- 2000 person hours per year
- 50 LOC/class (Java), 100 LOC/class (C++)
This method uses objects as a proxy for size estimation.[2] You need to supply the number of objects in the target software and out pops the magic number. The two dominant variables tend to be the the number of objects (obviously) and the LOC per developer per hour. The second can often be pulled from historical data. I tend to measure the start when developers are first engaged in serious coding, skipping the early requirements and visioning, and the end when the code is running, unit tested, and lightly functionally tested i.e. DCUT code (Design-Code-Unit Test). For some teams this alpha, others beta, and others Running Tested Features. However you do it, try to find reasonably consistent points and make your historical measurements.
If you have no historical data, here is a rough continuum:
- 25+ LOC/person/hour — prototypes; small trivial projects
- 20 LOC/person/hour — small, 2-3 person team with fast micro-requirement turnaround (e.g. onsite customer, or more commonly, the developers are able to fill in many of the details of the requirements)
- 10 LOC/person/hour — regular agile team building a non-trivial app
- 5 LOC/person/hour — typical enterprise development pace
- 1-3 LOC/person/hour — stringent or archaic, unproductive environments (e.g. banking software); you’ll see this in some historical literature, but they are often taking into account the time beyond DCUT
Pick one that seems to fit your team size and environment. Don’t be too optimistic. How big is your team size? Is it a prototype? Do you have to worry about localization, security, scalability? How familiar is the team with the languages, frameworks, and tools?
The 2000 person hours per year is just a shortcut to take care of holidays, sick days, bathroom breaks, and other daily down time. Also known as non-ideal programmer days (hours).
Now the hard part. How do you figure out the number of objects or lines of code in your future software? The easiest way is by analogy. Find a similar project that either you’ve done or someone else has done. There may be some open source projects that cover some of your project scope. If so, take a look at their code bases.
Barring that, you’ll need to do some high level design in order to start figure out how big your code will be. Knowing how many layers your architecture will have and which frameworks you’ll be using is important. More layers tend to add more code. Frameworks often provide design constraints that you can use to start to enumerate the scope of the code — count the number of services, commands, or functions. Database tables and screens are also good proxies for code size estimation. If you already have a database schema, how many objects will be needed to wrapper it? Will there be a separation of data objects and domain objects?
Screens tend to map to template files, controllers, views, model proxies, etc. If you have both a existing database schema and requirements that map out screens, you should be in pretty good shape. If you have a pure codebase with no external anchors such as screens, database tables, web services to process, or transactions to fulfill, you may want take a different approach.
Once you estimate out how many objects it is just a matter of multiplying out the Objects * LOC per object * LOC per person per hour to get the total person hours. Multiply by 2000 to get the person years.
Now take a look at the software estimation cone of uncertainty and realize your error bars are probably worse than +/-100%.[3] Still, it is better than nothing at this point. Ideally, you should use this technique along with a couple of others, such as a top-down work breakdown structure, gut checks with a few team members, and/or high level epic estimation via planning poker. Multiple techniques done independently (don’t taint each other!) are more powerful than one expert judgement.
Note this number does not take into account non-code related and other project related costs. Designing the database, setting up build machines, project management, and high level requirements definition should be estimated separately.
[1] Software Estimation, Steve McConnell. http://www.amazon.com/Software-Estimation-Demystifying-Practices-Microsoft/dp/0735605351/ref=sr_1_2?ie=UTF8&s=books&qid=1275355156&sr=8-2
[2] A Discipline for Software Engineering, Watts S. Humphrey. http://www.amazon.com/Discipline-Software-Engineering-Watts-Humphrey/dp/0201546108/ref=sr_1_4?ie=UTF8&s=books&qid=1275358404&sr=1-4
Relative Cost of Distributed Architectures
Applications that have both a desktop and a web version, often for online/offline use cases, force you to make a decision about whether you want to share or duplication the back-end code that isn’t dependent on the UI bits. If you have a nice, separable back-end engine component it is tempting to architect your application as two separate distributed components and treat the local configuration as a special case of that.
For example, when your core application logic is layered behind a REST API, why not just have mini-web server running on the client for the the desktop deployment scenario? The UI layer can manage this process transparently to the user.
The benefit is a single architecture to cover both the web and the desktop deployment scenarios — the trade-off is that you are building some fundamental latencies into your architecture. To put the costs in perspective, I tried to google up some rules of thumb on the typical latency of various types of calls. Here is a rough approximation of the relative costs:
synchronized method call — ~1000s ns
reflective method call — low ~10,000s ns
machine loopback — ~30,000-150,000 ns
local sub-network — 1-2 ms
internet — 10-100+ ms
- http://perspectives.mvdirona.com/2009/10/17/JeffDeanDesignLessonsAndAdviceFromBuildingLargeScaleDistributedSystems.aspx
- http://stackoverflow.com/questions/94794/what-is-the-cost-of-a-function-call
- http://stackoverflow.com/questions/667634/what-is-the-performance-cost-of-having-a-virtual-method-in-a-c-class
- http://hbfs.wordpress.com/2008/12/30/the-true-cost-of-calls/
- http://duartes.org/gustavo/blog/post/what-your-computer-does-while-you-wait
Model Your Resources Well and Don’t Worry About the REST
RESTfully modelling transient resources, events, collections, and other application facets can be difficult. The post “Square Peg, REST hole” nails it and has an excellent discussion in the comments section. While I am a fan of REST and have been following the “web architecture friendly web services” debate since before dissertation-REST existed, what has become clear over the past few years is that:
And yes, hackable URLs are not a part of REST, but they certainly are an integral part of the success of web architecture friendly web services in the real world. REST wouldn’t be winning over SOAP if it wasn’t for all the successful semi-RESTful APIs that developers found far more intuitive and usable. So if you model your Resources right and people can intuitively GET them, you probably don’t need to sweat the rest of the details.
A corollary to this is that if the majority of your application doesn’t involve getting resources that are at least in the granularity ballpark of a document, then REST may not be that important to you.
leave a comment