Rolandt

Ian Bogost writing for The Atlantic says that in too many cases today “artificial intelligence” is just another name for a fancy computer program. I don’t see it that way. I know from experience that what most data scientists are building is entirely different from what rank-and-file software developers are building. We use different tools and different approaches. And the data-driven learning algorithms we deploy at their best solve an entirely different class of problems than regular computer programs do.

Personally I like to call what we build “machine intelligence” rather than “artificial intelligence” because machine intelligence is really an alternative kind of intelligence, not an artificial version of human intelligence.

No, it’s not “Making computers act like they do in the movies” as Bogost quotes AI researcher Charles Isbell. That is too glib indeed. Why not let machines do what they do best rather than just serve as poor imitators of humans?

Part of what makes “artificial intelligence” feel a bit underwhelming is that we’ve barely begun to see what we might achieve with machine intelligence. Yes, self-driving cars are pretty amazing. I don’t have one myself (can’t afford a Tesla, darn) but I do adore the parking sensors on my SUV. They allow me to navigate around the dangerously-placed porch jutting out by the attached garage set back to the rear of my house. If I didn’t have them I probably would have hit the porch at least once already. The car can parallel park itself too but I’ve only tried that once, before I bought the car, with the salesperson sitting next to me.

I have faith that we are going to see many more amazing machine intelligence capabilities come out, as startups and big companies start focusing on vertical artificial intelligence in specific domains rather than continuing to build out horizontal machine learning capabilities for use by data scientists. Vertical AI (or MI) is tough. That’s where you have to get domain experts and data scientists together and figure out how to encode domain expertise and capabilities into machine learning models. It’s tough and slow work. I know. I’ve been doing it for a few years now in the temporary workforce management space. We’re beginning to see the payoff though, and that is truly exciting.

If you want to hear about it, I’m going to be at VMSA Live in Phoenix in early April talking about Machine Intelligence in Talent during the Executive Gateway session on Wednesday, April 5th. If you’ll be there, stop by.

My solution to the post-truth crisis is to develop a culture of collaborative explanation and exploration via development and use of new and different tools.

My belief is that humans have a couple modes of working with truth. Some are adversarial and propagative, and some are exploratory and collaborative. The adversarial mode is killing us.

My contention is that early visions of the web and digital technology (Bush, Engelbart, Kay, Berners-Lee, Cunningham) developed collaborative, exploratory approaches (Wiki, Memex, Dynabook, hypertext) as their dominant modes, but that later approaches  (Facebook,  Twitter) chose modes that promoted propagation and tribalism. That’s fine as it goes — these things are important. But as a dominant mode adversarialism is, unsurprisingly, polarizing us, and killing truth in the process.

It doesn’t have to be this way. Keep in mind that as the rest of the web has polarized, Wikipedia has, over the years, become less biased. Keep in mind that in the sciences tools like Jupyter notebooks have moved many scientists from “no it isn’t-ism” to “Let me tinker with your code.”

By embracing new exploratory modes of technology use we can create a culture of exploration, just as by adopting the tools of rhetorical dominance we created an adversarial culture focused on rhetorical dominance.

These tools include wiki (including newer versions of wiki), Jupyter notebooks, OneNote, and similar tools, but also require that tool makers rethink their own existing tools in radical ways. What would your platform look like if it made deeper investigation of an issue irresistible? If it made collaborative truth-seeking the norm?

Hint: Almost nothing like tools look now.

Hint: Almost the opposite of how things look now.

Hint: Fix that.

That’s it. That’s my one great insight. It’s been the drum I’ve beating since early 2013. It’s probably self-serving and maybe short-sighted. But it’s my insight and I thought I might put it in a single place and state it clearly.

And to the question of “But isn’t our current moment also caused by X?” Yes, most certainly. Gerrymandering, AM radio, racism, white supremacy, a parliamentary partisan culture mapped on top of a party-neutral government structure, corporate disinformation, adtech, Merchants of Doubt, the Big Sort, all of it. It all matters. My insight and expertise happens to be about the technologies we use, though, so I plan to work on that square of the problem.

“That’s four different ways to talk to Google on this phone, not counting apps like Maps and Gmail. And each one has a slightly different interface and provides slightly different results”

[..]

I quoted the above passage, though, because it suggests some rough edges regarding what is supposed to be the Pixel’s standout feature

— John Gruber

I don’t disagree . But consistency isn’t everything. To free-associate for 5 minutes on the subject of Force Touch (surely a stand-out feature, and moreover one that’s had 12 months to shake out the edge cases):

