Thursday, September 30, 2010

Hack the Planet: How I solved Global Warming in my sleep

I'm a level 1 hippy, and I think the best way to save the planet (because that's the sexy thing to do these days) is to be conservative in what and how I consume. The problem is that requires changing a whole bunch of angry kids (Americans) minds about how to live. Instead, I wonder as I lay in bed wondering things that could be: what if I hacked the planet?

How could I make the world cooler? Well, we can't build a giant air condition because that's just heat exchange and it wouldn't work. Bummer. We need to hack the planet, and either vent excess heat or prevent heat from entering.

Simpsons did it.

So, how do we block out the sun? If we go far enough out into space, then the projected distance of whatever we build would leave a larger shadow. Think of an eclipse where the moon blocks out the sun. If we go out farther, then we don't need to build a moon. (Although honestly, we need to build a moon and control it; how cool would that be).

What if we built a disc out of aluminum foil (you know, to enable it to gracefully degrade to deal with all the junk in space that will hit it) and sent it out into space? Yay! How much would it cost? How big does it need to be? How far does it need to go? What evil plans could I unleash onto the world if I controlled the sun? Could we position it to allow us to effectively negate heat waves in large regions and control temperatures per city? It could pay for itself if an global auction took place to cool cities and save energy!

Well, a few Google searches away, I found this interesting document that I would like to bring to your attention:

Global Warming and Ice Ages
I. Prospects for Physics-Based Modulation of Global Change

And, low an behold, they did the math and it costs less than $1 billion dollars per year. Seems like a heck of a good investment. So, I'll post this on HN and maybe influence the movers and shakers to move and shake.

I on the other hand will go back to bed knowing there is viable solutions to global warming, so tomorrow I can be guilt free in building yet another web framework.

Monday, September 27, 2010

Node.js love (and other cool technologies)

I think node.js, redis, CouchDB are the best web technologies of this year that have matured from neat ideas to things I'm willing to put into production.

To the contributors, movers, and shakers of these awesome technologies, I salute you.

My prediction for 2011 is that node.js (with the help of redis or CouchDB) will over-throw Ruby on Rails. I could justify that statement, but I'm not going too; I just feel it in my bones. My bones tend not to lie about these things.

Thursday, September 23, 2010

php.js

massive library for JavaScript that ports a bunch of common php functions:

http://phpjs.org/

WIN is going to use
  • addcslashesaddslashes
  • get_html_translation_table
  • html_entity_decode
  • htmlentities
  • htmlspecialchars
  • htmlspecialchars_decode
  • md5
  • sha1
  • mt_rand
  • base64_decode
  • base64_encode
  • parse_url
  • urlencode
  • urldecode
  • date
  • date_default_timezone_set
  • date_default_timezone_get
  • strtotime
  • time
  • timezone_abbreviations_list
  • utf8_decode
  • utf8_encode
Thanks to the php.js team!

Tuesday, September 21, 2010

Technical Debt for WIN

Well, I have a really good start on WIN (see prior post).

I have something that is kinda working and nice.

check it out

Here is the obligatory list of things that need to go into it to make it a real web platform:
  • Template Engine (Mustache)
  • Sessions (done, in memory)
  • Secured Session ID generation (done, thanks to php.js)
  • Spam/Bot Detection (Skip)
  • Rate Throttling (Skip)
  • Get User IP (Done)
  • GeoLocate the IP (Skip, need to build node.js module for GeoIP)
  • SSL Support
  • Linking (SSL, Absolute, Relative)
  • Auto Path Normalization
  • Some form of Persistence Support (Going with Couch DB)
  • Asset Management (JS, CSS, Language Files, SWF, Images)
  • Language Detection
  • Time Zone Support
  • i18n language support
  • Password Salting (done, thanks to php.js)
  • Multi-Error Handling
  • URL Routing (done)
  • Capcha Support
  • Large Scale user file system (part of an Asset Platform/CDN)
  • asset linking (maybe an asset platform is needed?)
  • static KVP cms (memcache to something else)
  • basic validation routines (just collect email, credit card, etc)
  • std package system (i.e. easy to clone: login, forgot, reset and friends)
  • geocoding
  • email (remote to HTTP service)
  • datetime (done, thanks to php.js)
  • REST clients (vague, got couchdb, what else do I need?)
  • CSV parsing (Skip, don't need yet)
If I spend 1/2 day to crank out a basic version of each of the above, then in half of a month, I could have the most awesome web platform ever!

EDIT: Or, I can go find stuff that already exists. :/

Monday, September 20, 2010

the WIN platform

I've played with ruby, I like the language, but I'm not really digging how the database gets managed with rails. That and I don't really want to use a database any more since I don't need too. Gauh, I just need a simple front-end platform that doesn't do models. GAUH, and I don't want to use PHP.

I'm going to do something extremely crazy.

I'm going to start a new web platform (because that's exactly what the world needs) using node.js for front-end development and node.ocaml for back-end development. Now, I have to think about the name since it should have a cool acronym.

