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…
RubyMotion 2.10 was announced on September 25th, and it’s a big improvement for me and my team. We’ve been stuck at version 2.7 for the last week due to a number of problems in the previous few releases.
It started with 2.8…
I was excited two weeks ago when RubyMotion 2.8 came out touting faster compilation. I upgraded, and right away I was anecdotally seeing builds take about a third of the time. This makes unit testing much faster and makes it easier to justify my preferred Red-Green-Refactor-style TDD workflow.
I was un-excited when it failed to produce useful error messages after a crash: Read more on RubyMotion 2.10 Released with Bug Fixes…
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…
I’ve really been enjoying using ReactiveCocoa lately. I’m sure I’d have felt the same if I was using it with Objective-C, but using via [RubyMotion] has provided a much lower barrier to focusing on the core concepts of reactive programming. If for no other reason, I prefer the language-building tools of RubyMotion to their counterparts in pure Objective-C.
One example of that comes from my preference for the Presenter-first pattern for writing software user interfaces. It takes a little work to adapt it to the iOS ecosystem, and Ruby seems up to the challenge. To give an idea of how you could apply the ideas of MVP and Presenter-first to a RubyMotion iOS app using ReactiveCocoa, I’ve prepared a sample app that does just that. Go take a look! Read more on ReactiveCocoa, RubyMotion, and InterfaceBuilder Can All Be Friends…