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

A large majority of the work we do in our project is to fix reported bugs. The project code is considered legacy code in the context of test driven development. Not only is the code considered legacy code, in many cases it is poorly written which makes it even more difficult to find the real issue. The code was inherited this way and it is not something that you can simply change even with adequate time and resources the ends may not justify the means to fix it completely. All this makes the issue of finding the solution to existing bugs very difficult. But all is not lost; there is an approach that we can take to make troubleshooting much easier. I am writing this paper with the goal of outlining a structured approach that we can take to make it easier to debug the legacy code. This paper is comprised of several tips that demonstrate the creativity necessary to find and fix the root cause of a reported bug. 1. Accept that it is not easy The first thing that you

The Raspberry Pi has been around for some time, three and half years to date, and it had not caught my interest until recently.  Sure I had heard about it and although it seemed interesting it was also a little intimidating, to be honest.  That's until recently when an individual decided to start a makers and coders meetup group right here in little old Belton Texas.  When the meetup up group was started I was immediately interested since I had already been introduced to making things with the Arduino.  I can't say enough about how pleased I am with joining this group.  I have learned some cool new geeky things since then about the Pi, Linux and Python. So What Is the Raspberry Pi? To put it simply in laymen's terms, the Raspberry Pi is small computer that has enough power to be a personal computer.  No it won't necessarily replace your Windows laptop. It does not have the same amount of power and hardware resources. Also, the operating systems available for

Last week I wrote the post Learn Python in 15 Minutes .  The point of that post was to demonstrate that the basic fundamentals of the Python language are simple and easy to learn.  However I will be the first to admit that you cannot learn any language in 15 minutes.  You won't be anywhere near proficient at least. Working in a particular language consists of much more than the language's syntax.  Part of being fluent in a programming language consists of being familiar with certain things such as string manipulation, collections handling, familiarity with the supporting framework and libraries and available third party frameworks. Anytime you learn a new language and you are already proficient with a different language, the question that always comes up is "I can do X thing in language Y, how do I do that in language Z?".  This is similar to knowing a real language but unfamiliar with the nuances of a different culture.  Don't believe me? Put someone from

Lately I've dove into the world of Python. I had been hearing a lot of different things about it and about its many benefits and was curious what the buzz was all about.  It's been a couple of years, at least, since I made it a goal to learn Python and just recently decided to take the dive and really get acquainted with it. If you're a programmer and have heard of Python but haven't had the opportunity to give it a try but would like to know more about it, you've come to the right place.  In a book I've been reading lately, The Basics of Hacking and Penetration Testing ,  I read about a concept called zero entry hacking. The idea behind zero entry is explained best with the analogy of a swimming pool where the water level starts at 0 feet and gradually gets deeper.  This idea allows you to get in as deep as you feel comfortable but with little commitment of anything deeper.  A zero entry lesson is what I will give you in this short post.  You can read this

Computer Science is built on many core concepts such as algorithms, data structures, programming paradigms, network communications, database persistence, etc.  Colleges usually teach you enough to understand the concepts and the lessons operate on a very theoretical level.  The lessons don't necessarily teach where or how to apply them.  Here are some things that you can learn today to help you put those concepts into practice. You don't have to become an expert, but tinkering enough to get a good understanding will go a long way for your software development career. Video Game Development Video game development is significantly different than line of business programming.  And many of the game concepts will not likely ever be implemented on a line of business application. Game actions occur in real time and lead to a different way of thinking about programming. One thing game development will do is help you see deeper into computer science. Video games will challeng

A few days ago I downloaded some software off the internet on my Mac. As you know Apple does not recommend downloading and installing software from the web.  They recommend to download software for the app store.  I really though I needed that software so I did anyway. As it turned out it installed a lot more than I bargained for. The symptoms were that my Chrome browser stopped working after receiving a "Call-us for help in removing malware from your Mac" pop up.  Safari was working but I was getting hi-jacked on every hyperlink. Instead of going to the actual links Safari would end up on commercial ads. Eventually the browser would end up with the pop up that had a toll free number asking me to call it because I had malware on my Mac. Once that ad popped up, it rendered the browser useless. Of course I figure they were the actual malware, so calling them would likely lead to some serious trouble. I searched the internet for an answer, on my windows box because my mac wa

This past week I was suddenly thrown into doing some work in Solaris.  My task was to install some server software.  Solaris is a Unix based system so this meant that I had to learn Unix quickly. I've taken courses in college related to Unix and Linux based systems but as with anything,  in a classroom you only do enough to pass the course but not as much as you would in a real world environment. Moving around the Unix command line and inspecting and modifying files was a bit painful but after a little bit of practice I was able to get through it. Here are some of the hurdles I ran into and some of the resources that I found to get over them. The Unix Command Line In Solaris the command line is anything but unavoidable. Solaris has a GUI but if you want to do anything significant the command line is the way.  The command line will help you move around the folder structure. It will help you move and manipulate files and execute shell scripts that may be part of software

"You can't handle the truth!" is an all time favorite movie line by Colonel Jessup, played by Jack Nicholson, in the movie A Few Good Men . In the movie Lieutenant Kaffee, played by Tom Cruise, is trying to get Colonel Jessup to admit ordering a "Code Red".  Kaffee is demanding the truth to which Jack Nicholson's character replies "You can't handle the truth". Col Jessup goes on to explain that he is the one that has to make the difficult daily choices to protect the very freedom that Lt. Kaffee enjoys but chooses to question the method on.  Life is like that sometimes.  We are afraid to tell the truth; to be honest.  For many different reasons we refrain from being honest. This apprehension is necessary in many cases to avoid being rude or unpleasant.  Yet other times, it may be necessary to be unpleasant because the truth is not only important but necessary and obligatory.  Providing estimates and level of efforts in software development i

Programming allows us to do just about anything with computers.  We can receive input, transform it, stage it and have it produce something useful on the output end.  One thing that I have observed in my 15 years of writing custom software is that we re-invent the product with every project. In a previous post I stated that programmers are like auto mechanics but mechanics have an advantage over programmers because, for the most part, all cars are the same.  I am not a mechanical engineer and will admit that I don't have the background necessary to design an automobile. However, I think that if I researched enough and got the right people, welders, machinists, I could possibly come up with a way to assemble a simple automobile (nothing fancy, more like a go-cart).  I could simply grab the different necessary components and assemble them into an automobile. The trick would be in making the components compatible with one another. I think line-of-business (LOB) software has the c