Soul Happiness

This made my soul happy upon reading; it’s so easy to get caught up in our little world while designing new features on an old app or even starting a new app from scratch. Great read!

Much Ado About Nothing

Don’t you hate when you get those mysterious compiler errors that no one can seem to explain very well?

Or when Xcode simply starts behaving weirdly?

I had that going on this morning.

The scenario:

Coworker of mine asked me to screenshare so he could show me a mysteriously failing test. Turns out the failure was due to a change he’d committed and forgotten about. Ah, how wonderful git blame inside of xcode is!

I however, was seeing weirdness going on in my personal environment. Whether I was on his remote brach or master, whenever I ran the test suite, half the tests were never executing. They simply weren’t wired up in the scheme, which was very odd, because I’d put some of them there myself and watched them run like a well oiled machine. And according to the target membership of each file, they belonged to the correct target…that I was cmd + U’ing…

huuuuh? 

Then I removed a test suite that it was running successfully, and got an error very similar to this one:

IDEBundleInjection.c: Error 3587 loading bundle '/Users/achilles/Library/Developer/Xcode/DerivedData/SingularityOne-ffgvwdrrxrlnvbauqgmrebtgywsw/Build/Products/Debug/SingularityOneTests.xctest': The bundle “SingularityOneTests.xctest” couldn’t be loaded because it is damaged or missing necessary resources.
DevToolsBundleInjection environment:
XCInjectDiagnostics: (null)
XCInjectBundleInto: /Users/achilles/Library/Developer/Xcode/DerivedData/SingularityOne-ffgvwdrrxrlnvbauqgmrebtgywsw/Build/Products/Debug/SingularityOne.app/Contents/MacOS/SingularityOne
XCInjectBundle: /Users/achilles/Library/Developer/Xcode/DerivedData/SingularityOne-ffgvwdrrxrlnvbauqgmrebtgywsw/Build/Products/Debug/SingularityOneTests.xctest
TestBundleLocation: /Users/achilles/Library/Developer/Xcode/DerivedData/SingularityOne-ffgvwdrrxrlnvbauqgmrebtgywsw/Build/Products/Debug/SingularityOneTests.xctest
TMPDIR: /var/folders/zy/q51vhcf91xl5j47fxzm424pm0000gn/T/
DYLD_LIBRARY_PATH: /Users/achilles/Library/Developer/Xcode/DerivedData/SingularityOne-ffgvwdrrxrlnvbauqgmrebtgywsw/Build/Products/Debug
DYLD_INSERT_LIBRARIES: /Applications/Xcode6-Beta6.app/Contents/Developer/Library/PrivateFrameworks/IDEBundleInjection.framework/IDEBundleInjection
DYLD_FRAMEWORK_PATH: /Users/achilles/Library/Developer/Xcode/DerivedData/SingularityOne-ffgvwdrrxrlnvbauqgmrebtgywsw/Build/Products/Debug
DYLD_FALLBACK_LIBRARY_PATH: (null)
DYLD_FALLBACK_FRAMEWORK_PATH: /Applications/Xcode6-Beta6.app/Contents/Developer/Platforms/MacOSX.platform/Developer/Library/Frameworks


*** Test session exited(82). without checking in. Executable cannot be loaded for some other reason, such as a problem with a library it depends on or a code signature/entitlements mismatch. Retry after a Clean build. If you believe this error represents a bug, please attach the log file at /var/folders/zy/q51vhcf91xl5j47fxzm424pm0000gn/T/com.apple.dt.XCTest-status/Session-2014-08-27_17:38:33-kIEHCX.log

*courtesy of here, I didn't get my original error: https://github.com/kiwi-bdd/Kiwi/issues/565

After a ridiculous amount of time struggling with it, I restarted Xcode (6.2, thanks to travis, if you’re interested).

And ran the test again.

And all of them ran, like my over excited chihuahua when she’s given a new rawhide.

What.

Xcode, stahp.

Freak out!

There’s something very, very therapeutic in free time.

For instance, I’m very fortunate in that at the end of every sprint at my current company, myself and my coworkers are given the entire day to 1) finish up any stories that are outstanding 2) Improve ourselves as developer. 10% is the best thing ever!

This isn’t a new concept; in fact, according to this article 3M takes credit for starting this kind of trend back in 1948 with “15% time.”

Here’s why:

• I get the chance to recharge my creative batteries
• I get the chance to explore what others in my industry are doing. For instance, I had an app idea the other day, so I spent a bit of uninterrupted time digging around through others’ repos on github/the App Store seeing what others had already done on the topic in an effort to not duplicate what they were doing. Since I’ve been doing smaller, more locally focused apps as of late, I also had time do some research into what sort of content I could use for it; creating content takes roughly forever to do.
• I get the chance to catch up on tech news. I try and read the news several times a day as is, but it almost always pays to see what is going on in other sectors of the world too. After all, we’re not living in a sterile vacuum. We’re not confined to the size of our monitor screen in space.

So what normally goes into my 10% time as of late? Since I’m the tech lead on one of our projects, I usually end up spending a chunk of my day going through PRs for others, and trying to help out where needed on other parts of the development. Then, I spend the rest of my time working towards my side project latest goals. I usually have at least the seeds of at least two side projects in my personal backlog that I usually want to do a bit of research and playground-ing on. It’s a nice break for the next sprint.

There’s so much in the world around us to draw inspiration from! So bring it!

Travailing with Travis

Recently one of my projects at work has been implementing and customizing Travis to fit my company’s needs.

Let me first vent my feelings by saying: Ew.

I’m not a huge fan of Travis, but I’ve spent enough time with it that I can say that I’m fairly comfortable with the basic set up.

Useful link:

• Travis CI for iOS – Hands down the one link that helped me a ridiculous amount in getting the initial set up.

I’ve since been in the thick of implementing a travis job that runs in project test suites and deploys to hockey app as well as notifies hipChat of the status of the build for both Swift and Objective-C. There are a few interesting additions I would add to the above link if I had to recreate a similar tutorial from the ground up.

First:

If you’re charged with getting a continuous integration environment going, as part of the setup in the .travis file before the before_script section, be sure include a specification of the osx_image that you will need to use. This will have to be xcode 6.1 and higher. So for instance, in my setup for a swift project, I added this line:

osx_image: xcode611

It is interesting to note here that one of the concerns I have with Travis is how quickly they tend to update the availability of their osx_images. For instance, Xcode 6.3 beta was released back in February of this year, along with Swift 1.2, but the image is not available for Travis to build with to the date of the writing of this post. This of course means that we cannot upgrade our projects to Swift 1.2 yet, without switching off of Travis completely. Similarly, the actual version of Xcode 6.3 was released earlier this month, and the image still has not been released, although there are promises to this affect floating around various github issues. Bottom line: we’ll see.

Second:

Keep all your scripts as separate as possible. I know it seems rather weird to have about 15 million scripts that the .travis.yml is running, but trust me, the more scalability you have, the happier you will be in the long run. For instance, I went through the setup in the previously linked blog post, and while it was all well and good, as soon as I got one project running, I had to turn around and run the same kind of set up only for an  obj-c project that was running multiple targets for multiple products. Double the fun! What I ended up doing, rather than having lots of forks in my code based on product and target type was to have separate scripts per target that were called from the .travis.yml.

For instance, in my .travis, I have a script that runs after the product is built that deploys an artifact to hockey app and notifies hipChat with a message sending along the the appropriate target name that was deployed, along with its install link, version number, and build notes. I also have another script for the same project that does this same project for a different product and target. So I could have had a single script that does this for both products, but it makes a lot more sense to just know which script to go to if there is debugging that needs to happen down the road, without having to fight through a lot of if-else statements. .yml is annoying enough, imo.

Third:

Comment all your secure keys.

But seriously, just do something like this:

#hipChat authentication key

– secure: generatedSecureKeyRightUpInHere

Take it from someone that did it the hard way: just make sure you know which “-secure” line is which, because if any of these keys change and you don’t know which is which, you’ll end up either just adding to the key list that travis keeps track of, a lot of garbage values that you don’t even know what they are, -or- you get to re do *all* of them just for the benefit of getting ‘er done. And that’s enough to make a saint say bad words.

Fourth:

Be Patient! The ultimate rule to programming that no one told me about in all those intro classes. 🙂

Just Walk Away

Lately I’ve had a couple of incidents that reminded me of the power of just walking away from a problem and letting it simmer for a while.

The back burner can be a wonderful place to get things done!

If you’ve spent any amount of time working in an industry where the main interaction with your job is build something, then you will probably find that a large amount of your work happens in your own head. This topic always reminds me of one of my all time favorite blog posts on the subject “The Case for Slow Programming.” In it, the author mentions that he actually does a lot of coding outside of his office setting- away from the keyboard. Now, I know being away from the keyboard is a scary concept at times, but I tend to agree with the author: some of my best solutions have come whilst I’m doing totally unrelated tasks, like cooking. Or pruning the roses. Or DEFINITELY sewing. (On a side editorial, did you know that sewing is just architecture in disguise? True story.)  Because like I mentioned in an earlier post, I’m a 40-year-old housewife that came into being in about half that time.

