Capitalism in the Workplace

Image via WikipediaA bit more on the compensation end of what I spoke of.

I would love to see people derive a large part of their compensation from revenue from the projects they've worked on. Employees could be given a percentage of the project's profits (shares) in exchange for not getting part of their salary.

If a project fails, employees would lose money too.

But what if employees could buy and sell those shares of the project's future revenue (or some amount of money earned by success) in an internal market? A stock price for all your projects would give you a pretty good idea of what employees working on the project really think.

What could be more valuable? Believe me, employees will not be blowing sunshine you know where when their own money is at stake.

I'd also make it so everybody could select what projects to work on and could leave them if they decided another project would be more profitable. By having some skin in the game and being able to act in their own interests, employees would be helping make decisions about where the company can most profitably deploy its capital.

Can't get on a project? Maybe you need some skills development or a course in manners. The company can offer a coach that gets his extra compensation only when you're on projects that succeed.

Still can't get someone to pick you for your team? Well maybe your base compensation starts declining gradually until you change that situation or decide another easier company is right for you.

I think such an approach would make everyone in the organization tune in to what really matters. High value opportunities, revenue-rich markets, eliminating effort wherever it doesn't create value. And everyone would be selling themselves, selling others on opportunities and selling to the world.

How About Really Going Capitalist?

Image via Wikipedia

Why is capitalism more productive than centralized economic systems? Perhaps its because people have incentives to make decisions that benefit the system as a whole.

Most companies make their decisions from the top down, making them more like the Soviet Union than a free market economy. But could they make a change?

I would like to see companies be more like startups internally. Employees know an enormous amount about the markets, technology and other employees that goes unleveraged when decisions are made from the top down.

I'd like to see people rewarded for the risks they take and for making decisions when their own compensation is at stake in the projects on which they work.

An important strength of capitalism is its decentralization of decision making, with commensurate risks and rewards. But traditionally companies are run from the top down, which makes slower to react and much more inaccurate when they do.

Startups do a much better job at taking risks and responding to the market. But there are advantages to scale that they cannot benefit from at the same time. But a large company could combine both with the right philosophy and information systems.

Interestingly, part of the appeal of scale comes from the tax code. Transactions between companies are taxed, but transactions between employees in a company are not, so the tax burden is lower per transaction. But often the loss of effectiveness more than swamps the advantages in size.

Ideas are the Bomb

Image by cogdogblog via FlickrI'm currently working on a provisional patent application for this idea I have, which will make life significantly better for older people.

I'm also reading a book on the topic called Patent Pending in 24 Hours. A good resource, but its taking way more than 24 hours!

Modelizer

Image by Shutterhack via FlickrI wrote a little Rails app called Modelizer back when I was first learning about Rails model associations.

Modelizer looks at the databases that your other Rails are using and identifies possible associations based on the naming conventions Rails uses for database table and column names.

Modelizer creates an ActiveRecord object that connects to the selected application's database using the credentials in each app's database.yml.

What should normally go in the model for an MVC app was pretty hard to pin down for this app, so most of what should be in the model is stuck in the controller. The model isn't specific to one schema, but actually would have to use databases instead of tables and hadn't really wrapped my head around how to do that. Basically, ActiveRecord handles tables, not entire databases and this app treats all of your schemas as the model.

This also uses AJAX when you drill down into tables and the possible associations for each.

Using REST for a Facebook Application

Image via CrunchBaseIf you're into Ruby on Rails, you've probably heard a lot about REST. It supposedly simplifies your life, but in many situations, things actually get more complicated.

Building Facebook apps is one of these situations. I've been using the Facebooker Rails plugin that helps you interact with the Facebook API.

Facebooker gives all requests from Facebook an "fbml" format. You need to add this line to your config/initializers/mime_types.rb file:

Mime::Type.register 'text/html', :fbml

You need to handle this format when you call respond_to:

def index
@facts = @topic.facts

respond_to do |format|
format.html # index.html.erb
format.xml { render :xml => @facts }
format.fbml end
end

The meaning of RESTful requests depends on which method or HTTP verb is used.

When GET is used and the path is "/topics/4/facts", the request is routed to the controller's "index" action. In this example, all the facts for topic 4 will be returned. But if POST is used, the request is routed to the "create" action, which will ry to add a new fact to topic 4 (these are nested resources).

But all Facebook requests are made with GET, so your code or your plugin needs to look at a request parameter called fb_sig_request_method to see which method was used initially.

One problem I had was deleting something RESTfully from a Facebook canvas page.

Normally, clicking a RESTful delete link created by Rails causes Javascript to run that creates the confirmation popup and a form that passes the authenticity_token variable required for deleting something.

But Facebook doesn't allow you to execute javascript so you can't rely upon the javascript normally created by the link_to tag to create the form when the page is loaded.

You can't create the form in HTML and then use FBJS to submit it either; Facebook rewrites your forms, dropping the name attribute. So you can't call the form when you click a link.

In the end I had to settle for confirming the deletion on a page of its own. And a less than desirable button had to be used instead of a link because Facebook links can't submit a form. So I'm still not happy with the outcome.

Facebook Plugins

Image via WikipediaThere are two Facebook plugins for Ruby on Rails. Both help you deal with the Facebook API.

RFacebook was the first Facebook plugin introduced and is basically a wrapper around the Facebook API enabling you to call it through plugin methods whose names map to the corresponding call in the API. If the API changes, the plugin supports that. You can use Facebook docs to figure out what to do and you can get data in XML or JSON.

RFacebook was intended to be quick and dirty and the author even stated early on that developers should eventually move to Facebook. But many people stuck with it.

Facebooker does things "the Rails Way", and gives you methods that follow Rails conventions. Data is delivered in arrays and hashes Ruby developers are used to working with. In addition, there are classes that help you with publishing to feeds and sending notifications.

With Facebooker, being able to deal with ruby objects saves development time. But you aren't always aware of whats happening under the covers. Sometimes a call to Facebook is initiated when you don't expect and that costs you time. Its an even bigger deal on Rails because your Mongrel can't service any other requests while its waiting for Facebook to respond.

The support for Facebooker has been questionable at times also, since the original auther Chad Fowler left the project. Code has been checked with typos, the entire project was simply moved to github without sufficient notification (even the Facebook app for the plugin pointed to an unusable SVN version for weeks) and some of code was baffling to use. The template registration stuff, for example, took me some major digging through the code to figure out what to do and it didn't even work.

Of course, some of these issues are due to Facebook changing so frequently, but at least with RFacebook, you're rely upon Facebook documentation rather than on the ability of Rails developers to code against each version of the API. Either way its still a moving target sometimes.

Facebooker does give you some help with REST, but even that took me quite a while to figure out how to use that successfully. I do use Facebooker for my grokLokker Facebook app and its stable enough for what I'm doing. But I doubt I'd use it if I had t to due over.