Cloudmanic Labs

Ok, maybe not totally dead, but my views on hybrid mobile software development have changed recently. Since the invention of the iPhone I have used HTML5 hybrid solutions to build mobile apps for both iOS and Android. I started with Phonegap, then moved on to Appcelerator, followed by Ionic. The guiding principle was speed of development—these platforms allowed me to build great apps much faster than I could using Apple or Google’s native platforms. Going forward, speed will continue to be a priority but I am adding a 2 more guiding principles to my decision tree: (a) the ability to develop software for new hardware platforms and (b) the irrelevance of Android.

Why Go Native Now?

Four very big happenings caused me to change course:

I am pretty vocal about what I think makes the kind of great programmer a manager should hire. A great programer is more than someone who has computer science fundamentals under control and knows how to write lots of comments in smartly modularized code. These skills are, so to speak, merely the cost of admission. I am on the record saying that a great programmer needs to be passionate and needs to hang out with the right people.

When it comes to PHP, I meet my own criteria. I am very passionate about PHP, and I follow and hang out with the best minds in the PHP world. Before I go to bed each night I search around on Github for new and interesting PHP libraries. And I get giddy waiting to see what Phil Sturgeon and Taylor Otwell are going to do next. Until recently, however, I did none of these things in relation to Javascript—a clear sign that I was not a great Javascript programmer.

Which is why I never should have hired myself. About a year ago I Googled around looking for a new Javascript framework because Jquery just wasn’t adequate. I reviewed all of the possible candidates, including AngularJs. None appeared to meet my design goals so I came to the conclusion that Cloudmanic Labs needed to write our own Javascript framework. We ended up investing thousands of dollars worth of time to develop CloudJs, and we are pretty proud of it. But there’s a catch . . . wait for it.

Recently I began putting in extra effort to become as connected with the Javascript community as I am with the PHP community. Frankly, I wanted to start promoting CloudJs as we got closer to launching version 1.0, but also I had become pretty passionate about Javascript. While hanging out around the Javascript watercooler I kept hearing about the AngularJs framework that I had dismissed. When I finally dug into it, I realized that AngularJs and CloudJs are essentially one and the same—except that AngularJs is far more mature. And so, because there is nothing that CloudJs does better than AngularJs, Cloudmanic Labs is going to adopt AngularJs.

Read More...

I am a pretty bleeding edge guy when it comes to technology. In fact, as the manager of Cloudmanic Labs I am willing to invest to upgrade our systems with the newest technologies before building additional features or products. To be clear: with respect to deploying code into production bleeding edge does not mean buggy alpha software. Rather, it signifies employing novel but tested libraries, technologies, and design patterns.

The major counterargument to being bleeding edge focuses on end users, who typically don’t even know which technologies products are use. Why replace the old technology with bleeding edge technology if users don’t care? I say this argument is short sighted. When users adopt new software, they hope to use it for a long time because switching can be annoying. But developers who allow complacency to set in and fail to keep up with technological innovations will one day wake up and realize that updating their product is nearly impossible. Advancing software to the next generation is not an easy task and the technology changes blindingly fast. Therefore, if you are not on the bleeding edge you are late.

Read More...

“I skate to where the puck is going to be, not where it has been.”
~Wayne Gretzky

Steve Jobs brought Gretzky’s quote to the computer world’s attention in 2007, and since then I have always kept these words in the back of my mind. At Cloudmanic, we like to make decisions based on this philosophy as well.

As many of you know, Cloudmanic Labs is a PHP / CodeIgniter development shop. We have been loyal to both of these technologies from the very early days. But things have changed: PHP is moving forward at a nice pace; CodeIgniter is not. As a firm, we can stay with the puck or skate to where it is going. Internally, we have made the decision to invest our time in Laravel along with Composer.

PHP has, for a while now, introduced two very powerful features: namespacing and autoloading. CodeIgniter, on the other hand, simply has not embraced these ideas. As a consequence, senior developers who contribute powerful libraries to the open source community have moved on. The libraries that we have grown to rely on are now being developed in a way that does not mesh well with the core CodeIgniter framework.

Another factor in our choice is that we want to engage and attract the best development talent we can. It seems most of our development peers have started to embrace Laravel with an increased focus on using Composer with Laravel. What senior engineer wants to work on old technology? To stay relevant and attractive as a company, we need to stay on the cutting-edge.

If you have not already checkout Laravel and Composer do it now. You can thank me later :).

Read More...

Disclaimer: This is just one man’s personal feelings. Pet peeve, if you will. While a few close friends of mine have certainly motivated me to write this, I will not be calling them out. They know who they are. These friends are close friends… I still love you guys! Feel free to blog about something crazy I do.

Open source doobs drive me nuts! What is this “doob” thing I speak of? Well, it’s someone who only uses open source software. They demand the freedom open source software gives you. They hate paying “The Man” for their software (ie. Apple, Microsoft, etc.). So they typically only use Linux, Android, Gimp, and so on. Free, open source software.

Freedom Over Quality

Some open source software is truly great. I use tons of open source software every day. In fact, I bet I use more open source software than I do paid software. It’s often much better than the stuff you pay for, but I always at least review my options. The idea that you would not pick and use a product based on its merits vs. being open source is just crazy to me. Any way you look at it Photoshop is better than Gimp. Many paid text editors are better than open source ones. For many years iPhone was way better than Android. Plex is better than XBMC. Roku is better than Boxee. In the software world, there is no good reason – other than a personal allegiance to a concept – to NOT use the very best tool for your personal needs. Yes, you have to truly try them all to know what the best is. Quality should always win.

Giving Back

