Regular Expressions May Be The Most Powerful Dev Tool I’ve Ever Learned

Posted on by

I started programming in 1986 when I got my first computer at age 13. It was an Apple IIc and the primary language on that machine was BASIC, so that’s what I learned. I exclusively programmed in BASIC until 1989 when my high school got Macintoshes and we spent the next two years working in Pascal.

When I graduated from high school I stopped programming for a few years. I started again in 1994, the year I moved to Oregon, and programmed steadily until 2001. In those years I learned C, a little assembly language, a little Microsoft’s foundation classes and finally Palm OS’ libraries. I also worked in BASIC for Excel and Access.

In 2001 my development team kicked me out of the dev room and told me to go focus on the business, which I did until the company shrunk again and I had to write code. That year was 2007. I learned Java and the Blackberry OS’ libraries, learned Ruby and Rails, and then got back into C development, this time with iOS’ libraries and Objective-C. I focused on Rails and iOS for the next few years before I started learning Javascript last summer. In the last year I’ve written more Javascript then Objective-C.

I left off one “language” that I’ve learned in the last year, probably the one I find most powerful and flexible: regular expressions. Regular expressions, or RegEx for short, is a way of finding and pattern matching text. It is unbelievably powerful and fairly easy to learn the basics. I thought I’d learn a little RegEx, use it a little bit, and never really need it again.

Not only does it turn out that Equals uses them constantly, I’ve also found other uses as well. For instance, my daughters’ school needed some content extracted from email messages. This task would have been impossible without regular expressions, and was so thankful I knew them before I started.

The book I learned with is Mastering Regular Expressions by Jeffrey Friedl. I also use a Mac app called Oyster, which allows me to write expressions, set up tests so I can verify that my changes work, and then copy my RegEx to the clipboard in one of 12 different languages that supports regular expressions.

If you write code or process text and haven’t spent any time learning RegEx, I highly recommend it.

 

The Equals Story: What’s Taking So Damned Long?

Posted on by

I’m experiencing a writing drought right now of proportions never experienced before. I love to write and yet the last month or so has been like pulling teeth to get anything down on paper, if you will. I realized that at least part of that is because I have always been reticent to dive into the weeds on what we are working on, mostly because I, for whatever reason, think it will scare all of you away.

Well, too bad. If you leave you leave because we are deep diving now, my friends! I’ve decided to write a series of posts on the thoughts and decisions behind Equals. I’ll make sure it is noted clearly in the title so you can ignore these if you prefer.

The concepts behind Equals came from an app my partner-in-code Rick Huebner invented in 1998 called MathPad. The concept was simple: what if the calculator was a piece of paper that you can write text, equations and variables on, then hit a compute button and it would fill in the missing values? It was a positive little seller but it had very small revenues compared to powerOne and we shelved it soon after Rick came to work for me in 2001.

It sat in holding for 10 years until it was brought up in 2011 in a multi-month exploration of new ideas. By 2011 we had already been selling apps in the iOS App Store for 2+ years and it was clear that selling productivity apps at $5 per copy was never going to make us enough money to even be in business, let alone support the two of us full-time. So we started hashing around for new ideas, still based on spreadsheets and calculators and numbers, that we could develop. We came up with a dozen ideas, built a few prototypes and started testing. Equals, which we were calling MathPoint at the time, was the most interesting and compelling of these partly because of its connection to our existing powerOne customers.

We spent months using MathPoint ourselves and with a few close friends of the company. We began to refine it. We eliminated all of the syntax complexity of Rick’s MathPad, we expanded variables to include numbers and spaces, which made them feel much more natural. We went from purely text-based notes to include formatting and started playing around with how to do that on iOS and the web. We even moved from an iOS-only app to a sync-based system to a web-first application. Refining and simplifying took forever. We came very close to releasing apps a few times but backed off for one reason or another each time.

Our momentum on the project was slow. Throughout we had two core problems: 1) we were moving more and more toward a web-based product as a starting point; and 2) powerOne was/is making so little money that it wouldn’t support even one of us full-time. So we took the value we had — iOS development experience and a well-regarded product — and sold those. We received a number of custom development contracts over the last couple of years, all of which kept us in business. Our income went from 100% product to 70% custom development work but we also had profits for the first time in years all while paying ourselves a break even salary.

As mentioned, though, our philosophy about where to release the first versions of Equals changed as well. We went from an iOS-only app to an iOS app that leveraged the web for syncing only to a browser-based app. I hope to get into this decision later but for now understand that at the time we made this decision we had very little experience with browser-based, HTML5 apps. We had worked with it a little in the iOS app, but very little.

So we got a development contract that basically paid us to learn HTML5. While the project was a huge pain, we were able to learn rudimentary skills and it brought us enough money to give us a window of development in the summer and fall of 2013.

We thought we were close. We reached out to some of our existing powerOne customers, getting them all excited, when we thought we were within a month of shipping. Unfortunately the window collapsed. One reason was because we had some health issues that our now dealt with. Another is because getting a releasable version turned out to be far more complex than we ever anticipated.

The window closed. By the fall of 2013, we were again running out of money. We closed more contract deals and focused exclusively on those. By early 2014, though, we had stockpiled enough money again to focus full-time on Equals. In fact, we have now stockpiled enough contracts and deals to likely need no contract work until the end of 2014, our longest window to focus exclusively on Equals (and get paid) in a very long time!

