Sunday, August 29, 2010

Towards a Statically Typed Universe? Fun with ocaml

When I was younger, i was a zealot of static types. Today, I admit that I have more fun working in dynamically typed languages (namely JavaScript).

Now I'm older, I find that using the right tool for the job is the best way to ensure professional happiness. The type system is just a tool to be utilized to gain either a sense of correctness or performance.

While in my heart, JavaScript wins these days for my hobby coding, I'm diving into OCaml for fun.

It seems to me that statically typed languages are converging (or, trying to converge) in terms of happiness towards dynamically typed languages. It is as if the promoters of statically typed languages are actively working towards "programmer happiness". Well, with languages like Ruby and JavaScript, there is a massive debt to be paid.

Paying off a bit of the debt

I remember when compile time was a big black mark on statically typed languages. Back in the day, when CPU power was limited, this was a talking point against compiled languages since compiling was a major interruption to the flow of work. Now, the issue seems to be a matter of productivity. For instance, working in C# with KayakHTTP is a huge PITA. I have to close the running server, compile, start it back up again, switch to my browser, and finally I need to hit refresh. This takes too freaking long.

Well, I discovered an awesome *nix tool that really helps in streamlining the process for my new (unannounced) project.

inotify-tools

I recommend checking it out (in your flavor of *nix).

For me (your mileage may vary), this enables me to work with node.js and ocaml very efficiently. I can treat server side development the same as I do web based development. That is, i save my file and refresh my browser. Now, I just need a Firefox plug in to listen for refresh events on some socket (or other mechanism).

How?

Here is how I use it for developing new project. The general pattern is
  • wait for file changes
  • kill
  • compile
  • launch
I hope you find this technique useful because it makes my life better.

Friday, August 27, 2010

An Asynchronous Life for the Happy Hacker

I used to use notepad + a little bit of discipline to organize the non-hacking things in my life. Now, i have the EpicWin app; its... EPIC.

poll() loop
Unfortunately (or fortunately depending on your point of view), EpicWin doesn't interrupt my day. This can be a problem when the flow has set in and morning turns to night; my love comes home to find out that well... I didn't do anything for her and now I have to deal with wife-aggro-damage-control. Using the alarm clock, I set three interrupts for 9:30am, 1:30pm, and 8:00pm. I use these interrupts to go get things done related to my life.

This really helps in finding balance between the awesome work I do and dealing with the mundane aspects of life. So, I thought I would share my quest list with the world.

Every Day Tasks
  • 75 pushups (+200 str)
  • 100 bicep curls (+150 stamina)
  • 100 crunches (+150 stamina)
  • Drink 32 ounces water [9am] (+100 spirit)
  • Drink 32 ounces water [2pm] (+100 spirit)
  • Take Afternoon Calcium +D [2pm] (+100 spirit)
  • Drink 32 ounces water [10pm] (+100 spirit)
  • Deal with Dishes (+200 stamina)
  • Take Evening ZMA [11pm] (+100 spirit)
  • Read Twitter [9am] (+50 social)
  • Read Twitter [2pm] (+50 social)
  • Read Twitter [10pm] (+50 social)
Every Sunday
  • Cook Level 3 Dinner (+300 social)
  • Read Current Book (+300 int)
Every Monday
  • Get groceries at HyVee (+100 stamina)
  • Cook Level 1 Dinner (+150 social)
Every Tuesday
  • Walk 6-12 miles (+300 stamina)
Every Wednesday
  • Get groceries at Whole Foods (+100 stamina)
  • Cook Level 2 Dinner (+100 social)
  • Watch The Colony (+100 social)
  • Go Drink'in at Buffalo Wild Wings with friends (+100 social)
Every Thursday
  • Prepare Level 0 Dinner (+100 social)
  • Walk 5 miles (+300 stamina)
  • Catch up on HN and comment as appropriately (+100 int)
Every Friday
  • Cook Level 2 Dinner (+100 social)
  • Take out Trash (+100 str)
  • Write blog post (+300 int)
  • Play Settlers of Catan/Mario Kart with friends (+300 social)
