You’ve got an Angular app and an accompanying test suite. You’ve followed the recommendations about using Page Objects, but it’s cumbersome to require each of them you’d like to use in each spec. Wouldn’t it be nice to automate that?
Page What Now?
If you happen to be writing “E2E” tests for your Angular app with Protractor but you aren’t using Page Objects yet, here’s a quick intro:
Once you’re convinced of their benefit and you’ve seen some nice examples of using them, you go and build a few. And then your app grows… and grows. Now you have a mess of page objects that have to be manually required in each spec that uses them. Read more on Requiring All Page Objects for Angular Protractor Specs…
I started pair programming in 2000 on my first real software job, while I was still working on a computer science undergraduate degree. I’ve been mostly pairing in daily practice since then.
First Impressions Matter
My earliest perspectives on pairing are useful because I’ve seen bad results when people are denied the chance of finding out its benefits for themselves. Pair programming wasn’t prescribed or preached to me, it was encouraged. Read more on Reflections on 10+ Years of Pairing – What Works, What Breaks, and What’s Next…
Github recently announced their project to create their own programming editor called Atom. (Nice logo! *wink*) If you haven’t seen it, here’s a great hands-on post showing off its features.
In 2012, Chris Granger announced a project called Light Table, which I think was a recent mile marker on the same road as Atom.
Here’s some of what Light Table shares with Github’s Atom:
- Both offer a web-based programming platform targeting customizability (Atom, LightTable).
- Both leverage modern languages to implement the editor itself (Atom, LightTable).
- Both envision open-source communities of 3rd party plugins (Atom, Light Table).
So if these two recent programming environment projects are points on a line, where does that line point? Read more on Editing the Future – Light Table, and Atom, and Then What?…
I use the terminal for a lot of my work, so when I need to process output from other tools, I have a lot of options. I started out using shell scripts, but eventually moved on to scripting languages — first with Perl, then Ruby, with occasional Python. Lately I’ve been getting familiar with my shell (
bash) again, finding new ways to stretch its usefulness as a tool on its own, without pulling in typical auxiliary support from
Bash is a big program, and the bulky
man page can hide some gems. One area where it’s quite capable, which I only recently dug into, is string handling. Except it’s not really called that, so you might not have noticed it. As James Coglan rightfully puts it: Read more on String Tricks that Bash Knows…
There’re a couple of ways to distribute iOS apps. Everyone knows about the App Store, but the more obscure modes of internal distribution are less common and more opaque. For instance, if you’re experimenting with Enterprise in-house distribution, you’re likely using some sort of mobile device management software. But what if you are a developer trying to test out builds for in-house distribution?
While my favorite way to distribute apps while testing is with TestFlight, device provisioning becomes a pain past a handful of testers. Another way to test a production distribution artifact is to simply sync a device through iTunes after adding your app. The problem I ran into with this method is that it seems to require that you wipe and sync the device as your own… not something I want to do with company-owned testing devices, nor my client’s devices.
Read more on Testing In-House iOS Apps with a Simple Python Web Server…
Last week I updated my laptop to Mavericks and Xcode 5. I had been waiting to do it pending resolution of a bug in pre-release versions of Xcode that was causing massive layout problems in my app. The fix finally came in the Xcode 5.0.1 release, so I installed it and provisioned a new iPad Air for development. But before I could build and install my app for this device, I had to add it to my team provisioning profile, which is “Managed by Xcode”. That process is a little different in this version, so I thought others might benefit from a simple guide.
Read more on Refreshing Team Provisioning Profiles in Xcode 5…
I was recently pointed to Ben Singelman’s post on Why Nobody Should Use Rails For Anything, Ever.
We seem to never get enough of arguing about application frameworks: I’m not going to do that. What irks me is when Ruby get thrown out with the Rails bathwater. As one commenter on Singleman’s post demonstrates:
“Interesting perspective. I agree on your general points — Ruby’s fine at an MVP stage I think, but when it comes to creating something for market, it just falls over.”
(This despite the second sentence of the post stating “Independent of ruby, I see Rails as the emperor with no clothes on.”)
Read more on My Experiences with Ruby off Rails…
Sometimes it’s hard to say the thing we want to see.
As a dad, I’m fascinated by human language development; and as a software maker, I’m constantly engaged in sharing mental models. Atoms spend a lot of time communicating with customers to bring a shared vision to reality. Reflecting on that practice, I recently discovered a sociological model that ties together language and shared understanding, called “interactionism.” Read more on Shared Understanding: Building Languages and Communities Around Software…
Surprises from Chrome
The next day while we were pairing, we opened up Chrome, hit our app, and noticed that our new “date” field had magically turned into a fully-functional date picker!
We were puzzled. We started looking at commit logs, wondering if another teammate had snuck in a little treat without us noticing. Then I tried the app in Firefox… and the date picker disappeared.
Read more on HTML5 Date Inputs and Ember.js…