- When a test is especially short or simple compared to the application code it tests, lean toward writing the test first.
- When the desired behavior isn’t yet crystal clear, lean toward writing the application code first, then write a test to codify the result.
- Because security is a top priority, err on the side of writing tests of the security model first.
- Whenever a bug is found, write a test to reproduce it and protect against regressions, then write the application code to fix it. Lean against writing tests for code (such as detailed HTML structure) likely to change in the future.
- Write tests before refactoring code, focusing on testing error-prone code that’s especially likely to break.
This is why I stopped using my State Farm Visa. They just shut my card off on my last trip– and called me a few hours later. This text message arrived within 10 seconds of my transaction.
Best “bug release” notes ever. #theyhavekidstoo
- Amazon Instant Video App
Please and Thank you.
Update: Released December 2017. Finally.
Today is the first day that I have an application available in the Apple app store. That means I actually “shipped” something. Pause for dramatic effect.
Learning to program in Swift has been fun, but challenging. All of the programming I have done in the past has been procedural in languages C or Pascal. But, it’s past time to update my skills and start thinking in objects.
After attempting and deciding the iTunes U Stanford Class, is too advanced for me, I joined Treehouse at end of September and have worked through their Swift and iOS tutorials. So far, so good. The slower pace and hand-holding is nice.
Am I on the road to be an Independent iOS Developer? No plans for that, but I am going to finish the Treehouse tutorials and see where to go from there.
Update: A good exercise, but the app was removed when pastie was shuttered.
I love the idea of a better way to input text on my iPhone. I celebrated when Apple announced alternate keyboard support last year with iOS 8. I was finally going to join my Android colleagues in swiping bliss1. There are so much better ways to input text into the iPhone than that traditional keyboard. I love inputting text with swipe keyboards2 and am constantly amazed at how well it does. But I don’t use them. Here’s why.
Flakiness. Many of the third-party keyboards are unreliable. I switch apps or use the launcher to find another app and things don’t work right. There is a several second delay or I don’t get a keyboard at all. I must admit that the flakiness has improved significantly since launch, but I still have problems. It also seems to vary by the developer.
Globe Button Position. How hard is it for alternate keyboards to put the “globe” icon in the same place and do the same function? It should be on the bottom row, the second one from the left and take you to the next keyboard. Simple. Easy to go through them quickly. But no, Emoji++, WordBoard, Switftkey, and Swype all have different ideas about the placement and the function of the globe key. Developers, please don’t be creative here!
Emoji Integration. I love Emojii++ by David Smith. His Emoji keyboard is easy-to-use, stable and much better than Apple’s solution. He doesn’t put the globe button where I would prefer, but I deal with it. What does bother me that I don’t want to switch keyboards to use Emoji. I only use a handful of Emoji and would like them integrated into my text input keyboard. I like how Swype suggests an emoji for the word– easy to use. I also like how SwiftKey makes a button to access emoji similar to accessing symbols. Good ideas.
Space Bar. Not a must have, but nice and preferably in the standard position. Phraseboard didn’t have one and I missed it.
Dictation. And finally, the biggest problem and the one that cannot currently be solved. Apple does not give third-party keyboards access to this iPhone function. Hopefully, a future iOS release will add the dictation option to other developers.
So now what? I have to have an alternate keyboard to use emoji and the standard keyboard for dictation.
My current solution is to use WordBoard as my second keyboard. It is a keyboard of “one-click shortcuts.” As shown in the picture below, I have set up three types of shortcuts on my keyboard– form fields, emoji, and hashtags. For example, when I press “fn”, it types “Ben.” It doesn’t give me full access to all the emoji, but I have created shortcuts to my favorites. I have been using WordBoard for over a month and passes my sophisticated not-as-flaky-as-others test.
Improving WordBoard. There are two improvements that I would like to see. First and most important, I would like categories like Phraseboard. Second, I would like to see the regular keyboard improved. It recommends that you don’t use it, but since it’s there, it would be nice if it were at least as good as the default one.
I like the idea of alternate text input methods and look forward to seeing what developers come up with this year.