webdav = RackDAV::Handler.new(:root => 'private/docs/', :resource_class => LockableFileResource)
    webdav_with_auth = Rack::Auth::Basic.new(webdav) do |username, password|
      user = User.find_for_authentication(:email => username)
      user && user.valid_password?(password)
    end    
    mount webdav_with_auth, at: "/webdav_docs"

4. Tell the browser to instruct Word to open the file: For users on the web, we don't want the default rendering of the WebDAV root, because we'd like these docs to be editable in Word, which means you have to tell Word to open it. While you could add this to your own resource collection, I just created an action to list the links to the files with the code to open it in Word. Here's the basis of what you need in the view:


Users who have Office 2010 installed on their system will also have those 2 plugins installed on their system, so we try to use them and return false (preventing the browser from following the link) if they have it. For those who don't, the JS provides a way to just download the file. See OpenDocuments Control API and FFWinPlugin Plug-in API for more info about what you can do with those plugins.

5. Tell Rails not to parse params for our mounted rack_dav app. For whatever reason, Word will try to save the file back to the server, PUTting it with the mime type application/xml, but it doesn't wrap in XML. I don't suppose it's supposed to, but it would be nice if it played well with Rails. Unfortunately, Rails understandably barfs when you tell it to parse parameters from XML and didn't send any XML. So, I had to create a patch and stuck it in an initializer. All we do is figure out if the request is for where we mounted rack_dav: if so, let rack_dav handle it without parsing the params. If not, just parse the params as normal:


There may be some security problems with this if rack_dav parses request parameters like Rails did before they put out their security updates in January and February 2013. I plan to review the rack_dav code to make sure it doesn't expose the same problems Rails had before I put this in production, and I'd recommend you do the same before you do.

6. Tell Devise not to authenticate OPTIONS or PROPFIND requests. This is needed if you redirect your root url to a protected controller/action, because when Word makes requests using these methods, you'll get redirected and asked for authentication on a web page, which totally breaks the whole concept. This is probably in your application_controller.rb, unless you moved it. So if you moved it, you'll need to make the change there.


That's all. Feel free to ask any questions if something is unclear or not working for you!

• Any time I'm using an open source project I haven't used before (or using a new-to-me feature of it), I am reading the docs about it as I implement whatever it is I'm using it for. If I find something unclear, or something unaddressed, I fork the project, improve the docs to mention it, and send a pull request. Examples: How to use init.d services with rvm, apartment code sample
• Any time I come across a bug, I don't stop at finding a workaround for my project -- I look to see if it is caused by something in the open source project, and if so, make the fix and send it to them. Examples: Slow MySQL count in composite_primary_keys, Stretch background in ruby-prof output
• Any time I am using an open source project and have need of functionality that could conceivably be provided by the project, if it's general enough I think it would be of use to others, I'll implement it in that project instead of mine, and send a pull request. Depending on the project, I might ask them if they'd be interested first. Examples: Rails table migration generator, Spree refactoring for reuse

