Called id for nil, which would mistakenly be 4 -- if you really wanted the id of nil, use object_id

Ever seen this come up in your console? What this means is that the object queried for id has unexpectedly turned out to be nil and that nil's id is 4. Why?

Remember that ruby is modeled after Smalltalk and that everything is an object. More importantly, every object has an id. Nil's id is 4. Always 4. This is just the way ruby is designed. This is because of the way the ruby interpreter loads objects when it starts up. Is nil the 4th object on the way up? I'm not sure about that. Well, if nil's id is 4, then which objects ids take up 1,2 and 3? Check this out:

irb(main):001:0> false.object_id

 => 0

irb(main):002:0> true.object_id

=> 2

irb(main):003:0> nil.object_id

=> 4

irb(main):004:0> 0.object_id

=> 1

irb(main):005:0> 1.object_id

=> 3

irb(main):006:0> 2.object_id

=> 5

false, true and nil have object ids 0,2,4 respectively. These are among the first subset of objects loaded by the ruby interpreter when it starts up. Interestingly, Fixnums get odd object ids. Why is this so? Why does ruby do things in this way? I don't know. Maybe its the answer to the eternal question. :)

Does anyone know how does Python or another dynamic language go about it?

When I started using memoization, some questions that struck me were where does the memoized data get stored? How exactly is it different from storing your model data in a distributed cache i.e memcached’ing it. Would it be more “efficient” to cache something in the distributed store such as memcached, that is already memoized? So, as I always do, I went to Anthony Garcia a.k.a frobot for clarifications. This blog is the result of several emails that were exchanged in the process. Any flaws with the information presented below are solely mine. 

Memoization and Memcached have different use cases

Memoization is simple and easy, and doesn't require any infrastructure. Memcached on the other hand requires memcached servers, boxes/slices to host them, and spare memory. However, the benefit is typically nowhere near as big for memoization versus memcached’ing. 

Memoization

Within the context of Rails, memoization basically "caches" the results of a computation for the duration of an http request — you're just stashing stuff in a local variable or instance variable. (Note that I say "computation." This is opposed to something that you typically cache (or memcache), i.e., a database request. So a computation might be calculating a complicated formula, or parsing some text, or building a complicated string or something). Anyway, I generally think you memoize when these two conditions are met:  

1) when you expect to be using that result multiple times within the request (so you don't have to keep recomputing it). And 

2) when you don't expect that result to be reused outside of this request.

Memcached

