Consider this: You’ve got a great web-based software app. You think you’re going to be the next 37signals. You build out your application to perfection, skipping all that trivial stuff about charging for the software for the latter stages of the development cycle. You think you can push out all that payment processing mumbo-jumbo until the end.

Well, you are in serious trouble.

The problem isn’t even bottlenecked at a grandiose level - like lacking a great business idea to reel in the money. The pain is all in the details like setting up an online payment processing system.

I understand that trying to process credit cards should be a heavier process than setting up a lemonade stand, but the current state of the art is absolutely ridiculous. This is because the current players in the market are either 1) pigeon-holing all e-commerce transactions into simple, but totally uninteresting processes, or 2) completely ill-equipped to handle online commerce.

In corner number one, you’ve got players like PayPal, with whom you can easily set up a check-out form with PayPal express. Given that this is just about as brain-dead as e-commerce can get, you’d think that it’s as easy as filling in your name, getting a URL, and link your form to that URL. No. You’ve got to wade through a million pages of marketing rhetoric to get to any real documentation. And the end result is often so simple, that it doesn’t break the mold. If you’re doing anything remotely interesting, like a web-based software app, you’re not going to get much mileage here. Move along.

In the other corner, you’ve got big bank institutions offering online merchant solutions. Big trouble. Don’t even bother. From personal experience, I walked in and talked to no fewer than 3 representatives from your big names like Bank of America and Wells Fargo and got nothing but empty stares. “You want to do what?” “Wait, are you shipping anything?” “Do you need a terminal?” “You want a merchant account? We’ve got a nice merchant services package…” If you want to actually do credit card processing, you’re on your own when you talk to these big boys. They’re still living in a world where people walk into shops, swipe their credit cards in a terminal, and physically transact. Trust me, they’ve got good reasons to keep their focus (and employee training) in the physical space.

However, that leaves us web guys stuck out of luck. If you do your research correctly, you probably know that online payment processing comes in 3 pieces. First, at the layer closest to your application or system is the payment processing logic to initiate transactions and authorizations. There are plenty of great ways to roll this logic, my favorite being ActiveMerchant, a great gem for Ruby on Rails. This is the area closest to developers and I promise you will spend more time shopping for a solution than implementing it. You’re mostly in the care of savvy professionals here.

The next level, and one step removed from your application, is the Payment Gateway. See Authorize.net or TrustCommerce or Braintree. These guys provide an API for your application logic to talk to banks and do the actual transaction. Payment gateways are generally good people - they understand web commerce, since that’s their bread and butter. They can hold your hands a bit and even offer sandboxes and other developer friendly options to make sure your app is behaving properly. ActiveMerchant will generally abstract away gateway differences for you, so this step is solid, though it could use some improvements.

Another step removed, and the final step is your merchant account. Your merchant account is the part of all of this that actually touches the banks. This is where the Visa or Mastercard magic happens. This is also where you’ll pull your hair out trying to figure out why the support folks are speaking in alien languages.

For the most part, people who provide merchant accounts and the people who work for them do not understand what you are doing. They don’t understand web applications, they don’t understand why you’re doing what you’re doing and why you chose to do things a certain way. They don’t understand APIs, IP addresses, servers, Ruby on Rails, HTTP, SSL, or anything like that. They understand forms, paperwork, support tickets, legal documents, and all that bureaucratic burden.

I’m not kidding when I say that it took me over a *month* to finally get a merchant account properly integrated with my payment gateway. I won’t say who the two parties were, but let me say that no fewer than 10 bulky and sometimes unnecessary forms where sent back-and-forth in a span of 3 weeks with the rest of the time wasted in some weird support limbo.

For developers like me, who prefer to focus on the elegance, simplicity, and unerring logic of clean code, the frustration and archaic nature of filling out PDFs and DOCs just seemed like a step back in the wrong direction.

The problem arises from the many layers that it takes to build an e-commerce solution. There are too many middle-men and too many ways to lose empathy along the way. There is no way a support person at a bank can understand how web applications tick - they’re not trained for that.