• The weather app springboard icon force touch action has both a widget and the actions are nouns – quick links to recent cities. The clock app force touch action has no widget, and the actions are verbs (create new alarm, for instance).
• The core “telephone” apps have different combinations of actions and widgets – Messages (no widget, “new message” and a list of recent contacts as actions), FaceTime (no Force Touch actions at all, but a widget listing recent contacts),  Phone (a widget listing recent contacts and actions, including contact search), and Contacts (a widget with recent contacts, and a create contact action, but no search this time).
• Some built-in Apple apps have no force-touch menu at all (eg Videos, Find iPhone,
• The “leaves” in the iPhone safari tab switcher have fake parallax as you tilt the phone, and respond to force-touch by flexing apart. You can long-press to drag them around. The “leaves” in the system task switcher do neither of these things.
• Springboard icon force-touch menus grew a “share app” action in iOS 10. Unless you get at that menu from a spotlight search, in which case they don’t have it any more.

While I was looking at the weather and clock apps anyway,

• The cities in the iOS weather app sync with their Mac equivalent (but the Celsius / Fahrenheit setting doesn’t). The cities in the world clock app do not.
• To rearrange world clock rows you tap “Edit” and use the drag handles that appear. To rearrange weather rows you long press (not force touch, that does something different) and drag up and down. But both apps have swipe to delete.

Having said all that, Force Touch is amazing and you will have to pry it from my cold dead fingers. I just don’t think universal consistency on a platform is achievable in a world where you sill also have to actually ship things.

First of all, a bit of background: to get onto the Mountain Leader course, I have to complete and log twenty ‘quality mountain days‘. It’s been winter, so my last couple of QMDs were back in October. However, now spring has sprung, I’m off back up mountains.

My previous four QMDs were in the Lake District, but this time I thought I’d mix it up a little by heading to Scotland. This is a little further for me to drive from my home in Northumberland, but, as you’ll see, it was definitely worth it!

Given that it’s only March, I decided against the Cairngorms, leaving that area for the summer months. Instead, I focused on Loch Lomond & The Trossachs National Park.

The great thing about the Ordnance Survey’s OS Maps app is that you can see routes that other people have added, and use these as inspiration for your own. I decided to go up Ben Ledi on Friday, and Ben Vorlich on Saturday, staying over at Callander Hostel.

Before I left, I watched some videos from The Bushcraft Padawan, aka Craig Taylor, who I know from the world of edtech. As you can see from the photos of my map further down this post, I followed his suggestions to pimp my map. I checked the Mountain Weather Information Service, which promised optimal conditions!

I knew I’d be tired on Saturday, as I never sleep that well when I’m away from home (especially in hostels where you can guarantee someone will snore) and I’d have spent a full day walking on Friday. It was for that reason, that I decided to walk further on Friday than on Saturday.

Friday (QMD 5)

The route I planned at home went up Ben Ledi, across to Stuc Dhubh, down the trail, through the trees and round past a waterfall, and then along the road back to Callander:

Driving from my home to Callander took a little over three hours. It was a straightforward journey, with light traffic and wonderful views. On arrival in Callander, I found the hostel, parked my car, and tried to find someone to give them a route card. However, there was no-one to be found, so I sent the route to my wife and told her to call Mountain Rescue if she hadn’t heard from me by 19:00.

Instead of driving from the hostel to the start point I’d originally identified, I walked to it, which added a good half an hour to the overall journey time. The initial walk up the path was pleasant.

However, I soon got to a scene of devastation. The timber forest around Ben Levi is a ‘crop’ and as such is harvested. What is left, though, looks like what I imagine parts of England looked like after the Harrying of the North.

I sat down on a few logs and sent my wife the image below. I put down my hat, gloves, and sunglasses. When I got back up, I must have knocked them off onto the ground somehow, as I realised about an hour later that I didn’t have them.

The route up to the top of Ben Ledi from that point involved some steep sections, but it was the snow that surprised me. I hadn’t expected it to be so deep!

Just before I made the final ascent to the top of the mountain, I sheltered from the wind behind a rocky outcrop. My hands were dirty, so I rubbed some alcohol gel into them in preparation for eating my lunch. That decision ranks as one of the stupidest I’ve made while on the side of a mountain, as without gloves, the wind on my hands then made them feel extremely stiff. I ended up putting spare woolly socks over my hands.

Once I got to the top of Ben Ledi, I followed a trail on my map rather than a demarcated path. The snow got even deeper at this point, to the extent that I had to start being very careful about the route I was taking.

My route took me via a couple of tarns, which were partly iced over and beautiful to behold. I just stopped and looked for a couple of minutes, before the cold wind encouraged me to keep moving.

The purple line on the map below shows the edge of a boundary between areas looked after by different organisations. It’s also, however, a path. I’d intended to head up to Stuc Dhubh and then down the track to Allt Ghleann Casaig.

However, by the time I got to the top of Bioran na Circe, the snow was thigh-deep, so I made my way down the slope towards the two fords. To make this easier, I kept the stream to my left, and the gully to my right.

It wasn’t easy going, and I slipped and slid down. I was thankful to get to the bottom. From this point onwards, I was walking along tracks and roads back to the youth hostel. It took me what seemed like ages to get back, and by the time I was on the last stretch, I had my head torch on. I’d already contacted my wife by that point, but I got back just before 19:00.

As you can see from the above, I use the OS Maps app to track my route. I was out for over seven hours, walked over 18 miles, and ascended over 4000 feet. I was pretty tired by the time I checked into my hostel, staggering out after a warm shower to get some fish and chips.

I slept reasonably well, despite the inevitable snorer, and the two drunken idiots who burst in at 02:30.

Things I learned

1. Check you’ve got everything once setting off again after resting.
2. Don’t put alcohol gel on your hands in cold weather.
3. Plan interesting routes that don’t involve lots of walking on roads.

Saturday (QMD 6)

The route I planned at home took a straight route from the southern shore of Loch Earn up the path to Ben Vorlich. From there, it looked like a straightforward walk to Stùc a’ Chroin, along the ridge, round and up along the river back to my starting point:

I was anticipating a couple of things on Saturday. First, because it was the weekend and a beautiful sunny day, I knew that there would be plenty of people out and about. Second, from the map, I anticipated an easier day than Friday. I was wrong on both counts; there were about the same number of walkers, and it was much harder going than Friday.

I bought provisions in Callander, and then drove around to my starting point. I hadn’t needed my ‘proper’ camera or my waterproofs the day before, so I left them in the car to make my backpack lighter.

My optician had warned me earlier in the week of the need to protect my eyes given my pale blue irises and ‘larger than average’ pupils. Having lost my walking sunglasses on Friday, I was forced to wear my aviator-style driving sunglasses. This was less than ideal.

It was tough-going up Ben Vorlich. Thankfully, I had a couple of individual walkers ahead of me, meaning that the route through the snow was clear. The path was steep, and very slippery in places. It made me realise why people have walking poles.

I overtook a guy who had a couple of dogs with him, and felt I was doing well. However, life has a way of knocking you down a peg or two and, on this occasion, that was done in quick succession. First, I came over the brow of the hill to see the final ascent involved scrambling through ice and snow. Second, a guy in his early twenties ran past me. Unbelievable.

I did, however, finally get to the top of Ben Vorlich. It felt like an achievement, and the views were stunning. I stopped for a few minutes, and then pressed on towards Stùc a’ Chroin.

It didn’t take long for me to realise I hadn’t read my map very well when planning this route. What I had assumed  was a ridge from Ben Vorlich to Stùc a’ Chroin actually involved a steep, snowy descent followed by an even steeper ascent. I sheltered at the bottom of the pass, enjoying my steak pie and bottle of Lucozade.

When I’m out on mountains, I talk to myself in my head. Not in a personality disorder kind of way, just in the sense that I think all of us do: having a conversation as to what’s coming up and what my response is going to be. Usually, I have no problem willing myself on after geeing myself a bit.

However, on this occasion, tired after yesterday’s walk, and surprised at having another steep ascent to make, I just couldn’t bring myself to do it. Instead, I decided to re-route and take what I assumed would be an easier route along the river.

Oh, how wrong I was.

Not only was the way down tricky, but the ground all the way walking down, keeping the river on my right-hand side was extremely boggy. I saw a herd of deer at fairly close quarters, but wasn’t quick enough to take photos.

I struggled through snow on top of sucking mud for what must have only been two or three miles, before turning the corner. I was hoping, but again it was assumption rather than close map reading, that the trail back would be reasonably straightforward. I had only paid attention to elevation, rather than what the ground would be like underfoot.

The journey by the river, however, felt like a walk in the park compared to what came next: walking over snow-covered heather, with small stream underneath. It was really hard-going, and I had to keep an ear out for the tell-tale sound a small stream under the snow. On a couple of occasions, I put my foot down through the snow and heather into a stream.

I was wet. I was tired. I was fed up. The photos all make it look beautiful, I suppose, but I had my head down most of the time, trying to not to stumble. The trail marked on the map was like Blackadder’s four-headed, man-eating haddock fish-beast of Aberdeen. It didn’t exist.

Eventually, I turned a corner and saw something so mundane, but so welcome: a bridge. If there’s a bridge, there’s a path. And from there, I walked down what felt like a motorway back down to my car. I collapsed into the boot, removing my sodden boots and gaiters, tore off a large piece of Soreen malt loaf, and greedily pushed it all into my mouth.

The above information really requires the context given above to understand the impact it had on me as a mountain walker. Despite a shorter route both in terms of length and duration, and the total ascent being less than Friday, nevertheless Saturday’s route was hard.

The drive back home was frustrating, both because of my desire to get home and drink all of the whisky in my house, but also due to the weekend traffic and number of speed cameras in the Scottish borders.

Things I learned

1. Assume nothing. Check and double-check your route, especially when it comes to elevation and ground underfoot.
2. Consider buying walking poles. It could save your knees.
3. Mountain water tastes amazing.

I turned my silly post about generating village names using a neural network into @urnowentering, a silly Twitter bot. It’s the gift that keeps on giving, procedurally, forever.

Curnham Green

— You are now entering (@urnowentering) March 26, 2017

Related on dandyhorsemagazine.com

Rookie Fast: Q&A with SendIt Courier

Feeding the community through bike-based delivery: Meals on 2 Wheels

Food Fight: Wayne Scott of Hoof and Cycle Courier Co. fought for couriers to write of food as fuel

Don't Fence Me In: New Right to Roam law coming to B.C.

Night Rider

When several teenage girls wearing leggings attempted to board a United Airlines flight in Denver, the airline blocked them for “inappropriate dress.” As the airline explained on Twitter, the girls were “pass riders” — dependents of employees using free standby tickets — subject to a more stringent dress code. United’s policy is wrong, and it … Continued

The post Everything United Airlines did wrong in the Denver Leggings Incident appeared first on without bullshit.

I should start by admitting I shot this picture with my phone, on the subway last night. I should also admit that I was no less absorbed in my personal rectangle than everyone else on the subway (and I do mean everyone) was with theirs.

I don’t know what the other passengers were doing on their rectangles, though it’s not hard to guess. In my case it was spinning through emails, texting, tweeting, checking various other apps (weather, navigation, calendar) and listening to podcasts.

One sure thing is that we are all serfs in the castles of Apple and Google, our two Lords of the Rectangle. Yes, our lieges treat us well in most ways (Apple most notably with its privacy policy); but that doesn’t make the systems they trap us in any less feudal. (A metaphor we owe to Bruce Schneier.)

We shape our tools and then they shape us. That’s was and remains Marshall McLuhan‘s main point. The us is both singular and plural. We get shaped, and so do our infrastructures, societies, governments and the rest of what we do in the civilized world. (Here’s an example of all four of those happening at once: People won’t stop staring at their phones, so a Dutch town put traffic lights on the ground. From Quartz.)

Two years from now, most of the phones used by people in this shot will be traded in, discarded or re-purposed as iPods, Sonos remotes or whatever. But will we remain just as tethered to Apple, Google, telcos and app providers as we are today? That’s the biggest question. Dependent or independent? Subject to sovereigns or self-sovereign on our own? Probably some combination of the both, but the need is for greater independence and agency for each of us.

For sure most phones will do less old-fashioned telephony and more audio, video, VR, AR, and other cool shit. Just as surely they’ll also give us whole new ways to shape and be shaped. Perhaps by then mass media will finish getting replaced by mess media.

But I have to wonder what comes after phone use spreads beyond ubiquity (when most of us have multiple rectangles). Because everything gets obsoleted. That doesn’t mean it goes away. It just means something else comes along that’s better for the main purpose, while the obsoleted media still hang around in a subordinated or specialized state. Radio did that to print, TV did it to radio, and the Net is doing it to damn near every other medium we can name, connected across its Giant Zero at approximately no cost.

So, while all our asses still sit on Earth in physical space, our digital selves float weightlessly in a non-space with no gravity or distance. This is new shit.

McLuhan says the effects of every new medium can be understood through four questions he calls a tetrad, illustrated this way:

Put a new medium in the middle and then sort effects into the four corners by answering a question for each:

1. What does the medium enhance?
2. What does the medium make obsolete?
3. What does the medium retrieve that had been obsolesced earlier?
4. What does the medium reverse or flip into when pushed to extremes?

These are posed as questions because they should help us understand what’s going on. Not so we can come up with perfect or final answers. There can be many answers to each question, all arguable.

So let’s look at smartphones. I suggest they—

• Enhance conversation
• Obsolesce mass media (print, radio, TV, cinema, whatever)
• Retrieve personal agency (the ability to act with effect in the world)
• Reverse into isolation (also into lost privacy through exposure to surveillance and exploitation)

I don’t think we’re all the way into any of those yet, even as every damn one of us in a subway rewires our brains in real time using rectangles that extend our presence, involvement and effects in the world. Ironies abound.

Item: New York has just begun putting up notices that claim every subway station in the city now has wi-fi and cellular service. In my own experience, this checks out. But New York is still behind London, Paris and Boston in full deployment, because there is mobile phone and data service in the tunnels under those cities and not just in the stations.

Which to me says we’re still climbing toward peak phone.

My main point, however, is that there’s still a slope down the other side. Count on it. Something will put smartphones in that lower right box.

Save

My Touch Bar rage has peaked.

It is a point of pride for me how I type. I am proud of the fact that I can sit in this here chair, stare at the screen, and let the words flow effortlessly. I very rarely look at the keyboard, and when I do, I have a word that describes this state. It is an interruption.

Productive work is the successful chaining together of uninterrupted minutes. The longer the chain, the higher the productivity. Interruptions break the chain.

In week #3 of actively using the 15” MacBook Pro, I am delighted by its build quality. I love its weight. Last night, I found myself admiring the machining of the aluminum notch that allows me to open the computer. I type deftly on this hardware.

I am also equally deft at randomly muting my music, unintentionally changing my brightness or volume level, and jarringly engaging Siri.¹

It is maddening. And it’s not improving.

However, the essential law of technology is evolve or die. This means it is worth my time to deconstruct the Touch Bar to infer design intent. To do this, we must answer the basic question: “What is a button?”

My Button Definition

Let’s start with my brief definition of an efficient button:

1. It has a perceptible boundary that makes it findable.
2. It exists in an expected location relative to its container.
3. It is “pushed” to achieve an obvious purpose.

To understand this definition, let’s test it against buttons, button-containers, and button-like-things:

A keyboard button. Your classic button. It’s got an edge you can both see and feel. It’s in a fixed location. When you push it, you normally see the result immediately. This is a button.

The home button on the iPhone. This button has gone through significant mechanical and design changes and is another classic button. As the iPhone is a far more mobile device than a keyboard, the importance of the perceptible boundary that makes it findable is increased. Close your eyes, grab your phone and unlock it. No problem, right? Keep those eyes closed and launch Safari. No fair using Siri.

Minor point. On the newer iPhones, you don’t push and physically move the button. The button doesn’t move, but it gives you the impression it does with haptic feedback. To fully experience this, “press” the button an iPhone with a dead battery. Apple has done an admirable job creating the impression of a satisfying button press.

The Force Trackpad. It has a perceptible edge, it is always in an expected location, and you do press it. However, the Trackpad serves a multitude of functions. Its purpose changes based on application, the number of fingers on the Trackpad, and the gymnastics those fingers perform whilst on the Trackpad. There is an argument that mechanically it’s a button, but due to its myriad functionality, I would say it’s not a button, but a Trackpad.

The Apple TV remote. I’m bringing this one up because the Apple TV buttons are a frequent source of frustration for me. When you look at my button definition, the flaw is clear. The Apple TV buttons are just fine provided that you understand which end of the remote, the container, is pointed where. It’s when the bottom of the remote is pointed forward, and your fingers start to the explore the remote when you realize, “Something’s wrong” and you glance at the remote to orient yourself.

The Apple TV remote has a pleasant feel in my hand. It’s by far the most visually appealing remote that I own. It offers a sensible set of useful button options. However, this grace is interrupted each time I have to stop and ask, “How am I holding it?” The buttons are fine; the flaw is that to work, you must visually inspect the remote. Even my worst remotes with their plethora of buttons easily convey which end should be pointed forward.

The Touch Bar The Touch Bar buttons fail my definition in a couple of ways. I’m going to give it partial credit for the perceptible boundary because, yes, you can look at the bar and see the buttons. However, try the close your eyes test and turn up the volume on your MacBook Pro. How’s your brightness looking? Did Siri say hi?

When you combine this difficulty in tactile findability with the fact that the buttons on the Touch Bar are gleefully changing position when you move from application to application, it appears the Touch Bar has more in common with the Trackpad than the keyboard. The buttons on the Touch Bar are most certainly buttons; my issue is with their container.

Grace Interrupted

In the history of keyboards, I have never been as inept as I’ve been with the Touch Bar keyboard. I’ve been finishing this piece for the last hour and I’ve been keeping track of the number of times I’ve accidentally hit a Touch Bar button, and that number is nine. The total number for this article is likely 5x the number.

Developers were the ones who originally raged on the Touch Bar because it contained one of their most frequently used keys – the escape key. The absence of the clear feedback of a physical key press is a violation of perhaps the most important word in my definition we have not explored “efficiency.”

The Touch Bar is gorgeous but is inefficient.

Apple’s job has always been to courageously lead the charge on design. Apple has a strong defensible opinion regarding where we should go versus where we’ve been. The Touch Bar hits common Apple Design high points. It cleanly integrates the keyboard and extends it. The gentle animations with occasional splashes of color are a joy to share with others.

… but it’s inefficient.

Apple, I am with you on this design journey. I am cool with the dongle explosion that accompanied the MacBook Pro because your opinion is one universal port and I get that. The future is shaped by those who lead.

However, the role of a well-designed keyboard is to stay the hell out of the way. A good keyboard is a tool designed to be unnoticed because its job is to get the ideas out of my head, through my fingers, and into the computer as quickly and efficiently as possible.

It’s called a Mac Book Pro. Pro. For professionals. I’ve worked under the assumption that professionals were interchangeable with developers. After multiple weeks of usage, I can’t see how a developer or a writer would choose the Mac Book Pro.

Neofreydizma – a term that combines the various schools of Freudianism, arising since the 1940s. (Primarily in the US). The common feature of these schools was the departure from Freud and the hegemony of the individual in his theory in the direction of recognition of the priority of social relations. Hence the desire to enrich the achievements of sociology Freudianism, which translates into “sociologization” psychology “psychologization” sociology. The starting point for neo-Freudianism can be regarded as the dissemination of ideas separated from Freud, Alfred Adler (inferiority complex, “will to power”, “social interest”) and CG Jung (collective unconscious), which sometimes is referred to the neo-Freudianism. The largest representative’s neo Freyd – Erich Fromm, Karen Horney, K. G. Sullivan, tend to it as Margaret Mead, E. Erickson et al.

Horney stressed the importance for the formation of anxiety neurosis that occurs in childhood when faced with a hostile outside world and lack of love of parents and entourage, resulting in internal conflicts and the struggle for self-realization (Horney, 1995, 2008, 2009, 2014). Erich Fromm also saw the origins of neurosis at odds with the world around them that creates a sense of loneliness and automatic conformism (Fromm 1966, 1986). G. Sullivan rejected the priority of Freudian libido, the main component of the system of the person admitted dynamisms (special “energy patterns”), which appear in the communications, ensuring the satisfaction of individual needs (Hall, Lindsay, 1997). American neo-Freudians E. Byrne attached special importance to the game as a form of interpersonal communication in the structure of the “I” singled out “child” state “parent” and “adult”, entering into the transaction with the respective state of the other person, created scenic personality theory, according to which the fate of identity is determined by its role in the life scenarios, interpersonal relationships (Bern, 1996). Thus Neo-Freudians go beyond the boundaries of Freudian psychoanalysis, making a contribution to sociological research (primarily in the sociology of small groups), giving them a psychological basis.

Apart stands the figure of the French “post Freyd” J. Lacan, who proclaimed “return to Freud”, although his theory of the “mirror stage” as a Function “I” (Lacan, 1999; Lacan, 2015) and the idea of structuring the unconscious on the model of the language also increase social significance of psychoanalysis.

His version was proposed and neo Freyd Freudo-Marxism.

In American literature on youth trail neo Freyd particularly noticeable. In the Russian literature, it took place in the 1920s. When Freyd and Marksizm trend in youth research has been very active (AB Zalkind et al.). In recent decades, the application of Neo-Freudian conceptual scheme for the study of Russian youth is rare. Jobs TN Bukhtiyarova, who studied in the aspect of sociology behavior of the Russian youth relying on theoretical and methodological arsenal of Karen Horney (Bukhtiyarova, 2006) – One of the few exceptions.

The post Neo-Freudianism appeared first on BookRiff.

@eddelbuettel’s idea is a good one. (it’s a quick read…jump there and come back). We’ll avoid confusion and call it R⁶ over here. Feel free to don the superclass.

I often wait for a complete example or new package announcement to blog something when a briefly explained snippet might have sufficient utility for many R users. Also, tweets are fleeting and twitter could end up on the island of misfit social media sites if it can’t generate revenue or find a giant buyer this year. Don’t get me wrong, twitter convos are fine/useful, but blogs are at least semi-permanent, especially if you let them be hoovered up by the Internet Archive (“Save Page Now” on their site or use this handy Chrome extension).

I’ll tag all R⁶ posts as “r6” if you want to auto-filter those out of your stream or just page through them.

I’ll also lead off the these micro-posts with a simple one: adding progress bars to your tidyverse purrr operations.

The purrr::map* functions enable expressive and type-safe vectorized operations. Mine are usually over a few million/billion IPv4 addresses or domain names/URLs and often involve moderately lengthy tasks so I usually add the ability to incorporate progress bars to functions I make (and, I’m trying hard to get out of the bad habit of long-ish anonymous functions in purrr calls). The following is a toy example, but it’s a working example you can run in your interactive R session now:

library(tidyverse)

arduously_long_nchar <- function(input_var, .pb=NULL) {
  
  if ((!is.null(.pb)) && inherits(.pb, "Progress") && (.pb$i < .pb$n)) .pb$tick()$print()
  
  Sys.sleep(1)
  
  nchar(input_var)
  
}

pb <- progress_estimated(length(letters))

map_int(letters, arduously_long_nchar, .pb=pb)

And, yes, I did make you wait ~26 seconds (unless you were intrepid enough to reduce the amount of sleep time :-)

If you happen to forget the progress bar object (or know you don’t need one):

map_int(letters, arduously_long_nchar)

the function still works (sans progress bars).

If you happen to also mess up what you pass in to the .pb parameter or get your progress bar out of sync with your object it won’t error out on you (it can be made much safer and wrapped in another function, say — tick_off(.pb) — but this is supposed to be a small post).

Comments/feedback/your-own-progress-methods are most welcome and encouraged.

Freenet is an anonymous, secure, distributed datastore. I've written about using Freenet before, including using it as the backend for static websites. In this post I'll demonstrate how to use the Freenet API to push data into the Freenet network and retrieve data from it.

Unfortunately the freenet protocol documentation is in a state of flux as it moves from a previous wiki to a github based wiki. This means some of the protocol information may be incomplete. The old wiki data is stored in Freenet under the following keys:

• CHK@San0hXZSyCEvvb7enNUIWrkiv8MDChn8peLJllnWt4s,MCNn4eUbl5NW9quOm4JTU~0rsWu6QlIdek9VtpFpXe4,AAMC--8/freenetproject-oldwiki.tar
• CHK@4sff2MgvexbsfgSuqNOwqVDkP~GaZPsZ1rJVKUg87g8,unU3TZ93pYGYPCoH7LC53dlc5~Rmar8SKF9fsZnQX-8,AAMC--8/freenetproject-wiki.tar

The API for external programs to communicate with a running Freenet daemon is FCPv2. It's a text based protocol accessed using a TCP socket connection on port 9481. The FCP protocol can be enabled or disabled from the Freenet configuration settings but it is enabled by default so the examples here should work in a default installation.

The basic protocol of FCP uses a unit called a 'message'. Messages are sent over the socket starting with a line for the start of the message, followed by a series of 'Key=Value' lines, and ending the message with 'EndMessage'. Some messages containing binary data and these end differently and I'll discuss this after some basic examples.

For the examples that follow I'll be using bash. I debated picking from my usual toolkit of obscure languages but decided to use something that doesn't require installation on Linux and Mac OS X and may also run on Windows 10. The examples should be readable enough for non-bash users to pick up and translate to their favourite language, especially given the simplicity of the protocol. I've found the ability to throw together a quick bash script to do inserts and retrievals to be useful.

Hello

The FCPv2 documentation lists the messages that can be sent from the client to the Freenet node, and what can be expected to be received from the node to the client. On first connecting to the node the client must send a ClientHello message. This looks like:

ClientHello
Name=My Client Name
ExpectedVersion=2.0
EndMessage

The Name field uniquely identifies the client to the node. Disconnecting and reconnecting with the same Name retains access to a persistent queue of data being inserted and retrieved. An error is returned if an attempt to connect is made when a client with the same Name is already connected.

The node returns with a NodeHello Message. This looks like:

NodeHello
Build=1477
ConnectionIdentifier=...
...
EndMessage

The various fields are described in the NodeHello documentation. This interaction can be tested using netcat or telnet:

$ nc localhost 9481
ClientHello
Name=My Client Name
ExpectedVersion=2.0
EndMessage

NodeHello
CompressionCodecs=4 - GZIP(0), BZIP2(1), LZMA(2), LZMA_NEW(3)
Revision=build01477
Testnet=false
...
ExtRevision=v29
EndMessage

You can connect to a socket from bash using 'exec' and file redirection to a pseudo-path describing the tcp socket. See HACKTUX notes from the trenches for details. The above netcat interaction looks like this from bash:

#! /bin/bash
    function wait_for {
      local line
      local str=$1
      while read -r line
      do
        >&2 echo "$line"
        if [ "$line" == "$str" ]; then
          break
        fi
      done
    }
       
    exec 3<>/dev/tcp/127.0.0.1/9481
       
    cat >&3 <<HERE
    ClientHello
    Name=My Client Name
    ExpectedVersion=2.0
    EndMessage
    HERE
       
    wait_for "NodeHello" <&3
    wait_for "EndMessage" <&3
       
    exec 3<&-
    exec 3>&-

The exec line opens a socket on port 9481, the FCP port, and assigns it to file descriptor '3'. Then we use cat to write the ClientHello message to that file descriptor. wait_for reads lines from the socket, displaying them on standard error (file descriptor '2'), until it reaches a specifc line passed as an argument. Here we wait for the NodeHello line and then the EndMesage line to cover the NodeHello response from the server. The remaining two exec lines close the socket.

The full bash script is available in hello.sh.

Retrieving data inline

The FCP message ClientGet is used to retrieve data stored at a specific key. The data can be returned inline within a message or written to a file accessable by the node. An example message for retrieving a known key is:

ClientGet
URI=CHK@otFYYKhLKFzkAKhEHWPzVAbzK9F3BRxLwuoLwkzefqA,AKn6KQE7c~8G5dLa4TuyfG16XIUwycWuFurNJYjbXu0,AAMC--8/example.txt
Identifier=1234
Verbosity=0
ReturnType=direct
EndMessage

This retrieves the contents of a particular CHK key where I stored example.txt. The Verbosity is set to not return any progress messages, just send messages when the entire contents are retrieved. A ReturnType of direct means return the data within the AllData message which is received when the retrieval is complete. The result messages are:

DataFound
Identifier=1234
CompletionTime=1490614072644
StartupTime=1490614072634
DataLength=21
Global=false
Metadata.ContentType=text/plain
EndMessage

AllData
Identifier=1234
CompletionTime=1490614072644
StartupTime=1490614072634
DataLength=21
Global=false
Metadata.ContentType=text/plain
Data
Hello Freenet World!

The first message received is DataFound giving information about the completed request. The following message, AllData, returns the actual data. Note that it does not include an EndMessage. Instead it has a Data terminator followed by the data as a sequence of bytes of length DataLength.

To process AllData from bash I use a function to extract the DataLength when it finds it:

    function get_data_length {
      local line
      while read -r line
      do
       if [[ "$line" =~ ^DataLength=.* ]]; then
         echo "${line##DataLength=}"
         break
       fi
      done
    }

This is called from the script after the ClientHello and NodeHello exchange:

    cat >&3 <<HERE
    ClientGet
    URI=CHK@otFYYKhLKFzkAKhEHWPzVAbzK9F3BRxLwuoLwkzefqA,AKn6KQE7c~8G5dLa4TuyfG16XIUwycWuFurNJYjbXu0,AAMC--8/example.txt
    Identifier=1234
    Verbosity=0
    ReturnType=direct
    EndMessage
    HERE
        
    wait_for "AllData" <&3
    len=$(get_data_length <&3)
    wait_for "Data" <&3
    dd status=none bs="$len" count=1 <&3 >&2

The dd command reads the specified number of bytes from the socket and outputs it to standard output. This is the contents of the key we requested:

$ ./getinline
Hello Freenet World!

The full bash script is available in getinline.sh.

The main downside of using inline data requests is that large files can exhaust the memory of the node.

Request Direct Disk Access

A variant of ClientGet requests the node to write the result to a file on disk instead of sending it as part of the AllData message. This is useful for large files that don't fit in memory. The data is written to the filesystem that the node has access to so it's most useful when the FCP client and the freenet node are on the same system.

Being able to tell the server to write directly to the filesystem is a security issue so Freenet requires a negotiation to happen first to confirm that the client has access to the directory that you are requesting the server to write to. This negotiation requirement, known as TestDDA can be disabled in the configuration settings of the node but it's not recommended.

First the client must send a TestDDARequest message listing the directory it wants access to and whether read or write access is being requested.

TestDDARequest
Directory=/tmp/
WantWriteDirectory=true
WantReadDirectory=true
EndMessage

The server replies with a TestDDAReply:

TestDDAReply
Directory=/tmp/
ReadFilename=/tmp/testr.tmp
WriteFilename=/tmp/testw.tmp
ContentToWrite=RANDOM
EndMessage

The script should now write the data contained in the ContentToWrite key into the file referenced by the WriteFilename key. It should read the data from the file referenced in the ReadFilename key and send that data in a TestDDAResponse:

TestDDAResponse
Directory=/tmp/
ReadContent=...content from TestDDAReply...
EndMessage

The server then responds with a TestDDAComplete:

TestDDAComplete
Directory=/tmp/
ReadDirectoryAllowed=true
WriteDirectoryAllowed=true
EndMessage

Once that dance is complete then put and get requests can be done to that specific directory. The bash code for doing this is:

    cat >&3 <<HERE
    TestDDARequest
    Directory=/tmp/
    WantWriteDirectory=true
    WantReadDirectory=true
    EndMessage
    HERE
    
    wait_for "TestDDAReply" <&3
    content=$(process_dda_reply <&3)
    
    cat >&3 <<HERE
    TestDDAResponse
    Directory=/tmp/
    ReadContent=$content
    EndMessage
    HERE
    
    wait_for "TestDDAComplete" <&3
    process_dda_complete <&3

It uses a helper function process_dda_reply to handle the TestDDAReply message from the server:

    function process_dda_reply {
      local readfile=""
      local writefile=""
      local content=""
    
      while read -r line
      do
       if [[ "$line" =~ ^ReadFilename=.* ]]; then
         readfile="${line##ReadFilename=}"
       fi
       if [[ "$line" =~ ^WriteFilename=.* ]]; then
         writefile="${line##WriteFilename=}"
       fi
       if [[ "$line" =~ ^ContentToWrite=.* ]]; then
         content="${line##ContentToWrite=}"
       fi
       if [[ "$line" == "EndMessage" ]]; then
         echo -n "$content" >"$writefile"
         cat "$readfile"
         break
       fi
      done
    }

This function reads the fields of the TestDDAReply and writes the required content to the write file and returns the data contained in the read file. This returned data is sent in the TestDDAResponse. The process_dda_complete function checks the TestDDAComplete fields to ensure that access was granted. The full bash script is available in testdda.sh.

Retrieving data to disk

The ReturnType field of the ClientGet message can be set to disk to write directly to a disk file once the TestDDA process is complete. The message looks like this:

    cat >&3 <<HERE
    ClientGet
    URI=CHK@HH-OJMEBuwYC048-Ljph0fh11oOprLFbtB7QDi~4MWw,B~~NJn~XrJIYEOMPLw69Lc5Bv6BcGWoqJbEXrfX~VCo,AAMC--8/pitcairn_justice.jpg
    Identifier=1234
    Verbosity=1
    ReturnType=disk
    Filename=/tmp/pitcairn_justice.png
    EndMessage
    HERE

In this case we're retreving a file I've inserted previously. The Verbosity key is set to 1 to enable SimpleProgress messages to be received. These messages contain fields showing the total number of blocks that can be fetched for that file, the required number of blocks that we need to get, how many we've successfully retrieved so far, and a few other fields. The following bash function processes this and prints the result:

    function handle_progress {
      local total=0
      local succeeded=0
      local required=0
      local final=""
    
      while read -r line
      do
       if [[ "$line" =~ ^Total=.* ]]; then
         total="${line##Total=}"
       fi
       if [[ "$line" =~ ^Required=.* ]]; then
         required="${line##Required=}"
       fi
       if [[ "$line" == "FinalizedTotal=true" ]]; then
         final="final"
       fi
       if [[ "$line" =~ ^Succeeded=.* ]]; then
         succeeded="${line##Succeeded=}"
       fi
       if [[ "$line" == "EndMessage" ]]; then
         echo "Progress: retrieved $succeeded out of $required required and $total total ($final)"
         break
       fi
      done
    }

The FinalizedTotal field indicates if the Total field is accurate and will not change. Otherwise that field can increase as more knowledge about the file is gained. The Required field is the number of blocks that need to be received to reconstruct the file. It is less than Total due to redundancy in the way freenet stores data to account for nodes going away and data being lost.

The handle_progress function is called from within wait_with_progress, which waits for a particular message (usually the one indicating the end of the transfer), displays progress, and ignores everything else.

    function wait_with_progress {
      while read -r line
      do
        if [ "$line" == "SimpleProgress" ]; then
          handle_progress
        fi
        if [ "$line" == "$1" ]; then
          break
        fi
      done
    }

These are called as follows:

    cat >&3 <<HERE
    ClientGet
    URI=CHK@HH-OJMEBuwYC048-Ljph0fh11oOprLFbtB7QDi~4MWw,B~~NJn~XrJIYEOMPLw69Lc5Bv6BcGWoqJbEXrfX~VCo,AAMC--8/pitcairn_justice.jpg
    Identifier=1234
    Verbosity=1
    ReturnType=disk
    Filename=/tmp/pitcairn_justice.png
    EndMessage
    HERE
    
    wait_with_progress "DataFound" <&3
    wait_for "EndMessage" <&3

The DataFound message is sent by the server when the file has been successfully retrieved. It can be found at the location specified in the Filename field of the ClientGet.

The full bash script is available in getdisk.sh.

$ bash getdisk.sh
Progress: retrieved 0 out of 1 required and 1 total ()
Progress: retrieved 1 out of 1 required and 1 total ()
Progress: retrieved 1 out of 5 required and 10 total ()
Progress: retrieved 1 out of 5 required and 10 total (final)
Progress: retrieved 5 out of 5 required and 10 total (final)

Inserting Data Inline

When storing data using FCP you can provide the data directly in the message or reference a file on disk that the node will read and store. They are both done using the ClientPut message. Sending this message looks like:

    file="$1"
    size=$(stat -c%s "$file")
    mime=$(file --mime-type "$file" |awk '{print $2}')
    
    cat >&3 <<HERE
    ClientPut
    URI=CHK@
    Metadata.ContentType=$mime
    Identifier=1234
    Verbosity=1
    GetCHKOnly=false
    TargetFilename=$(basename "$file")
    DataLength=$size
    UploadFrom=direct
    Data
    HERE
    
    dd status=none if="$file" bs="$size" count=1 |pv -L 500k >&3
    
    wait_with_progress "PutSuccessful" <&3
    uri=$(get_uri <&3)
    wait_for "EndMessage" <&3

ClientPut requires the mime type of the file and this is obtained using file. The size of the file is retrieved with stat. These are placed in the ClientPut message directly. The binary data for the file needs to be sent after a Data terminator similar to how we retrieved the data when doing an inline get. dd is again used for this but it's piped to pv to limit the data transfer rate otherwise the network gets swamped due to buffer bloat.

The URI for inserting is generated as a CHK key. This is a key based on a hash of the file content. Inserting the same file will result in the same key. get_uri reads the PutSuccessful message to find the full key of the insert. This is displayed to the user later in the script.

The full bash script is available in putinline.sh.

$ bash putinline.sh /tmp/example.txt 
Progress: inserted 0 out of 1 ()
Progress: inserted 0 out of 2 ()
Progress: inserted 0 out of 2 (final)

Inserting Data from Disk

Inserting data directly from a disk file works very similar to requesting from a disk file. It requires the TestDDA process followed by a ClientPut using a UploadFrom set to disk:

    cat >&3 <<HERE
    ClientPut
    URI=CHK@
    Metadata.ContentType=$mime
    Identifier=1234
    Verbosity=1
    GetCHKOnly=false
    TargetFilename=$(basename "$file")
    Filename=$file
    UploadFrom=disk
    EndMessage
    HERE
    
    wait_with_progress "PutSuccessful" <&3
    uri=$(get_uri <&3)
    wait_for "EndMessage" <&3

The full bash script is available in putdisk.sh.

Other Messages

There are other interesting messages that are useful. Using ClientPut if you set the field GetCHKOnly to true then the file isn't inserted but the CHK key is generated. Since CHK is based on the file contents it will be the same key if the file is inserted using the same mime type, filename and other parameters. This allows generating a key, sending it to a third party and they can start a file retrieval before the file completes inserting. There are security issues with this in that if an attacker knows the key while it is being inserted they may be able to narrow down the location of the inserting node.

Another useful message is GenerateSSK:

GenerateSSK
Identifier=1234
EndMessage

This results in a SSKKeypair reply containing a randomly generated SSK insert and request key:

SSKKeypair
InsertURI=SSK@AK.../
RequestURI=SSK@Bn.../
Identifier=1234
EndMessage

These can be used to insert data with ClientPut by setting the URI to the InsertURI, and retrieved by a third party using the RequestURI as the URI in ClientGet.

ClientPutDiskDir inserts an entire directory. This is the basis of inserting 'Freesites' - Freenet websites. I wrote a mirror.sh utility that mirrors an online website or page and inserts it into Freenet. This is useful for linking to news articles in Freenet without having to leave the Freenet environment. It uses a putdir.sh script that inserts a directory.

Conclusion

The Freenet API has a lot of functionality beyond what I've shown here. I used bash for the examples because it has few dependancies but more robust scripts would be easier in a full featured programming language. I'm not a bash expert and welcome corrections and additions. I've put the code in an fcp-examples github repository.

There are some client libraries with pyFreenet being an example. I recommend the following articles for a deeper dive into Freenet programming:

• Freenet Communication Primitives: Part 1, Files and Sites
• Freenet Communication Primitives: Part 2, Service Discovery and Communication

The music of the final cutscene fades, and my character stands alone in a field. I stare at him and he stares into the sunset. In my world, outside the game, it’s 2 a.m. I’ve stayed up to finish, and now I find myself glancing around, guilty. Guilty not because of the hour, but because of what I do next: The game’s over, but I don’t turn it off.

For years, I’ve been turning to open world role-playing video games — like Skyrim, The Witcher, and Assassin’s Creed — for precisely these moments, the moments when all the “content” promised on the slipcover has been exhausted, all the monsters exterminated, all the magic feathers and orbs of power deposited with their rightful owners, and every corner of the map explored. I am alone with the mechanics of the game. Free at last, I wander around the game world where towns still bustle and their inhabitants shout canned phrases I’ve already heard a hundred times. The in-game day-night cycle continues; but now, with nothing better to do, I notice it differently. Locations where major scenes took place provoke real nostalgia. This part of the game — the illicit, post-story part — is better than anything that might have preceded it in the name of story. In a world empty of fate, gone slack without a narrative, my character, alone and aimless, has a life for the first time.

I discovered this unlikely pleasure by accident when I was a teenager. One of my first video games, called Redguard, took place in a small open world that reminded me of the fantasy books I loved — I didn’t want to leave. After I’d played through the story several times, I started experimenting with other ways to use the game. If you simply jumped off the ship where the final boss battle took place, you found yourself in a wireframe version of the game world where you could pass through walls.

At first I hoped that the game developers had included this possibility on purpose, a trapdoor to the game’s backstage, a secret for the persistent and inquisitive to find. The best thing, I thought, would be to step out of the game’s story into a larger game with a bigger and more complex story. Of course, I hadn’t found a feature; I’d found a bug. The developers would have eliminated it if they had noticed it. But eventually I realized that if they had intended me to escape the game’s narrative, I wouldn’t really be escaping it at all.

Since then I’ve tried to find a way to escape the narrative of every video game I’ve played. These days, that’s why I play.

Even as I learned to pervert open world RPGs into something resembling the freedom of real life, game designers have been striving to destroy the distinction between life and games altogether.

The game industry’s mimetic aspirations touch every level of their product. Today’s hardware renders 2D images on a screen at frame rates that convincingly approximate real 3D motion. These images are composed of textures so complex that they seem, to my screen-addled, myopic eyes, more believable than the blurry beige wall of my own living room. But these visual effects, while impressive, are only the most superficial aspect of the gaming industry’s approximations of life. On the cutting edge, games pursue freedom. They feature stories where players make increasingly consequential choices, and they introduce randomness into the challenges generated for the player, so no two gamers experience quite the same puzzles. Contingency and choice have become the ultimate standard of simulation.

Perhaps the boldest experiment in freedom yet attempted by a game studio is No Man’s Sky, an exploration and survival game that takes place in a universe procedurally generated to include 18 quintillion separate planets. In the game world’s inexhaustible dimensions players can discover and explore places no one else will ever see. Surely this is the perfect embodiment of what I hoped to find when I first snuck away from the final boss battle in Redguard? No; I hate the very idea. The designers of No Man’s Sky have turned freedom into a task, making a game that goes on forever, an inescapable narrative of exploration. I will never play it. Unsurprisingly, many players report a sense of futility while playing No Man’s Sky: It generated enormous anticipation and enormous disappointment.

The freedom game designers seem to want for me and the freedom I want to seize from them are radically different. One freedom concerns choice. Game designers wager that the more they pack into their worlds, and the larger those worlds become, the more a game’s simulation will approximate the freedom of real life. The other freedom concerns autonomy. By exhausting a game’s content, I wager that I’ll find the pleasurably desolate state in which, whatever I do, I’ll be doing it on my own account and for its own sake. The first freedom requires a world built to accommodate it, a sumptuous palette of sanctioned choices; the second freedom depends upon a world it can defy.

“Part of human life escapes from work and reaches freedom,” wrote Georges Bataille: “Play, which is as fascinating as catastrophe, allows you to positively glimpse the giddy seductiveness of chance.” In these two brief lines, he manages to sum up the whole point of my gamer existentialism. Work is effort expended as a means to something else, leisure, a hobby, the maintenance of a family, the freedom of private life; and freedom, by contrast, is effort expended for its own sake. This seems to me a correct and necessary opposition, particularly in a consumer society where the identification of freedom with choice is not merely a metaphysical thesis, but a mystification of unfreedom. We have never been simultaneously so spoiled for choice and so enslaved to work, squeezed for every last drop of productivity at the office and dizzy with things to do at home. Fortunately we have games, play, ways to indulge the irrationality of freedom without destroying society.

Or do we? Thanks to the good-hearted — and from my perspective wrong-headed — efforts of game designers, with every new release it becomes harder for me to reach my post-story game world. It took a month of work to wring out the last drops of story from the RPG I played most recently.

It would be wrong to say that I play games in order to reach the post-story game world: in fact, until I’ve reached that state, I’ve not yet begun to play. The whole trend of game design seems likely to infiltrate this outpost of freedom with new and clever forms of work, to turn the nine to fiver who escapes into his video games into a five to niner at work on his second, virtual job.

Perhaps my pleasure in misusing games has something in common with my childhood love for burrowing into bushes and boxes and beneath piles of dryer-warmed sheets. Or perhaps it is a satisfying metaphor for the over-determined loneliness of a homeschooled nerd. But, honestly, I didn’t really interrogate the pleasure until just a few months ago when I heard that Elon Musk thinks we’re all living in a simulation.

With the insouciance of wealth, Musk made famous in the course of an interview a thought experiment developed 14 years earlier. In 2003 the philosopher Nick Bostrum suggested that a technologically advanced civilization might take it upon themselves to run simulations of their ancestors. For all we know, he suggested, we are such simulations. Ever since Musk took this speculation mainstream, everybody keeps noticing things that suggest to them we’re in a simulation. “Were the Oscars and the Election proof we’re living in a simulation?” asked a recent headline in New York Magazine. Every deja vú, statistically unlikely happenstance, and destabilization of the established order gives rise to a new round of simulation quips — which are, whether flip or not often a telling window into the zeitgeist.

The moments that bring the simulation meme to mind are precisely the moments game designers have committed themselves to eradicating from their games: moments of improbability, repetition, and unreality. The best simulation wouldn’t give itself away, if our own best simulators are anything to go by. Moreover, Bostrum’s thought experiment and Musk’s belief depends upon the assumption that our feeling of reality is indistinguishable from a sufficiently advanced simulation. It makes no sense to point to ostensible glitches in this very advanced simulation to prove that it is a very advanced simulation. So why do we keep making those jokes?

Perhaps because our collective awakening to looming catastrophe fits nicely with the idea that we’re stuck in somebody else’s computer game. Environmental, political, and personal disaster seems increasingly inevitable despite our best efforts. Our dread demands an explanation. The idea that we’re living in a simulation would justify an even deeper feeling: the need to take back control. My private pleasure in wringing freedom from simulations has become a cultural obsession on a much larger scale.

But is the feeling really new? Around 380 BCE, Plato asked his readers to imagine the human mind as a prisoner, tied immovable in a cave, watching shadows on a wall and mistaking them for life. In the 13th century, Bonaventure, a medieval theologian, referred to all creatures as “shadows” and “vestiges.” In 1710, George Berkeley proposed that each thing is an idea in the mind of God. In the 1800s, Percy Bysshe Shelley wrote a sonnet that begins:

Lift not the painted veil which those who live
Call Life: though unreal shapes be pictured there,
And it but mimic all we would believe…

The real question is not why everybody’s joking that we live in a simulation, but why we ever stopped talking about the world’s unreality in the first place.

So we’re entertaining an ancient and perennial notion, and like everyone else who has ever entertained that notion, we face a stark choice. If my experience is anything to go by, the absurdity of finding yourself in a simulation need not issue in despair or acquiescence. There is another possibility: Embracing the existential lesson that absurdity is always an opportunity to stop playing along and find a different way to play. The world is in our hands, simulation or not. Society does not run on rails, and where it seems to do so, it lies within our power to live another way.

The best RPG games are graced with soundtracks that ratchet into trumpets and massed strings when combat is imminent, or ease with pleasant fluting the passage between points in a quest. A soundtrack cleverly melded to player actions makes gameplay cinematic, so you feel as if you are both watching a scripted scene and acting it out yourself. Naturally, I hate this imposition.

So when the story is over and my fun really begins, I like to turn off the music. Not only is it old by then, but it has become ineluctably associated with interpretations of my character’s movement that I choose to reject.

In the sonic space cleared by this adjustment, I hear environmental noises better, the susurrus of virtual breezes, and the crunching of my virtual boot-heels in virtual loam. Maybe it’s because I’m tired and because my ears crave peace at 2 a.m., after a long evening hard at work on a game, but the silence that follows turning off an incessant soundtrack is sweet as only stolen silence can be.

Update (May 18th, 2017): Airfoil for Mac 5.6 restores direct streaming to all models of Apple TV. Get the latest version now from the Airfoil page. It is now safe to update your Apple TV to the latest tvOS.

Summary: To prevent loss of connectivity with Airfoil, Apple TV users should not upgrade to tvOS 10.2 at this time.

On March 27th, Apple released tvOS 10.2 for the latest generation of Apple TV. Changes made by Apple in this update have broken Airfoil’s ability to transmit audio to the newest generation of Apple TV. This issue affects both Airfoil for Mac and Airfoil for Windows, and prevents Airfoil from successfully sending audio to the Apple TV. If your Apple TV is still running tvOS 10.1.1 (or lower), stick with that for now to maintain connectivity with Airfoil.

Next Steps

We’re currently researching this problem, and hope to work around Apple’s changes with a future update. In the meantime, Airfoil users should avoid tvOS 10.2, sticking with their current version of tvOS instead. Be sure to disable automatic updates on the Apple TV as well. You can do this by going to Settings -> System -> Software Updates, and toggling “Automatically Update” to Off.

More to Come

We’ll post more news as soon as we have it, so watch this blog, as well as our Twitter account. When a new version is available, Airfoil itself can alert you, so be sure Software Update is on in the Preferences.

This post is going to help save you money if you're running a Rails server. It starts like this: you write an app. Let's say you're building the next hyper-targeted blogging platform for medium length posts. When you login, you see a paginated list of all of the articles you've written. You have a Post model and maybe for to do tags, you have a Tag model, and for comments, you have a Comment model. You write your view so that it renders the posts:

<% @posts.each do |post| %>
  <%= link_to(post, post.title) %>
  <%= teaser_for(post) %>
  <%= "#{post.comments.count} comments"
<% end %>

<%= pagination(@posts) %>

See any problems with this? We have to make a single query to return all the posts - that's where the @posts comes from. Say that there are N posts returned. In the code above, as the view iterates over each post, it has to calculate post.comments.count - but that in turn needs another database query. This is the N+1 query problem - our initial single query (the 1 in N+1) returns something (of size N) that we iterate over and perform yet another database query on (N of them).

Introducing Includes

If you've been around the Rails track long enough you've probably run into the above scenario before. If you run a Google search, the answer is very simple -- "use includes". The code looks like this:

# before
@posts = current_user.posts.per_page(20).page(params[:page])

and after

@posts = current_user.posts.per_page(20).page(params[:page])
@posts = @posts.includes(:comments)

This is still textbook, but let's look at what's going on. Active Record uses lazy querying so this won't actually get executed until we call @posts.first or @posts.all or @posts.each. When we do that two queries get executed, the first one for posts makes sense:

select * from posts where user_id=? limit ? offset ?

Active Record will pass in user_id and limit and offset into the bind params and you'll get your array of posts.

Note: we almost always want all queries to be scoped with a limit in production apps.

The next query you'll see may look something like this:

select * from comments where post_id in ?

Notice anything wrong? Bonus points if you found it, and yes, it has something to do with memory.

If each of those 20 blog posts has 100 comments, then this query will return 2,000 rows from your database. Active Record doesn't know what data you need from each post comment, it'll just know it was told you'll eventually need them. So what does it do? It creates 2,000 Active Record objects in memory because that's what you told it to do. That's the problem, you don't need 2,000 objects in memory. You don't even need the objects, you only need the count.

The good: You got rid of your N+1 problem.

The bad: You're stuffing 2,000 (or more) objects from the database into memory when you aren't going to use them at all. This will slow down this action and balloon the memory use requirements of your app.

It's even worse if the data in the comments is large. For instance, maybe there is no max size for a comment field and people write thousand word essays, meaning we'll have to load those really large strings into memory and keep them there until the end of the request even though we're not using them.

N+1 Is Bad, Unneeded Memory Allocation Is Worse

Now we've got a problem. We could "fix" it by re-introducing our N+1 bug. That's a valid fix, however, you can easily benchmark it. Use rack-mini-profiler in development on a page with a large amount of simulated data. Sometimes it's faster to not "fix" your N+1 bugs.

That's not good enough for us, though -- we want no massive memory allocation spikes and no N+1 queries.

Counter Cache

What's the point of having Cache if you can't count it? Instead of having to call post.comments.count each time, which costs us a SQL query, we can store that data directly inside of the Post model. This way when we load a Post object we automatically have this info. From the docs for the counter cache you'll see we need to change our model to something like this:

class Comment < ApplicationRecord
   belongs_to :post , counter_cache: count_of_comments
  #…
end

Now in our view, we can call:

  <%= "#{post.count_of_comments} comments"  %>

Boom! Now we have no N+1 query and no memory problems. But...

Counter Cache Edge Cases

You cannot use a counter cache with a condition. Let's change our example for a minute. Let's say each comment could either be "approved", meaning you moderated it and allow it to show on your page, or "pending". Perhaps this is a vital piece of information and you MUST show it on your page. Previously we would have done this:

  <%= "#{ post.comments.approved.count } approved comments"  %>
  <%= "#{ post.comments.pending.count } pending comments"  %>

In this case the Comment model has a status field and calling comments.pending is equivalent to adding where(status: "pending"). It would be great if we could have a post.count_of_pending_comments cache and a post.count_of_approved_comments cache, but we can't. There are some ways to hack it, but there are edge cases, and not all apps can safely accommodate for all edge cases. Let's say ours is one of those.

Now what? We could get around this with some view caching because if we cache your entire page, we only have to render it and pay that N+1 cost once. Maybe fewer times if we are re-using view components and are using "Russian doll" style view caches .

If view caching is out of the question due to <reasons>, what are we left with? We have to use our database the way the original settlers of the Wild West did, manually and with great effort.

Manually Building Count Data in Hashes

In our controller where we previously had this:

@posts = current_user.posts.per_page(20).page(params[:page])
@posts = @posts.includes(:comments)

We can remove that includes and instead build two hashes. Active Record returns hashes when we use group(). In this case we know we want to associate comment count with each post, so we group by :post_id.

@posts = current_user.posts.per_page(20).page(params[:page])
post_ids = @posts.map(&:id)
@pending_count_hash   = Comment.pending.where(post_id: post_ids).group(:post_id).count
@approved_count_hash = Comment.approved.where(post_id: post_ids).group(:post_id).count

Now we can stash and use this value in our view instead:

  <%= "#{ @approved_count_hash[post.id] || 0  } approved comments"  %>
  <%= "#{ @pending_count_hash[post.id] || 0 } pending comments"  %>

Now we have 3 queries, one to find our posts and one for each comment type we care about. This generates 2 extra hashes that hold the minimum of information that we need.

I've found this strategy to be super effective in mitigating memory issues while not sacrificing on the N+1 front.

But what if you're using that data inside of methods.

Fat Models, Low Memory

Rails encourage you to stick logic inside of models. If you're doing that, then perhaps this code wasn't a raw SQL query inside of the view but was instead nested in a method.

def approved_comment_count
  self.comments.approved.count
end

Or maybe you need to do the math, maybe there is a critical threshold where pending comments overtake approved:

def comments_critical_threshold?
  self.comments.pending.count < self.comments.approved.count
end

This is trivial, but you could imagine a more complex case where logic is happening based on business rules. In this case, you don't want to have to duplicate the logic in your view (where we are using a hash) and in your model (where we are querying the database). Instead, you can use dependency injection. Which is the hyper-nerd way of saying we'll pass in values. We can change the method signature to something like this:

def comments_critical_threshold?(pending_count: comments.pending.count, approved_count: comments.approved.count)
  pending_count < approved_count
end

Now I can call it and pass in values:

post.comments_critical_threshold?(pending_count: @pending_count_hash[post.id] || 0 , approved_count: @approved_count_hash[post.id] || 0 )

Or, if you're using it somewhere else, you can use it without passing in values since we specified our default values for the keyword arguments.

BTW, aren't keyword arguments great?

post.comments_critical_threshold? # default values are used here

There are other ways to write the same code:

def comments_critical_threshold?(pending_count , approved_count )
  pending_count ||= comments.pending.count
  approved_count ||= comments.approved.count
  pending_count < approved_count
end

You get the gist though -- pass values into your methods if you need to.

More than Count

What if you're doing more than just counting? Well, you can pull that data and group it in the same way by using select and specifying multiple fields. To keep going with our same example, maybe we want to show a truncated list of all commenter names and their avatar URLs:

@comment_names_hash = Comment.where(post_id: post_ids).select("names, avatar_url").group_by(&:post_ids)

The results look like this:

1337: [
  { name: "schneems", avatar_url: "https://http.cat/404.jpg" },
  { name: "illegitimate45", avatar_url: "https://http.cat/451.jpg" }
]

The 1337 is the post id, and then we get an entry with a name and an avatar_url for each comment. Be careful here, though, as we're returning more data-- you still might not need all of it and making 2,000 hashes isn't much better than making 2,000 unused Active Record objects. You may want to better constrain your query with limits or by querying for more specific information.

Are We There Yet

At this point, we have gotten rid of our N+1 queries and we're hardly using any memory compared to before. Yay! Self-five. :partyparrot:. 🎉

Here's where I give rapid-fire suggestions.

• Use the bullet gem -- it will help identify N+1 query locations and unused includes -- it's good.
• Use rack-mini-profiler in development. This will help you compare relative speeds of your performance work. I usually do all my perf work on a branch and then I can easily go back and forth between that and master to compare speeds.
• Use production-like data in development. This performance "bug" won't show until we've got plenty of posts or plenty of comments. If your prod data isn't sensitive you can clone it using something like $ heroku pg:pull to test against, but make sure you're not sending out emails or spending real money or anything first.
• You can see memory allocations by using rack-mini-profiler with memory-profiler and adding pp=profile-memory to the end of your URL. This will show you things like total bytes allocated, which you can use for comparison purposes.
• Narrow down your search by focusing on slow endpoints. All performance trackers list out slow endpoints, this is a good place to start. Scout will show you memory breakdown per request and makes finding these types of bugs much easier to hunt down. They also have an add-on for Heroku. You can get started for free $ heroku addons:create scout:chair

If you want to dig deeper into what's going on with Ruby's use of memory check out the Memory Quota Exceeded in Ruby (MRI) Dev Center article , my How Ruby Uses Memory, and also Nate Berkopec's Halve your memory use with these 12 Weird Tricks.

Over the past decade, theorizing about data and digital mediums has typically been kept to spaces like New Media Studies. The rise of Digital Humanities as a strictly empirical field cuts against this grain in a manner worth examining. Part I: The Hegemony of Data, discusses a longer history of information to evaluate the intuitive sense of objectivity that surrounds “Big Data”. Part II: The Heavens and Hells of the Web examines the initial beliefs in digital messianism as a method of eliminating moral and social problems, how they turned apocalyptic, and what lessons Digital Humanities should take from it. Part III: Digital Epistemology goes beyond critique and builds a sense in which anti-colonial, anti-capitalist, moral visions of a future may benefit and actually advance discourses through our experiences with digital tools and society.

“Epiphany” is a good description of my first encounter with Matthew Jockers’ Macroanalysis in 2014. Having come into the discipline history from a New Atheist Rational euphoric high, Macroanalysis struck me with its possibility for an entirely objective method of history. Jockers emphasized this possibility, by displacing the term “reading” with “analysis.” Where the formerwas entirely too close to problems of selectivity and bias, the latter emphasized the impartial potential of “big [literary] data.” Whereas before, we were all bound by the number of texts we could read in a single lifetime, Macroanalysis invited a more scientific approach to literature:

Today, however, the ubiquity of data, so-called big data, is changing the sampling game. Indeed, big data are fundamentally altering the way that much science and social science get done…

            …These massive digital-text collections are changing how literary studies get done. Close reading is not only impractical as a means of evidence gathering in the digital library, but big data render it totally inappropriate as a method of studying literary history. (p. 7)

The vision of arbitration-by-analysis has struck even the most interpretive of fields with considerable force. This is partially because we were primed for this vision of our future: an aristocracy of numbers where not only research, but also morality, ethics, and politics would be dictated by formulas that transcended mere human interest. That we presently take this reliance on data to religious proportions should invite some curiosity as to how life got to this point; in other words, Jockers’ faith in data asks us to historicize the ascension of data hegemony.

A reasonable starting point for this conversation is the development of the web. For both advocates and opponents, the web represents a requirement for the expansive role that data currently plays in society. That Google now stands in as the paragon of human knowledge only exemplifies the sense that the web was and continues to be essential to the current discussions about the Information Age. But how does our intuition compare to the (recent) history of data itself?

In 1964, the engineer Paul Baran published an eleven-volume proposal titled On Distributed Communications, which evaluated a method of rudimentary network connections between universities, military bases, and corporate labs across the country. Deeply influential to the development of ARPANET some five years later, Baran established many of the first packet switching protocols used to distribute information through a network. Baran’s proposal connected several of these regional networks for the purpose of creating a redundancy of data. This redundancy decentralized data in a manner that could preserve it in the worst-case scenario of nuclear war. If New York was lost in nuclear winter, labs at Berkeley, Chicago, and Texas would retain all the files that scientists and military researchers had collected on the east coast.

The redundancy of data was a useful method to ensure its survivability. (Volume I, p. ii) This aspect of the project was so important that in volume XI, Baran claimed that it was “survivability” that served as their top criterion for the proposal (Volume XI, p. 5). But much like any new technology, its cost was not cheap. Baran estimated a 234 million dollar initial investment cost, with a 60 million dollar annual maintenance estimate for the first ten years of the system; in comparison the Department of Defense had typically budgeted 1 billion a year for communications projects. (Volume X, p. 1-2) The web didn’t lead to the hegemony of data; rather, the hegemony of data led to a demand for the web.

This demand invites us to ask what work data was doing at the time. Three years before Baran submitted his report, President Kennedy appointed the civilian bureaucrat Robert McNamara to Secretary of Defense, an unusual move, given McNamara’s lack of battle experience. Prior to his arrival as the boss of the United States military, McNamara had spent part of WWII using his experience in data analysis with the Air Force: determining, for example, at what altitude to drop bombs in order to maximize enemy casualties and minimize friendly fire. McNamara’s efforts—which became known as “systems analysis”—joined with Abraham Wald’s work in statistical analysis, and Alan Turing’s more famous work in breaking the Enigma code machine, all of which demonstrated the significance of data for rendering military battles more efficient. Against an earlier tradition of warfare in which honor, masculinity, and birthright had all played prominent roles in the development of an aristocratic army, data had transformed war from something waged into something managed.

In the transition to “peace,” the extension of these statistical skills in civilian management seemed only logical, something emphasized by a policy wonk under McNamara. In 1966, E. S. Quade proposed that the work “systems analysis” did for the military should be used to manage civilian affairs as well. While Quade was careful to consistently acknowledge the limitations of the approach, he nevertheless suggested that this approach of efficiency could be used in things like the postman’s route, urban redevelopment, and welfare planning. The goal for these projects would ultimately be efficiency; it set aside questions of morality, instead emphasizing ambiguous utilitarian perspectives on the organization of civil society:

The key to a successful analysis is a continuous cycle of formulating the problem, selecting objectives, designing alternatives, collecting data, building models, weighing cost against performance, testing for sensitivity, questioning assumptions and data, re-examining the objectives, opening new alternatives, building better models and so on, until satisfaction is obtained or time or money force a cutoff. (Quade, 2006, 10-11)

It is here that we see the full stakes of a slow elision between efficiency and morality. The hegemony of data created a very specific vision of the future: data through methodological innovations would consistently produce a society that privileged maximizing efficiency. At best, efficiency ran parallel to moral advancements in society; at worst, it was entirely oblivious to moral visions for a better world. In the context of the war, such efficiency dedicated to the preservation of human life could be wed to an anti-Nazi morality with few problems. In peacetime, the hegemony of data was a lynchpin of US imperialism against the Soviet Union. In other words, its objectivity was only guaranteed insofar as its users took the military power of the United States as an unqualified good.

Corporations were not the only players in this gradual transition from method of management into mode of moral politics. At a 1939 symposium, the economist Frank Knight–a teacher of Milton Friedman–had suggested changing a quote from Lord Kelvin that had been inscribed upon the Social Sciences Building at the University of Chicago to the following: “If you cannot measure, measure anyhow.” Taking up this challenge, the economic historian Robert Fogel arrived at the University of Chicago in 1964, where he began work on the most controversial history book of the late-twentieth century. It was published in 1976 with the title Time on the Cross, which introduced McNamara’s systems-analysis methodology into history and called it “cliometrics.” The book rejected the long-held assumption that slavery stunted capitalism and instead used the analysis of data to argue that plantations had in fact been most profitable immediately before to the Civil War.

Historical debate aside, cliometrics most directly challenged the ways that historical research was undertaken. Much like Jockers, the authors of Time on The Cross–an interdisciplinary, collaborative book if ever one existed–juxtaposed the empirical certainty of plantation data against the interpretive mode of historical research, a mode they associated with the “ideological pressures of writing about the American system of slavery.” Fogel & Stanley Engerman (his co-author of the book) did not deny that interpretation had some role to play in historical work; the cliometrician instead viewed it as a method that should be used sparingly, only where no quantitative data could be produced for analysis and accordingly viewed interpretation as quite close to speculation.

This is, in fact, the climax of contestation under data hegemony. Whereas historians had–and still do, for the most part–elected to perform their work embracing the necessary, ruthless selectivity that comes with distilling centuries of time into hundreds of pages, Fogel and the rising crop of cliometricians instead echoed Knight’s command for the social scientist. The hegemony of data for these folks produced a very different vision of slave society, one in which the plantation became an efficiency-maximizing, rational agent. Sources that emphasized the violence and brutality against slaves were consequently viewed as “exaggerated” and research on such sources as “ideological.”

It is worth taking seriously how Fogel & Engerman conceived of slave agency to see how deeply the language of efficiency pervaded their work. Less a pathological racism that saw African Americans and slaves as subhuman, they actually conceived themselves as “rescuing” African Americans from history through an account of their ingenuity and industriousness as slaves:

The typical slave fieldhand was not lazy, inept, and unproductive. On average, he was harder-working and more efficient than his white counterpart. (5)

Throughout the text, both authors commit to showing a slave capable of becoming efficient through an assimilation and transformation of the Protestant Work Ethic. The question of whether or not efficiency is a good manner of measuring human worth is never raised. While both authors had retracted their perspectives on violence on the plantations by the 1980s, this vision of demonstrating “rationality” and “efficiency” for a group of marginalized people in order to account for their history was only possible in a world where such quantitative data was the only objective method to describe them. In other words, the question of whether slavery was a moral good was a question that conveniently fell outside the purview of the data analyst.

This is a lasting influence of the transition from interpretation to analysis. In a heavily-critiqued piece published last year on the Digital Humanities, David Golumbia, Daniel Allington & Sarah Brouillette argued precisely that this was the general, if subconscious direction of the DH field: fetishize the collection of data, program for the analysis, cease interpretation. Despite all the critiques, very few respondents addressed directly the issue of data-collection, except to again proselytize about the natural power of big data. At this point, it should be clear that this naturalization had always been a political process, despite the best efforts of Jockers to render literary studies an analytical, objective science.

Historicizing the role of data has given us a feel for the tension that existed between the gathering of information and the subsequent loss of a particular political imagination. On a whole, many proponents of the Digital Humanities field think even less critically than Matthew Jockers about the limits and possibilities of digitization in disciplines like literature, history, and anthropology. Instead, many of the textbooks that introduce programming and data collection into these fields typically trot out lines about the radical accessibility, dynamic possibilities, or digital revolution. These clichés have long since played out in fields like New Media Studies or Game Studies, where astute critics like Lisa Nakamura have pointed out that being online did not eliminate social or political inequalities offline. The humbling of digital utopia in these fields ought to ensure Digital Humanities ask itself a question: what interpretive work is being done in the collection, systematization, digitization, and publication of literary and historical data, and what are we losing in the process? It is at the intersection on this question between these fields that Part II will turn.

I would like to thank Sarah Brouillette for reading an early draft of this piece. I would also like to point towards two more sources asking particularly good questions on this front: the first is Bernard Harcourt’s 2011 Aims of Education speech titled “Questioning the Authority of Truth” from which I first learned of Robert McNamara’s story. Second is Lara Putnam’s 2016 AHR article “The Transnational and the Text Searchable,” which critically theorizes the role of digital sources and searches in the pursuit of historical research. 

Marley-Vincent Lindsey is a doctoral student in history at Brown. He tweets on occasion.

I’ve been curious about how Surrey will evolve ever since former mayor Dianne Watts set out to transform the city’s image and its reality.

Besides the music festivals and the beautification and the stunning new pools and other facilities built in the city, Watts also promised to create a downtown for Surrey out of almost literally nothing.

It’s been 10 years since she started talking about that. I took a closer look at what kind of development there has been — and what hasn’t arrived yet.

There are towers here and there, none of them yet forming a critical mass that feels urban. And there seems to have been a pause in development.

Some of that delay is because certain property owners are waiting to see exactly what the alignment of the new light-rail transit line will be.

But one Surrey watcher wrote to me afterwards with these observations.

Besides, as the story noted, a certain drop-off in energy and boosterism characteristic of the Watts noted, this writer said:

The other problem with slow growth in the City Centre is the lack of focus and the fact that this Council seems more concerned about courting political favour in neighbourhoods and with developers who want to build elsewhere. Also, the City Centre Plan covers too large an area. Even the Anthem property, across King George Boulevard, seems like it is in an area too distant from where development should be concentrated.

Finally, a lot of developers are waiting to learn what will happen with transit in Surrey City Centre. Everyone seems confident that LRT is coming, but station locations have shifted a few times and I believe the reason was that they were trying to accommodate larger station platforms to show that they can have longer trains and compete with SkyTrain, likely in response to some in Victoria who are pushing to replace the LRT plan with SkyTrain. This uncertainty, I believe, may have delayed some development.

This story came my way in the most random way. I was at the B.C. Non-Profit Housing Association dinner last fall and talking to the man across the table who, it turned out to be the CEO of the Community Living Society.

So what, I asked Ross Chilton, is the big story in your world? He said: the problem of finding housing for people with developmental disabilities.

As I started on this story, I was surprised to discover that those with developmental disabilities don’t get any kind of priority status for subsidized units — in fact, they get fewer “points” because they’re not at risk of homelessness (since their parents are usually heavily involved in helping them out). And they don’t get any kind of extra subsidy for housing — just the standard $375 a month that is the allowance for anyone on disability or welfare.

My story is here, with some really compelling stories from parents about what they have gone through to try to ensure that their adult children get set on the path to independent living.

One of the ways to advance as a software engineer is to be in charge of something, such as a one-time project like implementing a new feature or leading a software release, or an ongoing task such as triaging incoming bugs or analyzing crash reports.

One thing that makes it more likely that you'll be in charge of something is if others trust you to be in charge of that. And you're more likely to be trusted if you've consistently behaved like somebody who is responsible for that thing or similar things.

So what does being responsible look like? Largely, it looks like the behavior you'd expect from a project owner, i.e., the way you'd expect the person in charge of the project to behave. In other words, I think it helps to think of yourself as having the responsibility of the project's owner. (But, at the same time, remember that perhaps you don't, and collaborate with others.) Let's look at two specific examples.