Every Saturday
  • Solve one PhD problem (+300 int)
  • Walk 3-6 miles (+300 stamina)
  • Publish and post edited blog post (+300 int)
  • Grind on Bills and Validate Financial Integrity (+200 int)
  • Hang out with Family 2.0 (+200 social)
  • Clean Kitchen (+100 stamina)
  • Fill vitamins for next week (+150 spirit)
aside) 3 segment work day
I'm one of those people that can hack all day. Sit in front of a computer and enter the flow. This is great for research, hacking, making things work, and getting things done. Problematically, I have to interact with the world beyond my the limits of my skull, and my mind is supported by a problematic human body that is frail and needs to get out into the light. Ergo, I have to control the flow before it destroys me.

While I wish I could hack all day and all night, I limit myself to a maximum of 12 hours a day for work/hacking. While 12 hours is way more than needed, I break it up into 3 segments. I think anywhere between 2-4 hours is enough to get any serious task done (or series of tasks within one context). Once the flow ends, I switch to a different context. I call this the "Hardy Hack" since GH. Hardy wrote in his apology that 4 hours is the limit of time to get any serious math done; I extend this with the caveat that 4 hours is the time limit per context. If you finish the task in less than 4 hours, then goof off and have fun. The hard part is finding the discipline to make sure you are honest in how you plan your day out.

Tips for Asynchronous Behavior
  • Learn to think critically while exercising.
  • Channel all interruptions (i.e. cell phone or email) to occur during mundane tasks.
  • Have you significant other go through your twitter while you do the dishes.
  • Learn to negotiate with the your significant other to shard tasks.
  • Group as many mundane tasks together and get them done with (i.e. use proper cpu scheduling)

Redemption of a Cowboy Coder

Often, cowboy coding is looked down upon as a form of egotistical manic programmer that doesn't work well in the team environment. This can be very true, but it is an over simplistic view that is depressing for smart people who tend to cowboy up more often than not.

For a cowboy coder, the right thing to do is to do a start-up and then cowboy up so hard core that the product is awesome. Get the product into the market. Get it sellable. If it sells (which is way harder than making the product), then jobs have been created to support the product since the cowboy coder probably made a lot of mistakes that need human intervention.

I have a theory that this is one reason that most commercial software kinda sucks, but it is also why the job market for coders will always be strong.

Thursday, August 26, 2010

Four signs of an awesome coder (or person)

1) Studies the craft

When I talk to a person, and I find out that they read @codinghorror or some other technology blog, then I know "hey, this person is trying to catch up". If they have read both dragon books, then I know "this person is super cool and super awesome". I believe that core to being awesome is to be in a state where you know there is always more to learn and actively work towards knowing more than you did yesterday.

2) Codes for fun

What you do in your spare time says orders more about you than what is on your resume. If you wrote a super awesome CMS that enables you to publish your own content in a way you think is awesome, then you are awesome.

It doesn’t really matter what you write in your spare time because we all do what we do to make our lives better. I knew a guy in college (in the math department) writing his own parser generator language. Why? Because he was awesome, that’s why.

Also, you should never need to justify you work unless someone is paying you to do something else. Your work is what will make you awesome. I wrote a computer algebra system in graduate school, and many people asked me “why don’t you just use mathematica”. Any answer besides "Because I’m awesome." is wrong and disingenuous (of course, you should try to keep the ego in check)

3) Has a metric of quality

The most awesome coders have a sense of beauty in some form of metric that gives them a direction. This is the source of most (if not all) of the flame wars in the field since people have to work together yet have to do so with different (and often incompatible) metrics. Your metric may be performance, brevity, organizational, extensibility, obfuscated, or any other innumerable metrics that we judge code by.

As long as you have a metric, then you are awesome. You should grab a sword and shield and head toward reddit to do battle. Myself, I used to battle in the realm of type systems. These days, I'm going to champion NoSQL and kick some RDBMS ass.

3.5) Get shits done

Thanks to a comment in HN. Having just a metric implies being a critic. One also needs the process/fortitude to hone the craft to be an artisan. Or, as the commenter put it: "gets shit done".

4) Has an open mind

An open mind enables objectivity and the ability to change your mind. If you can change your mind and try something new, then you can advance your knowledge and learn something new rather than keep stale knowledge alive. Learning something new is always the best way to expand your skill-set and maximize your metric.

The more open you mind is, the more science you can do, and the more awesome you can be.