So my question is - can there be a hero to arise from all this mess and deliver to us a better way?

The funny thing about that is, this particular cuddliness of Rails has seemed to split the Rails camp into two groups of people. Yes I know, generalization is bad, but it’s convenient. In one corner, we have the hardcore developers who know the entire framework inside and out. These are the ones that can break Rails down into it’s actual and somewhat separable components. They know and understand how ActiveRecord (M) is separate from ActionPack (VC), which is separate from ActionMailer, which is separate from ActiveSupport, etc. They see both the forest and the individual trees that make the forest possible. The other corner of developers couldn’t care less. They’re using Rails as an all-in-one packaged deal. Like (some of) the old MFC developers of yore, they couldn’t tell how things work under the hood, they just care that it does.

Having said all that, in the spirit of “experienced-based” teasing out of great ideas, I think Rails has gotten to the point where it’s interesting to take a look at some of the concepts from which it is comprised and acknowledge them each individually. It’s time to not just look at the largest common denominator, but each reasonably sized denominator as well. I’ll skip the obvious cookie-cutter cliche ones like MVC and ActiveRecord. I’m going for the more underrated things.

Granted, I haven’t put much thought into this. This post is just a result of me thinking: “These ideas would and should work anywhere and everywhere”. Here’s my top 5:

5) Unit-testing and testing in general. I guess this falls under “cliche”, but the fact that Rails comes with testing ready out of the box speaks worlds of how important it is to all software projects. This is a should have/must have for any project

4) Mongrel (included in Rails 2.x I believe). It’s not this particular piece of software that I like, it’s what it represents. It screams “acknowledge your entire stack”. Mongrel was written to address the specific performance issues with Rails apps, but every project should have its Mongrel - its underlying engine that makes it run and run fast.

3) DB Abstraction/Migrations. MySQL, Oracle, SQLite, PostgreSQL, WhoTheHellCaresSQL. They should all be made to behave the same. Yes, I run SQLite on development and test, but MySQL on production. As long as I keep in mind the performance characteristics (see #4), who cares which DB is running?

2) Development, Test, and Production environments. Every project has some variation of these three environments. Every project should formalize that fact! Make it configurable in a YAML file! The fact that Rails comes with this out of the box makes development so, so easy.

1) Documentation. ‘Nuff said. If you don’t document it, it never happened.

I don’t think it’s worth while documenting the entire experience. Instead, I think it would be useful to list the webpages I referenced.

First and foremost, I downloaded subversion from tigris. In my case, since I’m running this on windows, I grabbed the Windows binaries built against Apache 2.2.x.

Next, the best reference for starting a project with Windows is here. This entry talks about setting up the right environment variables and creating a repository. Note that the SVNService wrapper being referred to is no longer necessary. Instead, check this out. Here, the author denotes steps to setup an NT service with no downloads necessary with subversion 1.4.x.

Lastly, I looked for a tutorial on some of the most basic svn commands and found this article, which goes over some of basic concepts of subversion as well.

The above articles should be all that is necessary for setting up a Windows subversion server in minutes.

It’s no secret that I love working on web apps. A necessary part of writing good web apps necessitates delving into the front-end technologies that the end-user interacts with while using said web apps. Thus, I’ve always been a fan of Firefox (for it’s developer friendly tools and plug-ins, it’s strict upholding of standards) and IE (out of necessity, due to widespread adoption, and the fact that they really did a good job on IE7). I’ve come to live with the fact that these two browsers simply must be supported, but Opera and Safari were always troublesome.

Then comes along Safari 3.0. I would have never known had I not installed Leopard over Thanksgiving weekend. Not only is it blazing fast, standards compliant, elegant, and full of new-hotness - dynamic widget creator anyone? - it comes with it’s own Inspector tool. Included are handy tools like a DOM-inspector, a CSS box model metrics tool, and a network transfer analyzer. The latter even comes with helpful hints about how to speed up transfer times, reminiscent of YSlow. The only thing missing is a firebug-esque debugger where one could set breakpoints. Oh well, nothing is perfect.

