Biscuit June 21, 2003 - April 28, 2016

Just this side of heaven is a place called Rainbow Bridge.

When an animal dies that has been especially close to someone here, that pet goes to Rainbow Bridge. There are meadows and hills for all of our special friends so they can run and play together. There is plenty of food, water and sunshine, and our friends are warm and comfortable.

All the animals who had been ill and old are restored to health and vigor. Those who were hurt or maimed are made whole and strong again, just as we remember them in our dreams of days and times gone by. The animals are happy and content, except for one small thing; they each miss someone very special to them, who had to be left behind.

They all run and play together, but the day comes when one suddenly stops and looks into the distance. Her bright eyes are intent. Her eager body quivers. Suddenly she begins to run from the group, flying over the green grass, her legs carrying her faster and faster.

You have been spotted, and when you and your special friend finally meet, you cling together in joyous reunion, never to be parted again. The happy kisses rain upon your face; your hands again caress the beloved head, and you look once more into the trusting eyes of your pet, so long gone from your life but never absent from your heart.

Then you cross Rainbow Bridge together....

Author unknown...

Using Encrypted Email Requires a HUGE Leap of Faith

This is first in a series of posts addressing email privacy and security.

There are a lot of services popping up offering encrypted email. They claim secure end-to-end encryption of emails with zero knowledge of keys and passwords used for encryption. It’s all seamless and requires no special action on the part of the user except to use their web interface or mobile app. The encryption happens locally on your device using JavaScript and no unencrypted data leaves your device. The keys are generated on and stay on your device as well as the password you use for encryption.

It’s an incredible bundle of awesomeness, right?

Well, just remember you are at the mercy of site to not capture the keys and encryption password in the JavaScript library they provide to handle the encryption. Depending on the laws and treaties of the jurisdiction where they are located, they could be compelled to alter their script to capture the keys and passwords at any time without your knowledge. They could be prevented from even notifying you they were required to do this.

Unless you have intimate knowledge of encryption and examine every line of JavaScript they used to handle the encryption you don’t really know what’s happening. If you don’t have the knowledge, perhaps you know someone who does you completely trust. But then what if they were compelled to not disclose the JavaScript was changed in the same way the site was compelled to change it? Then there’s the elephant in the room, you’d have to re-examine the code every time you used the site and by used, I mean every time the page is refreshed or reloaded.

In other words, it’s just not practical.

As for the mobile apps, you’d have to decompile each and every version and examine the code line by line before relying on it.

Again, in other words, it’s just not practical.

The bottom line is even if these encrypted email offerings come from people and organizations with the best of intentions are honest and honorable beyond question… you still don’t know. You still must take a leap of faith and pretend your emails are 100% secure for all of time.

Depending on why you want your emails encrypted that could be a huge mistake.

The more secure way to encrypt your emails is to use public key cryptography. That requires you to generate your own private/public key pair and exchange public keys with anyone with whom you want to exchange encrypted emails. As long as your private key is not compromised emails you receive remain securely out of reach of any prying eyes. As long as the private key of those receiving encrypted emails from you aren’t compromised the emails you sent remain securely out of reach of prying eyes.

Do you see the weakness even with public/private key email cryptography?

No? Okay, walk with me. Do people get into trouble because of emails they receive or because of emails they send?

Since you can’t control whether your recipients’ private keys are compromised, you are still taking a big leap of faith any emails you send will remain encrypted and out of reach of prying eyes.

But all is not lost. The first question you have to answer is, “Why Do You Want Encrypted Email?”

Hey Look! It’s A Code Bigot!

Yesterday, I asked a question on an Apple iPhone development forum. My question dealt with a bug in a Cordova plugin accessing the fingerprint API for authentication. For the most part the responses were helpful, except for one which literally made me laugh out loud. Now, the better part of me told me to just ignore it and walk away. But I didn’t.

“I’ve been writing application for the iOS environment since it first came out. Why anyone would try to write and support anything hybrid related is beyond me. Real iOS developers don’t limit themselves to the HTML/JS/CSS world. They write native apps using Swift and Objective-C.” Randall C. – lead developer, RPC Consultants, LTD.