First, what do responsibility and ownership look like for somebody doing triage of incoming bugs? One piece is to encourage more and better bug reports by acting in ways that acknowledge the bug reporter's contribution, such as: making the reporter feel their concerns are heard, not making the reporter waste their time, and improving the bug report on the way (making the summary accurate, adding clearer or simpler testcases, etc.). Another is taking responsibility and following up to make sure important things are handled, and to make it clear that you're doing so. When you do this (or many other things), it's important to make appropriate commitments: don't commit to things if you can't honor the commitment, but avoiding committing to anything is a failure to take responsibility.

Second, what do responsibility and ownership mean for somebody writing code? I think one big piece is that you should do the things you'd do if you were the sole maintainer of the code before you submit it for review. That is, submit code for review when you're actually confident it's ready to be part of the codebase. This implies doing many things, from high level tasks like having a clear model of what the code is supposed to do, to having appropriate tests, assertions, and structure that make future modifications easier and reduce their risk, to more low-level things like looking at all the callers of a function when a change you make to what the function does requires doing so.

Another big piece of responsibility when writing code is taking responsibility for and fixing the problems that you cause. (As you take on more responsibility, you might find others to help you do this, but you're still responsible for it.) How to do this depends on the seriousness of the problems. It sometimes means temporarily reverting the changes while figuring out the longer term fix. In other cases it means writing patches for serious problems promptly. And in less serious cases a quick response may not be needed, but it's useful to communicate that you've concluded the problem is lower priority in case others have a different view of the seriousness.

Having engineers exercise responsibility and ownership in this way is important because having more engineers take responsibility makes a project run better. So it's a characteristic that I like to see in software engineers and one of the characteristics that defines what I see as a good engineer.

Like Michael, I find the Touch Bar to be less than optimal – and after around three months of use, I’m ready to pass judgment on it.

The only reason I don’t rant about the Touch Bar constantly is that I’ve replaced Esc with other key combinations whenever possible (Ctrl-C works well enough in vim, for instance), and that I still rely on an (AA-powered) Apple Wireless Keyboard at my desk.

I will get used to it (just like I got used to touch typing at a fair clip on an iPad mini, but it is still a poor replacement for function keys, and buggier than a bait store (a day doesn’t go by without it obscuring the center set of “buttons” with a black rectangle for some reason).

In short, it is a flawed attempt at innovation – neither good enough to stand on its own, nor effective enough as a credible replacement for standard keys.

Nicky Case, whose projects to simulate segregation and systems with emoji you might recognize, likes to think in systems. Piece together steps and objects, and let them interact with each other using various probabilities and weights. Simulate. See what happens.

Case’s newest project, LOOPY, is a tool to build your own systems. No programming required. Just click-and-drag things and press play.

Tags: simulation

Following yesterday's release of iOS 10.3, which introduced the ability for developers to respond to App Store reviews, Apple has released official guidelines for how developer's can best craft responses.

The ideal response is concise and clearly addresses your customer's feedback. Communicate in the tone of your brand, and use terminology your target audience will appreciate and understand. If multiple people in your company can reply to reviews for your app, they should use a similar voice and style. Make sure your replies follow Apple’s Terms and Conditions, which prohibits using profanity, posting users’ personal information, and spamming.

The guidelines also recommend:

• Always providing individualized responses, even if only by pairing a personalized introduction with a more generic response.
• Soliciting feedback from users regarding what they'd like to see in future updates.
• Replying to reviews in a timely, consistent manner.
• Prioritizing responses based on a review's apparent level of importance.
• Writing release notes for app updates that specifically address issues mentioned in past reviews, and letting those past reviewers know of the update.
• Staying on topic with the issue raised by a review; no using replies as a means of advertisement.

Besides these guidelines from Apple, as App Store responses have gone live for the first time, more details have come out concerning how those reviews will work.

It appears that every reply submitted by a developer goes through some sort of review process before it is posted to the App Store. In the following tweet's screenshot, you can see a 'Pending' tag on the developer's review.

It was previously unknown how users would be notified when a developer responds to their App Store review. Although a notification from the App Store app seemed a possibility, Apple has instead chosen to go the route of email notifications. Those emails include a link with the option for reviewers to update their original review.

Support MacStories Directly

Club MacStories offers exclusive access to extra MacStories content, delivered every week; it’s also a way to support us directly.

Club MacStories will help you discover the best apps for your devices and get the most out of your iPhone, iPad, and Mac. Plus, it’s made in Italy.

Back when I was an actual Marxist, we used to talk about the “contradictions of capitalism”. It’s actually a handy phrase (alliterative too!) and recently I feel like the Internet is trying to stuff those contradictions down my throat.

Fish in a barrel

It’s not exactly hard to reel them off. Item: The owners of every business are incented to pay their employees as little as possible, but need their customers to have spare money in their pockets. Item: Prosperity depends on growth, everyone knows that; but we’re using our ecosystem fully and population curves around the world range from flattening growth to steepening decline.

See how easy it is?

Engagement in the clouds

Two pieces crossed my radar recently. First, Gartner recently released its annual State of the American Workplace report, a weighty slab of PDF you have to trade your email address for, but there’s a decent summary with some graphs over on LinkedIn.

The news isn’t good. It turns out that that only about 30% of American employees are “engaged”; of the rest, 50% or so are “disengaged” and 16% are “actively disengaged”. And there’s loads of quantitative data to show that lack of engagement correlates with lack of growth, profits, and other good-biz metrics.

Put another way: Scott Adams may be an annoying weaselly troll, but Dilbert is accurate reportage.

Now cast your eyes at The Future Of Labor by Fred Wilson, New York VC and Thought Leader; he discusses “three big megatrends impacting the future of labor/work”, one of which is “ the move to an on demand model for work”. He envisions a future where, when a business needs something done, “they issue the work order to the labor cloud and someone picks up the work order and gets it done.” This allows the business “to get the work done without thinking about the kind of relationship they have with the worker.”

Obviously, no sane manager should expect “engagement” from the denizens of the “labor cloud”, any more than they can from the growing chunk of the population working for low pay in permanent-part-time mode. See? Contradiction!

Hunger

You want real contradiction? How about 11 Facts About Hunger in the US. The US, you know, Earth’s richest nation. Where 17.5 million households are “food insecure”.

I don’t miss Marxism as a framework, but let’s not kid ourselves that the symptoms it was trying to address are behind us.