Now, I don't tend to contribute a lot to any one project. If you're more interested in that, I would guess you ought to do something similar, but focus it all in that one or two projects that really excite you. Go through the issue tracker, see if you can reproduce and fix the bugs people are reporting (or leave a comment telling them how to fix there problem if it's not really a bug), etc.

For example, Steve Klabnik wrote up a how-to contribute to Rails, which talks a little more on the human side of things, as opposed to just the project contribution guidelines. I think his blog post can be generalized to other projects as well, so it's worth a read to get an idea of how to go about interacting with bigger open source projects when you want to contribute.

Lots of projects will mention their own contribution guidelines though, so make sure you read them and follow them!

Hope that helps,
Sam

What does a greedy algorithm for yourself look like?
Perhaps we should first define what it is for which we're optimizing: To keep it simple, I'm going to identify it as maximizing income.

You could also be seeking to minimize the distance (in time) between working for clients, or minimizing the time you spend acquiring each customer -- maximization is not an intrinsic property of optimization.

I purposefully exclude things like time and happiness (or optimizing for some combination of all three). While I value those things and would like to think I've tried to optimize for them, upon closer inspection I recently realized I've tended to simply accept whatever side-effect optimizing for money has had on those values.

I think it's a fair assumption that plenty of other people are doing the same. If you're not one of them: congrats! But before you dismiss the idea entirely, you ought to consider that you might be, just to be sure.

So what does it look like? Again from Wikipedia, I like the idea of moving from node to node on a graph:



At each point in time (a vertex on the graph) we are presented with a series of options whose positive return is the value at that vertex. The options available to us are connected by the edges. (You might also assign a cost to each edge, and change your greedy-optimization heuristic to be return minus cost).

In the graphic I've used, only two options are available at each point, but in reality there are normally a lot more options from which to choose, and maybe even times when you have only one option.

If we're starting at 7 and being greedy in our search for a maximum, we miss out on the global maximum.

You might mention -- hey, we could backtrack and search the entire space. But you might not have the resources available once you've gone down the path to 6. You might have reached your maximum workload by that point, and by the time you free up some time, the opportunity for the 99 is gone.

How do you know if you're running your business like a greedy search algorithm?
Here are some symptoms:

• Taking the first job offer or client you get when you need work
• If you're a freelancer, filling all your time with client work
• Taking the first business model that seems to be working and trying to maximize it

Can you think of any others?

Prior to last year, I was executing a totally greedy algorithm with regards to my career. But it's not just something I've noticed in myself: almost every job I've had utilized greedy methods for making money.

As part of my greedy search (which was not just about maximizing money, but more towards minimizing unemployment, even if it meant working for people who would end up stiffing me on paychecks), I ended up burning through about four months of savings (I had six). Last year though, I started making some changes to a better approach. When I made my way back up to a six month cushion and took time to reflect on some of the changes that got me there, I realized the parallels to algorithms I'd learned about in college.

Improving your odds
How can you improve your chances of finding a global (or at least higher) maximum?

In the general problem, given enough time and resources, you could do an exhaustive search -- or in our graph model, visit every node.

But I don't have the resources to exhaustively search the entire space to produce an optimal solution, and I'm betting you don't either.

Instead of straight greedy hill-climbing, we could explore some variants. My favorite here is called "shotgun hill climbing," where instead of following a path all the way to it's maximum, we'll randomly restart (but we don't forget where we came from on those restarts, in case we don't end up in a better position).

It's what I like about Amy Hoy's stacking bricks metaphor. A freelancer can start taking time between gigs (or not remain fully engaged) and spend some time developing products. Each successive product is a new brick, and over time you can build a wall.

Savings and product revenue are like ammunition for your shotgun hill climbing business algorithm. They allow you to explore different starting positions, as long as you're not being greedy with minimizing the distance (in time) between clients or booking all your time to work for others.

In practice, all those ideas you have floating around in your head (or ideas.txt file) are the different options you have in paths to take (in addition to other jobs, clients, ideas for "upselling", etcetera). You have to spend a significant piece of time on one to find out if it gets you further up the hill or not -- but not so much so that you can't get back to your last local maximum or randomly try another.

(Side note: I'm not advocating strictly random here -- you can apply some heuristic to affect the "probability" of choosing a certain idea).

Last year I took my first steps to taking a shotgun approach. This year I plan to take it further.

Thoughts? I'd love to hear them below.

<cfloop condition="patArr[patIdxEnd] NEQ '*' AND strIdxStart LTE strIdxEnd">
  <cfset ch = patArr[patIdxEnd] />
  <cfif ch NEQ '?'>
    <cfif ch NEQ strArr[strIdxEnd]>
      <cfreturn false />
    </cfif>
  </cfif>
  <cfset patIdxEnd = patIdxEnd - 1 />
  <cfset strIdxEnd = strIdxEnd - 1 />
</cfloop>