A Person, Artist, Software Engineer, Geologist.

I've been working on my iPad application and ran across an issue that I did not understand how to implement using iOS Core Date.  After following a dead end or two (at my age you get a good feeling when your headed down a dead end) I decided to ask the web for help. Sure enough you could see where others have followed the same paths that I did before learning the "easy" way to solve my problem.  It was nice to see that I was not alone in my original false thinking of what I wanted and that (at least for me) I was able to understand the Core Data method of providing a simple solution. I did not see my final solution right away, there was the "try this code" solution that would not and did not work, the brute force methods that were written about but no code presented and then there was the "you need as sub-query for scanning the child entity........ that was the ticket I needed.  Along with the solution was a explanation of "why" this solution ...

I've been busy the last couple of weeks.  I've been working on my iPad application and again and I can see light at the end of the tunnel.  On the biggest challenges in it's development for me (besides learning all the different tools and technology) is the flattening out the user interface. By "flattening out" I mean the work flow to 1) make it as fluid as possible with 2) very few dialogs or context shifts.  The end result should be as fluid as possible with the workflow as transparent as possible.  This has been fun.  One problem I had was with the selection of colors.  I could have used a spinner in a popup but did not like that solution.  I ended up using 16 predefined colors that they can select from and placing it right in the setting page.  This prevented a context switch and gave instance feedback.  The limit of 16 is not a problem as the app will be most effective with a limited number of graphic elements.  Solution solved. ...

All the talk about Apple's latest Qtr results got me thinking of how this applies to my life.   Apple focuses on a specific market.  In this case it's the market for the iPad where it's 1) mobile (couch, car, where ever), 2) only fingers required (this means that all controls / action must be selectable with finger resolution) and 3) very very simple to use (flattening out of the applications logic, etc).  To this end they provide 80-90% of most peoples needs.   No overly fancy UI, no extra features that most people would never use and no real concern of what is actually in the iPad (chips, speed, ports, etc).  Just a device that provided a generic solution for most people. For software it's really about the same ideas, providing a solution to your target customers as simply as possible. CONSTRAINTS Apple has constraints as they work with hardware and the limits of currently battery life, screen displays, etc.  that force Apple to unique solutions. ...

I'm only human.  I make plenty of mistakes. Early in my career I thought that mistakes where to be avoided.  I rock climbed and mistakes could be at best scary.  In software development the mistakes I made were to be quickly forgotten as I was learning so fast I needed to focus on what I was doing.  Many of my mistakes were because of the fast pace of learning systems, languages, libraries and the like.  The software world was so large and I wanted to learn as much as possible. I no longer try to know everything.  I just need to know just enough. Now days I cherish watching and understanding how mistakes are made (including my own).  Many of my mistakes now days are still due to incomplete understanding of an issue., but it's far less than it used to be.  I now take time to think before deciding if I have enough information to provide valuable input.  I've also adopted the fortunate habit of asking what I call stupid questions.  Th...

I was reading a post on SlashDot.org this week about a developer asking what language they should learn next to further their professional career.  The poster then stated the languages they would not learn because of personal stances dealing with the languages parent company, political stance or whatever. What an interesting but self limiting point of view. For me, I can't really care or direct which language I develop with, other than to work for a company that generally uses the languages I'm interested in.   If the job and problems are interesting then the language is maybe not as important as what I'm learning.  I'm excluding the choices of using Perl for client side applications or XUL for business logic type of decisions.  I'm talking about sound business decisions by the company for selecting a toolset for a specific project. My job is providing a product for the company with the toolset I have.  If I can do this and a fellow developer is always arg...

I have found that I'm am getting picky on what I take time to learn these days.  I have only so many hours in a day that I can devote to learning that I've gotten real choosy on what to focus on. When I decide to learn something new I need to create a "real" product out of it to completely understand what I'm learning.  I tend to focus on products or technology that, for me, I view as having a long term impact on my knowledge, career or interest.  A couple of these technologies have been JSF (Java Server Faces) iPad iOS development.  Very different technologies but the method of my learning is about the same.  It kinda of goes like this: Get excited. Try to develop a product with this technology. Fail (because of my lack of understanding). Stop and learn why I failed. Try again and Succeed. I did this with both JSF and iOS (iPad).  I (falsely) believe that just because I have a zillion years of experience that I can just pick up new technology and...

It's the topic that stirs much emotion in the software development field. Being in the field for 30+ years I've had the opportunity to be involved with many different types of development methodologies with Agile only being the latest among them. Each of them have aspects that are shared but may be implemented differently in different phases of the development lifecycle and Agile is no different. The need to gather and understand the customers requirements, the need to track progress during coding and to verify the operational aspects of the work thus far. All of these aspects exist in different methodologies to different degrees. My personal perspectives on Agile are: It’s not the holy grail of development methodologies.  It tries to instill from a process what good concerned developers should already contain and just using a different process will not over come developers ill suited for a project.  It tries to instill a mantra that could be perceived as “somewhat” of ...