its-a-node-world = IANW?
node-world-tastic = NTW?
NodeSForWeb = NSFW?
world.on.node = WON?
world.in.node = WIN?

Yes, WIN. But, World.In.Node is kind of lame..? We geeks like recursive acronyms

WIN Is Node?

That's brilliant marketing. Well, now that the marketing is done, I need to build it.

Going to use mustache; it looks awesome and fits my universal view of what front-end developers need. Going to need routing; that's fairly easy and I've written it a billion different ways. Going to need sessions; that's a natural fit with node.ocaml's kvp system (that and node.ocaml is in need of serious testing). I just added file writing to node.ocaml, so that provides some form of persistence, and I can easily use node.ocaml for ACID. I've learned to not use cookies except for sessions and encrypted ids, so I can safely avoid most of those issues.

Things I need to think about: handling file uploads with node.js with some form of replication to S3 and a universal name space for files. This could be fairly neat especially with a work queue. Need to think about package management. Uploads / Session.

Gah, so much to think about!!! must go to sleep but hypomania taking over!!!

What about node.ocaml deployment?

GAUHHH!!! Must Sleep

Saturday, September 18, 2010

Thinking about joining a start-up?

If you join a start-up and get your full pay, then it is just a job and you are just an employee. If you don't get full pay, then guess what? You're an angel investor! And to protect yourself and get a fair shake of the deal, then you need to think like an angel investor.

Being an angel investor is more of an art than a science, and it takes years of experience and a multitude of mistakes to know what to look for. I generally look at these two things first:

The first thing to look for as an angel is look at who is driving the ship and how they respond to advice and criticism. You can learn a lot by attacking the person driving the ship from a critical stand-point. Do they get angry? Do they deflect? Are they blinded by their product? Are they objective? Do they hear you out? Do they counter? How they react to you is indicative of how they will react to other angel investors and venture capitalists who will ask much more invasion questions than you will ever have the balls to ask.

The second thing to look for is a hacker (and this could be you); if they don't have a hacker and you're not it, then I would walk away from the deal. It's going to fail.

Finally, as an angel, you should figure out what that means. Start exploring today

I have more to say on this, and I will write more over time on this subject since I find start-ups as the funnest place to be.

Thursday, September 16, 2010

Ideas, teamwork, execution, success; the nature of building stuff

I love it when I have ideas. However, my own internal metric for how I value my ideas is diminishing because ideas are a dime a dozen. The key to pulling off an idea is execution. This is old news, and I find myself with millions of ideas but not enough time, money, or people to pull them off. The ability to execute on an idea and get the idea into a form that helps people is the greatest talent on earth.

The greatest challenge with having an idea is not to fall in love with it. Sure, you can love it, but you can not be _in_ love with it. The moment you are _in_ love with it, then you are entrenched. Problematically, you can't scale, delegate, or be objective. The goal of having ideas is to be able to find people that can fall _in_ love with it so they spend their energy and life force into executing it. Passion is the key to executing.

Problematically, having an idea and giving it away means that you can not take credit for it. If you take credit for it, then you risk the other person falling out of love with it. In my world, no love equals no execution.

Making people fall in love with your ideas is surprising easy if they value the end result. You just lead them on and let them form the final part of the idea (or something better). Humble people will give you credit and work earnestly; egomaniacs will drive themselves relentless so they have the credit. Either approach works for getting the job done.

Personally, I have difficulty with other people taking credit for my ideas, but then I realize that I'm blessed to see the infinitude of ideas that could change this world for the better.

So I have a choice:
  • Do I stay in my cave taking credit for the world's progress to myself?
  • Or, do I build a team and start chipping away at the ideas to make the world awesome?
I choose to do team building (although living in a cave is an attractive idea)

Teamwork is hard for a multitude of reasons, and I've always felt that the best way to do it is to encourage/woo everyone to be in love with the idea. This quote guides my management style.

"If you want to build a ship, don’t drum up the men to gather wood, divide the work and give orders. Instead, teach them to yearn for the vast and endless sea."

– Antoine de Saint-Exupery

The key to this is to give ownership and autonomy to the parts of the idea to the people so they can own it and execute on it. This is no easy task as you have to let other people own and take credit for the idea. If you fail at giving credit, then you can' execute.

