Fernando Zamora

I've had many individuals approach me with app ideas.  Their ideas are good, but I don't think they have the slightest clue what it would really take to bring their idea to life.  Someone approached me with their idea today and it prompted me to write this about ideas, app ideas in particular. Ever since the app store was born the ideas for apps have grown.  We all have them.  "Wouldn't it be great if we could create an app that did [insert idea here]". First off let me start off by saying that ideas are great.  In fact I think everyone should keep a small notebook and paper handy for whenever that light bulb goes off.  Some of us have more ideas than we know what to do with. Ideas sound really enticing given that we only hear about the big success stories.  For each success story there are literally hundreds if not thousands of unsuccessful stories. As great as ideas are, it takes much more than an idea.  If you have a great "app" idea this wha

At some point in your project you may need to use a third party API.  One common approach for using third party APIs is to use the Adapter Pattern .  The API that you use may be very specific to a particular technology. When you do create these adapter classes that utilize that API you should avoid names for your adapter that relate to the particular technology. For example, let's say that you have an API for the Sony Toughpad barcode scanner.  You wouldn't want your adapter classes to be named SonyToughpadBarcodeScannerAdapter. You should avoid naming your adapter like this in favor of something more generic like BarcodeScannerAdapter. This is because in the future you may need to adapt your adapter to a different API such as the Intermec Handheld Device barcode scanner.  The name for you adapter will be adaptable to this API but the name will be misleading.  At this point you have the choice of renaming your adpter to the more generic name.  However, renaming comes w

Having nothing better to write about than the craft that I love.  Today I will write a little bit about clean code.  Seems that most new developers are unaware of the concept of clean code and I don't just mean the book by Uncle Bob. I mean the whole idea that code needs to be readable.  Code needs to be elegant.  Code needs to be, as my college professor used to say "sexy".  You should be able to look at code and simply admire it. When you look at clean beautiful code it should make you feel smarter because you understand it. And you understand because it is beautiful.  It is elegant.  The code does what it's supposed to do.  It reads like a good prose. Good code is not tricky.  Good clean code is not for the few uber smart people.  It is for nearly any one to understand, sometimes even non-programmers. If on the other hand you look at code and say any of the following phrases this is not clean code: "Oh sh_t!" "What the ___ where they thin

About three months ago I decided to start blogging regularly.  The thing that led me down this path was John Sonmez's talks about getting things done.  The idea that if you just show up and do it, the creative juices will start flowing and you will write something meaningful. Another writer that I listen to is Seth Godin.  Seth claims that writer's block is simply a myth .  Seth writes a blog post everyday.  All of his posts are insightful and provoke quite a bit of thought.  I really don't know how Seth does it. One thing is to blog regularly and a whole other story to write daily.   I admire what both of these authors do.  I admire that they don't just talk the talk but they also walk it. John is a very succesful entrepreneur that has made his niche out of mentoring other developers.  Everything that flows out of him seems to flow so naturally.  He is not only writing though.  See John is the most published author at pluralsight.com. One day he decided that