Ask me about Unit Testing and I’ll probably say, “nice to have”. Unit tests are very nice to have … but sometimes the project schedule doesn’t include time to build the unit tests — which often take nearly as much time as writing the functional code. But when I have time, I really like good unit tests.

I’ve never found a PHP unit test framework that I like, so I roll my own. It’s evolved over time from “call functions and see if they fail” to “test all scenarios and track complete coverage”. Here’s the basic framework I use:

All PHP files can conduct their own unit tests by simply executing them from the command line, e.g.

With iOS 8, getting the right launch screen has become a real pain. If you support only iOS 8, and you don’t need iPad, or everything is Portrait or some such, you’re fine.

With one of the apps I work on for Five Pack Creative, I need to support Landscape-only, iPad and iPhone, iOS 7 and 8. And man, getting the Launch screen correct has been tough. There are several choices — launch image catalogs, a launch nib/xib, and launch filenames. For Landscape, both types of device, both iOS versions, I’ve only found one approach that works for sure.

First, for iOS 7, you need to use the filenames approach. If you have any entries in your Info.plist related to launch screens, delete them. Just use the standard filenames.

Don’t use an Asset Image Catalog for iOS 7!! Just create a folder, then add those screens to your project, creating a Group for the Folder as they are copied in. The folder will be created under your project. This is IMPORTANT — don’t just drag in individual screens. It’ll work, but not when you have another target, e.g. a free version and a paid version of your app. You’ll need the exact same filenames with different images for the various versions of your app. Putting them in differently-named folders before adding the entire folder (and create a group) works best. DON’T use Folder references — iOS can’t find your launch images if they are under a folder reference — it must be a group.

Now, for iOS 8, you’re going to use a Launch.xib file and asset images. I’ve seen places where people assert that you can use filenames, manually editing your Info.plist. I guess that approach works for them, but I couldn’t get it for my specific situation. Using their solutions prevented iOS from properly detecting an iPhone 6 — it ran it in scaled iPhone 5 mode.

Create a new launch screen (File, New File, User Interface, Launch Screens). Add that to your target settings (Project, Targets, General, Launch Screen File). Select the XIB and add an ImageView to the View. Size it to match the View, then make sure you have the proper Size Class selected before adding Constraints. You want Regular/Regular (iPad Landscape).

With the ImageView selected, select the class using Editor/Size Class/Regular Width/Regular Height. At the bottom of the Interface Builder screen, you should see “wRegular hRegular”, indicating the size class you are editing. Add the constraints by Ctrl-Drag from the ImageView to the View. Hold the Shift key to select multiple items — Leading, Trailing, Top, Bottom. That should create your constraints with zero as the constants. Don’t worry about the View (frame) height and width — your size class images will take care of all that.

So now you need images for your ImageView. You are going to use some of the same ones. First, if you don’t have an image asset catalog for your specific target, add one (File/New File/Resource/Asset Catalog). Add a new set (click the + button) and call it Launch.

Okay, now for the really cool part, and where it all comes together easily. When you added the Launch image set (not to be confused with a Launch Image Source setting in your Target — we could have called it “Monkeys” instead of “Launch”), you’ll see 3 spots for images (1x 2x 3x) and underneath, “Universal”. Over on the right sidebar, you should see Devices, Width, Height, etc… Change Devices from Universal to Device Specific, and select iPhone, Retina 4-inch and iPad. Change Width to Any & Regular.

Now you should have two sections: iPhone and iPad, and two rows of boxes.

I enjoy watching “reality documentaries” such as Alaska: The Last Frontier, Mountain Men, Yukon Men and Ice Lake Rebels. But I really don’t like “fake” shows, especially when they go out of their way to seem real.

That’s why I stopped watching Dual Survivor. Without Cody Lundin, the show lost its credibility in my eyes. I usually watch a show or two, then do some research to find out how legit it is.

Alaska: TLF and MM are, as far as I can tell, solid and real. I haven’t researched Yukon Men yet.

Today, I researched Ice Lake Rebels. The first thing I checked was the “remoteness” factor. The show portrays the people as far from civilization, far from help and resources. I was disappointed to see that they were within walking distance (or rowing if the lake wasn’t frozen) of a fairly large city. They can probably hit the Canadian equivalent of a 7-11 for a box of Twinkies. Check out the picture below – that island at the top right is the one on the show.

