Ep 025: Fake Results, Real Speed

Functional Design in Clojure

Nate wants to experiment with the UI, but Twitter keeps getting the results.

• "This thing that we're making because we're lazy has now taken 4 or 5 weeks to implement."
• Last week: "worker" logic vs "decider" logic. Allowed us to flatten the logic.
• "You can spend months on the backend and people think you've barely got anything done. You can spend two days on the UI and then people think you're making progress."
• (04:20) Now we want to work on the UI, but we don't want data to post to real Twitter.
• "Why do you keep posting 'asdf asdf asdf' to Twitter?"
• UI development involves a lot of exploration. Need to try things out with data.
• We want to be able to control the data we're working with.
• "We want carefully-curated abnormal data to test the edges of our UI."
• (06:30) We could have a second Twitter account to fill with junk data.
• Or, we could use the Twitter API sandbox.
• Problem: we don't have much control over the data set. Eg. We can't just "reset" back to what it used to be.
• Problem: what about when we're hacking on a plane?
• Plus, we want to be able to share test data between developers.
• (09:10) What can we do instead? Let's make a "fake" Twitter service we run on our machine.
• "Fake" Twitter gives us something our application can talk to that is under our control.
• Having a "fake" Twitter service creates new problems
  • Project wants to grow larger and larger
  • Now we have to run more things
  • Creates more obstacles between checking out the code and getting work done
• (12:35) Rather than a "fake" Twitter service, we want to "fake it" inside the application.
• What is "faking it"? Is this the same as "mocking"?
• Use a protocol for our Twitter API "handle". Allows for an alternative implementation.
• Not the same as mocking
  • We are not trying to recreate all the possibilities.
  • We are not trying to use it to test the component code.
• The purpose is different than mocking. The Twitter "faker" is to help us work on the rest of the application.
• The "faker" is about being productive, not about testing.
• (17:20) Can have the faker start with useful data.
• Default data in the faker can launch you straight into dev productivity.
• "You want automation to support your human-centric exploration of things."
• "If your environment is as fast as it can possibly be, then it allows you to be as fast as you can possibly be."
• (20:10) Can use the faker for changing the interaction
• Eg. have a "slow" mode that makes all the requests take longer.
• Useful to answer the question: "What does this UI feel like when everything gets slow?"
• "The faker can implement behavior you need, for exploring the space you need to cover, to converge on the right solution."
• (22:00) Can have the faker pretend something was posted manually.
• Allows you to see how the UI behaves when the backend discovers a manual post.
• (23:00) Goals of faking
  • Support exploration. Not about testing and validation
  • Support the human, creative side of development
  • Support the developer experience

Related episodes:

• 006: All Wrapped Up in Twitter
• 021: Mutate the Internet
• 022: Evidence of Attempted Posting
• 023: Poster Child
• 024: You Are Here, But Why?

Clojure in this episode:

• defprotocol
• defrecord
• component/system-map

Related projects:

• Component