Now, I don’t know Randall but I know his type. When the personal computer burst onto the scene in the 1980s the Randal’s of the world said similar things about Unix. The self-important and often self-appointed Unix gurus would look down on anyone who didn’t share their knowledge of command line utilities and didn’t do things the ‘Unix’ way.

My response to Randall was straightforward, “I use HTML5, JavaScript and CSS for hybrid mobile apps for some of the same reasons you use Swift instead of writing your applications in assembly. It’s the same reason web applications haven’t written as standalone servers since the Apache web server came along.”

His response was priceless…

“That’s stupid. I use Swift instead of writing assembly code because it gives me better abstraction and makes me more efficient. I never learned assembly because I don’t need it because of advances in computer science. Comparing Swift to assembly shows you are just another web designer turned mobile hack.”


At this point, a lot of people piled on poor Randall. I didn’t even get a chance to respond before the thread was locked down. Randal is not unique in his thinking but he is outdated in his thinking.

It isn’t a question of whether someone can write an iOS mobile app in Swift or use Java for an Android app. The question is why would you not use a more abstracted layer when it is available? Then drop down to the lower levels when the abstraction can’t support what you need? I’ve been writing code for more than 35 years. When I started it was very common to have sections of assembly within C because it was needed.

Today, thanks to advances in computer science Randall pointed out, we have better ways to interact between the layers of abstraction such as Cordova plugins. These provide the low level functionality needed for a particular device ecosystem. These provide the ability to use JavaScript in a hybrid app to access things like cameras, GPS units and other system resources.

So, Randall, if for some unknown reason you are reading this, I use HTML5/JavaScript/CSS for hybrid apps because it allows better abstraction across devices allowing my clients to bring an application to market faster and cheaper. I don’t have to write the app multiple times, in multiple languages. I can have one codebase and then build for any mobile device. You might have the luxury of only supporting iOS apps but out here in the real world, not everyone uses an iPhone.

Rich Text Editors in Hybrid Mobile Apps

One of the biggest shortcomings with hybrid mobile apps is the lack of a robust rich edit control. Yes, hybrid apps are built using JavaScript and yes there are a lot of JavaScript based rich edit controls out there. But finding one with the feature set I needed for a project which actually runs reliably has been a challenge.

First, anything relying on an iFrame is out due to mobile apps being sandboxed on the device. Second, I am not a jQuery Mobile fan. I have no desire to argue the merits and weaknesses. I like jQuery on the desktop but in a perfect world, I prefer Vue or Angular. jQuery is too heavy for a mobile application and jQuery Mobile is better. But at the end of the day, using jQuery doesn’t enforce or even support MVC best practices and for me that is the deal killer.

I am a pragmatist though and I have used jQuery in projects and I’m sure I will in the future.

But this is a discussion about rich edit controls for a mobile hybrid app, not a discussion on the merits of a framework choice.

My needs for a rich edit control on both Android and iOS are driven by a project to develop a mobile app to access email features of an existing web application. This web application allows the user to write emails using a rich editor to send to others. Simple enough. It also allows the user to define signatures with HTML markup to automatically include them when an email is created. The user can also store fragments of HTML marked up text they can then choose to include when crafting an email.

So the editor on the mobile app must support the same editing environment the web application does. When a user starts a new email, it must pull in the appropriate signature and display it in the editor correctly to allow them to add whatever text they desire. It must allow allow them choose any of their stored fragments into the editor and make any changes or additions they desire.

My search for an acceptable editor even led me to stop development using the Ionic framework and rewrite the application using jQuery Mobile just to use jQueryTE. which looked promising. ON the mobile device it worked reasonably well but it had a problem with inserting the quick text fragments in the correct place but overall the performance app was sluggish and I did not like the look and feel at all. The client was okay with the look and feel but not jazzed about it either. The effort to overcome the non-editor related problems was going to be huge.

Eventually, I settled on going back to the Ionic framework and using textAngular as the editor. It is not perfect and I have had to customize it to better meet my needs but having the Ionic framework far outweighs the effort expended to work around the textAngular issues. There is an issue with inserting the quick text fragments due to a focus issue but I will fix that.

