computer

I want to forget—selectively. That’s why I stick with Google Chrome, even though Safari outclasses it in almost every way. Safari is zippy and mindful of system resources; it doesn’t slurp battery, or ever kick on a laptop’s fan. It’s prompt and polite. I think I’d call it courteous. Even Safari’s dev tools are probably objectively better than Chrome’s at this point.

However, I prefer to surf the web like an amnesiac—like someone who continually forgets, stumbling out of cyberspace, crumpled cig still lightly smoldering, figure mussed, and past erased. And for this reason, my go-to is Chrome. (It can be customized more in this regard than Safari.)

I’m terrified of tracking and predictive services. They ingrain what should be arbitrary, evanescent behaviors. A spontaneous search shouldn’t become an online identity, but, in a self-fulfilling way, it can. To combat this, I only want my web browser to know so much about me at once. When it’s able to build a profile—really, a magnified Polaroid—and it knows where to navigate before I do, I’m done. Volition is shot. I develop browsing patterns that become impossible to break. This was me after predictive features became commonplace in the late 00s. I almost never cleared my history (does anybody?), thus every letter I typed in my location bar corresponded with a website I visited too often. I couldn’t stop. I couldn’t change. Web browsing like this is a Groundhog Day-like ad nauseam repeat experience, except nobody ever figures out that they’re a disgruntled news reporter, they don’t fall in love or even bonk a former classmate, and they become generally worse human beings the longer they’ve trod around.

So: I now start each session with a clean slate: No history. No bookmarks. No hocus-pocus predictive services. Drop me into faraway white-sanded Sahara, queue up my magic carpet, and allow me to fly.

Browser Config #1: Cryogenic Chrome

What This Does

This setup preserves your identity, but wipes your history after each browsing session. The author’s most common use case: I’ve visited a bunch of webpages I regret having visited, and these pages recur as suggestions whenever I type in the location bar; Command-Q Chrome and—zap—I start over.

To Enable

1. Install, Configure: Auto History Wipe

Install from the Chrome Web Store then configure options to taste. My configuration:

• Each time Chrome starts:
  • Check: Clear Browsing History
  • Check: Clear Download History
  • Uncheck: Clear Cookies
  • Check: Clear Website Data
  • Check: Clear Cache
  • Uncheck: Clear Saved Passwords
  • Check: Clear Form Autofill Data
• When you exit Chrome:
  • Uncheck: Clear Local Data

Again, I’m trying to keep myself recognized across websites, so that when I choose to navigate anywhere, I’m able to access whatever it is I want with minimal friction. (N.B., cookies are what preserve logins.)

2. Install: Empty New Tab Page

Install from the Chrome Web Store (no configuring necessary).

Without this add-on, the New Tab page will display Google services and your most visited websites (and thus ingrain tendencies). I prefer a blank screen.

3. Configure: Chrome Settings

Open Chrome’s preferences (from the menu bar or Command-,) and configure the following:

• On startup
  • Select: Open the New Tab page
• Advanced: Privacy and security
  • Deactivate: Use a prediction service to help complete searches and URLs typed in the address bar

“Open the New Tab page” is selected by default; you may not need to change this setting. Prediction services will be activated by default. Deactivate this setting.

4. Delete: Bookmarks

Open Chrome’s bookmarks manager (from the menu bar or Option-Command-B), export (if you’d like), and delete everything.

If you keep bookmarks, Chrome will populate them in the location bar (Command-L) as you type (despite decerebrating prediction services). I instead throw URLs I may later reference into text files; Simplenote, nvALT, and Notes.app are all adequate proxies for managing bookmarks.

Browser Config #2: Always Private Safari

What This Does

This setup turns Safari into a burner browser. It saves almost nothing; back and forward navigation work, but no accessible history is maintained, and cookies don’t even persist from tab to tab, let alone from session to session. This configuration is conducive for not lingering online too long.

To Enable

1. Configure: Safari Settings

Open Safari’s preferences (from the menu bar or Command-,) and configure the following tabs/settings:

• General
  • Safari opens with: A new private window
  • New windows open with: Empty Page
  • New tabs open with: Empty Page
• Search
  • Uncheck: Include search engine suggestions

2. Delete: Bookmarks