Advice) Toward a better future

Now, having pointed out the signs, I can give you my awesomeness advice. Read at least one to two books every year and follow at least one technology blog/aggregator. Start a new open source project that you think will be awesome, or join another project that you think is going to be awesome. Ask yourself, what is beauty? Is it fast code? Is it brevity? Is it clarity? Once you know thyself, then you can start to measure and hone your craft. When you find yourself faced with a change, think about it. Do you have more to gain or lose? How can you experiment with the change? How can you measure the effects? How can you isolate the change? How can you bound your fear? How can you reap the reward?

Dangers) Life

If you want to be awesome, then you have to learn to deal with one very difficult part of human life. Disappointment in others, your environment, the world, the government, and yourself. Becoming awesome is hard work, and many can't get there because life is non-linear and from our perspective non-deterministic. Along the way, you may realize that you can't reach the level of awesome that you dream about due to any number of reasons (not enough something, shit happens like a bus, or you changed your mind).

Let go of negativity. Learn to adapt. Being awesome is being able to get up and adapt to something else. My personal hero in life is Bruce Lee with this awesome quote to his credit.

"Empty your mind, be formless, shapeless - like water. Now you put water into a cup, it becomes the cup, you put water into a bottle, it becomes the bottle, you put it in a teapot, it becomes the teapot. Now water can flow or it can crash. Be water, my friend." - Bruce Lee
The ultimate way to be awesome as a coder is to be water, my friend. This advice probably extends to anyone, so go forth and be awesome. Or, at least try.

Sunday, August 22, 2010

Why Open Source/Free Software Rocks!

For most of my formative years, I was primarily interested in building stuff as a personal hobby. Back then, when I first learned about Open Source, I was skeptical for one primary reason: financial (I need money ergo I need a job/gig). This reason is no longer a concern due to the brave souls that made open source software lucrative for businesses to build on.

The world we live in is not an absolutely rational world as there are no universal metrics of quality. This is where irrationality and human psychology comes in kicking over my objectivist dreams of being Hank Rearden and building the most awesome ... thing .. ever.

We humans are interesting creatures.

Why does having code rock?

I believe that having access to code, being able to extend other's ideas, and being able to combine code accelerates the art of computing through a form of evolution.

I used to have the idea that having access to code stinted the progress of innovation, but I didn't know the jargon/idea to effectively communicate it. Now I know that it is called Anchoring. By itself, anchoring is extremely bad for innovation. It forces us to use old technology to solve new problems. While this isn't bad for business as usual, it makes it harder to be disruptive and solve new problems.

Fortunately, there is a stronger force called Not Invented Here (NIH). Usually, NIH is referenced in the negative. However, if you are aiming to provide a new service or enable people to kick ass, then you need to execute and make it happen rather than being anchored to existing technology just because it worked for your old problems.

These forces combine and enable new inventions to mature to the point where the next step can be visible to someone in the community. The next step may be a small contribution, be a complete rewrite, or something entirely new and unexpected. It doesn't matter, it just speeds up our collective awesomeness.

I'm glad to have finally caught on... I wonder if I am in the early minority or the late majority.

Saturday, August 21, 2010

NoSQL and You, what is the daily deal for databases

To promoters of the relational world, I wish to speak to you as a concerned human being. Your days are numbered just like the days were numbered for COBOL developers. I wager I'm in the middle group between innovators and early majority, and I'm working towards figuring out what NoSQL solutions mean for businesses that rely on persistance.

This isn't a rant about scalability.

Scalability is just one facet that the NoSQL movement aims to provide, and it is the big facet that will get important players involved to fund the polish that makes NoSQL solutions awesome. Scalability isn't the biggest argument that promotes NoSQL solutions. The biggest and best argument is flexibility and how we can design software around NoSQL and solve problems quickly.

Flexibility always Wins

Unless your art (or job) demands you work in assembly, then you don't work in assembly. The struggle to produce high level languages has yielded a multitude of languages that are in-arguably superior to older languages for many domains. The quest for a better way to express how we compute continues on. and on. and on. and on.

The NoSQL movement is no different, and it is core to our quest for a better way to represent and share data. We seek better ways to store data. We seek better ways to share and transact data with other processes over a network. We want need our queries to be fast, optimal, and beautiful.