The city of Yellowknife is right there. In this case, I don’t think less of the people on the show, unlike the apparently very fake and scripted Alaskan Bush People. But I do think that the producers are being a bit deceptive. Some shots are high views of the island, and the developed mainland next to it are blurred, obscuring the docks and boats and buildings.

That’s NOT good television… but I am still watching the show. The Rebels clearly face some real dangers and some tough conditions. But I’m watching a bit more… skeptically than before.

EDIT
I did quit watching quite a while ago. It took a couple more shows for me to decide Ice Lake Rebels most likely wasn’t real.

I think scripted reality shows belong on network/dramatic television, NOT on purported “science” channels like Discovery, History or TWC. ILR has been replaced with Prospectors on TWC for me. 🙂

I’ve been driving organizational change in Scrum implementation for more than a year in two companies, and I’ve reduced the focus of change to 4 steps. And in keeping with Agile principal #10, I won’t be writing a long preamble :-).

1. Effective Scrum Masters

A Scrum Master is a process expert, a coach, a disciplinarian, and great at managing their own time. If you want to know if a person will be a good SM, look at their Inbox. Is it one or two pages, or is it a hundred pages with thousands of unread messages?

My time management process can be boiled down to just a few principals and techniques:

24 hour response on all emails

If it’s read but still in my Inbox, then I have an action to take

In meetings, my notes will result in actions: either paper notes with a ☆ star, indicating something to do, or electronic notes that I email to myself

Schedule a no-duration appointment so that I am reminded of actions to take

Using this technique, I’ve kept my Inbox clean, my notepads blank, and an expectation with my colleagues that I respond in a timely fashion to questions and requests.

Your Scrum Masters must be effective time managers. They are responsible for coordinating Sprints and ensuring planning gets done correctly. They must track implementation of retrospective items. They need to make sure dependencies are resolved, schedule Sprint Review/Demos far in advance. And they are often doing it for multiple teams, or otherwise doing other project work of some kind.

Your Scrum of Scrums Master must be an expert at this, coaching and keeping watch to ensure the Scrum Masters keep up with the work.

2. Principled Scrum

Organizations are different. Their needs vary. Managers want different types of information, results, and plans. Some people will be all for Scrum, others will resist it. You’ll have Q/A on your teams… or maybe not.

It’s okay – adjust how your organization implements Scrum, vary from the “orthodox” methods — but never compromise on Agile Principles. Your Scrum Masters need to know the Agile Manifesto and the 12 Agile Principles. That way, whenever a change is suggested or challenged, you can check it against Agile. Changes are fine, they’re great, they’re desired and expected: just don’t compromise on Agile or you’ll end up back where you started.

3. Acceptance Criteria is King

Nothing slows a team more than stories that lack good acceptance criteria. For the teams I coach, I have one test I use to see if the acceptance criteria is good:

How will you know if the developer did the work correctly?

What, exactly, are you going to do? What will you type/run/examine? Can you actually DO the test, or does it require other steps not in the story?

If you, as a Product Owner, as a Developer, cannot absolutely show that the story is working, by executing the steps in the Acceptance Criteria, then it’s not a Done story, and/or the acceptance criteria is flawed. Here are some flawed acceptance criteria items that I’ve seen get into a Sprint:

As a Thing, I get built

As a Platform Feature, I get refactored

As an Engineer, I researched and documented a design

Code is written and reviewed

Your acceptance criteria should be detailed: enough so that a developer can execute it or a tester can run it. Browse to the site, enter login credentials, click on the new feature, shows the new stuff. Without this detail, engineers cannot create good definitions of done and the team cannot estimate the size of the story. And worse: developers and product owners will have meeting after meeting to understand what needs to be Done.

4. Interfacing with other teams

Probably the biggest challenge I’ve seen to date is figuring out how to work with requirements outside of your own Scrum team. Within the team, it’s pretty simple to setup priorities for stories: just get them into the Sprint in the right order. It’s easy to track dependencies on stories: you know every day at the Daily Scrum whether there’s a story or task at risk. But what about between teams – both other Scrum teams and non-Scrum teams?

I call this Dependency Tracking. Or sometimes Dependency Management – something with the word “dependency” in it. Other teams have dependencies on you, and you have dependencies on other teams. Stuff they need to do must get done in time for your Stories, and vice versa.

There are three steps to perfect dependency tracking:

Dates: Every request, every dependency must have an actual date : When will it get resolved? When can you give me a date that it will get resolved? When can you give me a date where you’ll be able to give me a date? Never accept anything other than a solid date. And don’t accept dependency resolution dates too close to the end of your sprint. Aim for the middle.

Tracking Tickets/Tasks: Even when you are given a date, don’t absolutely trust it. Create a tracking task or story that’s due just before the dependency, and put it In-Progress: that way you’ll see it at every Daily Scrum. A tracking task is basically “Make sure that X dependency will be resolved as promised on mm/dd.”

Proactive Communications of Changes: Your team will often be a dependency for other teams: you must make sure that anyone dependent on one of your stories gets notified if you aren’t going to make your committed dates. As a Scrum Master, you need to track which of your stories are dependencies, and when they are expected to be Done. If they aren’t going to be Done by the committed date, inform the stakeholders! Stuff happens, people understand that. Let them know if a ticket will be late, and give them the new date. That way everyone has an opportunity to re-prioritize and ensure their teams aren’t sitting around blocked by your dependency.

As I’ve worked building the Cartera OfferLink app on iOS, I’ve learned a little about Apple’s Push Notification service. One thing that I wanted to do from the start was avoid sending a notification when someone might be sleeping! Every once in a while, I’ll get a text message early, like 6am. I’m a late sleeper, and the BUZZ! that my phone makes will always wake me.

I really don’t like that.

So I decided early on that I’d do the best I could to avoid sending messages at inappropriate times. I know you can change your phone settings to avoid notifications at certain times, but the default – and most folks devices are set to the default – is to just deliver the message when it arrives, buzzing and binging and waking you up.

What I did with OfferLink is send the current time, local to the phone, to the server, along with its data requests. Then I calculate the seconds offset from the server and the phone’s time. This gives me the current time zone of the phone as of that request.

It’s not a perfect system – the user could fly around the world to a different time zone, and get a notification before the app refreshed its data and told the server its new time zone. But it should be a good 80/20 solution – solving for 80% of users.

Thought I’d take a second to recommend Blitz.io – a cloud service to load test an application or API. I found it via NovaNet after a quick Google search. (Note – I’m hoping for some free extra credits at Blitz indicates they’ll give if you blog about them.)

But hey, I might have blogged anyway – it’s VERY cool. I was able to immediately test my API and get a response time and likely capacity.

So I signed up, then ran a few more tests. I modified my app slightly to accept recognition that it was being hit by a load test, so that PUT data to my REST API would go into development database rather than my production DB. It took maybe a minute or two to update, and BAM – I could run a quick (free) load test of 10 users for 6 seconds.

Neat. I’m waiting for a company response to see if we have a load test mechanism. If not, I’m going to let our enterprise operations team know I’m going to load test, get a good time to run it, and just nail the server and see how it does.

I remember writing my own load testing application back in the day, and now I’m happy to highly recommend Blitz.io – it’s an Easy button.

Every family has its customs, from eating dinner at the Outback Steakhouse on Sunday nights to the family vacation trip during the summer. There are special rituals that stand out in my memory: the coming of age ceremonies that transformed my cousins and me from boys into men.

My grandmother’s farm was the focus of the family while I was growing up. We’d visit almost every weekend, often staying the night during the summer. Their property and surroundings were in Midland, Texas, near the outskirts of the city. Oil pumps and mesquite bushes dotted the dry, dusty landscape. Randy and Ronnie, my two closest cousins, lived nearby. It was our Adventure Land and could easily rival staid, packaged and sanitized parks like Disneyland.

There we would find snakes, mice, jackrabbits, and our favorite: horned lizards. We called them horny-toads, and they were all over the place in West Texas. I’d put one in my pocket and it would kind of flatten out. They aren’t fast like other lizards, so I could easily catch them. Grabbing one of these was brave when you were only five years old. I’d carry them around for a few hours and let them go.