Memcache on the other hand is for caching results that are typically from the database, and will be used across multiple requests (so you don't keep hitting the database for what is typically the same data). So say you have a page that might be dynamic, but probably won't change all that much for some window of time. Even if it's just a few minutes, if you're talking about thousands of requests per minute, caching will be a huge benefit. But for those cached results to be available across multiple requests, they have to put someplace a little bit more long-lived than local or instance variables which go away once the request is done. And they have to be accessible to multiple processes (e.g. mongrels) and hosts (i.e. to all the servers in the cluster). So these obviously just can't be stored in a local variable or instance variable that disappears at the end of an http request (like with memoization). They have to be stored in memory in a separate process.

That's where memcached (the memcache server) comes in to play. Note that memcache is just one implementation of a shared cache — it just happens to be the most common one, at least in the LAMP world. Which means most large-scale web applications, but interestingly, not most enterprise or Java apps. Memcached is a process that can run either on the same host (or separate host) as your web application. You can run as many memcached processes as you have boxes with spare memory. Memcache is nice and simple in that all it is is a two-level hash: first it hashes to determine what host/memcache server to go to, and then it hashes again to do the actual lookup.

Memcache is also most commonly used for results from the DB. In this case, the cached results become available across multiple requests, multiple users, multiple processes and multiple hosts. That's why you get the most benefit from this when you're talking about scaling. For example, if you have a 5 thousand users requesting the same data, this results in only one hit to the DB. If those 5 thousand users request the same data 2 times each request this is still only one hit to the DB. If you had no memcache (and Rails automatic query cache disabled), this would be 10,000 hits to the DB. If you had no memcache (but Rails automatic query cache enabled), this would still be 5000 hits to the DB. That’s a lot of hits.

The bottom line

The bottom line here is that memoization and memcache, while similar at some superficial level, are really two very different things. And typically, if you're in a

situation that calls for memcache (which is any web application that needs to scale), only memcache will do. Memoization will only be of marginal benefit in comparison.

One other thing: ActiveRecord/Rails automatically caches the result of a DB query for the duration of a request, so if you're accessing the same thing over and over again during a request (which is very easy to do without even being aware of it), then you're not hitting the db every time. In essence, this is a form of memoization, in that the cached results are only available for the duration of the request. Again, this feature definitely has its benefits. But not the same as memcache.

What to memoize

Memoization is *typically* for expensive computations *not* from the DB, because you already get this sort of caching automatically from Rails, this is usually for "caching" other sorts of computations. Hence the use of the term "computation" rather than "query" or "DB resultset". Good candidates to memoize would be:

1. A method that performs an expensive computation by itself
2. A method that performs an expensive computation on data retrieved from the DB
3. A method that performs an expensive computation on data sent in from the controller (i.e. user), which is then going to be sent back to the view.

Where to memoize

Anywhere really. Although in Rails this is best done at the model layer, and possibly in helpers. "Computation" implies business logic and this shouldn't be done in controllers or views.

It goes without saying that starting a company is no longer a one man enterprise. In fact, even thinking along those lines is dangerous [1]. I think the best way to think of your startup is like a marriage between founders and the product will become your offspring. In reality you may end up spending more time with your co-founder than with your spouse or significant other. So it follows then, that getting someone on board who is competent, dependable, trustworthy and who matches your level of energy from the start is comparable to winning the lottery. 

A while back I made a serious effort to look for a co-founder. This turned out to be much harder and more time consuming that I expected. Here are some of my lessons learned and loop holes to look out for when you find your own. 

WHAT TO LOOK FOR IN A CO-FOUNDER

While it may seem intuitive - this one is actually tricky. The first mistake most founders (myself included) make is to join forces with a someone who does the same thing they do. This is human. We tend to socialize with people who come from the same socio-economic and educational strata as ourselves. Programmers will be attracted to other programmers, accountants to accountants and so on. However, if you are trying to drive an idea from concept to implementation, as in a startup, avoid this. If you’re a programmer, look for someone to join your team with marketing skills and vice versa. The danger zone is when both founders are enthusiastic about one thing, for example: writing code and then comes the time when the software needs to be sold, marketed or journalists have to be contacted - involving a different skill set than what the founders possess. Assuming you’re a programmer and you lack a VC team to supply you with the necessary contacts, and you don’t have a marketing/sales person on board to help, exactly how do you think you will proceed? Its one thing to sub for someone on your team when s/he is sick or takes off on a personal emergency. Its quite another matter to think you can completely replace a full-time sales person when push comes to shove. Reinventing the wheel will come at the expense of your company. Not to mention that the time spent learning these other skills will come at the cost of your main strength. Each day you spend learning this new trade, is an extra day you give your competitors an edge. So looking for a co-founder is more counter-intuitive than one would think. You need someone from another side to take a genuine interest in your software, your service model and help you aggressively ride that wave. From the start. You could still have another programmer co-founder, or as many as you want for that matter. However, if you’re thinking that’s all you’ll need, you’re probably not thinking of selling your product or managing client relations down the line. And if that’s the case, the rest of this essay probably doesn’t apply to you.

HOW TO GET A CO-FOUNDER WHO DOES SOMETHING YOU DON’T?

The best place is your workplace or the school you're going to (assuming it is relevant to your business idea). This is where most founders meet their prospective co-founders. You would have a really good feel for the people you work with every day. If they’re in the same job function as you and you want someone with different skills, then at least, you could reach out to these people who have a good idea of your level of competence and are possibly willing to vouch for you.

Look up your contacts on LinkedIn. Are you connected to people from a diverse range of job functions or are you connected strictly to people who do only what you do? If its the latter, that should be a red flag. 

Find local business schools, see if they have an entrepreneurial chapter and advertise accordingly.

Attend local meeting groups on startups or in the area you’re taking your startup in. Network, form contacts and if you’re impressed by the person, ask if they know someone who might be interested in your idea. My experience has been that most people are happy to help, especially if they can sense you’re enthusiastic about your idea. Not only that, I’ve run into some extremely competent and successful people this way.

Ask close friends. This is a gut decision. I like to make sure that the people I ask for such information are competent, trustworthy and will sincerely look for good contacts on my behalf. 

Advertise on craigslist, ebay, startup.ly, tech-cofounders and more. Chances are you’re going to get a lot of fakers, but if you can come up with a formula to weed those out, you might end up with some good choices.

Family: I’ll pass on this one. I like to separate business from personal. But if you think asking family works, by all means, go ahead. Like everything else, its a judgement call. 

INTERVIEWING

Do your homework. Ask lots of questions. State your terms and conditions clearly. Make sure the person understands how much equity and/or pay you’re willing offer from the start. Even with all this, there are going to be differences. But at least, you have a starting point. The process of interviewing itself is tricky. A very smart person told me the best interview is one where you can simulate a 40 hour work week or something as close to it. Either work together for a week or in a cafe for 3-4 hours each evening for 2 weeks or lock yourselves up in a room and brainstorm over a weekend and then some. If both of you come out alive and are still willing to work with each other at the end of that time, there is a better than average chance you’ll make it as a team. If not, at least you know right away rather than  3 months later. Even in this process there are several red flags that will pop up. Pay close attention so as to avoid the disappointment of feeling let-down later on. Here are some examples from my interviews:

1. “Oh by the way, I’m getting out of a divorce, selling my home and looking for a job which might involve relocating to another city.”. If someone has this much background music going on in his life, chances are he’s fantasizing about your business idea rather than thinking about it.   
2. Show them the competition and ask for opinions to see how they react. A co-founder who truly buys in be ready for this. If she bails at the first sign of competition, she’s probably not a good fit because she doesn’t have the stomach for it. Starting a company can be a grueling ride and not everyone has the stomach to manage the highs and more importantly, the lows.
3. Look for how the person thinks of your product and features. For example: is she randomly throwing darts in the dark and hoping one of them will stick? Or is she analytically reasoning, looking for market conditions, studying user demographics and logically trying to come up with what would work? Both aspects are important (startups have more randomness than I believed at first), but the second one is far more important.
4. Don’t be afraid to ask if there are upcoming life changing events. If you don’t know the person at all, this is very important. For example: Going to Kilimanjaro for 4 weeks?  Chances are most of these events can be worked through, especially if the person is committed, upfront and competent. 

Startups have a lot of surprises and not all of them are good. If you are thinking of committing your life, it only makes sense to expect the same from others who have bought in to your idea. Avoiding the “Oh, by the way, I’m going to be gone...” surprise is one less headache you’ll have to deal with. Its also a good way to ensure the responsibility and seriousness of your teammates.

HOW MUCH EQUITY? HOW TO VEST?

Be respectful of your co-founder’s time and talent. If she wants to work 60 hours a week on your project, be generous. I recommend vesting in stages. For example: 5-10% of equity per month every month until she’s reach her full equity entitlement. If your co-founder is really committed and competent, you want to keep her on board. Startups take over your life, and if your co-founder is willing to take on the risk as much as you, be honest and fair. 

PROTECT THE COMPANY

Protect your company. At all costs. Whether it is an NDA (so your co-founder can’t leave after 3 months and sell your idea), or a clause that says you can fire the person for behaving “inappropriately”. Have this written down somewhere, anywhere and signed off on. Even if it is worded in layman’s terms in an email. Signing off on something always adds a modicum of seriousness to the contract and people tend to think much more clearly when they do so. Whatever underlying or suppressed qualms they have will come out at that time. You might as well know. 

BE INTROSPECTIVE

This has everything to do with getting and retaining good people. Good people are hard to find. Really good people are next to impossible to find, possibly because they are working on their own ideas. Be honest, be introspective. Give your co-founder permission to find flaws with your idea, your implementation and with yourself. Most of all, lead by example. Subject yourself to the same terms and conditions that you apply to others on your team.

[1] http://paulgraham.com/startupmistakes.html

This article is written for technologists. It has the perspective of a technologist. It also applies to founders who are thinking of going it alone.

The theory of a startup is based on assumptions. The primary assumption being that you want to solve a problem - call it x, that hasn’t been solved yet. In an ideal world, you would write some code (assuming x can be solved using computer software), release it and tell the 10 people you know are suffering because x hasn’t been solved. They would  purchase your software or visit your website and end up being ambassadors for your project. By improving your software you would get more users and sell more of solution x. Then you’d find a VC (or two), make a pitch and work on getting acquired or getting more funding to grow. So what could possibly go wrong, right?

This article focuses on none of the above. It focuses on what we are unconscious of but is happening to us anyway during that run: hidden variables. Here is my summation of three.

Hidden variable #1: Don’t assume what you don’t know. Work on your market before you work your product.

If you're a technologist, it is the easiest thing to lure yourself into the trap of writing “cool” software. For example, for my first project, I decided to come up with a CMS like solution which I planned on marketing to condo-building managers and boards of Home owner associations. My problem in this area was that my building website sucked so bad, I couldn’t download documents from it on my mac. I spent two days playing with ruby on rails and decided it was the way to go. The next logical step seemed to be “Ok, what features will this app have?” And thus I dug myself into my first trap: I assumed that because I’m building a super cool website that can be fine-tuned to each building’s needs, that each condo building’s board and management will give me a chance to demo it and will fall out of their chairs when they see it in action. And they’ll be standing in line to use it.

In theory, one needs to have such crazy optimism to start a company and deliver the goods. We all have to start somewhere. Why not start with the best we’ve got to offer? If we write good software (perhaps even excellent software), that’s got to account for something. Right? Well, that’s true but like a Rubik’s cube, it is only one facet of the truth. Its like saying, “I know how to solve one side of the cube very quickly, therefore I’m capable of solving all the others as well”. 

What was really happening was that I was just pushing off the inevitable truth that there was a better than average chance that both I and my software would be rejected. I did do my homework though. I did lots of online research, looked at competitors’ websites, their pricing models, their marketing strategies, press releases (if any), and decided this would be a worthy endeavor. I made sure my app had > 90% code coverage (thank’s Rcov), I made it bullet proof with tests (thank you rSpec) and ran solid integration tests (thank you Selenium). Not to mention getting a professional web designer to help with nice mockups (back then, I had no clue about UI design[1]). Everything was bullet-proof. So what did I miss?

In hindsight, I would have done better to put on a pair of comfortable walking shoes and stop in on about 100 condo buildings around me (I live in Chicago, which has lots of high rises). I would have made a lunch appointment with each of the condo building managers. If the appointments materialized, I would have made notes of their pain points to see if they were even interested in something like this. This would have given me a good idea of the market I was trying to reach. Thus, I would have realized, that 

1. building managers control access to their boards and 
2. if they are not convinced that your software is going to make their lives easier, you’re screwed. [2] 
3. The average association/building management company has missed the internet wave altogether. Bye bye. [3]

But doing all this would have pushed me out of my comfort zone. And starting off, I was scared of so many things (I have no legal, HR, accounting, PR/marketing knowledge) that the thought of leaving my comfort zone was threatening. Unfortunately, this is exactly the step I needed to take. Instead of asking yourself “What language would I write this in?”, you need to trick your mind into asking: “Exactly who am I selling this to?”. In my case, the answer was “Managers and boards of condo-buildings.”. The next set of questions should have been “Ok. Can I be sure they want it? Does their survival depend on it? Or would it be a nice to have sort of thing”. Like writing software, working your market can also be an extremely analytical business. 

If I still wanted to stick to my comfort zone and write the best possible rails code, the next best option would have been to hire someone to do that leg work and run the numbers for me. Which brings me to...

Hidden variable #2: Don’t assume you’re superman (or super woman). Get a co-founder and a competent, energetic one at that. 

In the last 3 years, I’ve compounded my own hardships by assuming I could do every inch of leg work myself. If you’re going to be editing images in photoshop, coming up with front-end design, in addition to putting up the back-end code, fixing bugs, managing scope creep, that’s a full time job by itself (assuming you’re paying attention to detail). It may be one thing if your app has 3 pages, out of which one is a static home page, one is a login (and signup) page and one is a page with some dynamic functionality. Most apps don’t. On top of that, you have to attend local events to let others know about your latest project, you need to be on the look out for competitors’ moves and if you think you can pile on a whole lot of marketing work on top of all this, you have to be kidding yourself. There’s only 24 hours in a day. Donald Trump can probably sleep 2 hours a day and still be functional (and I’m pretty sure he’s doesn’t cook his own food or do his laundry or worry about paying bills on time)[4]. I can’t. And that means, I need to be on the lookout for a co-founder first. Ideally, this should happen before you even think about writing your first line of code.

If you do stop to think about it, there are so many variables with startups: the technology, cultivating a disciplined effort to get through ups and downs, market timing, getting the right VC, getting the product to market, getting and retaining love from early adopters  - these are just the visible ones. There are teams of brilliant founders with brilliant VCs to back them up and still many startups go wrong. It seems like they have everything going for them - smart and dedicated founders, smart VCs willing to write them a big fat check. So, if teams like this manage to muck things up, why do you believe that when there’s just one of you, you will strike gold where entire teams have gone bust? One answer could be (as mine was) “I have a lot more under my control - teams mean getting everybody to agree and that can take forever and besides, VCs can be skittish”. That’s true. But keep that Rubik’s cube in mind and remind yourself that your experience and knowledge are just one face of that cube. Assuming you’re in the internet business, unless you have a solid team in place, you simply will not have the time to explore, let alone master, the other facets of that cube. Think about getting a team in place. At the beginning. Not after you’ve made your first release. Which brings me to...

Hidden variable #3: Scrap the round robin approach. Run in parallel. And when I say run, I mean run with everything you’ve got! 

Here’s one approach I thought would work at the beginning of my second project: I would come up with a basic prototype. Then I would spam the heck out of my friends (just kidding, I don’t spam my friends) or get users, whichever comes first. Then I would get a co-founder. Together we would appear at local events, consult with journalists, spread the word and promote organic growth. Then we’d take the results to a VC and hopefully get some funding.

Well screw that. All of it. What makes startups worth the trouble is speed[5]. Being leaner, lighter, faster gives you an edge. And round robin[6] is not fast. You’ve got to parallel process. The smaller your team, the more parallel processing each of you needs to do. However, because we’re human i.e. there’s only one of us and several different tasks we need to get ahead on, its parallel processing with a round robin twist. Let me clarify.

Consider that I’m a lone ranger and I have a really cool idea I’m fully intent on pursuing, parallel processing would mean, I keep working on a basic prototype I have in mind. Simultaneously, I look for a co-founder. Simultaneously, I attend local events and start spreading the word. It goes without saying that waltzing with and through all these tasks takes solid organizational skills. I work by compartmentalizing. It helps me get a clear idea of the various things I need to get done each day and keeps me from spending half a day on twitter while consuming everyone else’s feeds. So for example, start by dedicating 2 hours a day to writing code, 2 hours to noodling on front end design, 2 hours following up on co-founder leads, 2 hours researching and attending local events, 2 hours researching and contacting journalists and so on.[7] You may never end up working exactly 2 hours on anything, but having some sort of a checklist will help you realize you are making progress (or not). If you could not spare even 2 hours during the week to get around to your co-founder leads, that should be a red flag. Drop everything you’re doing and ask yourself why. Once you get your team together, things will slow down a little and you can go back to doing one or two things and doing them really well.

Fortunately or unfortunately, those of us without funding and struggling for survival need to wear many hats. That’s part of the fun in running a startup. However, it doesn’t mean that you absolutely have to constantly juggle all the hats yourself. One juggler juggling 6 hats has a greater chance of making an error than 2 jugglers juggling 3 hats each. Get a co-founder and make sure she can juggle a different set of hats from yours. Her skill set  should complement yours, not extend it. Thus, you’re both doing your dance individually and at the same time together. Not mucking it up is an art form. Getting your dance down is half the battle. The more important half.

[1] I’ve gotten better since. Check out http://whatsinyourhive.com.

[2] In other words, they don’t care about updating amenities on a building’s website. They want something that makes their accounting process easier.

[3] This realization albeit demoralizing would have saved me a lot of hardship (and even more demoralization) 9 months later. I realized after printing brochures, direct mail marketing, using google’s Adsense and in person sales calls that the segment of people I was selling to had altogether missed the internet wave. In other words, I was trying to sell a calculator to people who saw nothing wrong with counting on their fingers.

[4] For the record I am not a Donald Trump fan. I was merely using him as an example.

[5] http://www.paulgraham.com/startuplessons.html

[6] http://en.wikipedia.org/wiki/Round-robin_scheduling

[7] 2 hours is just a number. Have your priorities listed out. For example: get a co-founder, decide on first 3 features for product, decide on language and so on. Then rank each item by importance and assign a time limit to each based on ranking. Assign slightly more time to the higher priority items and slightly less time to the lower priority items. At the end of your day take 5 and look through that list. Make up your mind to tackle items the next morning that you haven’t work on that day.