If you can't execute, then you fail.

If you execute, then you have Success!

Tuesday, September 14, 2010

Special people in our lives

I would like to take a moment to thank the special people in my Life.

Currently, I have a company of friends. I have my fiancée. Thanks for being Awesome.

In college, I had excellent teachers. Dr. Hsu, you're awesome. Dr. Burckel, you're awesome. To all my KSU professors, you're awesome.

In high school, I had two particular teachers that enabled me to develop in my own special way. Thank you Miss Farmer Mrs Julian. Thank you Mrs Phillips. Thanks be to the librarians that put up with my shenanigans.

All of the teachers that I remember were awesome, and I can remember a long chain of teachers going back to Mrs. Williams in first grade. Teachers are awesome.

I believe the best way that I can honor them is to be the best person that I can be, and my fiance is the focal point of my life. I've had a lot of grief over the years, and I wouldn't be able to live in this world without her. I have come from the darkest regions of my mind, and I've stood in the face of darkness. I have the power to resist the temptation.

John Lennon was correct and "All you need is love".

I've always fashioned myself as a hard person since that is what I thought the world needed. I was wrong. The world needs me to be the soft lovable Santa type figure that always has a smile and a large supply of hot cocoa.

So, I'm going to be positive from here on out.

And when I come around a negative person, I will hug them and move on. Life is too short to try to convert the haters and the closed minded people that make the world unpleasant.

Saturday, September 11, 2010

announcing node.ocaml

I've been spending my weekends building node.ocaml as a both a learning exercise in doing asynchronous programming in C and OCaml using libevent and as a way to get back into OCaml programming. node.ocaml is open sourced under a BSD license.

While I have many crazy ideas I want to do with node.ocaml, I find myself pleased with what I have as it has become useful (for some of my current projects). Not only am I happy with it, but I'm going to go stone cold crazy and start pushing some of it to a production environment. So, its now game on to finding and stomping out bugs as well as define deployment procedures

Currently, there are two example servers.

There is an ultra simple key value pair storage server and a geo-tagged-document search server. The KVP pair storage is basically inspired by memcached except without expiration polices; while this would be nice to clone to memcached, it would clutter this baseline example. The geo server is useful as a way of providing local search and local analytics quickly; that is, its a quad tree server (which I hope is correct, but I will soon find out).

Performance out of the gate has been very good. I've just utilized libevent's built in http server and kept all the code asynchronous. I'm sure I need to optimize some buffer utilization, but I'm pleased with what I have and the interface that I'm using.

The unix guys were smart by thinking about data in terms of lines, and by thinking about lines it makes building/connecting this stuff fairly standardized. Combine this idea with JSON (minus white-space), and you can build some expressive data servers with a decent protocol.

Why I called it node.ocaml?

I love node.js. It makes building custom servers fun again. However, every-time I do anything in node.js, I feel like I'm going to regret it and pay some terrible performance tax in the future. I like to squeeze every last drop of power from my CPU, and this is part of my art. I love fast code.

My goal is to utilize OCaml to enable developing expressive custom servers that are blazin' fast.

I hope you follow node.ocaml on github, and I'll throw up a Google group for future announcements/collaboration.

Sunday, September 5, 2010

Knowing Where to Look by using "Not Invented Here" (and a bit of NoSQL propaganda)

Ted Dziuba wrote an interesting article yesterday on things he wished he had learned earlier about programming in a start-up. He's spot on since start-up programming requires the full breadth of the computing field. He gives the best advice you can give, but it is often the hardest to actually execute on.
"You just need to know where to look."
In today's world with Google, this is becoming its own kind of skill. Not only that, you need to know the words related to your problem domain. Unfortunately, until you understand your problem and the language around it, Google isn't going to be of much help. Especially with all these damn kittens everywhere that are ... JUST SO CUTE!!!

Fortunately, our field suffers from a massive influx of "Not Invented Here" which means that for any known idea, there are probably ten good solutions available and already open source. Unfortunately, you don't know about any of them and you are about to invent the eleventh.

In its own way, this is pure awesomeness.

As your eleventh solution matures, you run into smaller problems that are easily understood and can be googled. When you get answers, your concepts get related to existing problems with existing solutions that may also solve your original problem. In the end, you will either create something new that is unique and solves a new class of problems or you will find an existing solution that solves your problem very well (or enables you to solve it very well).

The hard part is recognizing when your "not invented here" derived solution is inferior to an existing product and ditching your solution; it takes a surprising amount of discipline and humility to look at your creation (or child) and say "this sucks" and move on to make your product better.