And, again, keep no bookmarks, otherwise they’ll appear as suggestions in the location bar too. (Access Safari’s bookmark manager from the menu bar or by Option-Command-B.)

I should note: Safari does have an analog to Chrome’s Auto History Wipe—Safari Cleaner—but it hasn’t been updated in years. Steer clear.

pcmag.com

Having immersed myself in the WordPress publishing platform and its accompanying coding languages for intensive stretches while working on websites over the years, 2009–17, specifically, for posterity, (in case any of my fervid readers are wondering), I gained appreciation, disdain, and affinity for the various aspects of writing computer code and what it—computer code—can do and the extreme leverage it can provide. The programming languages used for writing code are similar to written languages (e.g., English, Mandarin, Tuvaluan, Crustacean) in that they serve as means of communication possessing inherent flexibility and thus can be deployed discretionally. Conversation between human and computer can proceed circuitously, linearly, verbosely, or concisely to the same end, much how an author can dispositionally lead a reader to feel, think, or behave a certain way. Here, amidst the 1s and 0s, the objective is to make the computer act a certain way.

To demonstrate the latitude a programming language can provide for achieving an end, below is CSS (cascading style sheets) code, which controls the appearance of an element on a webpage:

#sample-element {
border-top: 1px solid black;
border-right: 1px solid black;
border-bottom: 1px solid black;
border-left: 1px solid black;
}

This can be written instead, for the same effect, as:

#sample-element {
border: 1px solid black;
}

Lo! The four-liner condenses into a single property–value pairing.

Generally, when coding, the ideal is to have written less to achieve the end, whatever it may be, as demonstrated above—but for the sake of clarity for the human who might later be attempting to parse or revise the code, (which human may be and is often you), more lines, characters, and specification can be preferable. Another reason for the long-windedness: manipulation. In the first code block above, defining the top, right, bottom, and left borders separately allows more readily for the customization of each—that is to say, individually; during software development, it’s common to incessantly tweak attributes in the search of “just right.” Above, it’s totally plausible that (1) various border colors, types, and widths were fiddled with, (2) a rather unimaginative 1-pixel solid black border was deemed satisfactory for enclosing the element and (3) by the time the code was deployed to the production setting (i.e., live) the four discrete border attributes remained in the code, uncondensed into the superior one-liner.

This is ok. Yes, the shorthand definition is more elegant, but the form factor here matters little to the end-user (the person visiting the webpage where this style sheet is located). In the 90s or even 00s, the compactness of front-facing code like this was a bigger deal because (A) the internet was slow (think: download speeds under 56Kb/s) and (B) the front-facing code must be downloaded. (The attentive reader will have pieced together that the more compact the code, the faster it is downloaded.) But with download speeds averaging over 1000Kb/s globally now, in 2018, the penalty for an inflated style sheet is unnoticeable. Case in point: The main style sheet for this website at the time of writing is 10KB (kilobytes; 1KB = 8Kb) and I made no efforts to streamline its code. On a below average internet connection, this equates to a less than 0.1s download time. Comparatively, the “organ donor” photo of myself is 19KB, the thumbnail images on the homepage add up to somewhere around 200KB, the typefaces alone account for 325KB…and very quickly the 10KB style sheet is trending towards nothingness and a consequential state of nirvana. This file, the style sheet, also loads only once and is cached (stored for X period of time locally on the device) by most browsers. It is a drop in the digital ocean. So I do not enjoy writing CSS because the language tends to neither reward nor demand scrupulosity of me. Until internet connectivity is throttled to oblivion, which, who knows, may happen, and the size of a webpage becomes relevant again, I will continue to write lackadaisical, semi-bloated, -sloppy CSS.

Other languages that interact with databases (i.e., query them) I feel do reward the meticulous and attentive programmer for writing “better” code. For those unfamiliar with databases, they are essentially spreadsheets: rows and columns with cells full of data. Querying a database retrieves the data contained within these cells under specified parameters. To pull data from a database takes time. To process that data for display on a webpage also takes time. This runtime, or “wait time,” can actually be felt—verifiably perceived—by the end user in many instances, unlike the style sheet download mentioned above, because the querying process typically happens on the constrained server-side. It can only go so fast, and until it has completed, the end-user is left idling with a white screen in their face. Faster internet does nothing to mitigate the wait time. Until the webpage is generated, it cannot be loaded.