I will upgrade the project to Ionic 2 in the near future because of the incredible benefits it provides in a hybrid app. So far nothing has led me to believe textAngular won’t still meet the needs of this project even after the conversion.

Ionic Framework and the Intel XDK Work Well Together.

The last few months have been focused on adding a mobile app to an existing and very complex wed application. There have been a number of challenges in overlaying current technology and best practices onto an application started over a decade ago and still being updated and extended today.

To say it’s been a balancing act understates the complexity involved. To provide the functionality for the mobile front end, a new api layer had to be added without adversely impacting the existing functionality and played well with the current security framework in place. The current application is written in php so the current api layer is also written in php to leverage the security functionality in the application. The long term goal of course will be to eventually move to a node.js based api layer. But for now, the php api has not presented a performance problem.

For the mobile application, originally I started using the Intel XDK IDE to design and develop the app. While it is an excellent IDE with many rapid application development features and the Intel ecosystem provides excellent Cordova support, I’ve started using the Ionic Framework and a text editor. I still import the project into the Intel XDK for emulation, device connected testing and building the app.

The XDK does support creating apps based on the Ionic framework but the Intel IDE works best when all of your html markup is in a single file. I prefer things to be more modular and templated. Ionic provides a great way to start a project and include the needed Cordova plugins. When you import into the Intel XDK you can convert to using the Intel Cordova plugins or continue to use the independent ones. I use the third party ones configured by Ionic instead of converting to Intel’s versions.

By not converting to the Intel Cordova plugins, I retain the ability to build the app locally at any point in the future. I like the convenience of the Intel build system but I also want to be able to retain the ability to build elsewhere if Intel decides to discontinue their cloud based build system or introduce a fee structure making it too expensive to use. Currently it is free, but honestly, for the convenience it offers they could charge a modest fee and it would still be an excellent value to independent developers.

Ionic is built on top of Angular.js and is open source, well supported and well maintained. Currently Ionic 2 is in beta. It is built on top of Angular.js version 2 and is also open source and supported and maintained by the same group of developers. Version 2 is a substantial rewrite and converting from version 1 to version 2 is easy to non-trivial. Once version 2 is released for production it will become my framework of choice for hybrid mobile applications.

Did you feel it? Microsoft did.

We are in the midst of a technology shakeout and it won’t be very long until it doesn’t matter what hardware or operating system the majority of users use on a daily basis.

Don’t believe me? Then consider this. The explosion of cloud based services users love has pushed virtually all software developers and publishers to embrace the cloud model. That means more web based and mobile based applications and fewer hardware and operating system specific ones.

We are quickly reaching the point where the various device and operating system manufacturers will be the only ones creating much of anything natively targeted to their platforms. They are all supporting the same basic services and provide hooks allowing them or third parties to produce abstractions of their products.

Look at the evolution of mobile applications. Today, every mobile device has an abstraction via Apache Cordova and other third parties allowing hybrid applications built using HTML5, CSS and JavaScript to access all of their hardware and operating system specific features. In other words, you are no longer limited to the Apple tools and ecosystem to build applications for iPhones and iPads. The same is true for Android and Windows apps as well. Using one of several cloud based services, you don’t even need a Mac or Windows machine to build the actual apps. Right now, today, you can design, develop, test and build an app to submit to the Apple, Google and Windows App stores all from your Linux, Windows or OS X ecosystem.

Pretty cool huh?

Gone are the days when you had to have or hire application developers with intimate knowledge of the various platforms users might have. Now, all of that is pushed back to the hardware and operating systems and the abstraction layers which is where it should have been all along.

Within the next 5 years or so the importance of which device you use will become irrelevant to all but a very small minority of users. You will choose your desktop, laptop, tablet and/or phone based on what you like and can afford instead of what software you need to use.

Why? Because, with very rare exceptions, all business, scientific and entertainment applications will run on any hardware with any modern operating system. Microsoft realized this and extended Office support to iPads. It’s just a matter of time until your Office 365 subscription will let you use office on any device you own, no matter who made it or what operating system it runs. Granted, currently, they are supporting multiple code streams for Windows, OS X and iOS but over time, it’s likely they will merge much if not all of the code.