But in all seriousness, it seems that others have had similar thoughts. For instance- and you’re going to laugh at the reference for this quote:

Eccentric artist Salvador Dali believed that one of the secrets to becoming a great painter was what he called “slumber with a key.” “Slumber with a key” was an afternoon siesta designed to last no longer than a second. To accomplish this micro nap, Dali recommended sitting in a chair with a heavy metal key pressed between the thumb and forefinger of the left hand. A plate would be placed upside down on the floor underneath the hand with the key. The moment Dali fell asleep, the key would slip from his finger, clang the plate, and awaken him. Dali believed this tiny nap “revivified” an artist’s whole “physical and physic being.”

Dali said that he had learned the “slumber with a key” trick from the Capuchin monks and that other artists he knew also used it. Albert Einstein “napped” this way as well, as have other inventors and thinkers who believed this nap inspired their ideas and creativity. These men were unknowingly taking advantage of what scientists today call the “hypnogogic” nap, when the mind, before it reaches Stage 2 sleep, unlocks free flowing creative thoughts.

I find it fascinating what the mind can do while under (and not under) external pressure.

So the next time Xcode starts swimming in front of my eyes and even switching up the theme won’t help, just remember: walking away is a beautiful thing.

She Was So Young!

I think I’ve always been a 40-year-old housewife that worries about spots on dishes and the state of the laundry.

Seriously, I distinctly remember one of my brothers telling his then girlfriend that I was 10 going on 38.

Well, time runs different in my world, so there we have it.

The more I program for pleasure of honing my craft, the more this point is brought home to me: I’m an old fart in a non-wrinkled package.

The latest example of this came to my attention at random while I was figuring out a menu issue with my latest side project. Not only do I have a pad of physical paper by my desk and an omnipresent mechanical pencil, but I may or may not put all my scribbled ideas in a good old, dependable TextEdit file.

I seeeriously have a TextEdit file for each side project I work on. It’s where all my ideas go, and a lot of sweat as well. Because while I wire frame things out in Balsalmiq as I already alluded to in past posts, all of my tweaking goes into this file. And then it becomes my to-do list! 

Because I thrive on easy to follow to-do lists.

Not that I ever follow the directions on my boxes of macaroni, but dang it, someone has to be the rebel around here!

And yes, I really did take a screenshot of a document. I’m too lazy to upload the thing to wordpress, haha.

Bugs and Things

Have you noticed that the interoperability between Swift and Objective-C isn’t as seamless as Apple made it out to be in their announcement last June?

Well, it’s not.

I discovered a lot of weirdness, not in going from Objective-C to Swift but vice versa.

And I know that it’s risky putting out “newly discovered” bugs, because someone will invariably come along and say “Not so, Sherlock. Fix it like this.” Well, please don’t throw me in that briar patch, Brer Fox. Here’s what I’ve found.

I know, you’re probably like “Why in the blue beyond would you ever want to do that?”

Well, let me give you a “hypothetical” scenario.

Imagine that you have an app with, oh, I dunno, a hundred odd classes.
Everything is working fine and dandy in Objective-C.

You’re happy with it. Life is good.

You decide that it’s high time to really get into Swift, and the best way to learn its wily ways is to port, modify and cajole your app into Swift.

Well, unless you’re a superhero in spandex (I am not, unfortunately) and are going to do all of this in one fell swoop, you’re going to want to go a few features, groups, or even classes at a time.

That means that whatever you convert to Swift- for the *most part* will need to be able to play nice with your existing Objective-C code. Now I know, you’re probably going to give me the speech about how some things like optionals just aren’t available in Objective-C. After all, if everything was backwards compatible, it probably wouldn’t be much of a “more powerful language.” This is all true. But you have a fairly simple app. And you just want to make sure that *most* of it appears to work in the ten seconds it’s on your local box. Work with me, lol.

Well, here’s what I discovered in this possibly foolhardy endeavor.

This process isn’t perfect.

I know! Software that doesn’t have a golden compiler that spits out rainbows and butterflies instead of warnings, that was handed down by the Apple gods themselves! Shocking. Blasphemy!

You see, there is a generated file that I think of kind of like that funky “-Bridging-Header.h” file that was generated for you in order for your Swift code to know about various Objective-C files that are accessible to it. Anyway, this generated file takes on a name like this “YourModuleName-Swift.h” and basically has a lot of bridged over code that looks crazy. If the files all compile, it’s supposed to recompile and life will go on happy and fulfilling.

