Skip to main content

Posts

Rock Climbing and HTML (or any Development)

I'm an old timer in Rock climbing.  Not the Faux climbing in the gym but on real rock with whatever surface erosion has provided for it.  I remember a boulder problem on Mt. Woodson that was called Television Screen (aka, Super Edge).  It was a big rectangular block that was tilted just off vertical with an irregular surface and this wonder edge that also had variations in it.  There was just enough of both to provide light hand and food holds to lie back off of while edging with your feet on the face.  It was rated 5.10 and just on the edge of what I could do with my new (then) EB climbing shoes. I was so proud of finally being able to climb it with my new EB shoes.  Then a friend of mine just scurried up in the running shoes!  I could not believe it, regular shoes and much less effort! The difference between the two of us was the context, me -vs- him.  I could do it but I needed better shoes and it was still hard.  He just needed ...

Mixing It Up

Life is not static so you have to mix it up a bit to keep it interesting.  Well that is what I've done (at least I try to do) with publishing an iBook using iTunes and the iBookAuthor software.  Nothing better than using a new tool and learning about a new field.  My wife is a writer so I wanted to get a little taste of publishing my self, but I'll never be in her league. A lay persons guide into the messy world of software creation. This provides a basic foundation of what software is and the basic forces in it development.  This should provide the reader with the general development process and the complexities that can arise in the phases of development. Free download of iBook here I wanted to lay a foundation of the messy (dare I say wacky) world of software development.  It sounds so high-tech and science like, but for the most part it's the interaction between people, each with there own issues, desires and feelings that are the primary factors in ...

What is a Sweat Shop?

Lately there have been a number of posts on Slashdot.org  about older (40+) software developers or the half life of software developers. I don't use the term software engineers because the majority of younger workers in the software field have not yet gain enough experience and wisdom to be able to consistently and predictable design, plan and implement complex software project without a lot of re-design and refactoring along the way.   Being a bridge engineer does not afford the re-building of a bridge 2 or more times before getting it right.  The same principal also applies to software engineers. Back to the Slashdot articles.  My though on the comments of the half life of software developers only be 15 years is what the company is using their staff for.  If you are interesting in keeping wages down, have only simple to moderately complex projects, use 100's of staff (in this case 4,500) and expect them to not have a life outside of work, then yes, the h...

I'm Lazy

I'm Lazy. I don't want to write more code than I need to. I don't want to create a design that is too complex. I don't want to write "the next big thing", I just want to get the project done and make it a success. More code = more complexity = more debugging = more testing Even though I'll create bugs, I want them to be easy to fix, so I architect the design for each correction.  I don't want to be asked questions from other engineers on how things work so I make sure the class names, object hierarchy is clean and the operational processes are simple to understand. I don't want to have to hunt all over the code for related behavior so I group them by name or packages. I don't want to have to work late so I under promise and over deliver. I don't want to be confused so I ask stupid questions so that even I can understand what I need to do. I don't get too involved with shiny new objects because 1) too shiny and they distra...

The Developer and the 3 Bears

I've been revisiting HTML5 developing of late.  What I've found is three broad categories (I group by nature and habit), of current HTML5 development methods. They are: The tried and true, create your HTML page, add JavaScript and sprinkle with CSS.   Use "heavy weight" framework like Sencha's Ext-JS.  Heavy weight in sense of complexity and understanding.  Even for me it's a bit over whelming. Find a middle ground method that is in between the "build everything from the ground up" approach and the "kitchen sink" toolkits and libraries. I think I have found my "porridge that's just right" development method in the form of Enyo.js.  This is the framework that was born out of WebOS and is now in it's 2.0 release.  It's refreshing not to work in an all too common 0.999 release of a project and with the simplicity and clarity of design and implementation that eludes a project like Sencha EXT-JS. The Enyo.js co...

The Middle

Just read the book "Team Geek"  (amazon)  today and I would highly suggest reading it.  It's short, to the point and covers almost all aspects of development teams and the issues therein. It's a great book.  It does not mince words on problem staff, management (good and bad) and the multitude of issues that we have all been exposed to in our careers.   The good and the bad. Where Buddhism is about understanding oneself and making changes based on this understanding, this book covers the other side of the coin, working with others, problem staff, management anti-patterns and culture.  I can't say enough good about this book. The only comment I do have is the section on the physical working environment.  There are workgroups on one end and offices on the other.  I understand the flow of communication with workgroups but the interruption and lack of a personal workspace can effect a number of people.  This is somewhat covered by the comm...

Who Are Your Customers?

Last months news that Facebook was re-writing their iOS application did not come as a surprise.  I had been following (and researching) the trend of using HTML5 for native applications.  It appears there is a much larger population of web -vs- iOS developments and the lure of using what you know to solve a new problem is very temping.  It's this whole "change is hard" thinking. Facebook knows web development (PHP, JS, CSS, etc) and its understandable that the HTML5 option would be on the table.  It's not for a lack of money or resources.  I believe it was the thinking that there customers are familiar with the desktop browser version of Facebook and thus the transition for their customers would be a minor issue.  Business win, developer win, customer win. Except, for two issues: Their mobile users may not be the same as their desktop users, thus different expectations. The expectations from a mobile application (i.e., native) are much different from...