What does this mean for you? If you are a user of software, it means increased freedom to pick the best hardware and operating system that meets your needs and budget. For application developers and producers, it means a streamlined path to bring innovative solutions and applications to market. Just like a toaster manufacturer doesn’t have to worry about how it will interface with the electrical grid based on which builder built your house, your application can be built from a single code base to support any hardware running any modern operating system.

I have one Windows specific application I developed and still support and I am at a crossroads with it. I have to decide whether to discontinue further development and sunset support for it or migrate it to this new paradigm. There are several factors to consider not the least of which is it serves a really small community of lawyers now. The decision to sunset it or move forward will hinge on whether a larger market can be found for it. Honestly, I’m not very hopeful.

But looking at the potential projects in my pipeline, I can’t justify continuing with a platform specific application. I don’t have the resources of a Microsoft to manage a protracted transition and at this point, the current user base just can’t justify the costs to bring the application forward. The sad reality is to appeal to a larger market, it would need to abandon the specific feature set it needs to support the current users – tight integration with Microsoft Word.

Still Committed not to Update to Drupal 8

Last fall, I wrote a post on here about my decision not to upgrade this site to Drupal 8. I was more than a little tentative to make that known at the time. I was concerned my Drupal related clients would feel I was abandoning them. I approached each of them to gauge their possible timeframes for upgrades to Drupal 8 and have only found one who wants to upgrade to Drupal 8, but not until this summer. They are a content heavy knowledge base site and as a solution Drupal really shines and meets every need they have. Others decided to stay on Drupal 7 at least for now and surprisingly some were exploring non-Drupal replacements but were hesitant to approach me to help with the process.

The reason given most often for either not upgrading or exploring other solutions was the customizations previously done for them would need to be done again for the new version of Drupal.

Customizing Drupal can be complex, time consuming and even expensive. Unfortunately, those customizations often have to be done again when upgrading to a new major version of Drupal. The most interesting thing to me in all of this is I’ve recommended Drupal only one time since October and even that client decided to go with a Laravel based solution.

I still like Drupal. But for the projects I’m seeing, it’s just not the best tool for the job right now. I see a lot of need for brochure type sites and Drupal is overkill for anything simple like that. Yes, it can do it, but you shouldn’t use Drupal for that unless there are some other compelling reasons. Obviously, my longer term concern is I will lose my edge with Drupal. At some point, if a project comes along requiring the features Drupal offers I might have to spend some time coming back up to speed to handle any customization and integration issues. But I can’t justify using Drupal when better and simpler solutions are available just to satisfy my internal ‘need’ to stay current.

Many of the non-trivial projects in my current pipeline have some aspect of a mobile app to them. In one case they don’t want a frontend web page at all. Everything, including daily administration, is through the tablet based app. The front-end is Ionic and the backend is sails.js. Other than the scheduled upgrade later this summer, I don’t have a single Drupal project in my pipeline.

I kind of wish I did.

I Love Drupal… But…

Seriously. I love Drupal. I’ve been using and building sites with it since version 4 and version 8 is really awesome. As a content management system, Drupal cannot be beat in my opinion.  This where you are reading this is built on Drupal 7.

I love Drupal… but I am not going to update this site to version 8.

Now hear me out before you get out the pick forks and start lighting your torches. This site uses Drupal as a CMS but in parallel with it are multiple tools I use and my clients use during projects. The integration is not trivial and I started down the path to once again, reintegrate all of the tools with a new version of Drupal. I didn’t run into any insurmountable obstacles. I didn’t find anything that wouldn’t integrate with Drupal 8 without a major rewrite on either side. Everything was proceeding as expected. But…

While I was preparing my upgrade to Drupal 8 clients and former clients were as well. One of them has in-house developers and uses me only as needed. Unfortunately, their in-house Drupal expert had moved on to greener pastures and I was asked to bring their current developer up to speed on Drupal.