In fact, I’m sure Safari 3.0 is still missing a few bells and whistles. Even as I write this entry, I notice the lack of support of rich WYSIWIG editting in Safari that I usually have with IE or Firefox. Like I said, nothing is perfect. At least I won’t loathe debugging Safari specific issues as much as I have in the past. Maybe it’s also time for me to give Opera another chance…

Unfortunately, it also comes with a rather bloated httpd.conf, which was unappealing to me. Not only that, but the conf file didn’t seem to be picking up personal conf files (default in /private/etc/httpd/users/). Fortunately, all I had to do to get back in the game was to back up httpd, apxs, and apachectl and then symlink them to my custom installation of apache, with my own custom httpd.conf.

I’m actually convinced that this is better in the long run than using the out-of-box apache installation, since this affords me flexibility going forward. I like to be in control of the software running on my box (which may or may not be in conflict with Apple’s easy-to-use stance).

While I am quite happy to leave it at that in describing OOP to novices, that explanation itself never suffices for me. The above explanation does not explain interfaces, abstract classes, and class hierarchies. The explanation leaves no room to think about proper design of interfaces, object relationships, and above-all, separation of concerns, which are all fundamental concepts in OOP.

In truth, I believe the answer lies in the fact that we’re not so attached to Objects as we are to Types. For example, if we take time to the most basic of expressions, like:

x * y

We might infer that we are working with integer or float types. In fact, this is basic type inference operating in the human brain. However, taking an expression like:

"Hello" * "World"

We might be much less inclined to give a proper explanation for what this might do. This is because we understand string types don’t naturally implement multiplication.

From the most basic examples like this, we come to understand that we don’t rely on values so much as we rely on behavorial contracts. Even at the most basic primitive types, we understand the types that implement ‘+’ and the types that implement ‘*’. Extending this to the higher level objects, we come across the most elegant way to describe our logic in programming statements.

By thinking about types, from the simplest Printers to design-pattern favorites like Factories, we can reason about our code in a way that lends itself well to implicit understanding. We can also reason about our code not necessarily from the point of view of the object (which is just an instance, just a “value”) but the interface for which that object implements. And because we reason about interfaces, we are really reasoning about complex types - a concept that is much more universal and broad than objects.

So really, when we talk about object-oriented programming, we’re basically presenting a misnomer for type-oriented programming, which is a much stronger and older concept than objects. While this explanation might seem trivial to those not necessarily curious about the details, to me, it helps classify and generalize concepts which may seem to be pure convenience (Objects) to concepts that are more universal (Types).

• Download the latest apache src from http://www.apache.org. In my case it was version 2.2.4
• Extract the src to a directory where you keep all your src files, cd to that directory

./configure –prefix=/usr/local/apache2 –enable-so –enable-mods-shared=most
make
make install

• Replace /usr/local/apache2 with the directory you’d like apache to be installed in. I named mine apache2. The above command will build apache2.

cd /usr/sbin
sudo mv httpd httpd.apache1.back
sudo ln –s /usr/local/apache/bin/httpd httpd
sudo mv apxs apxs.apache1.back
sudo ln –s /usr/local/apache/bin/apxs apxs
sudo mv apachectl apachectl.apache1.back
sudo ln –s /usr/local/apache/bin/apachectl apachectl

• httpd (the binary for apache) version 1.3 is installed in /usr/sbin/. You can see the version by typing “httpd -v” in the command line. Replace this (after backing it up) with a symlink to our new apache2 httpd binary. This should also be done for apachectl and apxs.
• At this point. apache2 is already running on your system, but the conf files are not quite ready. Add the following to your httpd.conf (found under /usr/local/apache2/conf). The PidFile is where the Personal Web Sharing manager looks to see if an apache instance is running.

PidFile "/private/var/run/httpd.pid"

• You should also add the following to enable user directories.