Grandmother’s house had this rock and weed garden in the front where the horny toads could be found. They also owned wide swaths of land around their house. I remember cows, a few horses, some chickens, a mean old bull and lots of alfalfa. That’s what they mostly farmed: alfalfa. My cousins and I came to know those fields very well. We would be assigned the task of moving the irrigation pipes during the hot summer months. They just lay on the ground, so we’d have to move them from one part of the field to another. That was a real chore. I’d remove the connection collar, then slide the big pipe out. The pipes were twenty feet long and had a nine-inch diameter. They weren’t too terribly heavy – at least I didn’t dare show they were heavy in front of anyone. One of us would pick up an end to dump out the water, and possibly dump out any rabbits that may have wandered into the nice, cool, water-filled pipe. We’d carry the pipes about fifty yards to a new spot and hook them back up, then walk back to the next set of pipes and do it again. Over and over. Hour after hour. All three of us were about eleven years old at the time, and it sure seemed like a lot of work for a couple of silver dollars. We were happy to do it: you knew you were “growing up” when grandpa invited you into his truck for a day in the fields.

Once all that alfalfa turned into hay bales in the fields, I worked hauling it onto a flat bed. Attached to the trailer was a hay elevator. It picked up square bales of hay and carried them way up in the air where they dropped out of the top. Sometimes they became stuck in the top. I’d pull them out with big hooks that resembled the ones used by that homicidal rain slicker slasher guy in I Know What You Did Last Summer. I’d stack them neatly on the trailer, hour after hour, layer after layer, until I was perched on top of five layers of hay bales on a rickety, swaying flatbed and hoping not to fall into the hay elevator the next time the wheels hit a bump.

Near the fields were some rent houses that my grandparents owned. At the end of the block was an old fireworks stand that we would operate around the fourth of July. It wasn’t a big stand: not much demand for fireworks out there in the sticks. What was really cool was to light a bottle rocket and hold it until just before it went off, then toss it high into the air. If I timed it right, the rocket would gain extra altitude from the boost. If I didn’t, the rocket would be pointed randomly at the dry grass, someone’s car, the house, or the person who threw it into the air. Then there was a mad scramble to avoid the widely careening firework before it exploded. I don’t think we burned too many things down.

Grandmother’s house needed burning down anyway. It was built in the 50’s, but it wasn’t vacuumed until the 90’s, if then. The pipes were almost totally corroded away from the super-hard water. I think they pumped it straight out of limestone or something. We didn’t dare drink the stuff. Using it to brush your teeth was torture enough. I’m not sure if I got cleaner or dirtier taking a shower, but I certainly gained a nice, shiny coating.

The backyard wasn’t any cleaner. There were random holes, snakes, flies and bits of unrecognizable metal lying around: farm implements that had seen better days. The fence was made of concrete blocks but it had no top. That made for empty holes where the blocks were with unknowable creatures living inside. Only the bravest of us would dare to walk on or near that fence. There was a rickety old wooden gate at the back. It led into the barnyard and the fields beyond. Sometimes the bull would get into the yard. I think. Maybe that’s just vivid nightmares of the bull getting into the yard or something, but I know there were bees around the side, near the extra front porch. If you had to mow over there, well, just make sure you were a fast runner.

On the opposite side from the bees and way in the back, there was a big hay barn. When we were old enough to go exploring on our own, probably about twelve, we could walk through the field with the bull to go play in the barn. I’d stay close to the fence, but there was a problem with that strategy. The entrance to the barn faced the road, and we came up on the backside of the barn. Therefore, I had to either risk the run in the field with the bull or else climb over the fence. The climb wasn’t a big deal; it’s where I was climbing to that was the problem.

Bees. Lots of bees. Hives of bees. They were kept at the end of that field behind the barn. I guess they helped pollinate the fields of alfalfa. Maybe that hive on the side of the house was founded by Columbus Bee. All I knew back then was that: 1) Bees made honey, and 2) Bees stung little boys. However, they were near the hay barn, and although it was a good walk from the house, it was fun to play in the stacks and stacks of hay. It was also the shortest path to the gravel pit.

After working in the fields all day, we’d go down to The Pit and play around. It was big, probably a football field in length and forty feet deep. It had a mucky, yucky, water-filled end where we would swim, usually with cousins and sisters from five to fifteen. We had to wear these ratty old shoes because the bottom of the “pond” had the sort of trash you’d expect in a gravel pit: old tires, rusting re-bars and other pointy, infectious objects. There was a sort of platform (too generous to actually call it a “dock”) on one side. It was just barely possible to jump off and sort of dive into the water, but we first had to walk around out there to make sure we wouldn’t impale ourselves on something. Usually we had to aim to the side to avoid hitting an underwater obstacle, and it seems like only we twelve-year-old boys made that leap of faith. The water was only about four feet deep, and we couldn’t see the bottom.

