A Person, Artist, Software Engineer, Geologist.

The basic beliefs of Buddhism is that there is much suffering in life and much of the suffering is self inflicted.  There are many things that have caused me pain and strife in my life, but I really work on not adding to the amount of strife that I'll already endure.  My developing software is always a source of self-induced strife and I look for reducing my self punishment as much as possible. If you have been in this business a long time then you have been approached by friends or associates to create some software for free.  It's a hard choice sometimes, but the best answer maybe 'no'.  Software takes time, the lifecycle is long (how long to maintain?) and it can distract time from your family and happiness.   Does this apply to companies as well?  I would think so.  Let me explain what I see is currently occurring in mobile developement. Knowing both iOS and Android development, I've noticed a divergence of benefit to the developers and to the respective c

I just finished reading "Sybil Exposed" which I found fascinating on multiple levels.  On one side it was about how much  a single person can influence a profession (for better or in this case for worse) and how the progression of the Psychotherapy field, evolved over time, with some truly bazaar concepts and methodology. This evoloution is not unique to this field but I'm using it to illustrate my points. At any moment in time, the actions, concepts and beliefs for any field may appear to be correct and normal. But when viewed in hindsight many years later, can be seen for what they are, bazaar and narrow minded. The concepts of Freud with the fixation on parenting and sex.  The use of drugs and hyponosis induced states to reveal memorys that never existed, was a common and accepted practiced.  Some viewed this as normal, but not now.  Today we know the detrimental effects of these therapies had and would not dare to revert back to those practices.  We've chang

