PHP and MongoDB Web Development Beginner’s Guide – Thoughts of a first-time author

Social networking doesn’t always make you procrastinate, sometimes it pays off! When @packtauthors tweeted that they were looking for someone to author a book on PHP and MongoDB, I made contact. Few weeks later I signed a contract for writing the book. And six months after that, I am pleased to announce that PHP and MongoDB Web Development Beginner’s Guide is published and out for sale!

In this post I intend to share a few words about the motivation behind the book and the journey of a first time author.

The Motivation

I’m a supporter of the idea the MongoDB can potentially be the new M in LAMP. The web application data storage requirements have changed a lot during the past 4-5 years. Instead of producing contents of their own, the most popular websites are hosting contents created by their users. These contents are diverse in nature and humongous in volume. Mapping the diverse data into a rigid data structure gets harder as the volume grows. This is where the ‘Flexible Schema’ nature of MongoDB fits really well. Also MongoDB is easy to learn, developers with relational database experience should find little trouble adapting to it. There is a lot of similarity between the underlying concepts of an RDBMS and MongoDB (think documents for rows, and collections for tables). Developers don’t need to wrestle with radical ideas such as column-oriented or graph theory based data structures as some other NoSQL databases require them to. Finally, it is open-source, freely available (Creative Commons License), supports multiple platforms (Windows/Linux/OS X), have great documentation and a very co-operative community, and plays nicely with PHP! All these have lead me to believe that in near future MongoDB will be where MySQL is right now, the de facto database for web application development (I would urge you to read Stephen O’Grady’s article which makes more persuasive arguments). And since PHP is the dominating language for web programming, writing a book on web development with PHP and MongoDB felt just right.

The intended audience for this book are web developers who are completely new to MongoDB. It focuses on application development with PHP and MongoDB rather than focusing only on MongoDB. The first few chapters will try to ease the reader into understanding MongoDB by building a simple web application (a blog) and handling HTTP sessions with MongoDB as the data back-end. In the next chapters he will learn to solve ‘interesting’ problems, such as storing real-time web analytics, hosting and serving media content from GridFS, use geospatial indexing to build location-aware web apps. He will also brainstorm about scenarios where MongoDB and MySQL can be used together as a hybrid data back-end.

The Inspiration

Scott Adams, the creator of the famous Dilbert comic strip, wrote an inspirational article on Wall Street Journal. I’m going to quote a few lines here:

“I succeeded as a cartoonist with negligible art talent, some basic writing skills, an ordinary sense of humor and a bit of experience in the business world. The ‘Dilbert’ comic is a combination of all four skills. The world has plenty of better artists, smarter writers, funnier humorists and more experienced business people. The rare part is that each of those modest skills is collected in one person. That’s how value is created.”

These words moved me. I like programming and I like writing, and although there are smarter programmers and better writers out there, by combining these two passions I could potentially produce something. Besides I had an amazing learning experience with MongoDB. I built an API analytics solution with MySQL which became difficult to handle as the volume of the data grew. I started playing with MongoDB as a potential alternative. A month later I moved the entire data from MySQL to a more solid and scalable solution based on MongoDB. I wanted to share this learning experience through a series of blog posts but lacked the personal discipline and commitment to do so. Being obligated a deliver a book within tight deadlines solved that problem!

I also must thank Nurul Ferdous, my friend and former colleague who is a published tech author himself. His guidance and influence has been instrumental.

The Journey

My journey as an author writing a book for the first time has been an exhaustive yet amazing one! I work in a tech startup, which naturally requires longer than usual hours and harder than usual problems to solve. I would come home late and tired, research on MongoDB topics, plan how to deliver the message to the reader, write code, test and debug the code, write the content on a text editor, fight with Microsoft Word so the content has proper formatting as required by the publisher. Then on weekends I would revise and rewrite most of what I have done over the week and hustle to make the deadline. Nevertheless it all had been a rewarding experience.

In the rewrite phase I had a lot of help from the technical reviewers – Sam Millman, Sigert De Vries, Vidyasagar N V and Nurul Ferdous. They corrected my errors, showed me what more could be added to the content and what should be gotten rid off, helped me communicate complicated topics to readers in a clearer way. I convey my sincere appreciations to them!

Time to end this lengthy blog post. I hope you find this book enjoyable and use it to build some really cool PHP-MongoDB apps! I will then consider my endeavor to be a success.

Random snaps from Thailand tour

I’m kinda bummed out since I didn’t get any chance to travel this year (and it looks like I won’t for the rest of the year). So I’ve decided to share some of the photos that I took in my Thailand tour last year. This photos have been lying around in my hard drive for almost a year , so I finally decided to upload a few of them.

This picture was taken on a beach in Phuket, Can’t remember the name of the beach right now.

The rock at James Bond Island, named so because it appeared in one of the James Bond movie.