As a workaround, webpages are often served statically, which involves pre-generation, storage, and then retrieval of the pre-generated pages. This eliminates the runtime. In other cases, such as when logged into a website or app, the content will be served dynamically to tailor the display. This means the webpages will be generated on the fly and necessitate querying and data processing—wait time. The wait time hurts in two ways:

1. Websites become less functional the more slowly they serve content (humans don’t like waiting)
2. The slower the website, the higher the runtime (and thus web hosting costs)

Since querying and data processing are often what bottleneck the transmission of a webpage to the user, I think it’s especially important to optimize the two for any website that draws traffic or anticipates longevity. To illustrate conservatively: Suppose 0.1 seconds can be shaved off of a query and that query is executed 1,000 times per day. This equates to 100 seconds of runtime saved per day, which adds up to roughly 1 hour per month and 10 hours per year. (These are plausible figures for a low-traffic website.) I am absolutely content to emerge with a gain of this magnitude. And it’s often possible to reduce the runtime of a rogue query further than one tenth of a second. The savings can be dramatic. In the vacuum of a single runtime instance, the time-savings aren’t always noticeable, but the repeated occurrences add up. I won’t delve into the language of queries, like I did above for style sheets, but strategies for optimizing queries often involved eliminating queries (e.g., running them less often by storing results for a period of time) or tweaking comparison methods (e.g., resolving from the opposite angle). Shrewder processing of the data returned by queries increases efficiency as well.

So: I became particularly interested in page generation optimization after realizing the tangible utility of and return for deconstructing queries. A day spent remediating a slow query into a more lively one would translate into a net savings of hundreds or thousands of hours.

en.wikipedia.org

After burning out on my job and the internet in general last fall (see: “Drugged Out”), the physical, actual, verifiable (“Pinch me—ouch.”) environment around me materialized into view as I distanced myself from technology, and through the lens of query optimization I realized I could reduce the time and energy I spent on recurring tasks within this environment—the tangible one—much like how I felled inefficiencies within the digital realm. Actions or tasks are essentially the same as queries. What we are trying to reproduce—or, more analogously, “retrieve” (to borrow from the digital sense above)—are specific states with regularity and precision. Consumed during these real-life processes are resources too. For the sake of example: I boil water at least once per day. State retrieved: water @ 212°F. To refresh to this state from ambient water requires X time and Y energy, which variables hinge predominantly on the construction of the heating vessel (material, shape, capacity, etc.) and type of stove (gas, electric, conduction, etc.). By manipulating these factors (vessel and stove), water can be brought to a boil at varied rates—and why not attempt to raise the speed, (reduce the time), if possible, for a comparable amount of, or even less, energy? (“He’s right!”) Rather than modify my stove, I upgraded cookware. Implied with the acquisition of a new, more efficient pan is a moderate upfront cost, but if I am saving (1) time, because the water boils faster, and (2) energy, because less electricity or gas are spent, why not invest? The water only needs to come to a boil 30 seconds faster for the pan to save me 3 hours per year, and at that point, one year in, I’ve already seen a comfortable return on investment; the water does boil at least that much faster, and I value my time. To make this switch seems like a complete no-brainer to me in retrospect, and I wish I acted sooner. I would be remiss not to mention that there are other considerations inherent to any item besides how quickly it functions—read: you can’t microwave everything—but time is often the prevailing factor. Energy can be renewed; time cannot.

To express the idea of speed, or time-saving, in another format, listed below are generalized comparisons of common objects, concepts, and attributes. Each should be situationally scrutinized, selected, and discretionally employed:

• writing: click pens are faster than capped pens
• stationery: notepads are faster than journals
• laundry: hanging is faster than folding
• enclosures: the zipper is faster than the button
• footwear: slip-on is faster than tie-on
• containers: transparent and bare is faster than opaque and adorned
• objects in motion: lightweight is faster than heavy

