I just found out that you could use the Homebrew package manager to install remote packages as well as local packages. I needed Apache Ant while integrating HTML5Boilerplate with the FuelPHP Framework, and noticed it was not in the local packages. Here is the brew:
brew install https://raw.github.com/adamv/homebrew-alt/master/duplicates/ant.rb
One of my colleagues suggested that we set up email notifications so that we could know when git repositories got updated. We ended up using git-commit-notifier with gmail. It worked like a charm and took about 30 mins to get setup. First, you need ruby installed (even if you have it, make sure you’re using the dev version)
sudo apt-get install ruby1.8-dev
Install a few other dependencies
apt-get install libxml2-dev libxslt-dev
Run through the install and configure here:
https://github.com/bitboxer/git-commit-notifier
Note: You must add the post-receive to the repo directory on your server ie your-repo.git.
Note: When configuring for gmail, make sure that your mailinglist is only separated with commas, and that your delivery_method is set to smtp.
You can create multiple config files for each project. I placed mine in usr/share/git-notifier but you can put them wherever makes sense to you. Now you should receive a nice email showing you a summary of each push.
Essentially, it’s a buzzword to describe a packaged approach to completing work. It’s a way of building things, using strategically agreed upon components. The people who determine the components the framework will utilize can begin as one or a few original architects, and can morph into something that seems to have a life of itself – supported by thousands, in some cases, millions of users.
I started really diving into frameworks last January after working on projects developed with CodeIgniter and Zend, PHP frameworks. I had been *unknowingly* using frameworks for years.
Recently, I have begun adopting a more “comprehensive” opinion of what a framework encompasses. I can use CodeIgniter or Symfony as my PHP framework in a project, but this is only a part of the method – the complete framework, I use to complete a project.
I’d been meaning to look into HTML5 (more than just casually browsing sites which utilize HTML5, and reading the first chapter of “Dive Into HTML5.”) for quite a while.
Today, while working on a project where I wanted to finally utilize HTML5 and CSS3 in a big way (more than just setting an HTML5 doctype and throwing in a few CSS3 enhancements), I stumbled across a video presentation made by Paul Irish on Youtube, who is a really smart guy working for Google, and one of the leaders in the charge to full HTML5 support. The presentation was on boilerplate, what Paul describes as a “default” for starting HTML5 projects.
I sat down and watched the video… the whole thing (64 minutes)… I took notes, referencing and timing the most interesting points. Boilerplate integrates several innovative pieces, from how HTTP calls are made, to how htaccess is utilized and how javascript is gracefully degraded to support HTML5 / CSS3 features in older browsers. I’d be curious to see a time log showing hourly spend on each piece. Between the base experience, experimentation, community knowledge and rare “aha” moments it took to pull it off, I have no doubt that Paul Irish and other contributors could have spent thousands of hours building HTML5 boilerplate. Thousands of hours that I don’t have to spend.
The work that one dude or many put into in writing a better PHP framework, or creating a “default” for HTML5 projects benefits us all. It takes a ton of core computer science knowledge, real working experience, and experimentation time to write a good framework. The work these guys do is invaluable, and is a huge part of what moves our industry forward.
However, as a user on ServerFault once eloquently stated, “Not everybody works in a lab.” Some of us simply don’t have the time to write frameworks or languages, even if it interests us and even if we are capable. Our circumstances and our goals define what we spend our time on. Since I have always made my living based on my ability to build things and organize the efforts of others who build things, efficiency and productivity are extremely important to me. The expressiveness of a language, library, framework – whatever – are incredibly important. I don’t need to know how my code compiles to C – I only need to ensure that my code is elegantly constructed, well organized, and completely documented.
Frameworks aid me in this quest. By watching one 64 minute video, Paul Irish has shown me tools I can use to go out and build skyscrapers. I don’t have to reinvent steel, or glass windows, or elevators, or staircases. They are there for my deployment, should I need them. I am being enabled by Paul’s efforts, and my focus turns from pouring through the HTML5 spec and writing javascript libraries to support older browsers, things I honestly care little about – to my users and my applications, things I care a lot about.
Rasmus Lerdorf, the inventor of PHP, has spoken often about his “dislike” of PHP frameworks, because of the bloat that they add to projects. I THINK that it was E.B. White who once said, “A novel is finished not when nothing can be added, but when nothing can be taken away.” There is a lot of merit to that thinking, and often, Frameworks give us a lot we don’t need – things that obscure, obfuscate and abstract farther than is necessary or convenient – and we should not be imprisoned by these rules, guidelines and restrictions.
Just this morning, a colleague and I decided to go straight from content development and basic wire frames to simultaneous design and coding, a slight departure from our normal, more formalized way of doing things. We made this decision because it would allow us to build a finished product faster, and because further wire frame definition seemed to add little value. I’ve been involved in projects where formality and procedure created deadlock and wasted hours. If you’re not careful, your framework, be it a code framework or working framework, can also create redundancies and inefficiencies which limit you later.
Good frameworks provide good models for you to follow, and in the programming world, often give you reams of low-level code that you could otherwise spend days or weeks completing. They don’t lock you into doctrinal zealotry.
Whether you work in a lab or you’re out in the trenches, the framework you use for completing your work as a knowledge worker should be constantly evolving, and will always include sub-components which may be frameworks themselves. If, like me, you’re building apps and websites for consumers and businesses, you should rarely need to reinvent much. What you need to think about is what is included in your working framework. Question why you use certain technologies, and how much more productive they really make you – and stay sharp as you keep your eye out for the next great invention that makes your day easier from one of our fine men and women in the labs ; )
I’m working on a UPS shipping class and wanted to get a feel for the UPS API before I started writing any code. I decided to use cURL to to test. Anyways, here’s how you format a request to an XML API via Curl / command line (Specifically, the UPS Address Validation API):
curl -v -v -d ‘<?xml version=”1.0″ ?><AccessRequest xml:lang=”en-US”> <AccessLicenseNumber>YOURLICENSENUMBER</AccessLicenseNumber><UserId>YOURUSERID</UserId><Password>YOURACCOUNTPASSWORD</Password></AccessRequest><?xml version=”1.0″?><AddressValidationRequest xml:lang=”en-US”><Request><TransactionReference><CustomerContext>General Address Validation</CustomerContext><XpciVersion>1.0001</XpciVersion></TransactionReference><RequestAction>AV</RequestAction></Request><Address><PostalCode>42167</PostalCode><StateProvinceCode>KY</StateProvinceCode></Address></AddressValidationRequest>’ -H “Content-Type:text/xml” https://wwwcie.ups.com/ups.app/xml/AV
The -v -v tells the request to be verbose, so you can see the handshake / connection happen, and get the response object. -d is for the fields of the request and -H is the content-type. The API endpoint is at the end of the code.
Figured this might save someone a few minutes = )
I’ve done 3 rides now with a group of guys in Cookeville who are all pretty serious. A few of them even ride professionally. The first day, I finished dead last, though I stuck with one guy for most of the ride. The second time, I did a little better. It really started to hit me how important riding with people who are better than you is (as is following the work of those who are better than you in programming). I’ve been working hard to improve on my own for a couple weeks, after figuring out how much faster all these guys are than me, and yesterday I started out a lot stronger. I was so into my ride that I missed the turn I usually make, for the short route (25 miles), and stayed on the long route (40 miles) instead. I had never gone the long route, so I wasn’t totally sure about which direction I needed to go. Thankfully, a group of four riders who had started a few minutes after the first group caught up with me, and I fell in with them. A few minutes later, one of the guys got a flat and with the help of two others, had his tire changed in (I swear) about a minute. We all waited while he changed his tire. After we started riding again, I noticed something. The guy at the front would ride for a couple minutes, then he would fall off to the side, making his way to the end of the line, and the guy behind him would pull into the lead position. The process would repeat every few minutes. This was a lot easier than riding alone, trying to compete with each other – and we were making good time – I think the fastest I’ve ever gone.
Something sunk in while watching this go on that for whatever reason my skull has been too thick to truly absorb for just shy of 22 years…something that made me realize how important teamwork is, and how, perhaps, I’ve under appreciated the value of having a great team, and working to keep building it. The point is that you don’t have to be at your best all the time – you don’t have to push to the brink of exhaustion at a constant rate. You give it your all for a while, and then you let the guy behind you do the same. The entire team improves because you don’t have to be the hero every day. You get your time to shine, and so does everyone else.
Individual ability and drive remain extremely important. As you push and improve, your teammates are encouraged to do the same. If they cannot (or you cannot), new teams are formed, and members change teams. Your skill still determines the team you play on (or the strength of members who see value in joining the team you build), but don’t think for a moment you’ll get anywhere (or even improve significantly) WITHOUT a team. Who else will stop and help you change your flat?
I expected a lot from the PHP Community Conference when it was announced. My first attendance to a programming-centric conference, I didn’t quite know what to expect, but I did feel it was something I couldn’t afford to miss. I’m really glad I made the trip down to Nashville, and I’m thankful that I decided to buy a ticket right away – because they ended up selling out.
The Venue
The conference was held at “A Venue”, right off Broadway on third avenue south. The building was an old, brick building, two stories high with a basement, mostly wooded interior and high ceilings throughout. I’m not sure what the building was used for originally, but it had the feel of being a riverside storage and trading building – perhaps once filled with wooden barrels, dried goods and tools. The feel was earthy and comfortable, and in no small way lent itself to the relaxing and friendly atmosphere felt at the conference.
Being professionally catered and staffed, and perfect for the conference’s several hundred attendees, the venue was an excellent choice. This owes no small thanks to Lisa Denlinger, who took time off work to travel all the way from Columbus, Ohio to handle the selection of both venue and staff.
Speakers
To say that the conference featured strong speakers would be an understatement. The speakers were all PHP rock stars – and not just the proclaimed type – the very best in the industry. I only mentioned the speakers I actually saw.
Rasmus Lerdorf – Opening Keynote
Perhaps no member of the PHP community is a greater titan than Rasmus Lerdorf, the inventor of the language. Rasmus’ talk included:
1. General technology trends (server and database choices)
2. Low hanging performance optimization fruits
3. Analysis tools and further optimization techniques
4. Best practices for achitecture, workflow and deployment
5. Resources and QA
I had the opportunity to speak with Rasmus after the talk – not only is he incredibly smart, he’s also a nice guy willing to offer advice to even beginning PHP users. I was extremely impressed with Rasmus.
Feedback from other attendees.
Lorna Mitchell – Web Services
I think Lorna was the only Brit in attendance, but I could be wrong. Either way, England certainly sent her finest. Lorna’s talk focused on best practices for building PHP based APIs. Here is some of what she covered:
1. General information (types of APIs, how APIs are consumed, etc.)
2. Debugging and tools (Wireshark, Charles, etc. and how to use them)
3. Best practices
4. Covered REST in detail
5. Well-implemented, well-documented APIs (such as Flickr) and what made them so strong
6. What promotes API adoption
Lorna knew her content extremely well and presented it in a very logical format. In addition, her passion for building great software really showed. Despite a few technical problems due to the Ubuntu presentation tool she used, Lorna’s talk was excellent. Her well-known passion for the adopting open source technologies such as Ubuntu (which I share) certainly excused the slight hiccups.
You can view her slide deck and the feedback of others here.
Helgi Þormar Þorbjörnsson – Frontend Caching, The New Frontier
Don’t let Helgi’s young age fool you. Helgi has packed more into the past 8 years than most pack into a lifetime. His talk focused on an area that I knew extremely well, and that is unappreciated – the value of good front end engineering. I only stayed for the first 25% of the talk, but what I saw was very well prepared and presented.
The talk began with discussing how much of the load on web sites (up to 90%) comes from poorly implemented front ends, and then dove right into strategies to improve web site performance through simple practices like reducing HTTP requests, eliminating JavaScript at page load whenever possible, and markup structure. As I said, I left early to catch another talk, so I didn’t get to see the entire thing…luckily it can be downloaded here, along with feedback from other attendees.
Joel Perras – Lithium
A trained physicist, and author of the Lithium framework, Joel is one smart dude. I walked into his talk about 25% of the way in, and it took me a bit to catch up, but I was extremely impressed with Joel. I want to develop crazy leet skills like this guy some day. As he showed off Lithium’s routing and filtering system in MacVim and discussed in great detail the decisions he made in creating them, as well as providing some usage examples (but not enough).
Joel also discussed how hard it had been to find people to help with documentation, and how much it is needed on a project like Lithium. I’m hoping I can win some brownie points (and hopefully get what I do critiqued in the process) if I can find the time to help document some simple uses of Lithium.
Feedback from other attendees here.
Brian Moon – Phorum
Brian’s talk was about one of the web’s longest lasting and most popular message boards, Phorum, which was originally created in 1998 for Brian’s own need of a message board solution…he says it was “accidently” open sourced, yet over the past 14 years it has enjoyed more than 50 contributors, 3 of whom contributed to Phorum’s core.
Brian focused primarily on Phorum’s story;
1. The start
2. Failures
3. Successes
4. Technology choices (how they diverged from the mainstream)
5. Current status
6. What the future holds
The talk was one of the most interesting to me, as it did a great job of chronicling forum’s history, touching on both technology and adoption.
Feedback from other attendees is here.
XHProf & Wonderproxy – Paul Reinheimer
Paul’s talk was extremely fascinating. A veteran developer and incredibly smart guy who is tackling some world-changing problems in his day job, Paul talked about some really cool tools that he had created over the course of the past couple years, originally to get more performance out of projects he was working on. Mainly focused on the stories, Paul began with Wonderproxy, a tool for automating global testing. He discussed:
1. Where the idea came from
2. The venture capital that got him started (Amex, Visa, and Mastercard)
3. Early stumbling blocks
4. Successes
5. The future
6. Profitability achieved (hooray!)
Then on XHProf (a tool Rasmus had mentioned during his keynote):
1. How it started
2. How it was built
3. How it’s used (UI stuff)
At the end, in true Canadian style, Paul handed out a couple bottles of maple syrup. This guy kept me laughing through the entire talk.
Slides and feedback from other attendees here.
Sean Coates – GimmeBar
Another story-focused talk, Sean chronicled his adventures in GimmeBar, a new startup which aims to help you keep track of all that cool content you find on the web (and incidentally, liberated Sean from his consulting work). I took more notes during this talk than any of the others I attended, as Sean provided a pretty awesome road map for building stellar start-up technology.
He covered:
1. The technology they built with
2. The fact that they weren’t optimizing for IE (everyone clapped at this)
3. Difficulties in building (tough technology problems)
4. Mistakes
5. Successes
For any aspiring startup builder, there were endless nuggets of great information to be gleaned from the talk. You can find the slide deck here, along with feedback from other attendees.
Marcel Esser – From Earth to Jupiter
Marcel’s talk walked us through some big challenges his team had recently faced in building a Flash based application for a large government agency which would help sell an Earth to Jupiter mission to the US public. I found my mind wandering during the talk, but Marcel showed a solid information architecture process that his team employed, and went into great detail on the value of stories.
View feedback from other attendees here.
Terry Chay – Closing Statments
Holy shit. Terry Chay is one funny dude. And you can’t mention him without using expletives – that’s the rule. This guy has been featured in a PHP “player’s deck” of cards, has written reams of content, worked at some big names (he’s at Automattic now), and is basically the Chuck Norris of PHP.
Terry’s presentation was epic; This guy effortlessly mixes a well designed slide deck (quite rare at a PHP conference) with side splitting humor, a visionary sense of what’s next, and great anecdotes…and he also happens to be a former physicist.
Terry covered:
1. Key takeaways from the conference
2. PHPs expressiveness as a language (ie 5 lines of PHP is worth hundreds of lines of C)
3. New paradigms in application deployment (cloud hosting, platform as a service)
Impromptu Talks
At the end of the conference, impromptu talks were allowed, I don’t remember all of them, but Jason Hunter from Red Ventures and Ryan Weaver from knpLabs gave especially good ones about organizing user groups and writing documentation, respectively.
People
The people were definitely one of the high points of the conference. I’ve been to a fair amount of conferences in the past 5 years (usually one or two a year), but I enjoyed the company at this particular conference a lot. People were friendly, interesting, and eager to lend an ear to an inquisitive youngster (I think I was the youngest guy there).
This was my first programming conference, and for some reason I slightly expected the crowd to be a bit more shy…to my surprise nearly everyone I met was pretty outgoing, and there were a lot of conversations about things other than programming.
Sponsors
The hospitality of the sponsors was tremendous. Thanks guys, for the awesome parties and great meals. A special thanks to Larry Masters and the CakeDC team, who filmed the entire event, provided sound support, and probably a billion other things I don’t know about.
To the Moontoast team – you guys did an awesome job being the hands on deck throughout the conference. To Red Ventures and Microsoft, thanks for the awesome parties at great venues. A complete list of sponsors is available at the PHP Community Conference home page. Thanks again, guys!
Swag
Most conferences load you down with a lot of crap that you just end up throwing away. All we got here was a cool lanyard and name tag which cleverly had the entire conference schedule on the back. I don’t know who thought of that, but it was brilliant. It’s the little things…
Parties
The parties were fun, and everyone had a great time, but there was a definite gender imbalance… This was most apparent when everybody was riding the bull at Cadillac ranch. We still had fun, however. Thanks again to the generosity of Microsoft and Red Ventures for making the parties possible.
Food and Drinks
Excellent, unlimited and totally free. My only suggestion here would be having healthier snacks (fruit, yogurt, etc).
Possible Improvements
I talked with Nick Sloan a little about this during the conference. There are a few areas where I think the conference may be able to grow in the future, but this may just be me rambling. Here goes:
1. Free / reduced parking at the venue, for the local folks: Just sayin….
2. Involving young students / non programmers who are interested in learning: This would mean expanding the size of the conference, but it could be cool to let youngsters (middle school and high school students) come and learn around seasoned pros. It seemed everybody at the conference was hiring – I got a few job offers / hints at job offers myself – we could possibly get some younger kids started early so they’re available for later recruiting.
3. Involve VCs and business leaders so that they can see how complex and under appreciated the craft is.
Keep in mind these are only my suggestions, and you’re free to disagree. This was my first PHP conference, so my opinion could be totally worthless.
Summary
A great conference that embodied professionalism, painstaking preparation, and lots of string pulling from top to bottom. I learned a lot, met some really cool people, and gained quite a bit of perspective on everything from how PHP applications are being built to what attracts the best developers to the companies who build them. Most importantly, I walked away from the conference with that all-important yearning of improvement rekindled with fury. I’ll definitely be back next year, and I’ll definitely be buying my tickets in advance. Thank you again, guys, for a wonderful conference.
I just finished reading “50 Secrets of the World’s Longest Living People” by Sally Beare. Despite the infomercialesque title, this is an extremely well written book.
Mrs. Beare starts off by introducing readers to five cultures where multiple centenarians (someone beyond 100 years) live alongside many other elder (and younger) citizens – most of them having nearly perfect health – and the most common cause of death being of natural causes (aging). In America, your chances of developing cancer start off at around 1 in 3, and depending on your lifestyle habits, swing one way or the other. In the cultures Mrs. Beare examines, cancer is practically non-existent.
The five longevity hotspots studied in the book are Okinawa, Japan; Bama, China; Campodimele, Italy; Symi, Greece; and Hunza, Pakistan. Mrs. Beare looks at common and unique factors between each culture. Some commonalities:
After exploring each culture, Mrs. Beare delves into the 50 secrets, which deal largely with the science of why the aforementioned cultures have been so incredibly successful at living long and well. This is not just a book which waxes nostalgia for yesteryear and decries the evils of modern economies of scale…this is an exhaustively researched book that identifies the cornerstone elements of long life.
Included are great anecdotes, research findings, recipes and more, all presented in Mrs. Beare’s casual and flowing writing style. It took me about 3 weeks to make my way through the roughly 300 page hardback.
If you’re interested in becoming healthier, learning more about nutrition, “50 Secrets of the World’s Longest Living People” provides an amazing crash course, without ever reading like a nutrition text book. Reading this book was fun…I highly suggest it.
You can find it on Amazon (this is NOT an affiliate link): Here
I spent the past 30 minutes debugging a nasty little thing…thought I would share in case anyone else ever runs into this. When using JavaScript’s setInterval, make sure that the timeout duration is greater than or equal to the execution time of the function it calls. I made the mistake of setting the interval duration value to 0, so the function would execute again as soon as it had finished, and as a result could not clear my timeout. Here is an example that will be buggy if someFunction’s execution time is greather than 0 milliseconds:
$(document).ready(function(){
jQueryInterval();
$(‘.something’).focus(function(){
stopjQueryInterval();
});
});
function jQueryInterval()
{
slideTimer = setInterval(someFunction, 0);
}
//the timeout stop function
function stopjQueryInterval()
{
clearInterval(slideTimer);
}
So save yourself some time and frustration, always make sure the interval duration value is greater than or equal to the length in milliseconds of the function it calls.
Perfect for loading a random testimonial, banner image, etc. A quick helper for your coding pleasure = )
First, create your helper (helpers/randomview_helper.php). Here are the contents:
<?php if ( ! defined('BASEPATH')) exit('No direct script access allowed');
/**
* Random view
*/
function get_random_view($fullpath, $viewpath)
{
$file = str_replace('.php', '', random_element(get_filenames($fullpath)));
return $viewpath.$file;
}
Notice that random_element and get_filenames are both used. These are also CodeIgniter helpers which are included in Reactor 2.0. From your controller, load the helpers, call the get_random_view function and pass the data to your view:
//Get a random testimonial
$this->load->helper(array('file', 'array', 'randomview'));
$data['testimonial'] = get_random_view('application/views/sell/testimonials/', 'sell/testimonials/');
Notice that you’re passing both the full path to the folder where your view file is, as well as the path that the view loader well you. Now, when you load your main view, just make sure you pass in the $data array:
$this->load->view('myview', $data);
In the view you just loaded, you can now use your $testimonial variable to call your random view:
load->view($testimonial);?>
UPDATE 03/06: Added support for getting an array of random views (for example, if you want to randomize testimonials):
/**
* Returns an array of all views
*
* @param string
* @param string
* @return string
*/
function get_random_views($fullpath, $viewpath)
{
$file_array = str_replace('.php', '', get_filenames($fullpath));
$file_count = count($file_array);
$keys = array_keys($file_array);
shuffle($keys);
$random = array();
foreach ($keys as $key)
{
$random[$key] = $viewpath.$file_array[$key];
}
return $random;
}
Have fun = )
A Parable
Imagine you live in an ancient time – perhaps you are a Greek. Each morning, you wake up and milk your cows, and then you walk three kilometers to the market, where you sell your milk. You are not the only milk seller – this market is very large – and there are many. However, you get enough business to support your family and continue to produce the milk that others enjoy. You are a contributor, and others benefit from what you provide.
One morning, a band of raiders come to the market on horses with swords and spears, hoping to take what you have created. Just as you feel death is near, the market’s guards shoot the bandits with their bows. The news spreads that this market protects its merchants and customers, and soon more milk sellers arrive at the market. At first, you are afraid because there is more competition – but something funny happens – more customers appear – and soon, you find that you have sold all of your milk in just over an hour and can return home early. The marketplace, by showing that it could fend off bandits, created better conditions for buyers and sellers – and thus, everyone benefited and the marketplace experienced net growth.
Now, think about the conditions that created the marketplace. First, there was a wise man with vision. He saw a crossroads connecting several cities, and saw that merchants from each city passed through these crossroads each and every day, traveling to sell their goods. He saw that people would ride for miles, passing by the crossroads on their way to another city in order to buy something that they couldn’t find in their own city. One day this man decided to pitch a few tents and stalls at the crossroads, and hired his friend to stand guard. When the first merchants rode through in the morning, the man invited them to sell the wares at his market, instead of traveling on to the next city. The merchants agreed to try, as they knew many people passed through this crossroads each day, and that the road to the next city was often treacherous. When customers, hurrying to buy salts, wines (whatever) in other cities saw the merchants selling what they needed, they decided to stop and buy there, instead of traveling on to the next city.
Pretty soon, many merchants were coming to the crossroads to trade. So many, in fact, that a few farmers had started letting their cows graze in the pastures around the crossroads, and had even built homesteads and planted crops there, so that they could sell their milk and crops to weary travelers in the market. These farmers had need for new shoes on their horses, and soon there was a blacksmith who built his home nearby the market.
Only a few years after the wise man decided to build his market at a well-traveled crossroads, a new city had suddenly sprung up – with his market at the center of it. This wise man had only asked for 1% of what each merchant sold, which seemed like a bargain for the convenience gained and the safety the man provided – and now, because so much business had been conducted in his marketplace – he was very rich. Not only that, but because he was not a participant in the marketplace, and it was now well established, the man had time to consider other things. Soon, he had built an irrigation system to help bring water from the river and help the farmers grow more food. He built walls, and stocked them with armed men, to protect the citizens of his city and the traders in his market from bandits and invading armies. Very soon, the people proclaimed the man King – a title solidifying what the man already was in spirit, and had proven in deed.
The man could have been a merchant – and because he was wise and clever, he may have become a very rich merchant. But at best, he could only hope to become an administrator of his merchant empire – he would never find the time to become king. Because he focused not on filling the needs of individuals, but rather on creating conditions that would allow individuals to serve each other more effectively, the man was able to spend his time and energies solving problems – and thus, established more than a livelihood – he established a kingdom.
Great Marketplaces of the 21st Century
Today, we can find some of the best direct parallels to this story on the internet. I would argue that most or all of today’s dominant internet companies don’t participate in marketplaces, they create the marketplace. Let’s take a few of the most well-known examples:
I could delve into the history of more, but let me just throw out a few names of other sites which have been wildly successful by creating marketplaces:
There are plenty of (non-web-startup) examples as well (though, I think, fewer good ones):
This list could go on and on forever, and giving a complete history of each of these companies was not my intent, so let’s move on…
The Point
I believe that perhaps now more than ever, there is a distinct choice available to anyone who reaches working age. On the one hand, we can take the traditional route – hope to find a great job, most likely working for a company that provides a product or service within an established marketplace, or being a freelance service provider in one of these markets. Such is the path I went down for the past 5 years, building websites for businesses and startups and helping them compete more effectively in Google (for example).
The other path which can be taken is one that is much more elusive, one that most people will never even know exists – and it is the modern path to Kingship – creating the platforms and marketplaces that make the rest of the economy more effective, efficient and secure. Once you’ve created the marketplace and you’ve ensured it’s stability, you can pretty much do whatever you want. If you’re like Zuckerberg from Facebook, you’ll stay focused on making your particular marketplace. If you’re like Page and Brin from Google, you’ll enjoy the fruits of your labor by continuing to create more marketplaces, buying up companies on a whim, and just creating cool shit in general.
So as you brainstorm for your next startup or business – think about what you really want. Do you want to be the average merchant, a rich merchant, or a guardsman (ie a Google employee)? Or…do you want to be King? If your answer is the latter, you should skip the typical “business planning step” of deciding what product or service you will provide and to who, and jump straight into what type of commerce you want to facilitate between a particular set of consumers and producers.