You are always reflective when you are on a canoe.

A colorful moment.

This baby elephant put on quite a good show.

My attempt at snorkeling.

A sunny day on the beach of Koh Phi Phi

Loh Dalum bay

Masters of Doom: A book you should read if you’re a programmer

You’re probably surprised I haven’t mention “Code Complete” or “Pragmatic Programmer” or any of those books you’ve read reviews of in numerous programming blogs. Those are great books by the way, and should take the time to read at least some of them.

Masters of Doom will not teach you how to be a better programmer, it won’t preach the best practices of software development. Because it’s not a book about programming at all! It’s a biographic tale of two great programmers, John Carmack and John Romero, how their passion for playing and creating games drove them to achieve superb mastery at programming and produce legendary games, like Doom, Quake, Wolfenstein 3D and so on.

Neither Carmack, nor Romero had what you would call a healthy upbringing. They were from broken families, at odds with their surroundings. Playing games was one of the few things they would enjoy, and eventually they started learning how to create them. They had dreams of making it big in the gaming industry, creating and publishing under their own names.

These two brilliant minds met each other at their youth as coworkers. Each admired the unique qualities in the other one. Carmack was more adept in technical details of game development, while Romero had a knack for the creative direction. Together, along with some like minded programmers and designers, they founded id Software, and set out to produce hugely popular franchises. Not only were these games commercially successful, they achieved technological breakthrough in PC gaming. Commander Keen was the first side-scrolling game in PC. Wolfenstein 3D had immersive 3D graphics never before seen in games, And Doom set the bar even higher. These were the games that drove innovation in graphics programming, and established gaming as a part of pop culture.

So what do you, a programmer, are likely to gain from reading this book? The simple message that this book conveys, is that if want to succeed in the field of programming(or any other field) you must have passion for what you do. No amount of training would make you a better programmer if you lack this key ingredient. If you are a start-up founder(or work in a start-up) and have started your journey in the scary world of entrepreneurship, this book will prove to be inspirational to you.

So if you are a programmer who is looking for something to get him inspired, I strongly urge you to read it. Or read it anyway, it’s fun.

On Programming and Craftsmanship

I’ve just finished reading the article “Programming is not Craftsmanship” and couldn’t help but share my own views on this topic. If you haven’t read the article, I urge you to do so right away.

I agree with the author’s view in summary. As a programmer, you may take pride in your knowledge and skills, but the hard truth is the real world hardly distinguishes you from a plumber(may be a more literate plumber, if I dare say). They don’t care if the pipes are laid out in an elegant manner, or not, as long as the water is running. They focus on results, neither the process nor the tools. I’ve tried to share this point of view in the feedback section of every “Why programming language X rocks and Y sucks” blog post I’ve encountered.

But let’s consider the hypothetical situation where you are an entrepreneur, who has an idea of an amazing software. You hire some smart engineers. They build it out and the sales guys close deals. Customers are satisfied, and they ask for more features. The programmers code some more, you bill your customers for their work. Everyone’s happy.

Now a few years later, you’re techies are bored. They are looking for new challenges, as any good hacker would do. You recruit some smart guys to take over their work. They enter a painful transition period. The greenhorns have to learn the intricate details of your feature bloated software their predecessors have built; so they can fix, change or add stuff as demanded by the customers.

And here’s where the architecture of the software comes into play. If your early programmers have laid out a solid groundwork, keeping in mind the readability of the code and the extensibility of the software itself, the new guys will have less of a hard time getting things done. On the other hand, if the programmers have never cared about those things, and  just produced code to meet the deadlines, the new guys will go through hell figuring out which part of the software does what and how do they all come together. You’re customers are still waiting for those bugs to be fixed, those features to be added. They get impatient at the delay, and displeased at the higher than usual billing hours upon delivery. At this point you may think having a good “Documentation” helps, but it hardly does. If the programmers never had the time or will to build the software right, odds are against the fact that would have so for documenting it.

I’ve seen(and am continuing to see) it happen. Management and customers were happy playing with the pretty UI. But when I popped the hood out of curiosity, I was surprised(to say the least) to see, along with other things, the spiderweb-like intricacies of the if-else branches, and left with sympathy for the poor soul who would have to ‘maintain’ this codebase(praying that I wouldn’t be the one).

I’ll draw my conclusion with the personal opinion, that a successful programmer(or product manager) knows how to strike a balance between the two extremes. Being the prima donna programmer who whines about the elegance of code should be discouraged by all means. But the coder who pays the slightest attention to quality, must be avoided. For a software shop whose sole business plan is to “build, ship and forget”, the later breed may prove profitable. But not for the enterprise who seeks to deliver innovative and useful products.

(Joel Spolsky, one of my favorite bloggers, gave a presentation on a similar topic. You can watch it here.)