I believe the current generation of NoSQL solutions provide a platform for making our lives better, our work more productive, and enable us the flexibility to refine our services.

Momentum

Due to the companies that sponsor the work behind NoSQL solutions because they have scalability problems, we have enough momentum and interest to overcome the technical debt that causes typical databases to remain entrenched in small and medium sized sectors. NoSQL solutions are untested in many sectors and domains, but the current generation of start-ups are going to test them and polish them to make them work for a larger class of problems. Due to the open source nature of the multitude of NoSQL solutions, the knowledge to solve problems and the tools will be available either for free or offered by a vendor. This is great!

What is wrong with a Database?

Nothing! But, there is nothing wrong with assembly either. Sure, you can build any NoSQL solution offering with a Database. But then you are building on top of a crappy NoSQL offering. What matters in NoSQL isn't where or how you store data, but how you design and build services. Being competitive in this day and age means being flexible to adapt and iterate. How does one enable flexibility with NoSQL? How does one execute and deliver change to make services better? These are open questions that the programming community is facing now, and we will be answering them soon.

The Complement Set

The relational theory set forth back in the 70s is an amazing mathematical model. However, it is just one model. Is it complete? What is the set of all solutions that span the offering of a database package? Is it everything? No. The problem that set me on the path towards NoSQL solutions is that of graph traversals. Relational databases are horrible at graphs. It is no surprise that due to the rise of social networks, the interest in graph based databases has gone up as well. While this is a single problem, it is sufficient to demonstrate that relational databases are not the everything panacea that some claim it to be.

Better Database Education?

"Just learn everything your database offers!" While this is an argument that I would have given years ago, it is not an appropriate response for entrepreneurial computer science (the name of my future book). It is far more important to create a product that generates revenue, so if I run into a business problem that depends on code then I need to solve it quickly to test viability and get market feedback.

Using a database may be the wrong way to persist data, which means that what you initially learned about databases is probably bunk. Most medium sized problems can be solved by using insane amounts of memory as an intermediate cache to some Key Value Pair System (for backups and failure persistence). If I go back in time, I would unlearn what I know about databases and just make a product like I was doing when I was 16. All the knowledge of how seek time affects hard drive performance, network latency, and all the other tier data bottlenecks is bullshit (given that in today's world I can get commodity servers with insane memory). I can use that memory to solve problems at both the small and medium scale to get revenue, and that revenue will fund the larger scale version which may be easier to build due to the choice of NoSQL designs in the beginning.

I believe NoSQL techniques are the path from transient memory to a persisted disk, and I feel that designing and learning how to make NoSQL work will be more valuable than knowing how to configure and consume a database package.

In the End

What matters most is providing a service to the world.

If you argue that a relational database is good enough, then it is good enough... for you. If that is the case, then don't tell me what is good enough because you don't know the crazy shit I'm working on that could change the world for the better!

Friday, August 20, 2010

Journey back to OCaml; a land forgotten by marketing

Some years ago (3?), I used to regularly hack in OCaml. I'm picking it up again as my hobby/research language since it resonates with how I think (and more importantly how I think about the universe from a static typing/academic/math perspective/performance perspective).

Picking up OCaml is like riding a bike after three years in a hospital, and it is awesome; it just makes me happy to use.

Since I've been dealing with web stuff mostly, I wanted a platform that makes my life in OCaml well.... pleasant. I also want to build distributed systems with OCaml where machines can work together holding hands and drinking each other's koolaid. So, I'm building that platform first. It is called node.ocaml and can be found on github.

My hope is that my platform performs well and enables me to experiment and build some interesting services.

I choose OCaml because it's interesting, and because it is not marketable. It makes the boundary between my work coding and hobby coding very crisp.

Saturday, August 14, 2010

Guide to databases in a start-up; execute the vision

I've been doing start-ups for about 3 years now, and I love it because being in a start-up is probably the most hard-core way to live. It is super-duper fun. For sake of my own humility, I've made many errors and (am reluctantly forced to) embrace my errors as super-awesome-learning-experiences. If I were to start over (which is always a possibility), then this is how I would do it.

The Task

When you are starting up, you have a blank piece of paper and you need to turn the emptiness into a product. If you try to build it to be perfect from the start, then you will probably fail hard-core and waste a lot of time "refactoring". You need to realize that the need for change is the only technological invariant in a start-up. Changes come from many sources, and you need to hit the market as soon as your product is viable.

The Task as "the guy who knows databases"

The simple version of this task is "to not fuck things up", but it is impossible not to fuck up because that is the nature of the game. So, the task is to enable change and encourage change; that is a tall order, and it takes a bit of magic to pull off. Don't worry, this guide is here to help. The first step is to forget everything you may have learned in school about databases. In fact, forget everything you've learned during previous jobs. And, by "forget", realise that I mean that there was a context to what you learned that was relevant at the time. In a start-up, you have a blank context and you need to find what that means for your product.

Step 2. NoSQL to the rescue

The typical scenario is this: you have a bunch of users that have stuff. All of that stuff, we are going to put into a giant object per user. Where do we put it? We put it in a file (the file system is the oldest NoSQL solution on the market) with the user's email as the filename.Use one giant object for storing whatever it is that your users want to store; this object is your per-user database. (I'm glossing over collaborative features, but the key here is to center on documents as giant objects.)
Rule: Use huge objects for everything sharded by the most obvious key (i.e. user)