This post is not about how-to perform multi-tasking for Android and iOS, it's about my thinking related to how I handle threading issues in Android and iOS. I've written multi-threading code for decades (in C/C++ and Java) before I got into mobile development.  Threading was one of those issues that used to be a black art.  You needed to handle and understand all of the semaphores, mutating and memory issues to provide a robust threaded application.  It's a lot easier now in both Android and iOS.  Clear examples and simplified code make threading quick and easy, but there is still complexity underlying the concept of threading for the UI. My biggest insight when switching to mobile threads is the pattern of placing the threading inside of the activity or controller.  This is a big plus for simplicity and ease of use for development.  The thread is right there where it's needed and the thread has access to the Activities (or Controller's) data members for updatin

Yup, we all do it.  I know when I do it.  I feel bad about it because I'm tring to fool myself and that only makes me the fool. This came out of reading an article in New Scientist (Oct 8th 2011 issue, page 32 if you still use print) about biologist Robert Trivers.  Great interview that was right on (for me at least).  He was not talking about programming, but you know how it applies.  We are debugging a very difficult issue and we try to convince ourselves of what the cause is.  Yeah, right.  Facts are facts but that does not stop use from deceiving ourselves in so many ways.  Convincing ourselves that a bug is really a cool feature.  That we really know how the users will use the product.  On and on and on it goes. One of the most interesting points in the interview is even knowing that we are deceiving ourselves, we still go ahead and do it!  Robert knows it and still does it!  Life hard enough and then we do this to ourselves?  Yuck. The positive side to all of this is be

Been wanting to post about my perspectives on Android development.  This is not a Android -vs- iOS blog but just what I see as my perspective of Android development. Android feels easy.  Java feels like a well broken in shoe that slip on in the morning and can wear all day, so Android development feels easy for me.  I understand the attraction of the Intents and Activities for the providing of multiple filters for handling common features (select you email, photo editors, etc), but I view this as more of a benefit for geeks rather than most consumers.   What kind of support is there for uses that download apps only to be presented with selecting providers for comment activities, only to want to revert to the built in provider (yeah you can clear the selection but they need to know where). The destruction of the activity on rotation and on config changes feels like it's un-needed but exists because of legacy issues.  The save/restore of activities values are simple but feel like

Saw a posting on Slashdot today about a programmer being bored at work and asking what to do about it. Well, Slashdot readers being as they are, mostly responded with some not helpful suggestions (but some where).  Seeing as I've been in the development field or such a long time and had my share of periods of boredom (and almost every other emotion) I thought that I add my response.  Here goes. The first thing to find out is what you are bored with.  It may not be so easy to tell.  Is it the same coding, no designing, no attention, lack of social interaction, gotten into a rut?  It basically comes down to needing some kind of change.  New job always comes to mind, but is that the easiest and riskiest method of forcing change on yourself, never mind that jobs may not be easy to come by.  Change is needed but what and how? For myself, I find I get bored if : I'm not doing anything new I'm not keeping myself busy (I love getting things completed). I've run out of

Words, they can be hard to come by, misleading (on purpose or mistake) and costly.   The word "Done" means many things to different people during the software development process, with most of them not-really correct or helpful. Software Engineer says "it's Done" - The code may have been written but not tested.  Or written but not working, or done "except for some details", or if they told the client it's done, then what does that mean? Project manager says "it's Done" - This depends on whom they are saying this to.  Saying this to a client means that they should expect it in their hands NOW.  If it's the CEO then it means, to appease, to inform, to CYA, etc.? QA says it's "Done" - Then it means it's clear of bugs, ready to ship? Done only means "Done" when the client has it in their hands, installed it and it works as promised.  We have all seen or heard to people using the work "Done"

There are tons of blogs that provide sample code on the web and I've found them so helpful to providing insight to answers I've been looking for.  I would like to thank every one. But my blog does not provide code.  I've been tackling a different side of software development.  The side that is filled not with code, but how we think about code, think about why we do what we do. About source code.  Sooooooo subjective.  It's lifespan is limited to the development process and is soon turned into byte code by a compiler, never to be seen by anyone outside of development.  Source code is like shared painting where everyone has a vision.  The locations of brackets, spaces, names of functions, variable, etc. may instill heated debates from almost any group of developers. My guidelines (only) for myself are: Stay close to what ever standard your company uses.  It's not that big of a deal. Don't reformat others code.  You would not want them to reformat yours an

When you work with developing UI code as much as I do, you run into the issue of UI as Art.  It's (mostly) subjective.  People have built up mental maps of their life, surroundings and how they expect life should be and why doesn't everyone think like I do? I do it all the time, but now I try to seek out and enjoy the differences instead of working to avoid these conflicts of vision.  Unless a UI design is specified before hand, I have to come up with a visual implementation that I feel suits the needs best.  Sometimes it works, sometimes it doesn't.  It kind of depends on who is playing the bills and what their vision of the issues are. In this sense software is like art.  Not just the UI elements, but the internal design and structure of software as well.  Everyones internal bias get exposed when writing and looking at code.  Different code may do the same thing but be completely different internally.  Look at Android and iOS development, nothing a like but the end re

Software patterns are well know (Singleton, MVC, etc) as are anti-patterns (cut/pasting of code, etc.), but do developers ever think of their own personal patterns or anti-patterns? Just as tool sets can vary from project to project and technology changes over time, personal patterns can turn to anti-patterns based on the project. I know Java but I would not use Java on an iOS mobile device.  The quality of the product would suffer vs using native tools.  The same goes for trying to use Microsoft tools (does Mono come to mind?) on linux servers.  But this is not about tools but about how you (as a developer) think about your role in development and how you personally effect it.  If your pattern is thinking that Java is the perfect tool for any project, then that can become an anti-pattern if the project is on iOS. The interaction between team members can also be effected by personal anti-patterns.  Not asking questions is a personal anti-pattern, so is not making decisions or hid

You may be asking yourself where are the Buddhist teachings in my posts?  Well, I try to hide them in my topics but I don't want to be in your face as well.  The reason for my posts are not to teach you how to be a Buddhist software engineer, but how I've faced software engineering.  Which means facing myself, warts, insights, relationships and all. Here is the "in your face" part: A good understanding of Buddhism can be found at  Wikipedia.org  to start with.  There are so many books and web sites that you can explore that are only a Google away.  The good step to understand Buddhism is The Four Noble Truths and I have found this to be so key to my life.  Don't just read the Wikipedia page, please get a book by the Dala Lama on  Amazon  (or any of his books), read it and see how it relates to your life and maybe, to your philosophy  of software development.  This is one of the questions I like to ask prospective new hires, "What is your philosophy on sof

I've worked in all aspects of code from libraries, DB design, Web/API-services, requirements and everything else, but I've happily fallen into being very strong in the design of User Interfaces.  It's not that I'm artsy (I'm not) but I have a knack of being able to architect UI code so that the artsy presentation skin can be added easily without effecting the functionally of the UI. Unlike other layers of an application / service (or whatever layer), there are discreet operations and parameters with expected results.  Code can be written and tests created to the expected behavior.  It's the same with DB operations but will a bit more complexity based on relationships, triggers and transactions. Not so easy with UI code. Write code to show a form, easy.  Add validation and error handling and it gets a bit busier.   Add related actions, operations, state tracking for enabling / visibility, mix with async operations for data streams and any gee-wiz widget beh

Sad.

Cleaned out the garage this weekend and found some old development software that I had used "back in the day".  The things that struck me were : - The emotions that get evoked when I think about them -and- - The core of development changes very slowly but the tools / technology churns away. The first product was Symantec's "Visual Cafe" (1996).  This was an early Java 1.0/1.1 IDE that was a big hit for a short amount of time.  Back then it costs $299.00 when very few Java IDE's even existed.  Java is still here but Visual Cafe is long gone. The other product (1996) was IBM / Apples "OpenDoc" technology along with SOM and it's implementation of CORBA.  Whew, what a mouthful.  This was a response to Microsoft's COM/DCOM and embedded technology used in Office (think Excel inside of a word document).  Terribly complex stuff that 1) failed to be adopted by a critical mass of developers and 2) supplanted by the internet. Wow, what a time