The usual solution-seeking pattern is to deconstruct an action, identify its components, and reduce the friction precluding its end state. Forming a comparison base like this can help ramify creative channels. There is infinite possibility. In the case of boiling water, eliminating friction (or, more accurately, conserving energy) saves time. This strategy can also be used to form new, positive habits, rather than just reduce the time it takes to complete old ones. (Or, conversely, by increasing friction, bad habits can be broken.) To provide another example, which demonstrates habit forming and incorporates bullet points #1 and #2: I write down thoughts daily. (“Dear diary…”) Or I try to at least. I’ve found that if I don’t, I get stuck. Repeated thoughts will fester in my brain. I enter states of helplessness, inaction and delusion without regular extrication. It can get bad. I tend to perceive issues more clearly when they’re a foot or two away; left in my own head, I’m blind. And there’s something specifically therapeutic about transmuting these thoughts in my own handwriting, so I scribe with pen and paper rather than an electronic device. The pebble in my path is that I’m rather kind of unenthusiastic about recording these thoughts. It’s at times painful to confront reality or what I’ve initially perceived to be reality, and so I will avoid doing so. Unless I have paper sitting out in plain sight, within grasp, ready to be written on, and pen, too, I’m unlikely to write—so that’s precisely what I do: I leave an open-faced notepad with clean sheet on the top of my desk with engaged pen alongside ready to jot. Bound, covered journals require too much fuss; I can’t be bothered to flip open to my last spot. Serendipitously, the sheets of the notepad necessitate displacement once filled (i.e., tearing off), adding further distance to the thoughts. (“What’s in the past has passed.”) This may sound like psychobabble but in practice I’ve found the philosophy to be sound. Capped pens I am aware can be left uncapped; click pens have the edge in portability, which can matter, but this is largely a personal preference. To get to this point, where journal-keeping has become a sustainable habit, for me, I identified the high-friction aspects of the activity—(1) retrieval of paper and (2) engagement of pen—and attenuated them. There’s more to it than that, but this is enough to be illuminative.

In short, I am far more likely to establish a desired habit when the end state is nearer (e.g., with faster cookware, I am more likely to cook; with faster stationery, I am more likely to write) and it is easier to get started (think comparably of the activation energy required for a chemical reaction to proceed). The ability to establish and sustain new habits leads to personal growth—increased awareness and heightened potential.

To bookend with an extrapolation on the role of efficiency: As blatant hold-ups in action are addressed, previously imperceptible bottlenecks surface. These subsequent hold-ups warrant remediation, induce new ones, and so on. (Picture a metaphysical game of whack-a-mole.) As this sequencing progresses, and perceptual mastery is borne, habitual attentions begin to shift. Words like “routine” and “menial” give way to “variable” and “meaningful.” The less time and energy required for an individual to sustain an existence, the more favorable the conditions for them to flourish.

Strategies for identifying routine actions involve distancing oneself from them. Distancing inherently involves velocity (see: time) (see: space) and displacement. Traveling helps disrupt routines or forces the performance routines in new situations, which can highlight or make more obvious what is limiting about them. If traveling isn’t possible, time and space can still also be manipulated by varying the order, frequency and direction in which tasks are performed in their home environment. Writing, talking with a friend, and speaking into a voice recorder are other methods for distancing oneself from a situation and interpreting it in a new form.

The aforementioned “programming languages” are accompanied by mostly static manuals detailing the limited number functions and components the language possesses, which, when sequenced together strictly, can draw or manipulate query results; the real world is in flux, undefined, infinitely detailed, and incomprehensibly complex. But just as the database query and its corresponding functions may stifle the request for a webpage,—making it inefficient, less functional, and less likely to be used,—so do the minutiae of routine tasks preclude end states, and both are worth scrutiny.

By way of this process of translocating digital ideals to the physical plane, I’ve come to realize: Everything is kind of the same and reflects back what we see in it,—“If the doors of perception were cleansed…,”—and with each experience the apertures shrink or grow.

The Abandoned Gamesroom

We had this screen saver on our old HP computer in the late 90’s and I rediscovered it sometime last year. Nothing can beat Johnny Castaway, it’s by far the best screen saver ever produced.

Download it from that site and be prepared to waste hours watching Johnny do various tasks from eating coconuts to going for a jog.

Incredible the way Steve Jobs is able to woo the audience… 25 years later you can still feel the rush from this presentation.