For instance, I wrote my own programming language called Kira. For me, it solved many of my problems at the time very well. It was the perfect tool for the set of problems I was working on at that time, and then I discovered new problems for which it didn't work out that well, and beauty yielded to monstrosity. I killed Kira because C# was better.

When I created Kira, I didn't know that C# had closures (because it didn't when I initially learned C#). My ignorance combined with technical ability means that I took "Not Invented Here" to the next step and "Invented Here"; this can be dangerous for businesses, but it is a great learning tool. Looking back, Kira sucked. However, the knowledge I gained is priceless as long as I can keep an open mind and not become blinded by my own inventions.

Unlearning the old ways
While learning about existing products can be nice, it also may not be applicable to the next generation of developers. The computing field evolves and changes based on many factors. Ted took time to bash NoSQL again, and while I can agree with him on many levels. His points are going to be irrelevant because NoSQL is focusing on a deeper problem.

If everyone learned proper database design, then there wouldn't be a need for NoSQL. That is the problem, no one can agree on what is proper database design. It is more of an art than a science. Business is unpredictable, and your designs need to handle that. It takes expert designers to work with existing databases to make them do new things.

Core to the NoSQL movement is storing data in a way that is easily accessible. It must also be understood in a context more similar to how we worked with data in Computer Science 101. Remember those days? All you had was a file, and you could deliver neat little programs. Why do we add all the database complexity? What do we gain, especially with the hardware we have?

On the other hand, there are huge amounts of fail just lurking around NoSQL solutions. I see the shadow of fail lurking, and I wager many of the hot solutions now are going to epic fail in many businesses. I also see some that are going to do very well. For instance: I think CouchDB is great. I know this because I've invented my own version in PHP. Does mine suck? Yes. Did it enable me to find CouchDB? Yes!. Is there enough commercial support being raised for CouchDB to be a viable business solution? Maybe. Is it worth me investing in it since it enables me to solve some of my problems perfectly? Definitely.

On getting old
I'm getting old, and I'm feeling old. It seems that all these young people want to do is make mistakes when "all they have to do is learn `old person technology X` and master it!!!" This is the monologue in my brain when a green developer is talking about the latest and greatest technology, but it isn't the right mode of thought. I have learned to fight the urge to act on these "old people" feelings.

Change is great for the field in so far as the we the old people take a step back from the holy wars and mentor the new programmers in how to be successful professionals and not become zealots in some war against each other.

Saturday, September 4, 2010

Hack your resume; or, how to get a job you love

I'll be honest, most of the resumes I've read are bad. They are not bad due to the resume's content; they are bad because people don't know how to sell themselves. As a job seeker, you are a product and you are your own marketer. While I wish there was a universal metric of awesomeness, there isn't and it comes down to your abilities to sell yourself.

Personally, if you are going to work for someone else, then I would say it is better to maximize d$/dt (and just learn to deal with all the stupid shit that makes you unhappy). So, if you will permit me, then allow me to give some advice on bettering your career.

Data mine the competition

Throw up an ad on various job boards (the ethics of this is questionable and may be illegal in some regions; you could also just go search for resumes) and offer jobs to people with a similar skill set (or a senior position you would like to have). With 50+ resumes in hand, you can develop yourself relative to your competition.

Use the pile of resumes to guide your education by targeting skills that are most valuable to businesses (this is relative to each business but generally profit producing skills dominate). Try to determine when opportunities present themselves and take initiative to gain the experience. That is, if a senior staff member offers up some difficult task to the team, then jump on it.

Learn people

Be social and go out and make friends in real-life. This is getting easier with sites like meetup.com, but there are many ways to do this.

I also recommend reading "How to Win Friends & Influence People"; the hacker community is not exactly the best environment for developing social skills that translate into business success. People skills enables you to network. It also gets you out in the world where normal people have normal day problems that you may be able solve. Once you see what problems non-hackers run into, then you can begin to solve their problems; this tends to produce revenue.

Make something awesome

Maybe you are a misunderstood genius? There is only one way to put this to the test: build a start-up. Make something that only a genius could make. Then go pitch it in your local investment community. You may get funding, which would be awesome. You may get many job offers, which leads to the path of the consultant. If you get neither, then you are not a genius.

Understand Team Dynamics
  1. Join an MMO (Such as WoW)
  2. Join a Guild
  3. Study the Drama over time
  4. Practice to Resolve Conflict rather than force a split
  5. Quit Guild
  6. GOTO 2
Do this enough times, you will understand people very well and know that getting people to work together is far more valuable than trying to build the perfect team. At the same time, you learn about personalities and how they interact with each other.