Category: Technical

Extracting a Nested JSON Value in Python

First, some context: I’ve been working on some Python libraries at work that do things with sets of json data. This is generally pretty easy: Python has a nice library for reading json, so it can be worked on as a native dictionary object in Python. This is great for simple json objects, but there’s some pretty complex json data sources out there, whether it’s being returned as part of an API, or is stored in a file. Sometimes you need to access a specific value from a key buried a dozen layers deep, and maybe some of those layers are actually arrays of nested json objects inside them.

While both arrays and dictionaries are native to Python, so you can do this, it’s kind of a pain. Thankfully, many smart people have already been tackling things like this, which is how there are now handy libraries implementing a (pseudo-standard) approach for getting the value given a specific json path. (There’s even an online evaluator to help you craft a good jsonpath.) The one I’ve been using is called jsonpath-rw. When I looked at the docs for jsonpath-rw, I was a little frustrated, and I wanted to take a minute to write out my eventual understanding, in case there are other folks in a similar boat to me.

Note: I’m not primarily a programmer (currently I’m a Technical Writer, and prior to that I was a QA Engineer — mostly exploratory, not automation), so while my example works, there’s probably more robust and pythonic ways to do the same thing. Continue reading “Extracting a Nested JSON Value in Python”

My Take on the WWDC Keynote: Net Positive

First, if you’ve not watched the WWDC Keynote yet, you can watch it here: WWDC 2016 Keynote (You can also see a write-up over at Wired and a Liveblog of the event at Engadget.) There are a few things that came up that I think are pretty notable.

First, Continuity continues to be a big push: Apple wants as seamless an ecosystem as possible across all devices and platforms in their stable of products. We started seeing some elements of this in Yosemite and El Capitan, and it looks like they’re doubling down on it in Sierra. I have some reservations about this — mainly, lock-in and whether or not it will play well with third parties. The concept itself, though, makes a ton of sense. I’m curious to see what sort of response we’ll see from Microsoft and Google in this space (MS is starting to point this direction with their push towards a single core across platforms, but at the same time we’re seeing a de-emphasis of Windows Phone, so curious how this will play out).

Second, Machine Learning. All the big players are getting into it (Siri, Alexa, Cortana, Google Assistant), and Apple has clearly invested heavily in this area, with tight integration of Siri into iOS and macOS. One thing I think is notable about Apple’s choices with this, though, is keeping the AI on-device, rather than web-driven. I’m very curious to see how this evolves in future releases.

Third, Security, Privacy, and Encryption. Several times in the keynote, they made a point of calling out that they’re NOT building profiles of user, and are keeping PII on your device, not on their servers. This emphasis on privacy (and security) pervades a number of the choices they’re making, which I applaud them for committing to. While I disagree with some of their product decisions (single-port computers, charging ports on the bottom of the new magic mouse, etc), I genuinely appreciate that they’re sticking to their guns in the face of pressure from the government.

Fourth, Opening up new APIs. A big concern I’ve had in recent releases from Apple is continued lockdown of services, where it felt like if you weren’t Apple, you couldn’t play on the playground. This release sees several integrated services get opened up to third parties (Messages, Maps, Siri being the big three to me), which gives me some hope that Apple isn’t entirely forgetting what made OS X so great.

Fifth, Swift Playground. It’s worth noting that this closed out the keynote, and for good reason. Apple is committing to bringing programming into education in a big way, by making what appears to be a robust learning app that targets youth where they are (mobile devices like iPads), teaching them a language they can directly use for real, complex applications. This is a big win for both Apple and STEM: For Apple, it gets a new generation of developers started using their tools, environment, and language, which you can bet will make an impact on what they choose to use in the future. For STEM, they’re providing free tools, free resources (entire books, including guides on how to teach it and incorporate into your curriculum), already targeted to youth. That’s awesome. You can read more about the whole initiative at their Everyone Can Code page.

It wasn’t covered in the keynote, but has been brought up elsewhere: they’re also releasing a new Apple File System, replacing the old and creaky HFS+. This is significant: Apple’s been using HFS (and then an expanded HFS+) for basically the entire time Mac OS has existed. From reports, it sounds like a robust, next-generation file system that brings some brilliant and essential features. While we likely won’t see the OS truly make the most of these new features until the version after Sierra, this is still quite interesting, and I’m excited to see what gets done with it.

Overall, it felt like a productive developer-centric keynote. It leaves me feeling cautiously hopeful about the future of the ecosystem, and that they’re placing their bets in the right places.

Mood Driven Development

Chris over at CSS Tricks, telling it like it is:

But what is highly prized in our industry is productivity, in whatever form it takes.

“Hey, I refactored some of our mixins to be more efficient and made sure they are used properly site-wide.”