As we’ve been head’s down now for more than two months on developing a web-based version of Equals, we are finally getting very close. It has been interesting, though. Sometimes we think we are closer than we are and sometimes we are battling the technology for weeks on end trying to make it do what we want and sometimes we head down a path only to realize, after getting 95% of the way there, that it was absolutely the wrong technology or process.

It turns out the devil really is in the details. The amount of spec writing I’ve done in the past few months far exceeds the design work I’ve done in the history of the company, and of course every time we make a change it has ripple effects through the code. Add to that our relative inexperience with HTML5 and our time estimates have been way off.

Anyway, that’s enough for now. All I can say for certain is we are (finally!) very close. Yesterday I pushed to the live server our first partially working version and hopefully the remaining handful of missing pieces will lay in quickly over the next few weeks. The learning hurdles should be behind us now as we have the basics of the technology working. We need to finish up the last missing pieces and test and test and test.

Our goal is to roll this out slowly. We have never had to worry about server load before and we have never had to worry about client-server interactions and all the unknown unknowns that go with new technology on a new platform in a new environment. I’m also worried about the rudimentary nature of Equals. It is so early and there is so much to do. I hope Equals isn’t too far down on the minimum viable product curve.

I can’t wait to share it with you, though. It has been a slow train coming.

—

Would you like to know when Equals is ready? Tell us. Your email address stays between you and me.

 

Managing Risk

Posted on by

I’ve spent a massive amount of my time while running Infinity Softworks managing risk. In this case I’m talking about business and technical risk. When do I count revenues? How reliant am I on a partner? How reliant am I on a technology sticking around?

Sometimes I’ve been good at this. I’m conservative about deals, for instance, never adding cash expectations to my budget until the contracts are signed. Sometimes I’ve been bad at this. We were extremely reliant on Palm in 2004 and didn’t even understand how reliant we were. When the relationship failed 70% of our revenue disappeared at the same time.

Yesterday App.net announced that renewals didn’t meet expectations and that the product would continue but that the team developing it would no longer be full-time. Development would be open sourced.

This doesn’t bode well for those that rely on ADN for log in and syncing services, the developer back-ends. If I did, I would be looking for an alternative right now. In managing a business it seems that I am always surrounded by risk. My goal is to minimize it as much as possible where possible.

This is one of the reasons we don’t do log ins with Facebook or Twitter or Google. This is one of the reasons we prefer to manage our own servers. This is one of the reasons we have multiple revenue sources. As I was planning Equals one of the things I thought about was all of these risks. It is one of the reasons we chose to develop the web version first and mobile-specific versions later. Relying on Apple, Google, Samsung and Amazon to provide us customers is dangerous, especially if we factor in the rules that go along with participating in someone else’s store.

Honestly, it isn’t possible to get rid of all risk. But it is important to consider which risks are worth taking and eliminate all the rest.

Programming Sucks

Posted on by

Incredibly hilarious rant (especially if you are a programmer) about how ridiculous writing code is. One of my favorite snippets:

The human brain isn’t particularly good at basic logic and now there’s a whole career in doing nothing but really, really complex logic. Vast chains of abstract conditions and requirements have to be picked through to discover things like missing commas. Doing this all day leaves you in a state of mild aphasia as you look at people’s faces while they’re speaking and you don’t know they’ve finished because there’s no semicolon.

 

The Leveling Off Of iPad Sales

Posted on by

There has been much discussion this past week about the leveling off of iPad sales. From Benedict Evans’ excellent article on the topic:

Tim Cook also explained it on the earnings call: a channel inventory problem.

Fred Wilson asked about whether focusing on tablet sales is the wrong thing to do, and is going to recommend to his portfolio companies to focus on smartphones. Fred later revised his response by saying a drop in tablet pricing may change all that.

Personally, I think the smartphone growth rate was a strange beast because it was built on top of the feature phone business and subsumed its market. The world was already carrying a phone and we used those phones for communication: voice and text messaging. So when we bought smartphones, what apps really helped make it take off? Voice and text messaging. So Twitter took off and Facebook and Instagram and WhatsApp and Line and a bunch of others that are communication platforms. The phone itself was used before for communication and is used still for communication. At its core even Uber is a communication app, or at least that’s where it is revolutionary. A private car paid for with credit card isn’t. It’s the idea that you can do it from a phone and see where your driver is.

What’s the other use case that has done well on smartphone? Games and entertainment apps. These are easy to explain, too. I’m bored, need instant entertainment, and that phone is already in my pocket. My point is that there are long established use cases for the smartphone, a big reason is because we have been using them in a non-smart form for 15 years now.

What about tablets? The device is new. We’ve never had a highly portable piece of computerized glass before, with a day’s battery life, that’s light and compact. So what do we use it for?

I think that’s fundamentally what the slowdown in sales is about, not price. We don’t fully know yet. Yes, it’s an interesting reading device and I think that’s fueled a lot of the sales so far. But the best reading device is the one with us and that may very well turn out to be a 5″ phone.

Even look at the apps we use on them. Most are just slightly reconfigured smartphone apps. In other words, we haven’t really figured out yet what we will use these for, just like it took us years to figure out exactly what we were going to use the PC for. At one point there was a debate as to whether command prompts or GUI was better, too.

This isn’t to say that smartphones aren’t a good bet, just to say that I wouldn’t bet against the tablet. In some ways tablets are more interesting because each one of us has a higher likelihood of finding the business that helps sell tablets. I think the odds of that are less and less in smartphones.