This is what drives me the most nuts. It truly sends me into a tailspin: Not giving back. Being an open source doob is great – if you give back. Boatloads of blood, sweat, and tears goes into building great open source software. Yes, people open it up for all to use. It just feels wrong if someone is only using open source software and not giving back. You know that buddy who, when you go out to dinner with him, you always pay and he never offers in return? That is how it feels when you use open source and don’t give back. Take, take, take and give nothing – just wrong.

Read More...

How do you know if a developer has written good code (even if that developer is you)? I’ve been asking myself this a lot lately. I really want to define the answer as thoroughly as I can, because if I have some strong criteria to follow, I can hold myself to highest standards and never fall short. Also, I can be a better manager if I have some strong guiding principles.

Steve Jobs was famous for asking employees if their work was their very best. If they did not clearly state “yes,” he sent them back to the drawing board. I am not willing to be that type of manager, however, I do want to be able to recognize when my team is not doing their best work.

To be clear: I am not talking about knowledge or CS fundamentals. I am really talking about things like, how clean the code is to read? Did the developer go about things in a simple way or an overly complex way? Is this code designed to support the future or is it just thinking about today’s requirements? And so on.

Judging Code By Bugs

All code has bugs, and I think watching a developer (or yourself) manage bugs as they are reported is a great measure of how good the code is. Over the years, I’ve observed that if a developer gets a bug report and fixes it right away, that is a sign of great code. Here’s my logic: If your code is overly complex, it’s going to take a while to debug and fix.

When I’ve written great code, I can fix bugs right away. The process of tracking down the bug is almost instant. I can do that because it’s code I’m proud of, and I wrote it from a place of passion. There is something about code you are proud of that lets you almost instantly zoom in on the problem and solve it right away. It is your baby after all, and you want it taken care of.

Read More...

The story I am about to tell happens almost monthly.

I needed to add some complex functionality to a project I was working on. I did what any good programmer would do and searched the web for a library that already did what I needed. I found a great library and got to work. I was really excited this library was going to save me hours and hours of time (in the end it still did). As I was moving forward I discovered some bugs in the library. I was hoping to just be able to make a few fixes and continue on. After diving into the library I found the code very hard to read. By many standards the code was pretty well written, but you really had to go through the code with a fine tooth comb. You could not just easily skim the code and figure out what was going on. Functions were very cryptic and variables were short in nature and not very descriptive.

I get it. Programmers do not like to type. Saving keystrokes saves on finger pain. Again, I get it. We all learned that a line of code should never be longer than 80 chars long (well that was when monitors had tubes).

Everytime I find a library just like the one I mentioned above I end up just rewriting it. At the end of the day the logic is nearly the same. I have just written the code to be more descriptive and easy to understand. I like code to read like a book. You can quickly skim the code and understand what is going on. I also like my code to look pretty. If you printed it out and hung it on the wall it would be pleasing. I find code starts to look like crap when people wrap too many lines, or add too much logic without a few comments to break it up. There should be some symmetry to code.

Love me or hate me for it, I am going to continue to write very long descriptive functions, clearly define my variables, crazy long database column names, and add some sexxy curves of symmetry to my code. Oh, I almost forgot, don’t give me crap about code bloat and performance. There are always bigger performance fish to fry.

<?php echo $this->readers->ThankYouForReadingThisBlogPost(‘You Rock!’); ?>

Read More...

Andrew Warner of Mixergy.com says that when he interviews founders of startups the one thing they always say is the first release of their product looked like crap. Over time the product has evolved, but in general looking back the first release was not something they are proud of today. Hearing that always makes me ponder. Sure, I believe in release early and release often. Of course building a MVP (minimal viable product) and getting it out to customers is much better then continuously polishing your product hiding behind the “its not perfect” curtain. The idea of releasing something you are not 100% proud of seems odd to me.

Many products are a spin off of a consulting firm, and founding teams often have client work backgrounds. It seems product teams forget their client work process when they build their own product. When working with clients you often practice what I call CYA (cover your ass) software development. You work with your client to really flush out their ideas. This often turns into a scope document, and the clients signs off. Then you often move into wireframes flushing out any micro detail, and once again the client signs off (covering your ass). Lastly, before much development takes place you might have some design rounds with the client getting the client to fully sign off before the development really starts. With client work you are going through these phases to really ensure you are delivering just what the client wants and make sure everyone is on the same page. What also happens during this process is you flush out the entire idea from high level all the way down to the micro details. You never say “oh we will figure that part out later”. With this process you deliver just what the clients wants on budget and on time. Never would you deliver something to your client that you are not proud of.

When building your own product so many development teams just dive right in, pick a point at random and start programing. Since it is their own product many developers tend to think the CYA process is not needed, and maybe sometimes a little boring. I say this is a mistake. Not working through the different user experience issues, the data model, the design, and so on while just hitting the ground coding is a great way to have headaches later on. The CYA process front loads resolving headaches and problems that may arise in the future. Why not do that with your own product?

I am proud that any product we have ever released at Cloudmanic Labs has been well thought out. We go through the same process we would go through with clients. Not one line of code is written until we fully flush out our ideas, manage the scope, and fully design the product. The first release of our products have often been far from crap. They are polished. Also, our development time is not any longer then other hit-the-ground coding teams. Our discipline to maintain the CYA process has made it so we have never released a product we were not proud of, no matter how far from our desired final form it is.

We of course don’t think we are going to be perfect on our first release in terms of features, customer needs, and bugs. There is always going to be things we messed up, and that is why user feedback is very important. We listen to it all and evolve our products with our customers in mind. We never skip out on any of the important steps of a product development cycle just because it is convenient to ignore them or because it is boring. We never say “oh we will figure that out later”.

CYA software development has an important role in non-client work as well.

Read More...