The World

Don’t Panic! The Universe Expanding Faster Than Expected.

When things seem a little “off”, you might be right. Not only is the universe expanding, but it is expanding faster than we (i.e. astrophysicists) thought. But don’t worry, we’re only off by about 9%.

Look for the word “megaparsec” in this article. It means 3.26 million light years. 🚗💫🤯

An existential nightmare

Scary stuff…

If dark energy remains constant, everything outside our galaxy eventually will be moving away from us faster than the speed of light, and will no longer be visible. The universe will become lifeless and utterly dark.

As the universe expands, the push from phantom energy would grow without bounds, eventually overcoming gravity and tearing apart first Earth, then atoms.

But just a theory so far

Let’s science the sh*t out of this…

Two space missions — the European Space Agency’s Euclid and NASA’s Wfirst — have been designed to study dark energy and hopefully deliver definitive answers in the coming decade. The fate of the universe is at stake.

Software Dev

From Four Wheels to Two – Lyft Engineering

This is Lyft’s approach for adding a major new feature to their app. -> eng.lyft.com/from-four-wheels-to-two-403bcf1cbf59

I heard about this on the iOS Dev Discussions podcast.

Summary

  • Stay simple and lean
  • Reimagine over reinventing – ““Is it faster to rebuild this or reuse this, and what will we regret later?””
  • Launch what matters

Feature flags, feature modules, launching early and iterating small, facing questions they didn’t have answers to until they did some real world experimenting and iterating.

Love this…

Every new feature is a chance to start with a clean slate, and it’s often tempting to immediately build for scale. We all want our products to launch to massive fanfare and usage, but more often than not, the path to success for new features is slow and steady. With steady growth in mind, we designed our first architecture to support exactly what’s needed for our first product iteration, and nothing more

Also…

The computer scientist in me was angry, but when the datasets are small enough, reasonable tradeoffs can be made in the short term without sacrificing the user experience. When choosing the “rewrite” approach, it’s important to be confident that the code will stay simple and easily explainable. In this case, the algorithm wasn’t perfect, but it worked reliably and quickly.

Software Dev

Building reliable apps on unreliable networks – Superhuman

This post describes how we detect and communicate network status as part of making Superhuman the fastest and most reliable email experience in the world. Our previous post described an offline…
— Read on blog.superhuman.com/building-reliable-apps-on-unreliable-networks-3f75743fc457

Summary

In this case, they detect online/offline state in a web browser mostly for the purpose of communicating that state to the user so they can tell what is going on.

The web app keeps track of network state. If a network request times out, the state is set to offline. Then it polls every 10 seconds to see when the network comes back online.

This approach seems alright for a webapp, but in a mobile app I think we’d avoid polio every 10 seconds to see if the app is online. Perhaps poll on the next natural network request instead, or trigger on events such as view-will-appear or return-to-foreground.

Software Dev

How to Design Offline-first Approach in a Mobile App – net guru

Nowadays, almost everyone has access to either wireless network or the mobile network. Does it mean that we shouldn’t be concerned with the availability of network when making mobile apps?
— Read on www.netguru.com/blog/how-to-design-offline-first-approach-in-mobile-app

Great overview of building an app that works offline first as a means to a great user experience.

The offline-first approach is not the universal solution to every problem you will experience with unreliable network connectivity – it heavily depends on your app’s requirements. It’s more like a design approach that lets you focus on what really matters to your end user: a robust app with a great user experience. 

The World

The Trouble with Manager Objects – Ben Sandofsky

Benjamin Sandofsky, a Software Engineer in San Francisco, California.
— Read on sandofsky.com/blog/manager-classes.html

A technical pet peeve of mine, this post does a nice job articulating why “manager” classes in software design can be a problem. To me, a “manager” class is like saying, “this class does some stuff” and the stuff has no boundary. But what does this class do? What is it’s purpose? It might be a sign of an unfocused and unsustainable design.

Or as the post says:

Managers can be a symptom of poorly-defined responsibilities. When you think about it, the word “Manager” means nothing. In object oriented programming, every class is a manager. Cocoa Touch could have UIApplicationManager, UIViewManager, and even a humble NSStringManager.

Software Dev

The Many Offline Options for iOS Apps – Device Blogs – Medium

Offline mode is no longer just an extra feature you could choose to add to your app — it’s something many users expect. I’ve often seen developers force their favorite offline solution on a problem…
— Read on medium.com/device-blogs/the-many-offline-options-for-ios-apps-2922c9b3bff3

Summary

Runs through Caches vs. Databases and when each is a better fit. Basically, databases are better for a finite set of data that you can save “all” of, perhaps a game of personal database. Caches are better for something that is too big / complex / dynamic to save “all” of, e.g. social media, web, etc.

Also covers the idea of using a queue (or EveneBus) for offline tasks and mixing strategies.