All of these adventures helped shape the boys in our family, but there was one final exam before you could say that you ran the gamut and survived.

Grandmother’s house was near, way too near, a sewage treatment plant. When the wind was just right, which was all too often, the smell would waft over the house and fields. We boys were drawn to that place like flies to carrion. We just had to go see what a sewage treatment plant was like. It was at the outer edge of walking distance, just past one of the fields and across a highway. I don’t know why the plant drew us, but draw it did. We would talk about it almost every weekend.

“Let’s go to the plant!”

“Nahh, I saw a truck and a bunch of people when we came up. They’re doin’ somethin’ over there.”

“Let’s go see what they’re doin’!”

And so the dialog went, always discussing but rarely taking the chance until the need to visit overcame the obstacles of distance, highway and danger. First we’d plan the attack.

“Right after lunch,” I’d whisper to Ronnie, “We’re goin’ to the plant.”

“What are we gonna tell Mom?”

“Nuthin’, let’s just go to the other block and play around. We’ll head off down the road when the coast is clear.”

“I’ll tell Randy.”

It was rare that we’d attempt the trip when the wind was blowing the stench across the farm. It couldn’t really be that much worse close up, right? We’d work our way toward the plant, down the road and across the highway. It was at least a twenty minute walk. We ignored the “Keep Out!” signs and clambered over the low fence to stare at the pools of ooze before running out of stench range.

This was the pinnacle of our coming of age rituals: visiting the sewage plant and getting the blast full on. It was our final family test of manhood.

I’ve been on a few Scrum teams now, the latest with my current Intuit Hosting Engineering (HE) position. HE is doing Scrum well, implementing almost all of it as far as I can tell. I recently took the training to be a certified Scrum Product Owner – one of the three primary Scrum roles. It seems like this is what was missing from the Innovation Lab (iLab) processes we used – the “what came next” part that was always a challenge for us.

In the iLab, we had an unmatched process for discovering innovative solutions for tough problems, and getting quickly to the minimum viable feature set. What was tough was then transitioning that to a business unit for development and launch. Scrum takes care of that part of the process.

What we needed was a feature set that was described in terms of User Stories, detailed deeply enough for a development team to estimate in terms of relative development time (story points). The User Stories would be more than just the minimum viable, getting us over the hump of disbelief on the part of the business – disbelief that the product had enough features. The “minimum viable” would simply be the highest priority user stories, and the entire set would be in the “backlog” – all of the known user stories in diminishing detail.

The cost/time of development would be established if you already had a Scrum team, but it only takes about three Sprints – 1 to 4 weeks – to establish a baseline “velocity” for a new team. Velocity is a simple measure that indicates how many story points that a team can accomplish in a given sprint.

When a team follows Scrum, they can become hyper-productive: teams that quadruple their velocity compared to their first sprint. There’s apparently two simple things that get a team to this measure – a backlog that has very well-defined user stories and an automated build that includes automated testing.

I think there’s a trifecta here that, when combined, would be a simple but effective way to make a successful idea into a successful business: front end innovation (iLab style), with lean startup-mindset prioritizing of user stories, developed by a Scrum team.

It’s finally here (or at least it’s in the App Store awaiting review)! This is the Super Conversions (aka SuperConvert) that I’ve always wanted to develop. I had some time, so I coded almost non-stop, and it’s ready to roll. This is a fully functional calculator, with Memory, sin, cos, Pi, tan and other useful functions. See the calculations at the top and the unit conversions at the bottom, with easily selected conversion categories and units. Copy either the calculated value or the converted value.

If you have a support question on this or other SuperConvert or Super Conversions apps, please post a comment below or @Super_Covert on Twitter. There are also “conversion facts” that show up every once in a while. If you have a fact you’d like to see in the App, tweet it to @Super_Convert and I’ll add it to the list. Include a link to an image if there’s an appropriate one for the fact. Note that all facts are moderated.

The design of the new SuperConvert 9.0 is actually based on an old calculator I’ve had for about 28 years. The solar powered device still works, and it’s still the primary calculator I use at my desk. Check out the picture of the app and compare it with the picture I took of my calculator. I used that picture to design most of the visual elements of the app.

If you have any support questions, or features you’d like to see, bugs to report, etc… – please post a comment below and I’ll get back to you.