Drupal is not simple to learn. There, I said it. Drupal is a very complex web application managing content presentation and creation. It supports some incredibly complex workflows with multiple users. But it is complex and prior to Drupal 8 it didn’t support modern concepts like MVC frameworks in any way at all. Drupal 8 is a rewrite based on the Symphony framework so that has been addressed. But complexity remains and the learning curve to get up to speed with Drupal is still not trivial.

Knowing php doesn’t fix it. Knowing Symphony doesn’t fix it.

By the way, did I mention my client had similar integration needs I faced? Yep, we both used Drupal to manage users, roles, permissions and access across a suite of web applications.

To make a long story short, I realized I was using Drupal for the front of this site just because it could do it, not because it should do it. Once I took a step back, I realized I could and should use other tools for the front end.

So for my site, I will be using the same tools I’m currently recommending for clients. The new site will be built on a combination of sails.js and Laravel on the back end and mostly angular.js on the front end.

I love Drupal and really love Drupal 8 but unless you need a full featured workflow based Content Management System it’s probably overkill for your needs.

I expect to have the replacement site ready in early 2016 depending on client projects.

You Forget Many of the Details and That's a Good Thing

Building any business is a lot of long hours, hard work and worry. No, I am not complaining I am stating a fact many will immediately recognize. Once you get past the point where you have critical mass and are starting to grow and gain traction you think you remember how hard it was but you don’t. You remember it was a challenge. You remember how you persevered when you really wanted to quit and you remember how it paid off. But you don’t remember all the details of what it took.

I guess it’s a little like a woman giving birth. She looks back on it and remembers the process and the effort but not the minute details of each moment. This is our brain’s way of dealing with difficulty; it doesn’t forget it was difficult but it does cloud just how difficult or painful it really was.

This has been a challenging year. Granted not as challenging as 2014. I was laid off from M*Modal and after some effort and banging my head against the wall realized returning to the corporate world was just not what I really wanted at this point in my life. I enjoyed the corporate world. I reentered the corporate world in 2004 for the right reasons, but it was past time to close that chapter in my life.

I restarted my consulting practice in August of that year and honestly, I have not looked back very much except to measure results and plan. But it has been tough. In 1995 when I first started consulting and contract programming I started keeping a journal of the experience. That journal has been very helpful to me now because this time around I am doing this without the support and encouragement of Ann. The journal from the formative years of starting FasTrac has served as a substitute.

There have been countless times over the last 15+ months I’ve found myself thinking, “It just can’t be this hard. I must be doing something wrong. I don’t remember it being this difficult to gain traction the last time I did this!” Then I open the journal pages and read about the difficulties of getting in front of the right people to present our application and approach. Then the endless cycles of demos, discussions, meetings and phone calls and more often than not we were not chosen to provide the solution.

Sure, there are many things different now than in 1995 when we started FasTrac. Then, our focus was on contract programming to sustain us while we developed our solution to bring to market. Over time, part of our business became more partnership focused instead of simple contract programming. In reading the journal it is obvious those were the most fulfilling and profitable projects I took on.

Fast forward to now and the last 15 months have all been about generating revenue to get some traction. I won’t lie. It’s been an uphill slog and 2015 will definitely not meet my goals or expectations. But the incremental improvement is there and I am slowly perfecting a model where I can find the right projects to take on that provide the right mix of revenue now and recurring revenue later.

Go Hunt America is the first of my ‘revenue later’ projects and I have high hopes for it. It’s gotten off to a slower start than I would like primarily because a project I took on early in 2015 turned out not be as temporary as I expected. There are many reasons I haven’t cut that project loose even though using cold hard facts and data I might should have. But it’s a very interesting application and if I could just get the client to push beyond his comfort zone and start promoting his solution I know it could do well. Is it the next Facebook? Probably not, but it could provide a very comfortable living for him and allow him to expand his business model to look for the next big thing.