And yes, before you ask, I did include the regulated @objc tag on the applicable swift methods.

Unfortunately, sunshine and daises aren’t always in store for you along this yellow brick road.

That -Swift.h generated file? yeah, good luck getting that recompile and regenerate at predictable times. I literally spent an hour on the phone with another developer that’s been in the industry much longer than I have (not that it makes a ton of difference where Swift is concerned) showing him what was happening, and both of us were stumped as to when this regen happens. I even made some mods to a different class than the one I was porting just to see the regen happen. And guess what? It wasn’t on build time. It wasn’t even predictable. I literally sat for five minutes and didn’t do anything at all, and *poof* magic.

Or black magic.

That’s the theory I’m sticking with.

You know, bugs.

Bugs aren’t as interesting though. I mean, look at ’em.

Swiftly Marching Forward

In case you missed it in June of last year, Apple did this crazy thing that rocked the their developers’ worlds. 

They announced a new programming language. After the initial surge of “OMG, Let me go download the Swift Programming Language book that Apple’s put out in the iBooks app,” I admittedly didn’t do much with it. Sure, I took a stab at it on 10% days here and there, but nothing really dedicated.

I’ve since learned that there have been many tech companies that have followed a similar approach.

But no more! A week and a half ago, I really started hitting it all very hard. Optionals, wrapping and unwrapping raw values, the new way of making POST statements- it’s all been coming the tiniest bit faster as I turtle along.

They say that learning your first programming languages is the hardest. After that, there are just some syntax idiosyncrasies to manager in the file system of your mind, and it’s all very similar after that.

Well, at least with C based languages.

Objective-C and Swift are a bit like that. Luckily a lot of the API calls are pretty similar, but that’s about where it all ends. I find myself missing brackets. And semicolons. I really, really miss those. But it all sort of rolls off the fingers to a point right now. Even if I feel like I have one long run-on sentence without my semicolons to break it all up.

And that brings me to my next point. While my company has since started exploring Swift, I’ve also taken this as the green light to start doing so for myself. I won’t give you all the gory details now about it, but suffice it to say that I have a new project in the works. Once that lets me explore structures and forms that I’ve explored in objective-c before, but will give me the chance to see how it’s all changed in Swift. Not massively complicated, but useful. Just how i like it. 🙂

Because, after all, if you can’t explain it well, you don’t understand it at all.

Another reason I find it useful to learn Swift at the same time my company is, is The Language File. Did you learn Spanish in high school? I took some classes myself. Later, when I was doing the undergrad search, I realized that I love languages. They’re just satisfying. It’s so ironic that a mostly introverted person would love the sound of languages so much, but there we are. Anyway, while I was going through my undergrad, I took several Russian classes as well. And you know what I discovered? That my Russian as went into my mental Language File as well. If I didn’t know a word in Russian, it came back to me effortlessly (to a point, to be sure) in Spanish. This, as you can imagine is a bit confusing to the listener, haha. I found early on in Swift that this Language File phenomenon continues to happen, but for some reason, I am able to differentiate between the two with more ease now. I suppose when you’re hitting something for 4-7 hours a day consistently, it all becomes a bit clearer over time which is which under what circumstance.

And There You Have It

At the risk of sounding like a massive product review site, here are the final tallies on my Mycestro:

I had to send it back.

It was actually pretty sad, and not really through any fault of its own that I had to resort to this.

When I was 18, I broke my wrist. For the record it wasn’t my fault. Someone ran into me whilst roller skating and boom goes the dynamite…and my wrist. Anyway, ever since then, weird things set it off: very cold weather- which is greaaat, let me tell you, for someone that lives in the frozen western United States- large devices, and as it turns out, very small devices. Something about the way I was putting my thumb on said device in order to move the mouse just wasn’t making my wrist happy at all. I wanted to tell the returns clerk that it was the same story with the Galaxy S4 once upon a time (That one I only had for 24 hours and I just couldn’t deal with that one at all), but you know, they don’t care.

Sigh.

The other thing that kind of annoyed me was dealing with it while doing small tasks, like setting up balsamiq mockups. Putting small icons in place was really irritating. Soooo…there’s that. As a remote control? Probably be fine. Every day work? ehhh, too touchy/not touchy enough depending on the situation.

So ends the Mycestro era.

Github Two Factor Authentication Issue

Shout out to Olivier Lacan for this post. I was having a bit of a problem re-cloning a project the other day because of my two-factor authentication I have set on my github account for work. The TL;DR version of what I was running into was this: I needed to set up a private access token and login using that as my password on the command line before I could clone my project.

Thanks, Olivier!