I'm now on Twitter!  It's been awhile and I'm exploring how best to network with others interesting in Buddhist Software Development (or just Software Development). I'm also revamping my www.BlueFootedBoobie.com web site that contains my MySines iPad and iPhone/iTouch applications.  The changes will also include information on how to setup and work with developers from a management point of view. My handle is #ToddBlackley. My tweets maybe questions that I've axed myself many times that get me thinking, comments of the day or just a quick observation.  I hope you find them helpful. See ya in Twitter-sphere ...

We don't always stop dancing when the music stops and our song is over.  We learn to love our ruts, our comfort zones and fail to notice that the music has stopped and it's time to change. But it's change that we should always be planning for.  The world is not static and neither are companies, projects or even ourselves, so why are we so surprised when the music stops? We see this all the time with friends changing jobs, moving away, marriages breaking and always try to come up with what went wrong, what reason is there for this occurring. That's the wrong question.  The real question is why does it not occur more often?  When should we reject change and when should we adopt it?  Too much change and we spin our wheels with undirected motion, too little and the world moves on without us. Then the music stops.  Maybe you did not even notice it and you are still dancing.  Maybe when you where dancing you should have learning some other songs or other steps.  Did y

If you have been in the software development field for any length of time you've had to wear many different types of hats.  There the DB, API creation, Web design, Web code/JS, remoting / streaming, UI, Requirements, Architect, Help system, Error handling, Customer service and a zillion other types of hats that are required for a typical project in our field. I enjoy all of these different roles that I've needed to perform, however it does not make me an expert in them all.  I'm good in most of them, expert even in a number of them, but I know where my strength and weakness lay.  I must still learn from others. In my youth I wanted to be an expert in everything.  Learn something new then I would quickly become an expert.  Well, not so fast, wanting and being are not the same and I needed to learn that. I first needed to become an expert at myself and that took time.  I needed to understand what I knew, what I did not know and when it's helpful for me to provide

The bottom line for me is to provide something that others (we shall call them Users) find beneficial .  We take generic tools (languages, DB, logic) and hopefully turn it into a specific tool that solves some problem. The basic software stack contains the most generic code on the bottom with subsequent higher layers getting more specific (through business logic and APIs) until the most specific code resides in the UI, that hopefully solves a specific problem. The problem is that, as good little OOD engineers we just love re-use and generic all-purpose code.  We are always looking to making our logic, features and code as generic as possible because we just know that we may re-use it sometime in the future (yeah sure!).  Sometimes we try to push the generic code up through the layers and expose them in the UI, you know, because we love re-use and such.  It's in our nature.  Because we are sure the user will understand and love our code too.  We just have to convince them what

After what seams like a zillion years spent in development you pick up guiding principals to develop by.  One of these principals is to only spend time on efforts that either directly part of the development of the product and at most 1 step removed from the actual product.  Anything more that 1 step removed from the actual product development should be looked at with suspicion as to it's benefit. By benefit to the product I mean, if that process was removed could the development more or less still continue with the product will being completed?  Yeah, it's all subjective, as you will find developers always thinking that they must have this or that, or that the product would be "better" if their own testing framework was developed for their "special" needs.  Hummm, yeah right. Each step incurs it's own cost in design, coding, resources and more importantly on the timetable.  Time taken away from the direct product is time not getting the product done