Benefits: It Scales! Simply use S3 as a drop-in replacement for the file system, and you are done.

Big Con: It is all disconnected! Oh shit, it doesn't do anything useful or provide any insight into what is going on.

What about concurrency? Just man up and use file locks until you need fine-grain locking; chances are, you will not need it until you get some sales guys messing around with your users' data.

Step 3. Enable Reporting

When you need it, you replicate from your file to the database/search/other thing. That is, when you perform an operation on your file that changes something, you then need to update wherever you replicated to (I know, I know, amazing insight). I recommend focusing on table differences since it works very well with database systems. You can quickly enable table differences by writing a function that generates an in-memory version of your table (per user) respective of your user. Any operations that changes this table need to store a copy of the table (per user) before, then change whatever, then compute a copy of the after. The difference focuses on items that (a) are new and need to be inserted and have primary keys allocated, (b) are deleted, (c) are changed. It sucks, but it will work for enough time. Another option is to delete everything in the database respective to that aspect and regenerate it (this works well when you need to do it asynchronously and have to rely on a potentially out of order queue).

Benefits: Huge Scale. As a bonus, you are ready for both database sharding and map reduce techniques should you determine which will work for you (or maybe a mixture of both).

Con: It is slow to replicate. Yes, replication sucks for many reasons. However, you can get a quick boost of adrenaline by injecting a queue and doing the replication asynchronously.

What about the CAP theorem?. The CAP theorem is a giant kick in the balls, but you don't need to worry about it yet until the product has matured to the point where CAP actually matters. Just make sure you back-up hourly... ;)

Step 4. Build Secret Thing

This is where you collect data from your users and turn it into happiness. This is what makes your product awesome. This is what makes it work. This is what you want to build without worrying about stupid scalability or performance crap. This is the thing you think about while in the shower. You are on your own; good luck.

Step 5. Prepare for changes

At this point, you have users and documents that have some form of reporting. You have something cool that makes the business work. That is 10% of the challenge for a start-up. After building it, you no longer have a blank sheet of paper. You have something, and you need improve it. Chances are, the technology and code doesn't need to be improved for its own sake. Honestly ask yourself these questions once the prototype is built: Does it have a market? What can make the product more marketable? Your few users are complaining, how can the complaints be resolved? Your visitors are bouncing, why are they bouncing? Does the UX need to be improved? Answers to these questions are where changes come from, and they come from everywhere. You need to be able to quickly adapt and respond in a timely and reasonable manner.

Aside: Is this a good strategy? For technology awesomeness? No. For business? Yes! The above strategy has commercial vendor support. Look at S3 and SimpleDB, they basically do what I am promoting at some level with EC2 for building your secret sauce. Do I recommend jumping in Amazon's boat? Not yet, you may not need it. The optimal goal is to make the product as fast as you can and try to determine the market-fit of the product. The faster you make it, the sooner the entire company can be involved in product iteration. If you can't market or sell the product, then it doesn't matter if you need to scale it up or have Google's performance. However, you could probably open source it and build a consulting group around it if you can neither market nor sell it.