Will it happen? I honestly do not know. We are finally embarking on a mobile app to take advantage of the features I added for him this year. It’s been tough getting to this point, he’s a bit of a perfectionist and wants everything to be perfect. I’ve had many long conversations with him pointing out perfection is not needed to maximize revenue but forward movement is. I suggested pushing the mobile app out with minimal functionality to get people using it and talking about it then adding more and more features over a short period of time. He hasn’t bought into that. He wants a fully fleshed out app as the first release. Now the software mercenary in me should be saying, fine, if that’s what you want and can pay for it I will do it that way. Maybe it’s because I’m getting older but the mercenary in me seems to have at least semi-retired. I have agreed to build the first release and negotiated down a good bit of the initial want list. My hope is once the first release happens and he gets some positive feedback I can get him to agree to a much more frequent release schedule with small improvements and incremental feature releases.

Go Hunt is a different beast. I subcontracted the initial development of the mobile app for that project and have been very disappointed in the results. I’ll blog about that experience later because there are a lot of lessons learned. It cost me several thousand dollars and I am essentially rewriting it from scratch. I am pushing hard to get the initial version out and in the hands of the beta users.

I’m still confident my decision to not return to the corporate world is the right one. I am enjoying working with multiple clients on small projects that have tremendous long term potential. My only regret over the last year is I haven’t forced myself to write more. One of my goals for 2016 is to set aside time for writing. If I block out time each day or so it will prompt me to do it.

I guess it’s good we don’t remember all of the details of all of the pain and difficulties we go through in life. If we did, we wouldn’t attempt doing anything challenging a second time and most kids wouldn’t have any siblings.

Looking Forward and a Little Back

It’s that time of year again, planning season. Yes, Holidays too but 2016 is fast approaching.

I have to admit, I expected a little more out of 2015. In an earlier article I wrote how restarting my practice felt much like it did in 1995. I misread things in many ways. Now, don’t get me wrong, politicians have been dysfunctional for as long as there have been politicians. But what we have in Washington now is way beyond dysfunctional.

In my comparison to 1995 I failed to realize one simple reality. President Obama is not willing to compromise any of his agenda no matter what it costs our nation economically, culturally or security wise. Couple that with a Congress with a larger Republican majority in both houses than they had in 1995 but with less focus and much less leadership. They cave at every opportunity because they are afraid of being called obstacles to progress.

So, as I look toward 2016 and layout my goals for my company and myself the reality of the political, social and economic state of the country plays a huge role in my thinking. My clientele aren’t the average consumer, but in many cases their clients and customers are. The flip side is this does present some unique opportunities for me for specialty applications reducing labor costs and improving customer experience.

Too many people point to the stock market as an indicator of how well the overall economy is performing. And while over the long term, stocks perform based on the performance of the underlying company you can have extended periods of time when there are disconnects. For example, you can have a company that has increasing profits not through increased revenue but cost cutting by various means. If the cuts adversely affect their customers the company can end up in a spiral downward.

But what has driven the current stock market performance is speculation on companies’ future performances. Traders can do this because their cost of capital is exceedingly low. The Federal Reserve has not increased rates in a decade. While it looks very likely they will raise rates next month, it will only be 25 basis points. Hardly anywhere near where the rates should be by now. It will be interesting to see how the market digests the coming increase and how it digests the likelihood of future increases.

The central question is how does this affect little old me as 2016 starts?

I see opportunities for growth of my practice in short term projects. In the past, I’ve preferred to have at least one longer term project and several short term projects. I see that changing. My goal for 2016 is to focus on quicker projects, probably mobile apps, probably with more revenue sharing and lower upfront costs to the client.

Which leads me to my next area of change I see. Typically, my projects have been simple tell me what you want, I’ll build it for this price, let me know when you want me to do some changes and oh by the way, here’s the invoice for my fees. In 2016 I will be doing it differently.

I will be seeking projects where I can offer reduced development costs in exchange for a share in the long term revenue stream. I am looking less and less to be a gun for hire and more of a partner for hire. There are still aspects to work out but the biggest plus for me is I will be much more selective in the projects I take on and keep. Those offering a long term upside will win out over those where the client is just looking for a contract resource.

Looking at all of this, the biggest change to my long term plans is I doubt I will start hiring in 2016. I need to perfect my project selection criteria and given the business model I am building, substantial reserves are needed to fund adding an employee. It will all be worked out or I will realize this business model is not sustainable and I will adjust.

Test small, fail small, build on what works.