<IfModule mod_userdir.c>
UserDir Sites
</IfModule>
Include /private/etc/httpd/users/*.conf

• At this point, you are all set. Try toggling the Personal Web Sharing on and off. The next steps you might want to take (optionally) is to add MultiView support and change your DocumentRoot. These can all be done in the httpd.conf file. You might also want to uncomment the line that includes support for http://localhost/manual/
• You can also find the previous 1.3 conf file at /private/etc/httpd. Notice how much more verbose this conf file is compared to the apache2 conf file. This is because most of the additional conf settings can be includes via conf/extra directory.

I think it’s impossible to describe what it is like to suddenly come to full realization of becoming a father. Purposely, I’ve let all the emotions simmer down before making an entry here, as I knew only words of retrospect could do justice to the jumble of feelings that were suddenly thrust upon me. On that note, I’ve realized that there had been one overriding contemplation that I’ve had over the last week or so.

To bring life into this world is both a joy and an overwhelming responsibility, but it was also the onset of an epiphany. A baby is born into this world with no baggage, no past, no enemies, and no debt. When you think of all the new things to learn and experience for a newborn, it dulls the trivial things in our life we take as important - our everyday grind, our everyday matters, our everyday worries. It puts into perspective the everyday things in our life that we’ve become consumed in wrongfully, and frees us from the chains of mediocrity we’ve come to bind ourselves. At once, it is a new beginning for both the baby and the father.

What can we provide for our newborns? Of course, I mean more than just food, clothes, and shelter - I mean our knowledge, our sense of compassion, our sense of morality. Spare them our burdens, our hardships, and our immaturity. Spare them our love of bickering, our sense of greed, and our penchant for prejudice. Give them love, hope, and peace. Give them a better world in which to live, a better environment in which to grow. Give them truth. Give them honesty.

The one thing I can take away from this, as I step back and reflect on this little miracle of my own is that this is an opportunity for me to become a better person, and then to take that energy and posit it in a way that has lasting effects in this world. My contribution to humankind will be my willingness to give the next generation a better future, as should be the contribution of every father.

In the end, our society is built on the strength of our ability to not just create, but to share creation. That includes raising, and loving, our children.

So, besides Google Ads, here is my list of Marketing 2.0 do’s and dont’s.

Do:

1. Get Dugg
2. Stealthily mention yourself in wikipedia under hot dev terms like AJAX (Ahem, Meebo)
3. Be viral and incite word-of-mouth.
4. Have a presense on blogs and web-based articles.
5. Have free T-Shirts.

Don’t:

1. SEO
2. Rely on e-mail spam
3. Fight for impossible keywords.
4. Build a crappy product
5. Have Ads all over your site.

Unfortunately, another requirement is that the client must deal with Unicode perfectly. After all, in today’s international world, it’s just plain wrong to implement anything with purely 8-bit ASCII in mind. Specifically, in this implementation, the plaintext is encoded in utf-8, then encrypted in AES, followed by an encoding to base64. The web client is of course then responsible for receiving that base64 blob out of the XMLSocket and attempt to display the original plaintext properly.

It sounds easy enough, but the shopping for various open source parts took me longer than expected. In light of that, I’ve decided to document the various implementations I found useful.

The first step is to take that base64 blob and convert it to something useful. In C, we’d want to tear it down to 8-bit bytes in order to feed it to our AES implementation. Unfortunately, in JavaScript the notion of a byte is “nicely” abstracted away, so we’ll have to deal with strings. Using webtoolkits Base64 and Utf8 implementations, we can convert the blob to a garbled ASCII string. (i.e. 5Lit5paH -> 中文 -> [some unreadable 6-byte string] ). We can then feed this string into this Rijndael implementation. We’re now left with another string, which we can decode to JavaScripts internal Unicode representation. Voila!

The key to the particular Rijndael implementation I’ve chosen is that it has a well documented approach to dealing with bytes in JavaScript. In particular, it converts any ASCII string to its byte representation as an array of integers (i.e. “Hello” -> [104, 101, 108, 108, 111]) and then operates on those “bytes” following the AES algorithm. While this is slow, it is clearer than other implementations I’ve found.