Step 6: Support users

We live in a golden time where storage is practically free and infinite. Since the core to this strategy is a Key Value Pair System (file system, s3, etc), the best thing you can do to support users is record everything. Every time you save your user's data, keep a copy of it with a time stamp, IP, and the user id that invoked the write. Just do it. This enables you to support your users in ways that aids both operations (faults/security breaches), developers (finding bugs), and the user (data recovery).Also, make a backup every hour and test recovery every week. ;)

Epilogue: Good Luck

If you are in a start-up, then good luck.I hope you have a good idea that will make my life better, and I don't want you to fuck up on the execution.Give me something that will make me better.Give me something that will make me happy. Give me something that I want. Give me something that my woman will want. And, I? I will give you money for it. How much? $9.99 or maybe if you are lucky, $19.95. Do not fuck up the execution; find the humility to just "make it work" even if it kills you on the inside.

Ninja Programmer? Why are people so literal?

When I read Stop Calling Yourself a Rockstar and a Ninja, I was annoyed on a personal level. While I'm not a rock-star, I am a ninja. Problematical for myself, the implications and connotation of being a ninja in team are ... not good to say the least. As it was writ by the author:
Wow... that sounds awesome! Let's hire a backstabbing assassin for our company! Wait... is he assassinating us or infiltrating us?
So, yeah, being a ninja isn't so good. Wait, what about Teenage Mutant Ninja Turtles? They were awesome. I want to be like Donatello and have a big stick (i.e. bo). If TMNT can band together and fight crime, then being a Ninja must be a good thing. So, I'll keep calling myself a Ninja. I wager the author is an old fart that did not grow up with TMNT... Oh well.

Besides, it is very appropriate if one thinks about it. There is a bad bug on production, I have to log in as root (because I'm a real man), navigate the file system, enter the file, find the line of code, and change it without anyone being the wiser. The implied negative vibe against ninjas
The functions of the ninja included espionage, sabotage, infiltration, and assassination.
are awesome if the ninja is facing bugs and problems. Any negative can be made positive in the right context.

However, maybe the author of the post has a deeper issue that he should seek therapy on. When presented with the functions of the ninja, the first reaction was that it was against the company. Why the latent aggression towards the company? Is this a Freudian slip of sorts? I think it is interesting... nothing more.

Now, I just hope that people don't realise that my wanting a big stick has anything to do with my penis. Psychology is such a harsh mistress.

Saturday, August 7, 2010

Fall is for walking, and how I am changing my life

As you may know, I'm a fattie. This fattie has issues, and part of the answer is to lose weight. The other part of the answer is to become more of a people person. Over the past two years, i stopped the gain and have a very slow loss. I've lost about 20 pounds in the last year. Can I do more? yes.

Over the past four months, I've increased my fitness level to a point where I no longer feel the burden of my weight. Now, I need to lose it so I can feel like super-man so I can jump over buildings and fight crime with my awesome pecks.

Recently, I've been walking in the real world rather than using a treadmill. Once I maxed out the treadmill at 70 minutes, it became very boring and not challenging. So, I started out in the real world which started when my car's muffler fell off and I had to walk to/from the mechanic to get it fixed. It is liberating to drop off your car and walk two miles to home-base.

After walking, I moved all our (me + my woman) shit; it was liberating to not pay big $$$ for movers and just move my shit myself (Except for some of the bulky stuff which required the usage of some of my awesome friends). My back has recovered, and I feel stronger than ever.

Now, I'm walking again. I've been walking 6-8 miles every week and I'm going to step it up a notch. I'm going to walk 100 miles (in aggregate) once fall hits. I can get 6 miles every three days by walking from 139th & metcalf to 119th & metcalf. However, I'm going to try to walk a little bit every day (like in the old days). I have a lot near me within a 1-2 mile radius. I also plan to walk to Missouri! How fun would that be? Its only five miles to Missouri, but I figure I can make a 11 mile walk to and from the jack stack in martin city.

My ultimate plan is to walk for 90 minutes a day (or about 2 miles). In 2011, I want to walk to Lawrence... Why? I don't know... It's only 41 miles (and thus 20 hours of walking time). But I'm sure it would be awesome to feel that level of accomplishment.

btw: I advise in investing in audio books.