When I was a young software engineer life was intense.  Code was moving fast, we all thought that our way was better than others and always wanted our voice to be heard.  Meetings way back then were a pain and mostly self inflicted. It has not been that way for a long time now.  It's interesting and educational to listen to others and not talk.  Most decisions will find their way out if everyone gets a turn talking and listening.  Almost all choices are not life or death in nature, with most in flux and subject to change.  The whole listening part is mostly for understanding others viewpoints.  Good choices will mostly rise to the top with poorer choices failing to gain traction, as long as everyone (kinda) does not have a personal vested interest in specific choices.  There will always be code to design and write.  Persons will personal goals or desires that conflict will the direction of the project will stick out and may get minimized in their weight or they will bear a larger

Once in a while I'll hear from readers that I never new existed.  Just this last week I've heard from 3 readers that I was surprised read this blog. One was from overseas where they where also a user of my MySines iPhone/iPad application.  Very cool. One was from a old contact that I have not heard from for a long time and thought I could provide assistance to a contact of theirs.  It turned out that was able to provide some general startup / development guidance. And the last was a local contact that had questions about my last blog on Bullies.  They wanted to know if I was talking about an area close to them (I was not, it was a long time ago). It was very interesting to get such different contacts, each with very different areas and aspects of my life that has in some way intersected with theirs.  You never know what areas in your past has intersected with others.  I guess that is kind of what Facebook is all about.  However Facebook works to keep those contacts alway

This is a tough subject for me.  As kids we always remember those kids that bullied the rest of us kids.  Some worse than others but we will always remember them.  We thought it was just part of growing up. My viewpoint on this has changed.  Being a bully is more than just part of growing up but a window into the life perspective of the bully.  It's not a sign of being a kids but something that should be addressed as young as possible, not with punishment but with help so the person can understand how this behavior is detrimental to themselves and others. How does this related to software development?  People are people and this field has no special filter to prevent employing bullies.   The worst placement for a bully is that in management.  Their activities are cloaked under the name of management style and their very existence at this level ensures that it continues, both at this level and below. The flip side is where management understands the effect of bulling in the wo

Shay talked me into going to the PCT (Pacific Crest Trail) kickoff party last week.  For those that are not aware, there are very long hiking trails across the country with the PCT being one of the longest (it's 2,700 miles from Mexico to Canada).  About 1/2 the people were going to hike the trail this year (they start at the end of the party) and the other 1/2 had hiked it in prior years. These hikers are just regular folks like you and me but feel the urge to hike it.  They have lots of sessions that talk about the snow in the Sierra's, wild life, river crossings and the like.  It was a lot of fun.  The whole time there was no news or talk about anything else except hiking and "the trail". Because the trail take between 5-6 months, everyone was either unemployed or had arranged time off from work.  This trail is a commitment! At the end of the weekend I needed to return home and my cube and long of starting the trail.

Every day is a new start.  MySines is up in the AppStore and even getting a few sales (no retirement from this app).  Games are where the big sales are but I just don't feel like doing a game app.  Games are fun but I would rather try (and even somewhat succeed) to provide an app that could help people. No resting on what I've already done, gotta think of that next application. I'm working on the view point of starting applications where others end.  In the case of MySines, the main screen is where other apps may end, with a report.  I would like to make the report (the end result) first and have the user build up the report through their actions.  They always get to see how they are doing, the big picture. I've got a couple of ideas that I need to flesh out......  more later.

My "MySines" iPad application is now for sale on iTunes!  It's under the Health or Lifestyle sections.  Whew, that was a lot of work learning all XCode, IB, Objective-C, libraries, etc. I won't get rich, but it's been rewarding and I hope people find it beneficial in their lives.

Yep, my first iPad application is finished.  Well, at least Rev 1.0 done.  I have many ideas of how to extend it and have even reserved space in the DB schema for them, but that is for an update.  For now "MySines" is complete and I hope others find it useful. "MySines" continues my buddhist beliefs that you can never stop learning about yourself.  Yes every one has flaws but tools like "MySines" may help to discover patterns in a persons life that they did not know about. Cause & Effect has an impact on our lives.  Some are hidden from our view while others we would rather not know about.   We always have an opportunity to learn from our own actions (causes) that effect how we feeling and think. I hope "MySines" provides benefit to others.  Enjoy. Website - BlueFootedBoobie.com

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. Got my domain name already

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.  Bailing on F