“Good morning, I looked over a lot of the copy around the site and have some ideas on what we can change to make it more clear and cohesive.”

“This afternoon I closed out a couple of long-standing bugs that have been bothering me.”

Any place I’ve ever worked, any of these things would have been applauded. Especially if they relate to the current team/project at hand. That’s what productivity is.

The danger is that you fight against urges to work on something different. You feel like you should be working on converting some layouts, and you feel guilty for tweaking some color palettes. You’re kind of into cleaning your inbox out right now, but feel like you are being lazy for not getting the JavaScript scaffolded out for that new thing. You’re finding a funny image to respond to a playful customer with, but you’re a little mad at yourself for not updating those docs.

That’s too bad, since you are being productive anyway. You’re following your mood.

Chris Coyier, Mood Driven Development

Link: Why Learning to Code is So Damn Hard

Why Learning to Code is So Damn Hard over at Viking Code School. Nice article discussing the different phases of learning to code, and how to deal with each.

I usually wipe out somewhere in phase 2 or rarely phase 3, which is why I like to say I can read/figure out a fair number of languages, but not write them. Next time I take a stab at learning to program, I’ll try to bear this info in mind.

User Experience(d)

Last week, I was at a family reunion filled with fabulous, intelligent, talented people whom I’m glad to call family. One thing I noticed: as people pulled out laptops and iPads and smartphones, or discussed some of the current technological hurdles they’re facing in their day to day lives, there was still a lot of frustration and implied distrust of the hardware or software being used. It really hammered home to me that there’s still a long distance left between usable and intuitive. They were adding complexity and hurdles that didn’t need to be there, because they were used to a previous mental model that was more complex.

I work with software and computers every day, and have for years. Even a lot of my hobbies end up taking place on computers. It’s easy to take for granted the human-computer interactions I do on a daily basis, because I do them regularly, and generally even if it’s a new piece of software or hardware, it still behaves similarly enough to other software that I can get the hang of it pretty quickly. The thing is, even with the pervasiveness of technology these days, I am an anomaly, not the norm. Many people — highly skilled, capable people — simply don’t have that background and context for understanding, nor the time or interest to gain it. As far as I see it, this is a lot of what user experience design is all about: finding that line between simplicity and complexity, where people have enough detail to understand what is happening (at least a high level), but is still simple enough that they don’t have to invest cognitive energy to grasp how to use it.

Aiming for clarity is hard on its own, but what I was noticing is that it faces an additional hurdle: overcoming the complexities or mental models of previous designs. It seemed like a big problem in particular for older generations was that they’d fallen out of sync with what experiences were designed to be now, and were burdened with the expectation of complexity or failure from experiences in the past. It’s easy to say “oh, well they just need to retrain themselves,” but that implies they have the cognitive energy, time, and interest to do so.

That’s not to say we shouldn’t keep working on improving the user experience, but it is something to bear in mind when developing software or hardware. I have a few ideas on how to accommodate this, some of which may be more palatable than others:

  • Evolving UX: Going with more iterative, minor changes rather than a large shift. This already happens some (depending on the software), and sometimes it’s unavoidable that multiple changes will need to go in at once.
  • Documentation: Creating effective documentation can be invaluable for keeping older users up to speed on what’s happening. Three things I’d want to make sure to consider: keeping docs up to date to the current version of the software; keeping legacy docs for older versions; mapping the old user experience to the new user experience in change logs and within the docs themselves.
  • Usability Studies of Existing Users: Doing usability research has definitely become more prevalent, which is a good thing, but I feel like tends to focus on how to attract new users, and doesn’t really give a lot of attention to existing users (I suspect at least partially under the presumption that once a user is committed to your product, they are less likely to take the additional effort to switch). It would be really interesting to make sure to include existing long-time users when doing usability studies. If considering retention of existing users isn’t on your radar, maybe you should reconsider.

Obviously, it’s impossible to please all of the people, and maybe more of this is already in progress than I’m aware of, but it does feel like we’ve got a distance left to go on learning to effectively clear out the cobwebs of past experiences.

More on Cognitive Load and Decision Making

8 Things You Don’t Know Are Affecting Your Decisions Every Day: As a follow-up to the article I posted yesterday, here’s another article about cognitive load, and how we end up making worse decisions over time, over at Buffer. The more choices the user has to make, the more likely they’ll simply choose the default/easy/safe (but not necessarily correct) choice as time progresses. (Hat tip to Felicia Day for linking to it.)

Depleting Cognitive Resources

Your App Makes Me Fat: a neat essay over at Serious Pony discussing research into cognitive load and why it makes sense to avoid branding noise in your user experience.

But if it’s “content” designed solely to suck people in (“7 ways to be OMG awesome!!”) for the chance to “convert”, we’re hurting people. If we’re pumping out “content” because frequency, we’re hurting people.